comunicación - siemens ag · industrial ethernet security con cp 1543-1 13 . siemens ag division...

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

___________________

SIMATIC

S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro Comunicación

Manual de funciones

12/2017 A5E03735817-AF

Prólogo

Guía de la documentación 1

Descripción del producto 2

Servicios de comunicación 3

Comunicación PG 4

Comunicación HMI 5

Open User Communication 6

Comunicación S7 7

Acoplamiento punto a punto 8

Comunicación OPC UA 9

Routing 10

Recursos de conexión 11

Diagnóstico de conexiones 12

Industrial Ethernet Security con CP 1543-1

13

Siemens AG Division Digital Factory Postfach 48 48 90026 NÜRNBERG ALEMANIA

A5E03735817-AF Ⓟ 01/2018 Sujeto a cambios sin previo aviso

Copyright © Siemens AG 2013 - 2017. Reservados todos los derechos

Notas jurídicas Filosofía en la señalización de advertencias y peligros

Este manual contiene las informaciones necesarias para la seguridad personal así como para la prevención de daños materiales. Las informaciones para su seguridad personal están resaltadas con un triángulo de advertencia; las informaciones para evitar únicamente daños materiales no llevan dicho triángulo. De acuerdo al grado de peligro las consignas se representan, de mayor a menor peligro, como sigue.

PELIGRO Significa que, si no se adoptan las medidas preventivas adecuadas se producirá la muerte, o bien lesiones corporales graves.

ADVERTENCIA Significa que, si no se adoptan las medidas preventivas adecuadas puede producirse la muerte o bien lesiones corporales graves.

PRECAUCIÓN Significa que si no se adoptan las medidas preventivas adecuadas, pueden producirse lesiones corporales.

ATENCIÓN Significa que si no se adoptan las medidas preventivas adecuadas, pueden producirse daños materiales.

Si se dan varios niveles de peligro se usa siempre la consigna de seguridad más estricta en cada caso. Si en una consigna de seguridad con triángulo de advertencia de alarma de posibles daños personales, la misma consigna puede contener también una advertencia sobre posibles daños materiales.

Personal cualificado El producto/sistema tratado en esta documentación sólo deberá ser manejado o manipulado por personal cualificado para la tarea encomendada y observando lo indicado en la documentación correspondiente a la misma, particularmente las consignas de seguridad y advertencias en ella incluidas. Debido a su formación y experiencia, el personal cualificado está en condiciones de reconocer riesgos resultantes del manejo o manipulación de dichos productos/sistemas y de evitar posibles peligros.

Uso previsto de los productos de Siemens Considere lo siguiente:

ADVERTENCIA Los productos de Siemens sólo deberán usarse para los casos de aplicación previstos en el catálogo y la documentación técnica asociada. De usarse productos y componentes de terceros, éstos deberán haber sido recomendados u homologados por Siemens. El funcionamiento correcto y seguro de los productos exige que su transporte, almacenamiento, instalación, montaje, manejo y mantenimiento hayan sido realizados de forma correcta. Es preciso respetar las condiciones ambientales permitidas. También deberán seguirse las indicaciones y advertencias que figuran en la documentación asociada.

Marcas registradas Todos los nombres marcados con ® son marcas registradas de Siemens AG. Los restantes nombres y designaciones contenidos en el presente documento pueden ser marcas registradas cuya utilización por terceros para sus propios fines puede violar los derechos de sus titulares.

Exención de responsabilidad Hemos comprobado la concordancia del contenido de esta publicación con el hardware y el software descritos. Sin embargo, como es imposible excluir desviaciones, no podemos hacernos responsable de la plena concordancia. El contenido de esta publicación se revisa periódicamente; si es necesario, las posibles correcciones se incluyen en la siguiente edición.

Comunicación Manual de funciones, 12/2017, A5E03735817-AF 3

Prólogo

Finalidad de la documentación El presente manual de funciones proporciona una vista general de las posibilidades de comunicación que ofrecen las CPU, los módulos y procesadores de comunicación y los sistemas PC de los sistemas SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL y ET 200pro. En el presente manual de funciones se describe la comunicación asíncrona orientada a la conexión.

La documentación trata en detalle:

● Vista general de los servicios de comunicación

● Características de los servicios de comunicación

● Resumen de las actividades que debe realizar el usuario para configurar los servicios de comunicación

Conocimientos básicos necesarios Para comprender el manual de funciones se requieren los siguientes conocimientos:

● Conocimientos generales de automatización

● Conocimientos del sistema de automatización industrial SIMATIC

● Conocimientos del manejo de STEP 7 (TIA Portal)

Ámbito de validez de la documentación La presente documentación es válida como documentación básica de todos los productos de los sistemas SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL y ET 200pro. La documentación de los productos se basa en esta documentación.

Prólogo

Comunicación 4 Manual de funciones, 12/2017, A5E03735817-AF

Novedades del manual de funciones Ccomunicación, edición 12/2017 con respecto a la edición 09/2016 Novedades Ventajas para el cliente Dónde encontrar información Nuevos contenidos

OPC UA Companion Specification

La OPC UA Companion Specification permite especificar métodos de forma homogénea y no propietaria. Con estos métodos especificados pueden integrarse aparatos de los más diversos fabricantes en la instalación y en los procesos de producción.

Cap. Uso de modelos de in-formación OPC UA (Página 217)

Conexión segura con un servidor de correo a través de la interfaz de la CPU

Puede establecer una conexión segura con un servidor de correo sin necesidad de hardware adicional.

Cap. Secure OUC mediante correo electrónico (Pági-na 113)

Comunicación segura vía Modbus TCP

Puede establecer conexiones TCP seguras entre un cliente Modbus TCP y un servidor Mo-dbus TCP.

Cap. Secure OUC con Modbus TCP (Página 112)

Novedades del manual de funciones Comunicación, edición 09/2016 con respecto a la edición 12/2014 Novedades Ventajas para el cliente Dónde encontrar información Nuevos contenidos

Servidor OPC UA OPC UA es un estándar unificado para el inter-cambio de datos y no depende de la plataforma concreta del sistema operativo. OPC UA utiliza mecanismos de seguridad inte-grados en distintos sistemas de automatización, por ejemplo, en el intercambio de datos, a nivel de aplicación, para la legitimación del usuario. El servidor OPC UA facilita numerosos datos: • Valores de variables PLC a los que pueden

acceder los clientes • tipos de datos de estas variables PLC; • datos sobre el propio servidor OPC UA y so-

bre la CPU. Los clientes pueden obtener así una vista general de la gestión de variables y leer y escribir valores.

Cap. Comunicación OPC UA (Página 133)

Secure Open User Communication

Intercambio de datos seguro con otros dispositi-vos.

Cap. Secure Open User Com-munication (Página 95)

Gestión de certificados en STEP 7

En STEP 7 pueden gestionarse certificados para las siguientes aplicaciones: • Servidor OPC UA • Secure Open User Communication • Servidor web de la CPU

Cap. Administración de certifi-cados mediante STEP 7 (Pá-gina 45)

Desactivar SNMP para la CPU

Es posible desactivar SNMP para la CPU. Esto puede ser aconsejable en determinadas circuns-tancias, p. ej., si las normas de seguridad de su red no permiten usar SNMP.

Cap. Desactivar SNMP (Pági-na 58)

Prólogo


Convenciones STEP 7: Para designar el software de configuración y programación, en la presente documentación se utiliza "STEP 7" como sinónimo de "STEP 7 a partir de V12 (TIA Portal)".

El término "CPU S7-1500" abarca también las variantes de CPU S7-1500F, S7-1500T, S7-1500TF y S7-1500C, así como las CPU S7-1500pro, las CPU ET200SP y el controlador por software SIMATIC S7-1500.

La presente documentación contiene ilustraciones de los dispositivos descritos. Las ilustraciones pueden diferir del dispositivo suministrado en algunos detalles.

Preste atención además a las notas resaltadas del modo siguiente:

Nota

Una nota contiene datos importantes acerca del producto, el manejo de dicho producto o la parte de la documentación a la que debe prestarse especial atención.

Consulte también PRODIS (http://www.siemens.com/simatic-tech-doku-portal)

Catálogo (http://mall.industry.siemens.com)

Información de seguridad Siemens ofrece productos y soluciones con funciones de seguridad industrial con el objetivo de hacer más seguro el funcionamiento de instalaciones, sistemas, máquinas y redes.

Para proteger las instalaciones, los sistemas, las máquinas y las redes de amenazas cibernéticas, es necesario implementar (y mantener continuamente) un concepto de seguridad industrial integral que sea conforme a la tecnología más avanzada. Los productos y las soluciones de Siemens constituyen únicamente una parte de este concepto.

El cliente es responsable de impedir el acceso no autorizado a sus instalaciones, sistemas, máquinas y redes. Los sistemas, las máquinas y los componentes solo deben estar conectados a la red corporativa o a Internet cuando y en la medida que sea necesario y siempre que se hayan tomado las medidas de protección adecuadas (p. ej. uso de cortafuegos y segmentación de la red).

Adicionalmente, deberán observarse las recomendaciones de Siemens en cuanto a las medidas de protección correspondientes. Encontrará más información sobre seguridad industrial en (http://www.siemens.com/industrialsecurity).

Los productos y las soluciones de Siemens están sometidos a un desarrollo constante con el fin de mejorar todavía más su seguridad. Siemens recomienda expresamente realizar actualizaciones en cuanto estén disponibles y utilizar únicamente las últimas versiones de los productos. El uso de versiones anteriores o que ya no se soportan puede aumentar el riesgo de amenazas cibernéticas.

Para mantenerse informado de las actualizaciones de productos, recomendamos que se suscriba al Siemens Industrial Security RSS Feed en (http://www.siemens.com/industrialsecurity).

http://www.siemens.com/simatic-tech-doku-portal

http://mall.industry.siemens.com/

http://www.siemens.com/industrialsecurity

http://www.siemens.com/industrialsecurity

Prólogo


Siemens Industry Online Support Encontrará información actualizada de forma rápida y sencilla acerca de los siguientes temas:

● Product Support

Toda la información y amplio know-how en torno al producto de su interés, datos técnicos, preguntas frecuentes, certificados, descargas y manuales.

● Ejemplos de aplicación

Herramientas y ejemplos para la solución de sus tareas de automatización, además de bloques de función, información sobre rendimiento y vídeos

● Servicios

Información sobre Industry Services, Field Services, Technical Support, repuestos y oferta de formación.

● Foros

Para respuestas y soluciones en torno a la automatización.

● mySupport

Su área de trabajo personal en SIEMENS Industry Online Support para mensajes primados, solicitud de consultas al soporte técnico y documentación configurable.

Encontrará esta información disponible en Siemens Industry Online Support en Internet (http://www.siemens.com/automation/service&support).

Industry Mall Industry Mall es el sistema de catálogos y pedidos de SIEMENS AG para soluciones de automatización y accionamientos sobre la base de la Totally Integrated Automation (TIA) y Totally Integrated Power (TIP).

Encontrará el catálogo para todos los productos de automatización y accionamientos en Internet (https://mall.industry.siemens.com).

http://www.siemens.com/automation/service&support

https://mall.industry.siemens.com/


Índice

Prólogo ................................................................................................................................................... 3

1 Guía de la documentación .................................................................................................................... 10

2 Descripción del producto ....................................................................................................................... 15

3 Servicios de comunicación .................................................................................................................... 20

3.1 Vista general de las opciones de comunicación ..................................................................... 20

3.2 Protocolos de comunicación y números de puerto utilizados en la comunicación Ethernet .................................................................................................................................. 23

3.3 Los recursos de conexión en resumen ................................................................................... 28

3.4 Crear una conexión ................................................................................................................. 29

3.5 Coherencia de datos ............................................................................................................... 33

3.6 Secure communication ........................................................................................................... 36 3.6.1 Principios básicos de secure communication ......................................................................... 36 3.6.2 Confidencialidad por cifrado ................................................................................................... 38 3.6.3 Autenticidad e integridad mediante firmas.............................................................................. 41 3.6.4 Administración de certificados mediante STEP 7 ................................................................... 45 3.6.5 Ejemplos de administración de certificados ........................................................................... 49 3.6.6 Ejemplo: HTTP over TLS ........................................................................................................ 54

3.7 SNMP ...................................................................................................................................... 58 3.7.1 Desactivar SNMP .................................................................................................................... 58 3.7.2 Ejemplo: Desactivar SNMP para una CPU 1516-3 PN/DP .................................................... 59

4 Comunicación PG ................................................................................................................................. 62

5 Comunicación HMI ................................................................................................................................ 65

6 Open User Communication ................................................................................................................... 67

6.1 Resumen de Open User Communication ............................................................................... 67

6.2 Protocolos para Open User Communication .......................................................................... 68

6.3 Instrucciones para Open User Communication ...................................................................... 70

6.4 Open User Communication con direccionamiento a través de nombres de dominio ............ 74

6.5 Configurar la Open User Communication vía TCP, ISO-on-TCP, UDP e ISO ....................... 77

6.6 Configurar la comunicación vía FDL ....................................................................................... 84

6.7 Configurar la comunicación vía Modbus TCP ........................................................................ 87

6.8 Configuración de la comunicación por correo electrónico ...................................................... 90

6.9 Configuración de la comunicación vía FTP ............................................................................ 91

6.10 Establecer y deshacer relaciones de comunicación ............................................................... 94

Índice


6.11 Secure Open User Communication ....................................................................................... 95 6.11.1 Secure OUC de una CPU S7-1500 como cliente TLS a un PLC externo (servidor TLS) ..... 95 6.11.2 Secure OUC de una CPU S7-1500 como servidor TLS a un PLC externo (cliente TLS) ..... 98 6.11.3 Secure OUC entre dos CPU S7-1500 ................................................................................. 102 6.11.4 Secure OUC a través de interfaz CP ................................................................................... 107 6.11.5 Secure OUC con Modbus TCP ............................................................................................ 112 6.11.6 Secure OUC mediante correo electrónico ........................................................................... 113

7 Comunicación S7 ................................................................................................................................. 118

8 Acoplamiento punto a punto ................................................................................................................. 128

9 Comunicación OPC UA ........................................................................................................................ 133

9.1 Información importante sobre OPC UA ............................................................................... 133 9.1.1 OPC UA e Industria 4.0 ....................................................................................................... 133 9.1.2 Estructura de la descripción ................................................................................................. 133 9.1.3 Propiedades generales de OPC UA .................................................................................... 135 9.1.4 De la interfaz OPC clásica a OPC UA ................................................................................. 137 9.1.5 El servidor OPC UA de las CPU S7-1500 ........................................................................... 137 9.1.6 Direccionamiento de nodos ................................................................................................. 139 9.1.7 Mapeado de tipos de datos .................................................................................................. 143 9.1.8 Puntos finales de los servidores OPC UA ........................................................................... 145 9.1.9 Comportamiento del servidor OPC UA durante el funcionamiento ..................................... 148 9.1.10 Información importante sobre clientes OPC UA .................................................................. 149

9.2 Seguridad en OPC UA ......................................................................................................... 153 9.2.1 Ajustes de seguridad ........................................................................................................... 153 9.2.2 Certificados según X.509 de la UIT ..................................................................................... 154 9.2.3 Certificados en OPC UA ...................................................................................................... 157 9.2.4 Crear certificados autofirmados ........................................................................................... 158 9.2.5 Autogeneración de parejas de claves PKI y de certificados ................................................ 159 9.2.6 Transferencia segura de mensajes...................................................................................... 162

Índice


9.3 Uso de la CPU S7-1500 como servidor OPC UA ................................................................. 166 9.3.1 Configurar el acceso a variables PLC .................................................................................. 166 9.3.1.1 Administrar derechos de escritura y lectura ......................................................................... 166 9.3.1.2 Administrar derechos de escritura y lectura para un DB completo ...................................... 167 9.3.1.3 Posibilidades de acceso a datos del servidor OPC UA ........................................................ 169 9.3.1.4 Exportar archivo XML con las variables PLC habilitadas ..................................................... 170 9.3.2 Configurar el servidor OPC UA de la CPU S7-1500 ............................................................ 171 9.3.2.1 Activar servidor OPC UA ...................................................................................................... 171 9.3.2.2 Acceso al servidor OPC UA .................................................................................................. 173 9.3.2.3 Ajustes generales del servidor OPC UA ............................................................................... 175 9.3.2.4 Ajustes del servidor para suscripciones ............................................................................... 177 9.3.2.5 Manejo de certificados de cliente y de servidor .................................................................... 179 9.3.2.6 Tratamiento de los certificados de cliente de la CPU S7-1500 ............................................ 184 9.3.2.7 Crear certificados de servidor con STEP 7........................................................................... 186 9.3.2.8 Autenticación del usuario ...................................................................................................... 190 9.3.2.9 Usuarios y roles con derechos de función OPC UA ............................................................. 191 9.3.2.10 Licencias para el servidor OPC UA ...................................................................................... 193 9.3.3 Proporcionar métodos en el servidor OPC UA ..................................................................... 193 9.3.3.1 Métodos de servidor ............................................................................................................. 193 9.3.4 Instrucciones del servidor OPC UA para la implementación de métodos ............................ 198 9.3.4.1 OPC_UA_ServerMethodPre ................................................................................................. 198 9.3.4.2 OPC_UA_ServerMethodPost ................................................................................................ 201 9.3.4.3 Programa de ejemplo para proporcionar un método para clientes OPC UA ....................... 205 9.3.4.4 Códigos de error ................................................................................................................... 208 9.3.5 Uso de modelos de información OPC UA ............................................................................ 217 9.3.5.1 Utilización de especificaciones OPC UA Companion ........................................................... 217 9.3.5.2 Coordinar derechos de escritura y lectura para variables de CPU ...................................... 230 9.3.5.3 Notas sobre capacidades al usar interfaces de servidores .................................................. 233

10 Routing ............................................................................................................................................... 235

10.1 Routing S7 ............................................................................................................................ 235

10.2 Routing de registros .............................................................................................................. 240

11 Recursos de conexión ......................................................................................................................... 242

11.1 Recursos de conexión de una estación ................................................................................ 242

11.2 Asignación de recursos de conexión .................................................................................... 246

11.3 Visualización de los recursos de conexión ........................................................................... 250

12 Diagnóstico de conexiones ................................................................................................................. 254

13 Industrial Ethernet Security con CP 1543-1 ......................................................................................... 258

13.1 Cortafuegos .......................................................................................................................... 260

13.2 Registro de datos .................................................................................................................. 260

13.3 Cliente NTP ........................................................................................................................... 261

13.4 SNMP .................................................................................................................................... 262

13.5 VPN ....................................................................................................................................... 262

Glosario .............................................................................................................................................. 263

Índice alfabético .................................................................................................................................. 275


Guía de la documentación 1

La documentación del sistema de automatización SIMATIC S7-1500, de la CPU 1516pro-2 PN basada en SIMATIC S7-1500 y de los sistemas de periferia descentralizada SIMATIC ET 200MP, ET 200SP y ET 200AL se divide en tres partes. Esta división le permite acceder específicamente a los contenidos de su interés.

Información básica

En los manuales de sistema y en los Getting Started (primeros pasos) se describen detalladamente la configuración, el montaje, el cableado y la puesta en marcha de los sistemas SIMATIC S7-1500, ET 200MP, ET 200SP y ET 200AL; para la CPU 1516pro-2 PN, utilice las instrucciones de servicio correspondientes. La Ayuda en pantalla de STEP 7 le asiste en la configuración y programación.

Información de dispositivos

Los manuales de producto contienen una descripción sintetizada de la información específica de los módulos, como características, esquemas de conexiones, curvas características o datos técnicos.

Guía de la documentación


Información general

En los manuales de funciones encontrará descripciones exhaustivas sobre temas generales, p. ej., diagnóstico, comunicación, control de movimiento, servidor web, OPC UA.

La documentación se puede descargar gratuitamente de Internet (https://support.industry.siemens.com/cs/ww/es/view/109742705).

Los cambios y ampliaciones de los manuales se documentan en informaciones de producto.

Encontrará los ejemplos de aplicación en Internet.

● S7-1500/ET 200MP (https://support.industry.siemens.com/cs/es/es/view/68052815)

● ET 200SP (https://support.industry.siemens.com/cs/es/es/view/73021864)

● ET 200AL (https://support.industry.siemens.com/cs/es/es/view/99494757)

Manual Collections Las Manual Collections contienen la documentación completa de los sistemas recogida en un archivo.

Encontrará la Manual Collection en Internet:

● S7-1500/ET 200MP (https://support.industry.siemens.com/cs/ww/es/view/86140384)

● ET 200SP (https://support.industry.siemens.com/cs/ww/es/view/84133942)

● ET 200AL (https://support.industry.siemens.com/cs/ww/es/view/95242965)

"mySupport" Con "mySupport", su área de trabajo personal, podrá sacar el mejor partido al Industry Online Support.

En "mySupport" podrá guardar filtros, favoritos y etiquetas, solicitar datos CAx y elaborar una librería personalizada en la sección Documentación. Asimismo, en las consultas que realice con el Support Request (solicitud de soporte), este ya estará cumplimentado con sus datos, y en todo momento podrá ver una relación de las solicitudes pendientes.

Para usar todas las funciones de "mySupport" basta con registrarse una sola vez.

Encontrará "mySupport" en Internet (https://support.industry.siemens.com/My/ww/es).

"mySupport": "Documentación" En "MySupport", en la sección "Documentación", se pueden combinar manuales completos o partes de ellos para elaborar un manual personalizado. Este manual se puede exportar como archivo PDF o a un formato editable.

Encontrará "mySupport", "Documentación" en Internet (http://support.industry.siemens.com/My/ww/es/documentation).

https://support.industry.siemens.com/cs/ww/es/view/109742705

https://support.industry.siemens.com/cs/es/es/view/68052815






https://support.industry.siemens.com/My/ww/es

http://support.industry.siemens.com/My/ww/es/documentation



"mySupport": "Datos CAx" En el área "Datos CAx" de "mySupport" puede acceder a datos de producto actualizados para su sistema CAx o CAe.

Con solo unos clics configurará su propio paquete para descargar.

Puede elegir lo siguiente:

● Imágenes de producto, croquis acotados 2D, modelos 3D, esquemas de conexiones, archivos de macros EPLAN

● Manuales, curvas características, instrucciones de uso, certificados

● Datos maestros de los productos

Encontrará "mySupport", "Datos CAx" en Internet (http://support.industry.siemens.com/my/ww/es/CAxOnline).

Ejemplos de aplicación Los ejemplos de aplicación le asisten con diferentes herramientas y ejemplos a la hora de resolver las tareas de automatización. Los ejemplos muestran siempre soluciones en las que interactúan varios componentes del sistema sin centrarse en productos concretos.

Encontrará los ejemplos de aplicación en Internet (https://support.industry.siemens.com/sc/ww/es/sc/2054).

TIA Selection Tool TIA Selection Tool permite seleccionar, configurar y pedir dispositivos para Totally Integrated Automation (TIA). Es el sucesor de SIMATIC Selection Tool y aúna en una misma herramienta los configuradores de automatización ya conocidos. TIA Selection Tool permite generar un lista de pedido completa a partir de la selección o configuración de productos realizada.

Encontrará TIA Selection Tool en Internet (http://w3.siemens.com/mcms/topics/en/simatic/tia-selection-tool).

http://support.industry.siemens.com/my/ww/es/CAxOnline

https://support.industry.siemens.com/sc/ww/es/sc/2054

http://w3.siemens.com/mcms/topics/en/simatic/tia-selection-tool



SIMATIC Automation Tool Con SIMATIC Automation Tool puede ejecutar tareas de puesta en servicio y mantenimiento globales en distintas estaciones SIMATIC S7 a la vez, independientemente del TIA Portal.

SIMATIC Automation Tool ofrece un gran número de funciones:

● Escaneado de una red PROFINET/Ethernet de la instalación e identificación de todas las CPU conectadas

● Asignación de direcciones (IP, subred, gateway) y un nombre de estación (dispositivo PROFINET) a una CPU

● Transferencia de la fecha y la hora de la programadora o del PC convertida a hora UTC al módulo

● Descarga de programas a la CPU

● Cambio de modo de operación RUN/STOP

● Localización de la CPU mediante parpadeo de los LED

● Lectura de información de error de la CPU

● Lectura del búfer de diagnóstico de la CPU

● Restablecer ajustes de fábrica

● Actualización del firmware de la CPU y los módulos conectados

Encontrará SIMATIC Automation Tool en Internet (https://support.industry.siemens.com/cs/ww/es/view/98161300).

PRONETA Con SIEMENS PRONETA (análisis de red PROFINET) podrá analizar la red de la instalación durante la puesta en marcha. PRONETA dispone de dos funciones centrales:

● La vista topológica general escanea automáticamente la red PROFINET y todos los componentes conectados.

● La comprobación de E/S es una comprobación rápida del cableado y de la configuración de los módulos de una instalación.

Encontrará SIEMENS PRONETA en Internet (https://support.industry.siemens.com/cs/ww/es/view/67460624).





SINETPLAN SINETPLAN, el Siemens Network Planner, es una ayuda para planificadores de instalaciones y redes de automatización basada en PROFINET. La herramienta facilita, incluso en la fase de planificación, el dimensionamiento profesional y anticipativo de la instalación de PROFINET. SINETPLAN le ayuda también a optimizar la red así como a aprovechar al máximo los recursos en la red y planificar reservas. De esta forma se evitan problemas en la puesta en marcha o fallos durante el funcionamiento productivo antes de iniciar la aplicación programada. Esto aumenta la disponibilidad de la producción y contribuye a mejorar la seguridad de operación.

Resumen de las ventajas

● Optimización de la red mediante el cálculo puerto a puerto de las cargas de red.

● Mayor disponibilidad de producción mediante escaneo online y verificación de las instalaciones existentes

● Transparencia antes de la puesta en marcha mediante la importación y simulación de proyectos STEP 7 existentes

● Eficiencia mediante la protección a largo plazo de las inversiones existentes y el aprovechamiento óptimo de los recursos

Encontrará SINETPLAN en Internet (https://www.siemens.com/sinetplan).

https://www.siemens.com/sinetplan


Descripción del producto 2

Las CPU, los módulos y procesadores de comunicación y los sistemas PC de los sistemas S7-1500, ET 200MP, ET 200SP, ET 200pro y ET 200AL ofrecen interfaces para la comunicación vía PROFINET, PROFIBUS y acoplamiento punto a punto.

CPU, módulos y procesadores de comunicaciones Las interfaces PROFINET- y PROFIBUS DP están integradas en las CPU S7-1500. Por ejemplo, la CPU 1516-3 PN/DP dispone de dos interfaces PROFINET y una interfaz PROFIBUS DP. Otras interfaces PROFINET y PROFIBUS DP están disponibles a través de módulos de comunicaciones (CM) y procesadores de comunicaciones (CP).

① Interfaz PROFINET (X2) con 1 puerto ② Interfaz PROFINET (X1) con switch de 2 puertos ③ Interfaz PROFIBUS DP (X3) ④ Interfaz PROFINET (X1) con switch de 3 puertos

Figura 2-1 Interfaces de la CPU 1516-3 PN/DP y de la CPU 1512SP-1 PN

Descripción del producto


Interfaces de módulos de comunicaciones Las interfaces de módulos de comunicaciones (CM) complementan las interfaces de CPU (p. ej., el módulo de comunicaciones CM 1542-5 amplía el sistema de automatización S7-1500 con una interfaz PROFIBUS).

① Interfaz PROFIBUS DP

Figura 2-2 Interfaz PROFIBUS DP del CM 1542-5 y del CM DP



Interfaces de procesadores de comunicación Las interfaces de los procesadores de comunicación (CP) ofrecen una funcionalidad adicional a la que proporcionan las interfaces integradas de las CPU. Los CP cubren casos de aplicación especiales; p. ej., el CP 1543-1 ofrece funciones de seguridad informática para la protección de redes Industrial Ethernet a través de su interfaz Industrial Ethernet.

① Interfaz Industrial Ethernet

Figura 2-3 Interfaz Industrial Ethernet del CP 1543-1



Interfaces de módulos de comunicaciones para acoplamiento punto a punto Los módulos de comunicaciones para acoplamiento punto a punto ofrecen comunicación a través de sus interfaces RS232, RS422 y RS485, p. ej., comunicación Freeport o Modbus.

① Interfaces para acoplamiento punto a punto

Figura 2-4 Ejemplo de interfaz para acoplamiento punto a punto en CM PtP RS422/485 BA



Interfaces de los módulos de interfaz Las interfaces PROFINET y PROFIBUS DP de los módulos de interfaz (IM) en ET 200MP, ET 200SP y ET 200AL sirven para conectar la periferia descentralizada ET 200MP, ET 200SP y ET 200AL a PROFINET o PROFIBUS del controlador IO o maestro DP de nivel superior.

① Interfaz PROFINET con switch de 2 puertos

Figura 2-5 Interfaces PROFINET IM 155-5 PN ST (ET 200MP), IM 155-6 PN ST (ET 200SP) y IM 157-1 PN (ET 200AL)

Servicios de comunicación Los servicios de comunicación descritos a continuación utilizan las interfaces y los mecanismos de comunicación que ofrece el sistema a través de las CPU y los módulos y procesadores de comunicación.


Servicios de comunicación 3 3.1 Vista general de las opciones de comunicación

Vista general de las opciones de comunicación Existen las siguientes opciones de comunicación para las tareas de automatización:

Tabla 3- 1 Opciones de comunicación

Opciones de comunicación Funcionalidad A través de interfaz: PN/IE1 DP serie

Comunicación PG Puesta en marcha, test, diagnóstico X X - Comunicación HMI Manejo y visualización X X - Comunicación abierta vía TCP/IP Intercambio de datos vía

PROFINET/Industrial Ethernet con TCP/IP Instrucciones: • TSEND_C/TRCV_C • TSEND/TRCV • TCON • T_DISCON

X - -

Comunicación abierta vía ISO-on-TCP Intercambio de datos vía PROFINET/Industrial Ethernet con ISO-on-TCP Instrucciones: • TSEND_C/TRCV_C • TSEND/TRCV • TCON • T_DISCON

X - -

Comunicación abierta vía UDP Intercambio de datos vía PROFINET/Industrial Ethernet con UDP Instrucciones: • TSEND_C/TRCV_C • TUSEND/TURCV/TRCV • TCON • T_DISCON

X - -

Servicios de comunicación 3.1 Vista general de las opciones de comunicación



Comunicación abierta vía ISO (solo CP con interfaz PROFINET/Industrial Ethernet)

Intercambio de datos vía PROFINET/Industrial Ethernet con protocolo ISO Instrucciones: • TSEND_C/TRCV_C • TSEND/TRCV • TCON • T_DISCON

X - -

Comunicación abierta vía FDL (solo CM 1542-5 a partir de la versión de firmware V2.0)

Intercambio de datos vía PROFIBUS con protocolo FDL Instrucciones: • TSEND_C/TRCV_C • TSEND/TRCV • TUSEND/TURCV • TCON • T_DISCON

- X -

Servidor OPC UA (solo a través de interfaces PROFINET de la CPU)

Intercambio de datos con clientes OPC UA X - -

Comunicación vía Modbus TCP Intercambio de datos vía PROFINET con protocolo Modbus TCP Instrucciones: • MB_CLIENT • MB_SERVER

X - -

Correo electrónico Enviar avisos de proceso por correo electrónico Instrucción: • TMAIL_C

X - -

FTP (solo CP con interfaz PROFINET/Industrial Ethernet)

Administración y acceso a archivos vía FTP (File Transfer Protocol); el CP puede ser cliente FTP y servidor FTP Instrucción: • FTP_CMD

X - -

Fetch/Write (solo CP con interfaz PROFINET/Industrial Ethernet)

Servicios de servidor vía TCP/IP, ISO-on-TCP e ISO A través de instrucciones especiales para Fe-tch/Write

X - -

Comunicación S7 Intercambio de datos vía PROFINET/PROFIBUS con protocolo S7. Instrucciones: • PUT/GET • BSEND/BRCV • USEND/URCV

X X -

Servicios de comunicación 3.2 Protocolos de comunicación y números de puerto utilizados en la comunicación Ethernet



Acoplamiento punto a punto serie Intercambio de datos punto a punto con protocolo Freeport, 3964(R), USS o Modbus A través de instrucciones especiales para PaP, USS o Modbus RTU

- - X

Servidor web Intercambio de datos a través de HTTP(S), p. ej., para el diagnóstico

X - -

SNMP (Simple Network Management Protocol)

Para la vigilancia y la detección de errores en redes IP y, en su caso, parametrización de componentes de red IP a través del protocolo estándar SNMP

X - -

Sincronización de la hora A través de la interfaz PN/IE: la CPU es cliente NTP (Network Time Protocol)

X - -

A través de la interfaz DP: La CPU, el CM o el CP es reloj maestro o reloj esclavo

- X -

1 IE: Industrial Ethernet

Información adicional ● Ejemplo de aplicación: Comunicación CPU-CPU con controladores SIMATIC

(compendio) Encontrará el ejemplo de aplicación en Internet (https://support.industry.siemens.com/cs/ww/es/view/20982954).

● La configuración de la comunicación Fetch/Write con S7-1500 mediante un CP1543-1 se describe en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/102420020).

● Encontrará más información sobre los servicios Fetch/Write en la ayuda en pantalla de STEP 7.

● Para más información sobre el acoplamiento PtP, consulte el manual de funciones CM PtP - Configuraciones para acoplamientos punto a punto (http://support.automation.siemens.com/WW/view/de/59057093/0/es).

● Encontrará una descripción de la funcionalidad de servidor web en el manual de funciones Servidor web (http://support.automation.siemens.com/WW/view/es/59193560).

● Encontrará más información sobre el protocolo estándar SNMP en las páginas de Service & Support en Internet (http://support.automation.siemens.com/WW/view/es/15166742).

● Encontrará más información sobre sincronización horaria en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/86535497).



http://support.automation.siemens.com/WW/view/de/59057093/0/es

http://support.automation.siemens.com/WW/view/es/59193560





3.2 Protocolos de comunicación y números de puerto utilizados en la comunicación Ethernet

Este apartado ofrece una vista general de los protocolos y números de puerto que se utilizan en la comunicación a través de interfaces PN/IE. Para cada uno de ellos se indican los parámetros de dirección, la capa de comunicación afectada, la función de comunicación y la dirección o sentido de la comunicación.

Esta información permite adaptar las medidas de seguridad informática que protegen el sistema de automatización (p. ej., firewall) a los protocolos utilizados. Dado que estas medidas de seguridad informática se limitan a las redes Ethernet y PROFINET, en las tablas no se incluyen los protocolos PROFIBUS.

Nota Números de puerto utilizados

Los números de puerto indicados son los que la CPU S7-1500 utiliza de modo predeterminado. Muchos protocolos de comunicación o implementaciones permiten utilizar otros números de puerto.

Las siguientes tablas muestran las diferentes capas y protocolos utilizados.

La siguiente tabla muestra los protocolos soportados por las CPU S7-1500, las CPU ET 200SP y la CPU 1516pro-2 PN. Los controladores por software S7-1500 soporta asimismo los protocolos indicados en la siguiente tabla para las interfaces Ethernet asignadas.

Tabla 3- 2 Capas y protocolos de las CPU S7-1500 y controladores por software (a través de la interfaz PROFINET de la CPU)

Protocolo Número de puerto

(2) Capa de enlace (4) Capa de trans-porte

Función Descripción

Protocolos PROFINET DCP Discovery and Configuration Protocol

Irrelevante (2) Ethertype 0x8892 (PROFINET)

Dispositivos accesibles, PROFINET Dis-covery and confi-guration

PROFINET utiliza DCP para detectar dispositivos PROFINET y permitir ajustes básicos.

LLDP Link Layer Discovery Protocol

Irrelevante (2) Ethertype 0x88CC (LLDP)

PROFINET Link Layer Discovery protocol

PROFINET utiliza LLDP para detectar y adminis-trar relaciones de vecindad entre dispositivos PROFINET. LLDP emplea la dirección MAC Multicast espe-cial: 01-80-C2-00-00-0E

MRP Media Redun-dancy Protocol

Irrelevante (2) Ethertype 0x88E3 (IEC 62493-2-2010)

PROFINET me-dium redundancy

MRP permite controlar vías de transmisión re-dundantes mediante una topología en anillo. MRP utiliza direcciones MAC Multicast normali-zadas.






PTCP Precision Transparent Clock Protocol


PROFINET send clock and time synchronisa-tion, based on IEEE 1588

PTC permite medir un retardo entre puertos RJ45 y, con ello, la sincronización horaria y de los ciclos de emisión. PTCP utiliza direcciones MAC Multicast normali-zadas.

PROFINET IO data


PROFINET Cy-clic IO data trans-fer

Los telegramas o tramas PROFINET IO se utili-zan para transferir datos IO de forma cíclica entre el controlador PROFINET IO y los dispositivos IO vía Ethernet.

PROFINET Context Ma-nager

34964 (4) UDP PROFINET con-nection less RPC

El PROFINET Context Manager ofrece un ma-peador de puntos finales para establecer una relación de aplicación (PROFINET AR).

Protocolos de comunicación orientados a la conexión SMTP Simple Mail Transfer Pro-tocol

25 (4) TCP Simple Mail Transfer Protocol

SMTP se utiliza para enviar correos electrónicos.

SMTPS (SMTP over TLS)

465 (4) TCP Secure SMTP SMTPS se utiliza para enviar correos electróni-cos a través de conexiones seguras.

SMTP con STARTTLS

25 587

(4) TCP Simple Mail Transfer Protocol con el comando de SMTP "STARTTLS"

SMTP con STARTTLS se utiliza para enviar correos electrónicos a través de conexiones seguras.

HTTP Hypertext Transfer Pro-tocol

80 (4) TCP Hypertext Trans-fer Protocol

HTTP se utiliza para la comunicación con el servidor web interno de la CPU.

ISO-on-TCP (según RFC 1006)

102 (4) TCP ISO-on-TCP protocol

ISO-on-TCP (según RFC 1006) sirve para el intercambio de datos orientado a mensajes con CPU o controladores por software remotos. Comunicación S7 con ES, HMI, servidor OPC, etc.

NTP Network Time Protocol

123 (4) UDP Network Time Protocol

NTP se utiliza para sincronizar la hora del siste-ma de la CPU con la hora de un servidor NTP.

SNMP Simple Net-work Mana-gement Protocol

161 162 (trap)

(4) UDP Simple Network Management Protocol

SNMP permite leer y activar datos de administra-ción de redes (objetos administrados mediante SNMP) por medio del administrador SNMP.

HTTPS Secure Hyper-text Transfer Protocol

443 (4) TCP Secure Hypertext Transfer Protocol

HTTPS se utiliza para la comunicación con el servidor web interno de la CPU vía Secure So-cket Layer (SSL).






Modbus TCP Modbus Transmission Control Proto-col

502 (4) TCP Modbus/TCP protocol

Modbus/TCP es utilizado por instrucciones MB_CLIENT/MB_SERVER en el programa de usuario.

OPC UA Open Platform Communica-tions Unified Archi-tecture

4840 (4) TCP Basado en el protocolo TCP/IP

Estándar de comunicación que abarca desde el nivel empresarial hasta el nivel de campo.

OUC1 Open User Communica-tion y Secure OUC

1 ... 1999 Uso condi-cionado2

(4) TCP (4) UDP

Open User Communication (TCP/UDP) Secure Open User Communi-cation (TLS)

Las instrucciones OUC permiten establecer y deshacer la conexión y transferir datos sobre la base de Socket Layer.

2000 ... 5000 Recomen-dado 5001 ... 49151 Uso condi-cionado2

IGMPv2 Internet Group Managment Protocol

Irrelevante (3) Capa de red Internet Group Managment Protocol

Protocolo de red para la organización de circuitos Multicast.

Reserved 49152 ... 65535

(4) TCP (4) UDP

- Área de puertos dinámica que se utiliza para el punto final activo de la conexión cuando la apli-cación no determina el número de puerto local.

1 Nota: La comunicación abierta proporciona al usuario un acceso directo a UDP/TCP. El usuario se responsabiliza de tener en cuenta los límites/definiciones de los puertos de IANA (Internet Assigned Numbers Authority).

2 No utilice puertos para OUC que ya estén ocupados por otros protocolos.



La siguiente tabla muestra los protocolos soportados por el controlador por software S7-1500 a través de las interfaces Ethernet asignadas en Windows.

Tabla 3- 3 Capas y protocolos de los controladores por software S7-1500 (mediante la interfaz Ethernet de Windows)


(2) Capa de enlace (4) Capa de transpor-te


Protocolos PROFINET DCP Discovery and Configuration Protocol


Dispositivos accesibles, PROFINET Discovery and configuration

PROFINET utiliza DCP para detectar dispositivos PROFINET y permitir ajustes básicos.

Protocolos de comunicación orientados a la conexión SMTP Simple Mail Transfer Pro-tocol

25 (4) TCP Simple Mail Transfer Proto-col

SMTP se utiliza para enviar correos electrónicos.

HTTP Hypertext Transfer Pro-tocol

Configura-ble1

(4) TCP Hypertext Transfer Proto-col

HTTP se utiliza para la comunicación con el servidor web interno de la CPU. El número de puerto puede modificarse en Windows para evitar conflictos con otros servidores web. Si desea utilizar el acceso al servidor web, debe habilitar el puerto en el firewall de Windows.

ISO-on-TCP (según RFC 1006)

102 (4) TCP ISO-on-TCP protocol

ISO-on-TCP (según RFC 1006) para la comuni-cación S7 con PG/PC o HMI.

OUC2 Open User Communica-tion y Secure OUC

1 ... 1999 Uso condi-cionado3,4

(4) TCP (4) UDP

Open User Communication (TCP/UDP) Secure Open User Commu-nication (TLS)

Las instrucciones OUC permiten establecer y deshacer la conexión y transferir datos sobre la base de Socket Layer. Si desea utilizar OUC, debe habilitar los puertos en el firewall de Windows.

2000 ... 5000 Recomen-dado4 5001 ... 49151 Uso condi-cionado3,4




(2) Capa de enlace (4) Capa de transpor-te


IGMPv2 Internet Group Managment Protocol

Irrelevante (3) Capa de red Internet Group Managment Protocol

Protocolo de red para la organización de circuitos Multicast.

Reserved 49152 ... 65535

(4) TCP (4) UDP

- Área de puertos dinámica que se utiliza para el punto final activo de la conexión cuando la apli-cación no determina el número de puerto local. Si desea utilizar esta comunicación, debe habili-tar los puertos en el firewall de Windows.

1 Ajuste predeterminado en interfaces asignadas en Windows: 81 2 Nota: la comunicación de usuario abierta proporciona al usuario un acceso directo al UDP/TCP. El usuario se respon-

sabiliza de tener en cuenta los límites/definiciones de los puertos de IANA (Internet Assigned Numbers Authority). 3 No utilice puertos para OUC que ya estén ocupados por otros protocolos. 4 No utilice puertos para OUC que ya estén ocupados por otras aplicaciones de Windows.

La siguiente tabla muestra los protocolos soportados adicionalmente por los módulos de comunicaciones S7-1500 (p. ej., CP 1543-1) además de los ya indicados en las tablas anteriores.

Tabla 3- 4 Capas y protocolos de módulos de comunicación S7-1500




Protocolos PROFINET/Industrial Ethernet Protocolos de comunicación orientados a la conexión FTP File Transfer Protocol

20 (data) 21 (control)

(4) TCP File Transfer Protocol

FTP se utiliza para transferir archivos (solo en combinación con CP 1543-1).

secureFTP File Transfer Protocol

20 (data) 21 (control)

(4) TCP File Transfer Protocol

SecureFTP se utiliza para transferir archivos a través de una conexión TSL (solo en combina-ción con CP 1543-1).

DHCP Dynamic Host Configuration Protocol

68 (4) UDP Dynamic Host Configuration Protocol

DHCP se utiliza para obtener la IP Address Suite de un servidor DHCP al arrancar la interfaz IE.

NTPv3 seguro Network Time Protocol

123 (4) UDP Network Time Protocol

NTP seguro se utiliza para adaptar la hora de sistema interna de CP 1543-1 a un servidor NTP.

SNMP Simple Net-work Mana-gement Protocol

161 162 (trap)

(4) UDP Simple Network Management Protocol

SNMPv3 permite a CP 1543-1 leer datos de administración de redes (MIB) del agente SNMPv3 con autenticación.

Particularidad del S7-1500 MFP: Puerto 111: S7-1500 MFP utiliza el puerto 111 para el servicio NFS para la comunicación interna.

Servicios de comunicación 3.3 Los recursos de conexión en resumen


3.3 Los recursos de conexión en resumen

Recursos de conexión Algunos servicios de comunicación requieren conexiones. Las conexiones ocupan recursos en las CPU, los CP y los CM implicados (p. ej., áreas de memoria en el sistema operativo de la CPU). En la mayoría de los casos, para una conexión se asigna un recurso por CPU/CP/CM. En la comunicación HMI se necesitan hasta 3 recursos de conexión por cada conexión HMI.

Los recursos de conexión disponibles dependen de la CPU, el CP o el CM utilizado y no deben rebasar un límite superior definido para el sistema de automatización.

Recursos de conexión disponibles en una estación La CPU determina el número máximo de recursos de una estación.

Cada CPU incorpora recursos de conexión reservados para la comunicación PG, HMI y de servidor web. Además, existen recursos disponibles que pueden utilizarse para SNMP, conexiones de correo electrónico y la comunicación HMI y S7, así como la comunicación abierta.

¿Cuándo se asignan recursos de conexión? El momento de la asignación de recursos de conexión dependerá de cómo se cree la conexión: automáticamente, por programación o por configuración (ver el capítulo Crear una conexión (Página 29)).

Información adicional Encontrará más información sobre la asignación y la indicación de recursos de conexión en STEP 7, en el capítulo Recursos de conexión (Página 242).

Servicios de comunicación 3.4 Crear una conexión


3.4 Crear una conexión

Conexión automática STEP 7 crea una conexión automáticamente (p. ej., una conexión PG o HMI) siempre que la interfaz PG/PC esté conectada a una interfaz de la CPU y se haya efectuado la asignación de interfaces en STEP 7, en el cuadro de diálogo "Conexión online".

Crear una conexión por programación La conexión programada se crea en el editor de programación de STEP 7 en el contexto de una CPU parametrizando instrucciones de comunicación, p. ej., TSEND_C.



La cómoda interfaz de usuario le ayudará a definir los parámetros de la conexión (en la ventana de inspección, en las propiedades de la instrucción).

Figura 3-1 Crear una conexión por programación



Crear una conexión por configuración La conexión configurada se crea en la vista de redes del editor Dispositivos y redes de STEP 7 en el contexto de una CPU o de un controlador por software.

Figura 3-2 Crear una conexión por configuración



Efectos en los recursos de conexión de la CPU A menudo puede optarse por una conexión configurada o bien por una conexión programada. La conexión por programación permite liberar recursos de conexión después de transferir los datos. Al igual que las conexiones enrutadas, las conexiones programadas no están garantizadas, es decir, solo se establecen si hay recursos disponibles. En la conexión por configuración, el recurso queda disponible después de descargar la configuración y hasta que esta se vuelva a modificar. Por ello se reservan los recursos necesarios para poder establecer conexiones mediante conexión configurada. La tabla "Recursos de conexión" de la ventana de inspección de la CPU muestra una vista general de los recursos de conexión asignados y disponibles.

¿Cómo se establece cada tipo de conexión?

Tabla 3- 5 Crear la conexión

Conexión Automático Por programación Por configuración Conexión PG X - - Conexión HMI X - X Comunicación abierta mediante conexión TCP/IP

- X X

Comunicación abierta mediante conexión ISO-on-TCP

- X X

Comunicación abierta mediante conexión UDP

- X X

Comunicación abierta mediante conexión ISO

- X X

Comunicación abierta mediante conexión FDL

- X X

Comunicación mediante conexión Modbus TCP

- X -

Conexión de correo electrónico - X - Conexión FTP - X - Conexión S7* - - X * Tenga en cuenta que, en el caso de una CPU S7-1500 con versión de firmware inferior a V2.0, debe

habilitarse el uso de la comunicación PUT/GET en las propiedades de la CPU. Encontrará más in-formación al respecto en la ayuda en pantalla de STEP 7.

Información adicional Encontrará más información sobre la asignación y la indicación de recursos de conexión en STEP 7, en el capítulo Recursos de conexión (Página 242).

Servicios de comunicación 3.5 Coherencia de datos


3.5 Coherencia de datos

Definición Para la transferencia de datos es muy importante la coherencia de estos, que debe tenerse en cuenta a la hora de configurar una tarea de comunicación. Si esto no sucede pueden producirse fallos de funcionamiento.

Un área de datos que no puede ser modificada por procesos concurrentes se denomina área de datos coherente. Esto significa que un área de datos conexa cuyo volumen supere el tamaño máximo del área de datos coherente puede estar compuesta en un momento dado en parte por datos nuevos y en parte por datos antiguos.

Una incoherencia puede producirse cuando se interrumpe una instrucción de comunicación, p. ej., por un OB de alarma de proceso de mayor prioridad. De este modo también se interrumpe la transferencia del área de datos. Si el programa de usuario de este OB modifica ahora los datos que todavía no ha procesado la instrucción de comunicación, los datos transferidos proceden de diferentes instantes.

La figura siguiente muestra un área de datos más pequeña que el tamaño máximo del área de datos coherente. En este caso, a la hora de transferir el área de datos se asegura que durante el acceso a los datos no se producen interrupciones por parte del programa de usuario y, por tanto, que los datos no se modifican.

① El área de datos de origen es menor que el tamaño máximo del área de datos coherente (②).

La instrucción transfiere los datos de forma conexa al área de datos de destino. ② Tamaño máximo del área de datos coherente

Figura 3-3 Transferencia coherente de datos



La figura siguiente muestra un área de datos más grande que el tamaño máximo del área de datos coherente. En este caso existe la posibilidad de modificar los datos durante una interrupción de la transferencia de datos. Se produce una interrupción, p. ej., cuando el área de datos debe transferirse en varias partes. Si los datos se modifican durante la interrupción, los datos transferidos provienen de instantes distintos.

① El área de datos de origen es mayor que el tamaño máximo del área de datos coherente (③). En el instante T1,

la instrucción transfiere al área de datos de destino únicamente el volumen del área de datos de origen que cabe en el área de datos coherente.

② En el instante T2, la instrucción transfiere el resto del área de datos de origen al área de datos de destino. Des-pués de la transferencia, en el área de datos de destino hay datos de instantes distintos. Si los datos del área de datos de origen han cambiado entretanto, es posible que se produzca una incoherencia.

③ Tamaño máximo del área de datos coherente

Figura 3-4 Transferencia de datos con mayor volumen que el área de coherencia máxima

Ejemplo de incoherencia La figura siguiente muestra un ejemplo de la modificación de datos durante la transferencia. En el área de datos de destino hay datos de instantes distintos.

① Tamaño máximo del área de datos coherente

Figura 3-5 Ejemplo: modificación de datos durante la transferencia



Coherencia de datos máxima del sistema para el S7-1500: No se producirá ninguna incoherencia si se respeta el tamaño máximo del sistema para los datos coherentes. En el S7-1500 se copian los datos de comunicación de forma coherente en/desde la memoria de usuario en bloques de como máximo 512 bytes durante el ciclo del programa. Para las áreas de datos mayores no se garantiza la coherencia de datos. Si se requiere una coherencia de datos definida, los datos de comunicación del programa de usuario de la CPU no deben exceder los 512 bytes. A estas áreas de datos puede accederse de forma coherente p. ej. desde un dispositivo HMI con lectura/escritura de variables.

Si debe transferirse de manera coherente un volumen de datos mayor que el tamaño máximo específico del sistema, el propio usuario deberá velar por la coherencia de los datos en el programa de usuario tomando las medidas adecuadas.

Asegurar la coherencia de datos Uso de instrucciones para el acceso a datos comunes:

Si el programa de usuario contiene instrucciones de comunicación que acceden a datos comunes, p. ej. TSEND/TRCV, el propio usuario puede coordinar el acceso a esa área de datos, p. ej., con el parámetro "DONE". Por lo tanto, en el programa de usuario puede garantizarse la coherencia de datos de las áreas de datos que se transfieren con una instrucción de comunicación.

Nota Medidas en el programa de usuario

Para conseguir que los datos sean coherentes existe la posibilidad de copiar los datos que deben transferirse a un área de datos separada (p. ej., bloque de datos global). Mientras el programa de usuario sigue trabajando con los datos originales, es posible transferir de forma coherente los datos guardados en el área de datos separada utilizando la instrucción de comunicación.

Para copiar utilice instrucciones que no puedan interrumpirse, como UMOVE_BLK o UFILL_BLK. Dichas instrucciones garantizan la coherencia de datos hasta 16 KB.

Uso de instrucciones PUT/GET o Escribir/Leer vía comunicación HMI:

En la comunicación S7 con las instrucciones PUT/GET o Escribir/Leer vía comunicación HMI debe tenerse en cuenta el tamaño de las áreas de datos coherentes ya durante la programación o configuración. En el programa de usuario de un S7-1500 que actúa de servidor no hay ninguna instrucción que pueda coordinar la transferencia de datos en el programa de usuario. El S7-1500 actualiza los datos intercambiados mediante las instrucciones PUT/GET en el tiempo de ejecución del programa de usuario. No hay ningún instante dentro del procesamiento del programa de usuario cíclico en el que los datos se intercambien de forma coherente. La longitud del área de datos que debe transmitirse debe tener menos de 512 bytes.

Información adicional ● También encontrará el número máximo de datos coherentes en los datos técnicos de los

manuales de producto de los módulos de comunicación.

● Encontrará más información sobre la coherencia de datos en la descripción de las instrucciones de la ayuda en pantalla de STEP 7.

Servicios de comunicación 3.6 Secure communication


3.6 Secure communication

3.6.1 Principios básicos de secure communication Para STEP 7 (TIA Portal) a partir de V14 y para las CPU S7-1500 a partir de la versión de firmware V2.0 se han ampliado considerablemente las posibilidades de una comunicación segura, denominada en adelante "secure communication".

Introducción El atributo "secure" se utiliza para identificar mecanismos de comunicación basados en una Public Key Infrastructure (PKI) (p. ej., RFC 5280 para Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile). Public Key Infrastructure (PKI) es un sistema que permite emitir, asignar y comprobar certificados digitales. Los certificados digitales emitidos se utilizan dentro de PKI para garantizar la comunicación asistida por ordenador. Si una PKI utiliza un procedimiento de claves asimétrico, en una red los mensajes se pueden firmar y cifrar digitalmente.

Los componentes que se han configurado para la Secure Communication en STEP 7 (TIA Portal) utilizan un procedimiento de cifrado asimétrico con clave pública (Public Key) y clave privada (Private Key). Se utiliza el protocolo de cifrado TLS (Transport Layer Security). TLS es el sucesor del protocolo SSL (Secure Sockets Layer).

Objetivos de la secure communication La secure communication se aplica para lograr los siguientes objetivos:

● Confidencialidad es decir, los datos son secretos o ilegibles para fisgones no autorizados.

● Integridad es decir, un mensaje que llega al receptor es el mismo, sin cambios, que ha enviado el emisor. El mensaje no ha sido modificado durante el recorrido.

● Autenticación del punto final es decir, el interlocutor como punto final es exactamente quien dice ser y a quien debe llegar el mensaje. La identidad del interlocutor está comprobada.

Si en el pasado estos objetivos tenían importancia fundamentalmente para el mundo de las TI y para los ordenadores conectados en red, en la actualidad en entornos industriales las máquinas y controladores que contienen datos que precisan protección están expuestos a riesgos debido a su interconexión y plantean requisitos exigentes de intercambio seguro de datos.

Hasta ahora lo más habitual es, y sigue siendo, proteger la célula de automatización mediante el concepto de protección de células a través de firewall o a través de conexión VPN, p. ej., con el Security Modul.

Sin embargo, las necesidades de comunicación incluyen también cada vez más la transmisión de datos a equipos externos en forma cifrada a través de Intranet o redes públicas.



Principios básicos comunes de la secure communication Independientemente del contexto, Secure se basa en el concepto de Public Key Infrastructure (PKI) y contiene los siguientes componentes:

● Un procedimiento de cifrado asimétrico. Este procedimiento permite lo siguiente:

– Cifrado o descifrado de mensajes utilizando claves públicas y privadas.

– Comprobación de firmas en mensajes y certificados.

Los mensajes/certificados son firmados por el emisor/titular del certificado mediante su clave privada. El receptor/validador comprueba la firma con la clave pública del emisor/titular del certificado.

● Transporte y almacenamiento de las claves públicas mediante certificados X.509.

– Los certificados X.509 son datos con firma digital que permiten comprobar la autenticidad de claves públicas en lo que respecta a la identidad asociada.

– Los certificados X.509 pueden contener información que caracteriza con más precisión o limita el uso de claves públicas. Por ejemplo, desde cuándo una clave pública es válida en un certificado y a partir de cuándo no será válida.

– Un certificado X.509 también contiene, protegida, la información relativa al emisor del certificado.

Las explicaciones que siguen muestran una visión general de los conceptos básicos que son necesarios, p. ej., para manejar certificados en STEP 7 (TIA Portal) o para programar las instrucciones de comunicación para secure Open User Communication (sOUC).

Secure Communication con STEP 7 STEP 7 a partir de V14 proporciona la PKI necesaria en cada momento para la configuración y el manejo de una secure communication.

Ejemplos:

● Hypertext Transfer Protokoll (HTTP) se convierte, con ayuda del protocolo TLS (Transport Layer Security), en Hypertext Transfer Protokoll Secure (HTTPS). Dado que HTTPS es una combinación de HTTP y TLS, se denomina "HTTP over TLS" en el correspondiente RFC. En el navegador, el uso de HTTPS se reconoce porque en la barra de direcciones se utiliza el esquema URL "https://" en lugar de "http://". En la mayoría de los navegadores destaca también visualmente la conexión segura proporcionada.

● Open User Communication se convierte en secure Open User Communication. El protocolo base sigue siendo TLS.

● Los proveedores de correo electrónico también ofrecen acceso a través del protocolo "Secure SMTP over TLS", con el fin de aumentar la seguridad de la comunicación por correo electrónico.



La figura siguiente muestra el protocolo TLS en el contexto de las capas de comunicación.

Figura 3-6 Protocolo TLS en el contexto de las capas de comunicación

Secure Communication con OPC UA En las CPU S7-1500, a partir de la versión de firmware V2.0 hay implementado un servidor OPC UA. OPC UA Security incluye también autenticación, cifrado e integridad de datos mediante certificados digitales X.509 y, por tanto, también utiliza una Public Key Infrastructure (PKI). En función de los requisitos de la aplicación, pueden seleccionarse distintos niveles para la seguridad de punto final. Encontrará una descripción de la funcionalidad de servidor OPC UA en el capítulo Comunicación OPC UA (Página 133).

3.6.2 Confidencialidad por cifrado Una contribución importante a la seguridad de los datos es el cifrado de los mensajes. Si un tercero intercepta mensajes cifrados en su recorrido, el fisgón potencial no podrá utilizar los mensajes interceptados.

Existe un gran número de procedimientos matemáticos (algoritmos) para cifrar mensajes.

Todos los algoritmos tienen en común que procesan un parámetro "clave" para cifrar o descifrar mensajes.

● Algoritmo + clave + mensaje => mensaje cifrado

● Mensaje cifrado + clave + algoritmo => mensaje (descifrado)



Cifrado simétrico Lo esencial del procedimiento de cifrado simétrico es que los dos interlocutores utilizan la misma clave para cifrar y para descifrar mensajes, como se representa en la figura siguiente. Bob utiliza la misma clave para cifrar que la que utiliza Alice para descifrar. En general puede decirse que ambas partes comparten un secreto, la clave secreta, con la que pueden cifrar o descifrar un mensaje.

① Bob cifra su mensaje con la clave simétrica ② Alice descifra el mensaje cifrado utilizando la clave simétrica

Figura 3-7 Cifrado simétrico

Intuitivamente el procedimiento es comparable a un maletín del que tanto el emisor como el receptor tienen una llave igual que les permite cerrarlo o abrirlo.

● Ventaja: Los algoritmos de cifrado simétricos (p. ej., AES, Advanced Encryption Algorithm) son rápidos.

● Desventajas: ¿Cómo puede llegar una clave a un receptor sin que caiga en manos equivocadas? Se trata de un problema de distribución de claves. Además, la intercepción de un número suficientemente grande de mensajes permite adivinar la clave, por lo que dicha clave debe establecerse de nuevo con una frecuencia razonable.

Además, con un gran número de interlocutores debe distribuirse también un gran número de claves.

Cifrado asimétrico El procedimiento de cifrado asimétrico trabaja con una pareja de claves, compuesta por una clave pública y una clave privada. En relación con una PKI también se denomina procedimiento de clave pública o simplemente procedimiento PKI: un interlocutor (en la figura de más abajo, Alice) posee una clave privada y una clave pública. La clave pública está a disposición de todo el mundo, es decir, de cualquier interlocutor potencial. Cualquiera que tenga la clave pública puede cifrar mensajes para Alice. En la figura de más abajo esa persona es Bob.



Alice utiliza su clave privada, que debe mantener en secreto, para descifrar un mensaje cifrado dirigido a ella.

① Alice proporciona su clave pública a Bob. Para ello no se necesitan medidas de precaución:

cualquiera puede utilizar la clave pública para enviar mensajes a Alice si está seguro de que es realmente la clave pública de Alice.

② Bob cifra su mensaje con la clave pública de Alice. ③ Alice descifra con su clave privada el mensaje cifrado por Bob. Dado que Alice es la única que

posee la clave privada y nunca la entrega a nadie, es la única que puede descifrar el mensaje. Con la clave privada puede descifrar cualquier mensaje que se haya cifrado con su propia clave pública, no solo el cifrado por Bob.

Figura 3-8 Cifrado asimétrico

Plásticamente, el procedimiento es comparable a un buzón en el que cualquiera puede introducir un mensaje, pero del que únicamente puede extraerlo quien posea su llave.

● Ventajas: un mensaje cifrado con clave pública solo puede ser descifrado por el propietario de la clave privada. Dado que para el descifrado debe utilizarse otra clave (privada), es considerablemente más difícil adivinar la clave de descifrado a partir del conjunto de mensajes descifrados. Por ello no es necesario custodiar en estricto secreto las claves públicas, algo que sí es necesario en el cifrado simétrico.

Otra ventaja estriba en la mayor sencillez de distribución de las claves públicas. En el procedimiento asimétrico no se necesita ningún canal especialmente seguro para transmitir la clave pública del receptor al emisor que cifra los mensajes. Así, la gestión de las claves exige un esfuerzo menor que con el procedimiento de cifrado simétrico.

● Desventajas: algoritmo que precisa muchos cálculos (p. ej. RSA, acrónimo de los tres matemáticos Rivest, Shamir y Adleman) y, por tanto, menor rendimiento en comparación con el cifrado simétrico.



Procedimiento de cifrado en la práctica En la práctica, como ocurre, p. ej., con el servidor web de la CPU o con Secure Open User Communication, se utiliza el protocolo TLS por debajo de la correspondiente capa de aplicación. Ejemplos de capas de aplicación son HTTP o SMTP, como se muestra en el apartado anterior.

TLS (Transport Layer Security) utiliza una combinación de cifrado asimétrico y cifrado simétrico (procedimiento de cifrado híbrido) para la transferencia de datos segura, p. ej., en Internet, y utiliza los protocolos siguientes:

● TLS Handshake Protocol, responsable de la autenticación de los interlocutores y de negociar los algoritmos y las claves que se utilizarán posteriormente para la transferencia de datos, basándose en procedimientos de cifrado asimétrico.

● TLS Record Protocol, responsable del cifrado de los datos de usuario mediante procedimientos simétricos de cifrado e intercambio de datos

Tanto el cifrado asimétrico como el simétrico se consideran procedimientos de cifrado seguros (básicamente no existe diferencia entre ambos procedimientos en cuanto a seguridad). El grado de seguridad depende de los parámetros, p. ej., de la longitud de la clave seleccionada.

Uso ilegítimo del cifrado Una clave pública es una secuencia de bits que no revela la identidad que tiene asignada. Un impostor podría pretender proporcionar su clave pública haciéndose pasar por otra persona. Si un tercero utilizara esa clave creyendo dirigirse al interlocutor deseado, la información confidencial podría acabar en manos del impostor. Entonces el impostor descifraría con su clave privada el mensaje que no estaba destinado a él, y la información confidencial acabaría cayendo en manos equivocadas.

Para evitar estos abusos es necesario crear en los interlocutores la confianza de que están tratando con el interlocutor deseado. Para establecer dicha confianza, en una PKI se utilizan los certificados digitales.

3.6.3 Autenticidad e integridad mediante firmas Los ataques de programas que interceptan la comunicación entre servidor y cliente y que actúan como si ellos mismos fueran el cliente o el servidor se denominan "man-in-the-middle attacks". Si no se detecta su falsa identidad, estos programas son capaces de obtener información importante, p. ej., sobre el programa S7, o de activar valores en la CPU, atacando así a una máquina o a las instalaciones. Para evitar estos ataques se utilizan certificados digitales.

Secure communication utiliza certificados digitales acordes con el estándar X.509 de la International Telecommunication Union (ITU). De este modo es posible comprobar (autenticar) la identidad de un programa, un equipo o una organización.



Cómo crean confianza los certificados La misión fundamental de los certificados X.509 es vincular una identidad que incluye los datos del propietario de un certificado (p. ej., dirección de correo electrónico, nombre del equipo) con la clave pública de la identidad. Las identidades pueden ser personas, equipos o máquinas.

Los certificados son emitidos por entidades emisoras (Certificate Authority, CA) o por el propio titular del certificado. Los sistemas PKI definen cómo tienen que depositar los usuarios su confianza en las entidades emisoras y en los certificados expedidos por las mismas.

El camino hasta el certificado:

1. Quien desea obtener un certificado, presenta una petición a través de una oficina de registro adherida a la entidad emisora.

2. La entidad emisora evalúa la petición y al solicitante, aplicando criterios definidos.

3. Si la identidad del solicitante puede determinarse inequívocamente, la entidad emisora certifica dicha identidad expidiendo un certificado firmado. En ese momento, el solicitante se convierte en titular del certificado.

En la figura siguiente se representa de manera simplificada el procedimiento. No se muestra la posibilidad que tiene Alice de comprobar la firma digital.

Figura 3-9 Firma de un certificado por una entidad emisora

Certificados autofirmados Los certificados autofirmados son aquellos cuya firma procede del titular del certificado, no de una entidad emisora independiente.

Ejemplos:

● Se puede crear y autofirmar un certificado, por ejemplo para cifrar mensajes para un interlocutor. En el ejemplo de arriba, el propio Bob (en vez de Twent) podría firmar su certificado con su clave privada. Utilizando la clave pública de Bob, Alice puede comprobar que la firma y la clave pública de Bob coinciden. Esto es suficiente para una comunicación sencilla que debe desarrollarse cifrada dentro de una instalación.

● Un certificado raíz es, p. ej., un certificado autofirmado por la entidad de certificación (emisora), que incluye la clave pública de la entidad emisora.



Particularidades de los certificados autofirmados Los atributos "CN" (Common Name of Subject) para el titular del certificado y "Issuer" (emisor) de los certificados autofirmados son idénticos: el titular ha autofirmado su certificado. En el campo "CA" (Certificate Autority) debe poner "False", dado que el certificado autofirmado no va a utilizarse para firmar otros certificados.

Los certificados autofirmados no están incluidos en una jerarquía PKI.

Contenido de los certificados Un certificado según el estándar X.509 V3, el que utilizan STEP 7 y las CPU S7-1500, consta esencialmente de los componentes siguientes:

● Clave pública

● Datos sobre el titular del certificado (es decir, el propietario de la clave); puede ser, p. ej., el Common Name (CN) of Subject

● Atributos como el número de serie y la vigencia

● Firma digital (certificación) de la entidad emisora (CA), que certifica que los datos coinciden.

Además existen ampliaciones; p. ej.:

● Indicación de la finalidad para la que se permite usar la clave pública (Key Usage), p. ej., para firmar o para cifrar claves. Si se crea un certificado nuevo con STEP 7, p. ej. en el contexto de Secure Open User Communication, seleccione en la lista de finalidades posibles la entrada correspondiente, p. ej. "TLS".

● Indicación de un "Nombre alternativo del titular del certificado" ("SAN", Subject Alternative Name) que, p. ej., en la comunicación segura con servidores web (HTTP over TLS), se utiliza para garantizar que el certificado pertenece al servidor web que se ha indicado en la URL de la barra de direcciones del navegador web.

Cómo se generan y se verifican las firmas Los requisitos técnicos que permiten comprobar los certificados los proporciona el uso de claves asimétricas: Tomando como ejemplo el certificado "MyCert" se mostrarán los procesos de "firma" y de "comprobación de firma".

Crear firma:

1. El emisor del certificado "MyCert" genera un valor hash a partir de los datos del certificado, utilizando una función resumen o hash determinada (p. ej., SHA-1, Secure Hash Algorithm).

El valor hash es una secuencia de bits de longitud constante. La longitud constante del valor hash ofrece la ventaja de que la firma del valor hash requiere siempre el mismo tiempo.

2. A partir del valor hash generado, el emisor del certificado genera una firma digital utilizando la clave privada. Para ello suele utilizarse el procedimiento de firma RSA.

3. La firma digital se guarda en el certificado. Así, el certificado está firmado.



Verificar firma:

1. El verificador del certificado "MyCert" obtiene el certificado del emisor, y por tanto la clave pública.

2. Con el mismo algoritmo hash utilizado para la firma (p. ej., SHA-1) se forma de nuevo un valor hash a partir de los datos del certificado.

3. A continuación, este valor hash se compara con el valor hash que se obtiene con ayuda de la clave pública del emisor del certificado y el algoritmo de firma para la verificación de la firma.

4. Si la verificación de la firma ofrece un resultado positivo, queda acreditada la identidad del titular del certificado, y por tanto la integridad -es decir, la autenticidad y legitimidad- de su contenido. Cualquiera que tenga la clave pública, es decir, el certificado de la entidad emisora, puede verificar la firma y determinar así que el certificado ha sido firmado efectivamente por la entidad emisora.

En la imagen siguiente se muestra cómo verifica Alice la firma de la clave pública de Bob utilizando la clave pública del certificado de Twent (que encarna la entidad emisora CA). Por tanto, el único requisito para la verificación es que el certificado de la entidad emisora se encuentre disponible en el momento de la verificación. La validación se realiza automáticamente en la sesión de TLS.

Figura 3-10 Verificación de un certificado a través de la clave pública del certificado de una entidad

emisora

Firma de mensajes El método de firma y verificación descrito también utiliza la sesión de TLS para firmar y verificar mensajes:

Si se genera un valor hash de un mensaje y dicho valor hash se firma con la clave privada del emisor y se agrega al mensaje original, el receptor del mensaje estará en condiciones de detectar la integridad del mensaje. El receptor descifra el valor hash utilizando la clave pública del emisor y, a partir del mensaje recibido, genera su propio valor hash y compara ambos valores. Si los valores son distintos, el mensaje ha sido falseado durante el recorrido.



Cadena de certificados hasta el certificado raíz Los certificados de una PKI suelen estar organizados de modo jerárquico: En la cúspide de la jerarquía se encuentran los certificados raíz, también denominados certificados root. Son aquellos que no están certificados por una entidad emisora jerárquicamente superior. El titular y el emisor de los certificados raíz son idénticos. Los certificados raíz se consideran absolutamente fiables, ya que constituyen la piedra de toque de la confianza en la transacción, y por lo tanto al receptor le debe constar de forma fehaciente su fiabilidad. Se almacenan en un área prevista para certificados fiables.

Según la PKI, la función de los certificados raíz puede consistir, p. ej., en firmar certificados de entidades emisoras jerárquicamente inferiores, los denominados certificados intermedios. De este modo, la confianza se traslada del certificado raíz al certificado intermedio. El certificado intermedio puede firmar un certificado igual que un certificado raíz, por lo que ambos se denominan "certificados CA".

Esta jerarquía puede recorrer varios certificados intermedios hasta llegar al certificado de entidad final (end-entity). El certificado de entidad final es el certificado del usuario, que debe identificarse.

Para la validación se recorre la misma jerarquía en sentido contrario: Como se ha descrito anteriormente, se determina el emisor del certificado, se verifica la firma con su clave pública, después se determina el certificado del emisor de certificados jerárquicamente superior hasta que se recorre la cadena de traspaso de confianza completa hasta el certificado raíz.

Resumen: La cadena de certificados intermedios hasta el certificado raíz (la ruta de certificados) debe existir en todo dispositivo que vaya a validar un certificado de entidad final del interlocutor, con independencia del tipo de secure communication que se configure.

3.6.4 Administración de certificados mediante STEP 7 STEP 7 a partir de la versión V14, junto con las CPU S7-1500 a partir de la versión de FW 2.0, soportan la PKI de Internet (RFC 5280) de modo que una CPU S7-1500 es capaz de comunicarse con otros equipos que también soportan la PKI de Internet.

De esto se deriva el uso de certificados X.509, p. ej., para comprobar certificados del modo descrito en los apartados anteriores.

STEP 7, a partir de V14, utiliza una PKI similar a la PKI de Internet. No existe compatibilidad con Certificate Revocation Lists (CRL), p. ej.



Crear o asignar certificados Para los equipos con propiedades de seguridad como, p. ej., una CPU S7-1500 a partir de la versión de firmware V2.0, en STEP 7 se crean certificados para distintas aplicaciones.

Las siguientes áreas de la ventana de inspección de la CPU permiten crear certificados nuevos o seleccionar los ya existentes:

● "Protección y seguridad > Administrador de certificados" para crear o asignar certificados de todo tipo; el tipo de certificado que se crea de modo predeterminado es el certificado TLS para Secure Open User Communication.

● "Servidor web > Seguridad del servidor" para crear o asignar certificados de servidor web.

● "OPC UA > Servidor > Seguridad" para crear o asignar certificados OPC UA.

Figura 3-11 Ajustes de seguridad para una CPU S7-1500 en STEP 7



Peculiaridad del área "Protección y seguridad > Administrador de certificados" Esta es la única área de la ventana de inspección en la que se puede alternar el administrador de certificados global (a escala del proyecto) con el local (a escala del equipo) (opción "Utilizar ajustes globales de seguridad para el administrador de certificados"). Esta opción determina si el usuario tiene acceso a todos los certificados del proyecto o no.

● Si no utiliza el administrador de certificados en los ajustes globales de seguridad, solo podrá acceder al almacén local de certificados de la CPU. Por ejemplo, no podrá acceder a los certificados importados ni a los certificados raíz. Sin estos certificados solo se dispone de funcionalidad limitada; p. ej., solo pueden generarse certificados autofirmados.

● Si utiliza el administrador de certificados de los ajustes globales de seguridad y ha iniciado sesión, p. ej., como administrador, puede acceder al almacén global de certificados para todo el proyecto. P. ej., podrá asignar certificados importados a la CPU o crear certificados emitidos y firmados por la CA del proyecto (entidad emisora del proyecto).

La figura siguiente muestra cómo aparecen los "Ajustes globales de seguridad" en el árbol del proyecto tras activar la opción "Utilizar ajustes globales de seguridad para el administrador de certificados" en la ventana de inspección de la CPU.

Al hacer doble clic en el árbol del proyecto en "Inicio de sesión de usuario" por debajo de los ajustes globales de seguridad e iniciar sesión, también aparece allí, entre otras cosas, la fila "Administrador de certificados".



Al hacer doble clic en la fila "Administrador de certificados", se obtiene acceso a todos los certificados del proyecto, clasificados como "CA" (entidades emisoras), "Certificados de dispositivos" y "Autoridades de certificación raíz y certificados acreditados".

Claves privadas STEP 7 genera claves privadas al crear certificados de dispositivos o certificados de servidor (certificados de entidad final). El lugar donde se almacena la clave privada depende del uso de los ajustes globales de seguridad para el administrador de certificados:

● Si se utilizan los ajustes globales de seguridad, la clave privada se guarda cifrada en el almacén global de certificados (a escala de todo el proyecto).

● Si no se utilizan los ajustes globales de seguridad, la clave privada se guarda cifrada en el almacén local de certificados (específico de CPU).

La existencia de la clave privada necesaria, p. ej., para descifrar datos, se muestra en la columna "Clave privada" de la ficha "Certificados de dispositivos" del administrador de certificados en los ajustes globales de seguridad.

Al cargar la configuración hardware, el certificado de dispositivo, la clave pública y la clave privada se cargan en la CPU.

ATENCIÓN

La opción "Utilizar ajustes globales de seguridad para el administrador de certificados" afecta a la clave privada utilizada hasta el momento. Si ya ha creado certificados sin utilizar el administrador de certificados en los ajustes globales de seguridad y luego cambia la opción para el uso del administrador de certificados, las claves privadas se perderán y la identificación del certificado puede cambiar. Aparecerá un mensaje para advertírselo. Por ello, al iniciar la configuración, elija la opción que será necesaria para la administración de certificados.



3.6.5 Ejemplos de administración de certificados Como se ha descrito en los apartados anteriores, los certificados son obligatorios para cualquier tipo de Secure Communication. A continuación se muestra mediante un ejemplo el modo de manejar los certificados con STEP 7 para que se cumplan las condiciones necesarias para la Secure Open User Communication.

En lo sucesivo se especificará el tipo de dispositivo al que pertenecen los distintos interlocutores implicados. Se describen también los diferentes pasos para el envío de los certificados necesarios a cada uno de los interlocutores. La condición previa es siempre una CPU S7-1500 o un controlador por software S7-1500 con versión de firmware 2.0 o superior.

Por lo general rige lo siguiente:

Durante el establecimiento de una conexión segura ("handshake"), los interlocutores, por lo general, solo transmiten sus certificados de entidad final (certificados de dispositivos).

Por ello, los certificados CA necesarios para verificar el certificado de dispositivo transmitido deben encontrarse en el almacén de certificados del interlocutor en cuestión.

Secure Open User Communication entre dos CPU S7-1500 Dos CPU S7-1500, denominadas PLC_1 y PLC_2, deben intercambiar datos entre sí mediante Secure Open User Communication.

Puede crear los certificados de dispositivo necesarios con STEP 7 y asignarlos a las CPU del modo que se describe a continuación.

Para firmar los certificados de dispositivo se utilizan entidades emisoras de proyecto STEP 7 (CA del proyecto).

Los certificados deben referenciarse mediante su identificación de certificado en el programa de usuario (instrucción de comunicación TCON junto con el correspondiente tipo de datos de sistema, p. ej., TCON_IPV4_SEC). La identificación de certificado es asignada automáticamente por STEP 7 al generar o crear certificados.



Procedimiento STEP 7 carga automáticamente los certificados CA necesarios junto con la configuración hardware en las CPU implicadas, de modo que se cumplen las condiciones para la verificación de certificado de las dos CPU. Por lo tanto, solo es necesario crear los certificados de dispositivo para la CPU en cuestión, y STEP 7 se encarga de todo lo demás.

1. Seleccione PLC_1 y active la opción "Utilizar ajustes globales de seguridad para el administrador de certificados" en el área "Protección y seguridad".

2. Inicie sesión como usuario en el árbol del proyecto en el área "Ajustes globales de seguridad". En los proyectos nuevos se asigna el rol "Administrador" al iniciar sesión por primera vez.

3. Vuelva a PLC_1 en el área "Protección y seguridad". Haga clic en la tabla "Certificados de dispositivo" en una fila vacía de la columna "Titular del certificado" para agregar un certificado nuevo.

4. Haga clic en el botón "Agregar" de la lista desplegable para la selección de un certificado.

Se abre el cuadro de diálogo "Generar nuevo certificado".

5. No modifique las opciones predeterminadas de este cuadro de diálogo, que están pensadas especialmente para Secure Open User Communication (uso: TLS).

Sugerencia: Complete el nombre predeterminado del titular del certificado, en este caso el nombre de la CPU. No modifique el nombre de la CPU para poder identificarla mejor en caso de que deban administrarse muchos certificados de dispositivo.

Ejemplo: PLC_1/TLS se convierte en PLC_1-SecOUC-Chassis17FactoryState.

6. Compile la configuración.

El certificado de dispositivo y el certificado CA forman parte de la configuración.

7. Repita los pasos descritos para PLC_2.

En el paso siguiente debe crear los programas de usuario para el intercambio de datos y cargar las configuraciones junto con el programa.



Utilizar certificados autofirmados en lugar de certificados CA Al crear certificados de dispositivo puede seleccionar la opción "Autofirmado". Puede crear certificados autofirmados sin haber iniciado sesión para los ajustes globales de seguridad. Este procedimiento no es recomendable, ya que los certificados creados de tal modo no se guardan en el almacén global de certificados, y por ello no pueden asignarse directamente a una CPU interlocutora.

Como se ha descrito anteriormente, seleccione con cuidado el nombre del titular del certificado a fin de poder asignar sin dudas el certificado correcto a un dispositivo.

Los certificados autofirmados no permiten realizar la verificación con los certificados CA del proyecto de STEP 7. Para poder verificar certificados autofirmados, debe registrarse el certificado autofirmado del interlocutor en la lista de dispositivos interlocutores de confianza para cada CPU. Para ello debe haber activado la opción "Utilizar ajustes globales de seguridad para el administrador de certificados" y haber iniciado sesión como usuario en los ajustes globales de seguridad.

Para agregar el certificado autofirmado del interlocutor a la CPU, haga lo siguiente:

1. Seleccione PLC_1 y navegue hasta la tabla "Certificados de interlocutores" en el área "Protección y seguridad".

2. Haga clic en una fila vacía de la columna "Titular del certificado" a fin de abrir la lista desplegable para agregar o seleccionar certificados.

3. Seleccione el certificado autofirmado del interlocutor en la lista desplegable y confirme la selección.


Secure Open User Communication entre CPU S7-1500 como cliente TLS y un equipo externo como servidor TLS

Dos dispositivos deben intercambiar datos entre sí a través de una conexión TLS o sesión TLS, p. ej., para intercambiar recetas, datos de producción o datos de calidad:

● Una CPU S7-1500 (PLC_1) como cliente TLS; la CPU usa Secure Open User Communication

● Un equipo externo (p. ej., un Manufacturing Execution System (MES) como servidor TLS

La CPU S7-1500 establece la conexión/sesión TLS con el sistema MES como cliente TLS.

① Cliente TLS ② Servidor TLS



Para la autenticación del servidor TLS, la CPU S7-1500 necesita los certificados CA del sistema MES: el certificado raíz y, si los hay, los certificados intermedios para verificar la ruta del certificado.

Estos certificados deben importarse al almacén global de certificados de la CPU S7-1500.

Para importar certificados del interlocutor, haga lo siguiente:

1. En el árbol del proyecto, abra el administrador de certificados en los ajustes globales de seguridad.

2. Seleccione la tabla adecuada para el certificado que se va a importar (certificados de confianza y entidades emisoras de certificados raíz).

3. Haga clic con el botón derecho del ratón en la tabla para abrir el menú contextual. Haga clic en "Importar" e importe el certificado necesario o los certificados CA necesarios.

Al ser importado, el certificado recibe una identificación de certificado y puede asignarse a un módulo en el siguiente paso.


5. Haga clic en una fila vacía de la columna "Titular del certificado" para agregar los certificados importados.

6. Seleccione los certificados CA necesarios del interlocutor en la lista desplegable y confirme la selección.

Opcionalmente, el sistema MES puede solicitar también un certificado de dispositivo de la CPU (es decir, del cliente TLS) a fin de autenticar la CPU. En este caso, deben ponerse a disposición del sistema MES los certificados CA de la CPU. Para poder importar los certificados al sistema MES es necesario haber exportado antes los certificados CA desde el proyecto de STEP 7 de la CPU. Proceda del siguiente modo:


2. Seleccione la tabla adecuada para el certificado que desea exportar (certificados CA).

3. Con el certificado seleccionado, haga clic con el botón derecho del ratón para abrir el menú contextual.

4. Haga clic en "Exportar".

5. Seleccione el formato de exportación del certificado.




Secure Open User Communication entre una CPU S7-1500 como servidor TLS y un equipo externo como cliente TLS

Si la CPU S7-1500 actúa como servidor TLS y el equipo externo, p. ej., un sistema ERP (Enterprise Resource Planning), establece la conexión/sesión TLS, necesitará los siguientes certificados:

● Para la CPU S7-1500, cree un certificado de dispositivo (certificado de servidor) con clave privada y cárguelo con la configuración hardware en la CPU S7-1500. Para generar el certificado de servidor, active la opción "Firmado por la autoridad de certificación".

La clave privada es necesaria para el intercambio de claves, como ilustra la imagen para el ejemplo de "HTTP over TLS".

● Para el sistema ERP debe exportar el certificado CA del proyecto de STEP 7 e importarlo/cargarlo al sistema ERP. Con el certificado CA, el sistema ERP comprueba el certificado de servidor de S7-1500 que la CPU transmite al sistema ERP durante el establecimiento de la conexión/sesión TLS.

① Servidor TLS ② Cliente TLS

Figura 3-12 Secure OUC entre una CPU S7-1500 y un sistema ERP

En los apartados anteriores encontrará la descripción de las operaciones necesarias.

Secure Open User Communication con un servidor de correo electrónico (SMTP over TLS) Una CPU S7-1500 puede establecer una conexión segura con un servidor de correo electrónico utilizando la instrucción de comunicación TMAIL-C.

Los tipos de datos del sistema TMail_V4_SEC y TMail_QDN_SEC permiten determinar el puerto interlocutor del servidor de correo electrónico a fin de acceder a este mediante "SMTP over TLS".

Figura 3-13 Secure OUC entre una CPU S7-1500 y un servidor de correo electrónico



La condición necesaria para una conexión segura de correo electrónico es la importación del certificado raíz y de los certificados intermedios desde el servidor de correo (Provider) a la memoria global de certificados de la CPU S7-1500. Con ayuda de estos certificados, la CPU puede verificar el certificado de servidor que el servidor de correo envía al establecerse la conexión/sesión TLS.

Para importar certificados del servidor de correo, proceda del siguiente modo:


2. Seleccione la tabla adecuada para el certificado que se va a importar (certificados de confianza y entidades emisoras de certificados raíz).

3. Haga clic con el botón derecho del ratón en la tabla para abrir el menú contextual. Haga clic en "Importar" e importe el certificado necesario o los certificados CA necesarios.

Al ser importado, el certificado recibe una identificación de certificado y puede asignarse a un módulo en el siguiente paso.


5. Haga clic en una fila vacía de la columna "Titular del certificado" para agregar los certificados importados.

6. Seleccione los certificados CA necesarios del interlocutor en la lista desplegable y confirme la selección.

En el paso siguiente debe crear los programas de usuario para la función de cliente de correo electrónico de la CPU y cargar las configuraciones junto con el programa.

3.6.6 Ejemplo: HTTP over TLS A continuación se muestra cómo utilizar los mecanismos descritos para establecer una Secure Communication entre un navegador web y el servidor web de una CPU S7-1500.

En primer lugar se describen las modificaciones para la opción "Permitir acceso solo vía HTTPS" en STEP 7. A partir de STEP 7 V14 es posible modificar el certificado de servidor del servidor web de una CPU S7-1500 con firmware V2.0 o superior: A partir de estas versiones, el certificado de servidor se genera con STEP 7.

Además se muestran los procesos que se ejecutan al solicitar acceso a una página web del servidor web de la CPU con un navegador web de un PC a través de una conexión HTTPS cifrada.



Manejo de certificados de servidor web para las CPU S7-1500 a partir del firmware V2.0 Para las CPU S7-1500 con versión de firmware anterior a V2.0, al ajustar las propiedades del servidor web sin requisitos es posible que se haya elegido la opción "Permitir acceso solo vía HTTPS". Con estas CPU no es necesario ocuparse del manejo de certificados; la propia CPU genera automáticamente los certificados necesarios para el servidor web. Con las CPU S7-1500 con firmware V2.0 o superior, STEP 7 genera el certificado de servidor (certificado de entidad final) para la CPU. En las propiedades de la CPU (Servidor web > Seguridad del servidor) se asigna un certificado de servidor al servidor web. Dado que siempre hay un nombre de certificado de servidor predeterminado, la sencilla configuración del servidor web no varía: Active el servidor web y la opción "Permitir acceso solo vía HTTPS". Al compilar, STEP 7 generará un certificado de servidor con el nombre predeterminado. Tanto si se utiliza el administrador de certificados en los ajustes globales de seguridad como si no, STEP 7 dispone de toda la información necesaria para generar el certificado de servidor. Además existe la posibilidad de determinar las propiedades del certificado de servidor, p. ej., su nombre o su periodo de validez.

Cargar el certificado del servidor web Al cargar la configuración hardware en la CPU, se carga también automáticamente el certificado de servidor creado por STEP 7. ● Si se utiliza el administrador de certificados en los ajustes globales de seguridad, la

entidad emisora del proyecto (certificado CA) firma el certificado de servidor del servidor web. En el momento de la carga se carga también automáticamente el certificado CA del proyecto.

● Si no utiliza el administrador de certificados en los ajustes globales de seguridad, STEP 7 generará el certificado de servidor como certificado autofirmado.

Si se direcciona el servidor web de la CPU a través de la dirección IP de la CPU, cada vez que se cambie la dirección IP de una interfaz Ethernet de la CPU será necesario generar y cargar un nuevo certificado de servidor (certificado de entidad final). La razón es que al cambiar la dirección IP cambia también la identidad de la CPU y, conforme a las reglas de PKI, esta debe certificarse (firmarse). Es posible evitar este problema direccionando la CPU mediante un nombre de dominio en lugar de hacerlo con su propia dirección IP, p. ej., "myconveyer-cpu.room13.myfactory.com". Para ello deberá administrar los nombres de los dominios de las CPU mediante un servidor DNS. Enviar un certificado CA del servidor web al navegador web El usuario que accede vía HTTPS a las páginas web de la CPU debe instalar el certificado CA de la CPU en el navegador web. Si el certificado no está instalado, se mostrará una advertencia con la recomendación de no usar la página. Para ver la página, el usuario tiene que "Agregar una excepción" de forma explícita. El usuario puede descargar un certificado raíz (Certification Authority) válido de la página web "Introducción" del servidor web en "Descargar certificado". STEP 7 ofrece otra posibilidad para ello: Exporte el certificado CA del proyecto con el administrador de certificados en los ajustes globales de seguridad de STEP 7. A continuación importe el certificado CA al navegador.



Ejecución de la Secure Communication La figura siguiente muestra de manera simplificada el esquema de cómo se establece la comunicación ("handshake"), haciendo hincapié en la negociación de las claves que se utilizan para el intercambio de datos (en este caso, mediante HTTP over TLS).

Sin embargo, la secuencia es fundamentalmente la misma en todas las modalidades de comunicación basadas en el uso de TLS, y por lo tanto también en Secure Open User Communication (ver Principios básicos de Secure Communication).

Figura 3-14 Handshake en HTTPS

En la figura no se representan las acciones ejecutadas por parte de Alice (navegador) para verificar el certificado enviado por el servidor web. El hecho de que Alice pueda confiar en el certificado de servidor web transmitido y, por tanto, en la identidad del servidor web, y comenzar el intercambio de datos depende de que la verificación haya resultado positiva.



Pasos concretos para la verificación de la autenticidad del servidor web:

1. Alice debe conocer las claves públicas de todas las entidades emisoras involucradas, es decir, Alice necesita comprobar la cadena de certificados completa del certificado del servidor web (es decir, del certificado de entidad final del servidor web):

Habitualmente Alice tiene en su almacén de certificados el certificado raíz que necesita. Al instalar un navegador web se instala también, p. ej., una serie de certificados raíz de confianza. Si Alice no dispone del certificado raíz, debe descargarlo de la entidad emisora e instalarlo en el almacén de certificados del navegador. La entidad emisora puede ser también el equipo en el que está alojado en servidor web.

Para obtener los certificados intermedios existen las posibilidades siguientes:

– El propio servidor envía a Alice los certificados intermedios necesarios, juntamente con su certificado de entidad final, en forma de mensaje cifrado, para que Alice pueda verificar la integridad de la cadena de certificados.

– Los certificados suelen incluir las URL del correspondiente emisor. Mediante esas URL Alice puede cargar los certificados intermedios necesarios.

Si se manejan certificados en STEP 7, es necesario haber importado previamente al proyecto los certificados intermedios necesarios y el certificado raíz y haberlos asignado al módulo.

2. Con las claves públicas de los certificados, Alice valida las firmas de la cadena de certificados.

3. Debe generar la clave simétrica y transferirla al servidor web.

4. Si el servidor web está direccionado con su nombre de dominio, Alice verificará la identidad del servidor web conforme a las reglas de PKI establecidas en RFC 2818: Puede hacerlo porque la URL del servidor web, en este caso el "Fully Qualified Domain Name" (FQDN), está depositada en el certificado de entidad final del servidor web. Si el certificado introducido en el campo "Subject Alternative Name" coincide con la entrada en la barra de direcciones del navegador, todo está correcto.

Después tiene lugar el intercambio de datos con la clave simétrica, como se muestra en la figura superior.

Servicios de comunicación 3.7 SNMP


3.7 SNMP

3.7.1 Desactivar SNMP El protocolo de gestión de red SNMP (Simple Network Management Protocol) es un protocolo que utilizan diferentes servicios y herramientas para detectar y diagnosticar la topología de red.

Las solicitudes SNMP que pueden recibir las CPU S7-1500 y las CPU S7-1200 están descritas en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/79993228).

SNMP usa el protocolo de transporte UDP. SNMP conoce dos componentes de red, el administrador SNMP y el cliente SNMP. El administrador SNMP vigila los nodos de la red. Los clientes SNMP recopilan en los diversos nodos de red diversa información específica de la red y la depositan de forma estructurada en la MIB (Management Information Base). Estos datos permiten a diferentes servicios y herramientas ejecutar un diagnóstico detallado de la red.

En determinadas ocasiones es aconsejable desactivar SNMP. Ejemplos:

● Las normas de seguridad de la red no permiten utilizar SNMP.

● Se utiliza una solución SNMP propia, p. ej. por medio de instrucciones de comunicación propias.

Si se desactiva SNMP para un dispositivo, ya no estarán disponibles algunas posibilidades de diagnóstico para la topología de red (p. ej., mediante la herramienta PRONETA o el servidor web de la CPU).




Desactivar SNMP Para desactivar SNMP para una de las interfaces integradas de una CPU S7-1500, haga lo siguiente:

1. Cree un bloque de datos en STEP 7 que contenga la estructura del juego de datos B071H.

– La siguiente tabla muestra la estructura del juego de datos B071H.

Byte Elemento Código Explicación 0-1 BlockID F003H Encabezado

La longitud del juego de datos se cuenta a partir del byte 4 "Versión".

2-3 BlockLength 8 4 Versión 01H 5 Subversión 00H 6-7 Reservado - - 8-11 Controlador SNMP Desactiva-

ción/activación de SNMP

Si desea desactivar SNMP, introduzca el valor 0. Si desea activar SNMP, introduzca el valor 1.

2. Transfiera el juego de datos B071H del OB de arranque (OB100) a la CPU con la instrucción WRREC (escribir juego de datos). Utilice para ello el identificador de hardware de una interfaz integrada de la CPU.

3.7.2 Ejemplo: Desactivar SNMP para una CPU 1516-3 PN/DP

Tarea Puesto que las normas de seguridad de la red no permiten SNMP, para una CPU 1516-3 PN/DP debe desactivarse SNMP.

Requisitos ● CPU 1516-3 PN/DP con versión de firmware V2.0

● STEP 7 V14



Solución En primer lugar, cree un bloque de datos que contenga la estructura del juego de datos B071H. La figura siguiente muestra el bloque de datos "Deactivate SNMP". Además del juego de datos B071H, el bloque de datos "Deactivate SNMP" contiene otras variables que se utilizan para transferir el juego de datos. La variable "snmp_deactivate" se utiliza para lanzar la petición de WRREC. Deposite esta variable en el área de memoria remanente para que el valor también esté disponible en el OB de arranque (OB100).

Figura 3-15 Ejemplo: Bloque de datos para desactivar SNMP

Transfiera el juego de datos B071H del OB de arranque (OB100) a la CPU 1516-3 PN/DP con la instrucción WRREC (escribir juego de datos).

En el siguiente código de programa, el juego de datos B071H se transfiere con la instrucción WRREC en un bucle REPEAT UNTIL. ORGANIZATION_BLOCK "Startup" TITLE = "Complete Restart" { S7_Optimized_Access := 'TRUE' } VERSION : 0.1 BEGIN REPEAT "WRREC_DB_1" (REQ := "Deactivate SNMP".snmp_deactivate, //Transfer data record INDEX:=16#B071, //Data record number for SNMP deactivation ID:="Local~PROFINET_interface_1", //any integrated PROFINET Interface DONE => "Deactivate SNMP".snmp_done, ERROR => "Deactivate SNMP".snmp_error, STATUS => "Deactivate SNMP".snmp_status, RECORD := "Deactivate SNMP".snmp_record) //Data record UNTIL "Deactivate SNMP".snmp_done OR "Deactivate SNMP".snmp_error END_REPEAT; END_ORGANIZATION_BLOCK



Utilizar el código del programa El código de programa completo se encuentra aquí.

Para incorporar el código del programa al proyecto, proceda del siguiente modo:

1. Copie todo el código del programa en el portapapeles con los comandos Ctrl+A, Ctrl+C.

2. Abra un editor de textos (p. ej. "Editor").

3. Inserte el contenido del portapapeles en el editor de textos con el comando Ctrl+V.

4. Guarde el documento como archivo scl, p. ej. SNMP_DEACT.scl.

5. Abra el proyecto en STEP 7.

6. Importe el archivo scl como fuente externa. Encontrará más información sobre la importación de fuentes externas en la Ayuda en pantalla de STEP 7.

7. Genere el OB de arranque y los bloques de datos. (Haga clic con el botón derecho del ratón en el archivo scl, menú contextual: "Generar bloques a partir de fuente")

Activar de nuevo SNMP Si los cambios son pequeños, es posible utilizar el código del programa usado anteriormente para activar SNMP.

En el programa de usuario asigne el valor "1" a la variable "Deactivate SNMP".snmp_record.SNMPControl: "Deactivate SNMP".snmp_record.SNMPControl := 1;

En el siguiente arranque de la CPU se activará de nuevo SNMP.


Comunicación PG 4

Características En la comunicación PG, la CPU u otro módulo apto para comunicación intercambia datos con una estación de ingeniería (p. ej., programadora, PC). El intercambio de datos es posible a través de subredes PROFIBUS y PROFINET. También es posible pasar de unas subredes S7 a otras.

La comunicación PG ofrece funciones necesarias para cargar programas y datos de configuración, así como para ejecutar tests y evaluar información de diagnóstico. Estas funciones están integradas en el sistema operativo del módulo apto para comunicación.

Una programadora o un PC puede estar conectado online con una CPU. La programadora o el PC puede utilizar en paralelo como máximo 4 conexiones online (p. ej., hasta 4 CPU).

Requisitos ● La programadora o el PC tiene conexión física con el módulo apto para comunicación.

● Si debe accederse al módulo apto para comunicación mediante routing S7, la configuración hardware debe estar cargada en las estaciones implicadas (router S7 y punto final).

Procedimiento para la conexión online Para la comunicación PG, debe establecerse una conexión online con la CPU:

1. Marque la CPU en el árbol del proyecto de STEP 7.

2. Elija el comando de menú "Online > Establecer conexión online".

Comunicación PG


3. Efectúe los siguientes ajustes para la conexión online en el cuadro de diálogo "Establecer conexión online":

– Seleccione el tipo de interfaz (p. ej., PN/IE) en la lista desplegable "Tipo de interfaz PG/PC".

– En la lista desplegable "Interfaz PG/PC", seleccione la interfaz PG/PC (p. ej., tarjeta Ind. Ethernet) a través de la cual desea establecer la conexión online.

– En la lista desplegable "Conexión con interfaz/subred", seleccione la interfaz o la subred S7 con la cual la programadora o el PC tiene conexión física.

– Si se accede al módulo apto para comunicación mediante un router S7 (gateway), seleccione el router S7 que conecta las subredes implicadas en la lista de selección "Primer gateway".

Figura 4-1 Configurar la comunicación PG

Comunicación PG


4. Haga clic en "Iniciar búsqueda". Al poco tiempo aparecerán en la tabla "Dispositivos compatibles en la subred de destino" todos los dispositivos a los que puede accederse con la comunicación PG.

5. En la tabla "Dispositivos compatibles en la subred de destino", seleccione la CPU correspondiente y confirme con "Conectar".

Información adicional Para más información sobre cómo establecer una conexión online, consulte la ayuda en pantalla de STEP 7.


Comunicación HMI 5

Características En la comunicación HMI, uno o varios dispositivos HMI (p. ej., HMI Basic/Comfort/Mobile Panel) intercambian datos para manejo y visualización con una CPU a través de la interfaz PROFINET o PROFIBUS DP. El intercambio de datos se realiza a través de conexiones HMI.

Si desea crear varias conexiones HMI con una CPU, utilice, p. ej.:

● las interfaces PROFINET y PROFIBUS DP de la CPU;

● CP y CM con las correspondientes interfaces;

Procedimiento para configurar la comunicación HMI En el momento en que se arrastra una variable, p. ej., una variable de un bloque de datos global, a una pantalla de HMI mediante Drag & Drop o a la tabla de variables HMI, STEP 7 crea automáticamente una conexión HMI. Como alternativa también puede crear manualmente la conexión HMI.

Para crear una conexión HMI, haga lo siguiente:

1. Configure el dispositivo HMI en la vista de redes del editor Dispositivos y redes de STEP 7 en una configuración en la que exista la CPU.

2. Seleccione el botón "Conexiones" y, en la lista desplegable, la entrada "Conexión HMI".

3. Trace una línea entre los puntos finales de la conexión (dispositivo HMI y CPU) mediante la función de arrastrar y soltar. Los puntos finales se resaltan en color. Si todavía no existe la subred S7 correspondiente, se creará de forma automática.

Comunicación HMI


4. En la ficha "Conexiones", seleccione la fila de la conexión HMI.

En el área "General" de la ficha "Propiedades" se muestran las propiedades de la conexión HMI, que en parte pueden modificarse.

Figura 5-1 Configurar la comunicación HMI

5. Cargue la configuración hardware en la CPU.

6. Cargue la configuración hardware en el dispositivo HMI.

Información adicional Para más información sobre routing S7 para conexiones HMI, consulte el capítulo Routing S7 (Página 235).

Para más información sobre la configuración de conexiones HMI, consulte la ayuda en pantalla de STEP 7.


Open User Communication 6 6.1 Resumen de Open User Communication

Características de Open User Communication Open User Communication, también denominada "comunicación abierta", permite a la CPU intercambiar datos con otro equipo apto para la comunicación. La Open User Communication presenta las características siguientes:

● Estándar abierto (los interlocutores pueden ser dos CPU SIMATIC o bien una CPU SIMATIC y un dispositivo de terceros adecuado)

● Comunicación mediante distintos protocolos (designados en STEP 7 como "tipos de conexión")

● Alta flexibilidad en relación con las estructuras de datos que deben transferirse; en consecuencia, permite un intercambio de datos abierto con los dispositivos que se desee si estos soportan los tipos de conexión disponibles

● Secure Communication: Para proteger su sistema de automatización, pueden intercambiarse los datos de manera segura a través de Open User Communication. Con la Secure Open User Communication, los datos se envían firmados y cifrados.

● Open User Communication es posible en diferentes sistemas de automatización; ver datos técnicos de los manuales de producto correspondientes. Ejemplos:

– Interfaces PROFINET/Ind. Interfaces Ethernet de las CPU (S7-1500, CPU ET 200SP, Software Controller S7-1500, CPU 1516pro-2 PN)

– Interfaces PROFINET/Ind. Ethernet integradas de módulos de comunicaciones (p. ej., CP 1543-1, CM 1542-1).

Encontrará información sobre Secure Communication en el capítulo Secure communication (Página 36).

Open User Communication 6.2 Protocolos para Open User Communication


6.2 Protocolos para Open User Communication

Protocolos para Open User Communication Para la comunicación abierta se dispone de los siguientes protocolos:

Tabla 6- 1 Protocolos de transporte para la comunicación abierta

Protocolo de transporte A través de interfaz TCP según RFC 793 PROFINET/Industrial Ethernet ISO-on-TCP según RFC 1006 (Class 4) PROFINET/Industrial Ethernet ISO según ISO/IEC 8073 Industrial Ethernet (solo CP 1543-1) UDP según RFC 768 PROFINET/Industrial Ethernet FDL PROFIBUS

Tabla 6- 2 Protocolos de aplicación para la comunicación abierta

Protocolo de aplicación Protocolo de transporte utilizado Modbus TCP TCP según RFC 793 Correo electrónico TCP según RFC 793 FTP TCP según RFC 793

TCP, ISO-on-TCP, ISO, UDP Estos protocolos (excepto UDP) establecen una conexión de transporte con el interlocutor antes de la transferencia de datos. Los protocolos orientados a la conexión se utilizan cuando lo que se requiere es una transferencia de datos segura frente a la pérdida de datos.

Con UDP es posible:

● Unicast a uno o Broadcast a todos los dispositivos de PROFINET a través de la interfaz PROFINET de la CPU o de la interfaz Industrial Ethernet del CP 1543-1

● Multicast a todos los receptores de un circuito multicast a través de la interfaz PROFINET de la CPU* o la interfaz PROFINET/Industrial Ethernet del CP 1543-1

* a partir de la versión de firmware V2.0, la interfaz PROFINET de la CPU soporta como máximo 5 circuitos Multicast

Longitudes máximas de datos de usuario UDP: Encontrará la longitud máxima de datos de usuario soportada para UDP en los datos técnicos de los respectivos manuales de producto.

Open User Communication 6.2 Protocolos para Open User Communication


Protocolos de comunicación vía PROFIBUS: FDL La transferencia de datos a través de una conexión FDL (Fieldbus Data Link) es adecuada para la transferencia de bloques de datos relacionados a un interlocutor de PROFIBUS que soporta el envío o la recepción de acuerdo con el servicio FDL SDA (Send Data with Acknowledge) según EN 50170, vol. 2. Ambos interlocutores tienen los mismos derechos; es decir, cada interlocutor puede iniciar el proceso de envío y recepción en función de los eventos.

De acuerdo con el servicio FDL SDN (Send Data with No Acknowledge) según EN 50170, vol. 2, en FDL es posible:

● Broadcast a todas las estaciones de PROFIBUS a través de la interfaz PROFIBUS del CM 1542-5

● Multicast a todos los receptores de un circuito Multicast a través de la interfaz PROFIBUS del CM 1542-5

Modbus TCP El protocolo Modbus es un protocolo de comunicación con topología en línea basado en una arquitectura maestro/esclavo. En el tipo de transferencia Modbus TCP (Transmission Control Protocol), los datos se transfieren como paquetes TCP/IP.

La comunicación se controla en el programa de usuario exclusivamente con las respectivas instrucciones.

Correo electrónico y FTP Por correo electrónico es posible, p. ej., enviar contenidos de bloques de datos (p. ej., datos de proceso) como datos adjuntos.

La conexión FTP (FTP = funciones de transferencia de archivos) se utiliza para el intercambio de archivos con los dispositivos S7 en ambos sentidos.

En el lado del cliente, la comunicación se controla en el programa de usuario con las respectivas instrucciones.

Ejemplo de aplicación: MQTT Publisher para la CPU SIMATIC S7-1500 El "Message Queue Telemetry Transport" (MQTT) es un protocolo sencillo a nivel TCP/IP. Es adecuado para intercambiar mensajes entre dispositivos con funcionalidad reducida y para la transmisión a través de redes poco fiables.

El ejemplo de aplicación le proporciona un bloque de función que permite implementar el protocolo MQTT en SIMATIC S7-1500.

Encontrará el ejemplo de aplicación en Internet (https://support.industry.siemens.com/cs/ww/es/view/109748872).


Open User Communication 6.3 Instrucciones para Open User Communication


6.3 Instrucciones para Open User Communication

Introducción La Open User Communication se configura mediante la conexión correspondiente (p. ej., conexión TCP) como se indica a continuación:

● mediante programación en los programas de usuario de los interlocutores;

● configurando la conexión en el editor de hardware y de redes de STEP 7.

Independientemente de si la conexión se crea por programación o por configuración, en los programas de usuario de ambos interlocutores siempre se requieren instrucciones para enviar y recibir los datos.

Crear una conexión en el programa de usuario Cuando se crea una conexión por programación, la conexión se establece y deshace en el programa de usuario mediante instrucciones.

En determinados campos de aplicación, se recomienda no crear las conexiones de comunicación de forma estática, por configuración en la configuración hardware, sino hacerlo en el programa de usuario. Las conexiones pueden crearse con una aplicación específica por programación y, en consecuencia, cuando es necesario. La creación de conexiones por programación permite además liberar recursos de conexión después de transferir los datos.

Para cada conexión de comunicación se necesita una estructura de datos que contenga los parámetros para establecer la conexión (p. ej., tipo de datos del sistema "TCON_IP_v4" para TCP).

Los tipos de datos del sistema (SDT) que pone a disposición el sistema tienen una estructura predefinida que no puede modificarse.

Los distintos protocolos tienen estructuras propias (véase la tabla siguiente). Los parámetros se guardan en un bloque de datos ("DB de descripción de la conexión"), p. ej., del tipo de datos del sistema TCON_IP_v4.

Existen dos opciones para especificar el DB con la estructura de datos:

● Recomendación: crear automáticamente el bloque de datos al parametrizar la conexión en las propiedades del editor de programación, con ayuda de la parametrización de la conexión en el caso de las instrucciones TSEND_C, TRCV_C y TCON.

● Crear manualmente el bloque de datos, parametrizarlo y escribirlo directamente en la instrucción Necesario para:

– Secure OUC

– Conexión vía DNS

– Correo electrónico

– FTP

El "DB de descripción de la conexión" permite modificar los parámetros de la conexión.

La programación de la instrucción TCON para crear una conexión de Open User Communication entre dos CPU S7-1500 se describe en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/58875807).




Protocolos, tipos de datos del sistema e instrucciones utilizables para crear conexiones por programación

La tabla siguiente muestra los protocolos de la Open User Communication y los tipos de datos de sistema e instrucciones adecuadas.

Tabla 6- 3 Instrucciones para crear conexiones por programación

Protocolo Tipo de datos del sistema Instrucciones TCP • TCON_QDN

• TCON_IP_v4

Establecer la conexión y enviar/recibir datos mediante: • TSEND_C/TRCV_C • TCON, TSEND/TRCV • TCON, TUSEND/TURCV

(posibilidad de deshacer la conexión mediante TDISCON)

ISO-on-TCP • TCON_IP_RFC

ISO según ISO/IEC 8073 (Class 4)

• TCON_ISOnative1 • TCON_Configured

UDP • TCON_IP_v4 • TADDR_Param • TADDR_SEND_QDN • TADDR_RCV_IP

Establecer la conexión y enviar/recibir datos mediante: • TSEND_C/TRCV_C • TUSEND/TURCV/TRCV


FDL1 • TCON_FDL Establecer la conexión y enviar/recibir datos mediante: • TSEND_C/TRCV_C • TCON, TSEND/TRCV • TCON, TUSEND/TURCV


Modbus TCP • TCON_IP_v4 • TCON_QDN

• MB_CLIENT • MB_SERVER

Correo electrónico • TMAIL_v4 • TMAIL_v6 • TMAIL_FQDN

• TMAIL_C

FTP2 • FTP_CONNECT_IPV43 • FTP_CONNECT_IPV63 • FTP_CONNECT_NAME3

• FTP_CMD

1 Este protocolo solo puede utilizarse a través del CM 1542-5 2 Este protocolo solo puede utilizarse a través del CP 1543-1 3 Tipo de datos definido por el usuario



La tabla siguiente muestra las diferentes conexiones de la Secure Open User Communication y los tipos de datos de sistema e instrucciones adecuadas. Conexión Secure OUC Tipo de datos del siste-

ma Instrucciones

Conexión TCP segura desde una CPU S7-1500 como cliente TLS a un PLC externo (servidor TLS) Conexión TCP segura desde una CPU S7-1500 como servidor TLS a un PLC externo (cliente TLS)

• TCON_QDN_SEC • TSEND_C/TRCV_C • TCON

Conexión TCP segura entre dos estaciones S7-1500

• TCON_IP_V4_SEC1

Conexión segura con un servidor de correo2

• TMAIL_V4_SEC • TMAIL_QDN_SEC

• TMAIL_C (a partir de V5.0)

Conexión Modbus TCP segura • TCON_IP_V4_SEC1 • MB_Client • MB_Server • TCON_QDN_SEC

1 También es posible con CP 1543-1 2 La conexión segura con un servidor de correo también es posible con CP 1543-1 y TMAIL_C

(V4.0)

Crear una conexión por configuración Al crear una conexión por configuración, los parámetros de dirección de la conexión se definen en el editor Dispositivos y redes de STEP 7.

Para enviar y recibir los datos se utilizan las mismas instrucciones que al crear conexiones por programación:

Tabla 6- 4 Instrucciones para enviar/recibir en conexiones configuradas

Protocolo Enviar/recibir en conexiones configuradas Instrucciones utilizables: TCP Enviar/recibir datos mediante:

• TSEND_C/TRCV_C • TSEND/TRCV • TUSEND/TURCV

ISO-on-TCP ISO según ISO/IEC 8073 (Class 4)

UDP Enviar/recibir datos mediante: • TSEND_C/TRCV_C • TUSEND/TURCV

FDL Enviar/recibir datos mediante: • TSEND_C/TRCV_C • TSEND/TRCV • TUSEND/TURCV

Modbus TCP No soportado Correo electrónico No soportado FTP No soportado



Instrucciones adicionales para la comunicación abierta Las siguientes instrucciones pueden utilizarse tanto con conexiones creadas en el programa de usuario como con conexiones configuradas.

● T_RESET: Establecer y interrumpir la conexión

● T_DIAG: Comprobar conexión

Ejemplos básicos de Open User Communication Siemens Online Support proporciona bloques de función (FB) que facilitan el manejo de las instrucciones de la Open User Communication. Encontrará los bloques de función con los correspondientes ejemplos en Internet (https://support.industry.siemens.com/cs/ww/es/view/109747710).

Información adicional En la Ayuda en pantalla de STEP 7 se describen:

● los tipos de datos de usuario y del sistema;

● las instrucciones para la comunicación abierta;

● los parámetros de conexión.

Encontrará más información sobre la asignación y liberación de recursos de conexión en el capítulo Asignación de recursos de conexión (Página 246).

Consulte también Secure Open User Communication (Página 95)


Open User Communication 6.4 Open User Communication con direccionamiento a través de nombres de dominio


6.4 Open User Communication con direccionamiento a través de nombres de dominio

A partir de la versión de firmware V2.0, las CPU S7-1500, las CPU ET 200SP y la CPU 1516pro-2 PN soportan Open User Communication con direccionamiento a través de un Domain Name System (DNS). En la CPU hay un cliente DNC integrado. Para la comunicación mediante DNS se utilizan nombres de dominio como alias para direcciones IP a fin de direccionar interlocutores. Es posible direccionar interlocutores a través de nombres de dominio para comunicación abierta mediante TCP y UDP.

El requisito para la comunicación mediante DNS es que en la red exista al menos un servidor DNS.

El controlador por software S7-1500 soporta la comunicación mediante DNS para todas las interfaces asignadas al controlador por software.

Configurar la comunicación vía DNS Para que una CPU pueda establecer una conexión con un interlocutor mediante el nombre de dominio de este, el cliente DNS de la CPU debe conocer la dirección IPv4 de al menos un servidor DNS. La CPU soporta hasta 4 servidores DNS distintos.

Para configurar la comunicación mediante nombres de dominio para una CPU S7-1500, haga lo siguiente:

1. Seleccione la CPU en la vista de redes de STEP 7.

2. En la ventana de inspección, navegue hasta "Propiedades" > "General" > "Configuración DNS".

3. En la tabla "Lista de servidores", introduzca la dirección IPv4 de un servidor DNS en la columna "Direcciones de servidor DNS". Puede introducir hasta 4 direcciones IPv4 de servidores DNS.

Figura 6-1 Introducción de direcciones de servidor DNS en el caso de una CPU 1516-3 PN/DP



Configurar una conexión TCP mediante el nombre de dominio del interlocutor Para la comunicación TCP mediante el nombre de dominio, el usuario debe crear un bloque de datos del tipo de datos del sistema TCON_QDN, parametrizarlo y llamarlo directamente en la instrucción. Las instrucciones TCON, TSEND_C y TRCV_C soportan el tipo de datos del sistema TCON_QDN: Para crear una conexión TCP mediante el nombre de dominio del interlocutor, haga lo siguiente:

1. Cree un bloque de datos global en el árbol del proyecto.

2. Defina en el bloque de datos global una variable del tipo de datos TCON_QDN.

El siguiente ejemplo muestra el bloque de datos global "Data_block_1" en el que está definida la variable "DNS Connection1" del tipo de datos TCON_QDN.

Figura 6-2 Tipo de datos TCON_QDN

3. Programe los parámetros de la conexión TCP (p. ej., el nombre completo de dominio (FQDN)) en la variable del tipo de datos TCON_QDN.

4. Cree una instrucción TCON en el editor de programas.

5. Interconecte el parámetro CONNECT de la instrucción TCON con la variable del tipo de datos TCON_QDN.

En el siguiente ejemplo el parámetro CONNECT de la instrucción TCON está interconectado con la variable "DNS connection1" (tipo de datos TCON_QDN).

Figura 6-3 Instrucción TCON



Direccionar una conexión UDP mediante el nombre de dominio del interlocutor Al enviar datos a través de UDP, para las CPU S7-1500 con versión de firmware V2.0 o superior el receptor se puede direccionar con su nombre de dominio completo (FQDN). Para ello, en la instrucción TUSEND, parámetro ADDR, remita a una estructura del tipo TADDR_SEND_QDN.

El receptor puede devolver una dirección IPv4 o una dirección IPv6. Para ello remita a una estructura del tipo TADDR_RCV_IP en el parámetro ADDR de la instrucción TURCV. Es la única que puede acoger ambos tipos de direcciones IP.

Nota Carga de red

Al contrario que TCP, el protocolo UDP no trabaja orientado a la conexión. Con cada flanco en el parámetro de bloque REQ, la instrucción TUSEND o TURCV consulta al servidor DNS. Esto puede provocar una carga elevada de la red o del servidor DNS.

Información adicional Encontrará más información acerca de los tipos de datos del sistema TCON_QDN, TADDR_SEND_QDN y TADDR_RCV_IP en la Ayuda en pantalla de STEP 7.

Encontrará las instrucciones para configurar una conexión TCP segura mediante el nombre de dominio del interlocutor en el capítulo Secure Open User Communication (Página 95).

Open User Communication 6.5 Configurar la Open User Communication vía TCP, ISO-on-TCP, UDP e ISO


6.5 Configurar la Open User Communication vía TCP, ISO-on-TCP, UDP e ISO

Parametrización de la conexión para las instrucciones TSEND_C, TRCV_C o TCON Requisitos: se ha creado una instrucción TSEND_C, TRCV_C o TCON en el editor de programación.

1. Seleccione un bloque de la Open User Communication TCON, TSEND_C o TRCV_C en el editor de programación.

2. Abra la ficha "Propiedades > Configuración" en la ventana de inspección.



3. Seleccione el grupo "Parámetros de la conexión". Mientras no se haya seleccionado ningún interlocutor, solo estará activa la lista desplegable vacía del punto final del interlocutor. Todas las demás entradas posibles estarán desactivadas.

Se muestran los parámetros de conexión que ya se conocen:

– Nombre del punto final local

– Interfaz del punto final local

– Dirección IPv4 del punto final local

Figura 6-4 Parametrización de la conexión para TSEND_C



4. Seleccione un interlocutor en la lista desplegable del punto final del interlocutor. El interlocutor puede ser un dispositivo sin especificar o una CPU del proyecto. Seguidamente, se registrarán automáticamente algunos parámetros de la conexión como valores predeterminados.

Se ajustan los parámetros siguientes:

– Nombre del punto final del interlocutor

– Interfaz del punto final del interlocutor

– Dirección IPv4 del punto final del interlocutor

Si los interlocutores están conectados en red, se muestra el nombre de la subred.

5. Elija entre utilizar bloques de programa o conexiones configuradas en la lista desplegable "Modo de configuración".



6. En la lista desplegable "Datos de conexión" seleccione un DB existente de descripción de la conexión o, para conexiones configuradas, una conexión existente en "Nombre de conexión". También es posible crear otro DB de descripción de la conexión u otra conexión configurada. Posteriormente puede seleccionar otros DB de descripción de la conexión o conexiones configuradas o bien modificar los nombres de los DB de descripción de la conexión para crear bloques de datos nuevos:

– El bloque de datos seleccionado también se ve en el conexionado del parámetro de entrada CONNECT de la instrucción seleccionada TCON, TSEND_C o TRCV_C.

– Si ya se ha indicado un DB de descripción de la conexión para el interlocutor mediante el parámetro CONNECT de la instrucción TCON, TSEND_C o TRCV_C, podrá utilizarse dicho DB o bien crearse uno nuevo.

– Si se edita el nombre del bloque de datos visualizado en la lista desplegable, se genera automáticamente un bloque de datos nuevo con el nombre modificado pero con la misma estructura y el mismo contenido y se utiliza para la conexión.

– Los nombres modificados de un bloque de datos tienen que ser unívocos en el contexto del interlocutor.

– Dependiendo del tipo de CPU y de la conexión, un DB de descripción de la conexión debe tener la estructura TCON_Param, TCON_IP_v4 o TCON_IP_RFC.

– No es posible seleccionar un bloque de datos para un interlocutor sin especificar.

Tras seleccionar o crear el DB de descripción de la conexión o la conexión configurada se determinan y registran más valores.

Para interlocutores especificados vale lo siguiente:

– Tipo de conexión ISO-on-TCP

– ID de conexión con el valor predeterminado 1

– Establecimiento activo de la conexión por el interlocutor local

– ID de TSAP para S7-1200/1500: E0.01.49.53.4F.6F.6E.54.43.50.2D.31

Para interlocutores sin especificar vale lo siguiente:

– Tipo de conexión TCP

– Puerto interlocutor 2000

Para una conexión configurada con interlocutor especificado vale lo siguiente:


– ID de conexión con el valor predeterminado 257

– Establecimiento activo de la conexión por el interlocutor local

– Puerto interlocutor 2000

Para una conexión configurada con interlocutor no especificado vale lo siguiente:


– Puerto local 2000



7. Indique una ID de conexión para el interlocutor si es necesario. Para un interlocutor sin especificar, no es posible asignar una ID de conexión.

Nota

Para un interlocutor conocido se debe introducir un valor unívoco para la ID de conexión. La univocidad de la ID de conexión no es verificada por la parametrización de conexiones y al crear una conexión no se registra ningún valor predeterminado para la ID de la conexión.

8. Seleccione el tipo de conexión deseado en la lista desplegable correspondiente. Los detalles de la dirección se ajustan con valores predeterminados en función del tipo de conexión. Puede elegir entre:

– TCP

– ISO-on-TCP

– UDP

– ISO (solo con Modo de configuración "Utilizar conexión configurada")

Los campos de entrada se editan en los detalles de la dirección. Según sea el protocolo ajustado, se pueden editar los puertos (para TCP y UDP) o los TSAP (para ISO-on-TCP e ISO).

9. Ajuste el comportamiento de establecimiento de la conexión con los botones de opción "Establecimiento activo de la conexión" en TCP, ISO e ISO-on-TCP. Existe la posibilidad de elegir qué interlocutor debe establecer la conexión activamente.

La parametrización de la conexión comprueba inmediatamente si los valores modificados presentan errores de entrada y los registra en el bloque de datos para la descripción de la conexión.

Nota

La Open User Communication entre dos interlocutores sólo funcionará cuando se haya cargado en el hardware también la parte del programa destinada al punto final del interlocutor. Para que la comunicación funcione, asegúrese de no cargar en el dispositivo únicamente la descripción de la conexión de la CPU local, sino también la de la CPU interlocutora.

Configuración de conexiones (para TSEND/TRCV, p. ej.) Si, p. ej., desea utilizar las instrucciones de TSEND/TRCV para la comunicación abierta, debe configurar primero una conexión (p. ej., una conexión TCP).

Para configurar una conexión TCP, haga lo siguiente:

1. Configure los interlocutores en la vista de redes del editor Dispositivos y redes de STEP 7.

2. Seleccione el botón "Conexiones" y, en la lista desplegable, el tipo de conexión "Conexión TCP".



3. Conecte los interlocutores entre sí mediante la función de arrastrar y soltar (a través de la interfaz o el punto final local). Si todavía no existe la subred S7 correspondiente, se creará de forma automática.

Como alternativa, también puede crear una conexión con interlocutores no especificados.

4. Seleccione la conexión creada en la vista de redes.

5. Si es necesario, en la sección "General", ficha "Propiedades", configure las propiedades de la conexión, p. ej., el nombre de la conexión y las interfaces utilizadas de los interlocutores.

Ajuste la dirección del interlocutor para las conexiones con un interlocutor sin especificar. La ID local se encuentra en el área "ID local" (referencia a la conexión en el programa de usuario).

6. Seleccione en el árbol del proyecto la carpeta "Bloques de programa" de una de las dos CPU y abra el OB 1 en la carpeta haciendo doble clic. Se abre el editor de programación.

7. Seleccione en la Task Card "Instrucciones", en el área "Comunicación", "Open User Communication", la instrucción deseada, p. ej., TSEND y desplácela a un segmento del OB 1 mediante arrastrar y soltar.

8. Asigne en el parámetro ID de la instrucción la ID local de la conexión configurada que debe utilizarse para la transferencia de datos.

9. Interconecte el parámetro "DATA" de la instrucción TSEND con los datos de usuario, p. ej., en un bloque de datos.

10.Cargue la configuración hardware y el programa de usuario en la CPU.

Cree la conexión en la CPU interlocutora con la instrucción de recepción, TRCV siguiendo el procedimiento anterior y cárguela en la CPU.



Particularidad en las conexiones ISO con CP 1543-1 Si se utiliza el tipo de conexión "Conexión ISO", debe activarse la casilla de verificación "Utilizar protocolo ISO" en las propiedades del CP para que funcione el direccionamiento a través de direcciones MAC.

Figura 6-5 Elegir protocolo ISO CP 1543-1

Información adicional En la ayuda en pantalla de STEP 7 se describen:



El comportamiento de las instrucciones TSEND_C y TRCV_C en S7-1500 se describe en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/109479564).


Open User Communication 6.6 Configurar la comunicación vía FDL


6.6 Configurar la comunicación vía FDL

Requisitos ● Software de configuración: STEP 7 Professional V14

● Punto final de la conexión: CPU S7-1500 a partir de la versión de firmware V2.0 con el módulo de comunicación CM 1542-5 con la versión de firmware V2.0

Crear una conexión FDL configurada Para crear en STEP 7 una conexión FDL configurada, proceda del siguiente modo:

1. Cree una instrucción TSEND_C en el editor de programas.

2. Seleccione la instrucción TSEND_C y navegue a "Propiedades" > "General" > "Parámetros de conexión" en la ventana de inspección.

3. Seleccione el punto final del interlocutor en Punto final. Utilice uno de los dos puntos finales del interlocutor siguientes:

– CPU S7-1500 con CM 1542-5

– Sin especificar

4. En Tipo de configuración elija "Utilizar conexión configurada de".

5. En tipo de conexión, seleccione "FDL".

6. Seleccione las siguientes interfaces en Interfaz:

– Local: interfaz PROFIBUS del CM 1542-5

– Interlocutor especificado: interfaz PROFIBUS del CM 1542-5

7. En Datos de conexión seleccione el ajuste <nuevo>.



La figura siguiente muestra una conexión FDL completamente configurada en STEP 7.

Figura 6-6 Configurar una conexión FDL

Configurar una conexión FDL en el programa de usuario Para la comunicación vía FDL, el propio usuario debe crear el bloque de datos del tipo de datos del sistema TCON_FDL, parametrizarlo y llamarlo directamente en la instrucción. Proceda del siguiente modo:


2. Defina en el bloque de datos global una variable del tipo de datos TCON_FDL.

El ejemplo siguiente muestra el bloque de datos global "FDL_connection" en el que está definida la variable "FDL_connection" del tipo de datos TCON_FDL.

Figura 6-7 Programar una conexión FDL

3. Programe los parámetros de la conexión FDL (p. ej. las direcciones PROFIBUS) en la variable del tipo de datos TCON_FDL.



4. Cree una instrucción TCON en el editor de programas.

5. Interconecte el parámetro CONNECT de la instrucción TCON con la variable del tipo de datos TCON_FDL.

En el siguiente ejemplo el parámetro CONNECT de la instrucción TCON está interconectado con la variable "FDL_Connection" (tipo de datos TCON_FDL).

Figura 6-8 Ejemplo: Instrucción TCON para conexión FDL

Open User Communication 6.7 Configurar la comunicación vía Modbus TCP


6.7 Configurar la comunicación vía Modbus TCP

Crear una conexión mediante el programa de usuario para Modbus TCP La parametrización se realiza en el editor de programación, en la instrucción MB_CLIENT o MB_SERVER.

Procedimiento para configurar la comunicación vía Modbus TCP La instrucción MB_CLIENT permite la comunicación como cliente Modbus TCP a través de la conexión TCP. Con esta instrucción se establece una conexión entre el cliente y el servidor, se envían peticiones Modbus al servidor y se reciben las respuestas Modbus correspondientes. Además, con esta instrucción se controla la desconexión de la comunicación TCP.

La instrucción MB_SERVER permite la comunicación como servidor Modbus TCP a través de una conexión TCP. La instrucción permite procesar peticiones de conexión de un cliente Modbus, recibir y procesar peticiones Modbus y enviar mensajes de respuesta. También puede controlarse la desconexión de la conexión TCP.

Requisitos: El cliente puede acceder al servidor en la red mediante comunicación IP.

1. En la vista de redes del editor Dispositivos y redes de STEP 7, configure un sistema de automatización S7-1500 con CPU.

2. Seleccione en el árbol del proyecto la carpeta "Bloques de programa" de la CPU y abra el OB 1 en la carpeta haciendo doble clic. Se abre el editor de programación.

3. Seleccione en la Task Card "Instrucciones", en el área "Comunicación", "Otras", "MODBUS TCP", la instrucción deseada, p. ej., MB_CLIENT y desplácela a un segmento del OB 1 mediante arrastrar y soltar.



4. Parametrice la instrucción MB_CLIENT o MB_SERVER. Al hacerlo, observe las siguientes reglas:

Para cada conexión MB_CLIENT debe especificarse una dirección IPv4 del servidor.

Toda conexión MB_CLIENT o MB_SERVER debe utilizar un DB de instancia unívoco con la estructura de datos TCON_IP_v4 o TCON_QDN.

Toda conexión requiere una ID de conexión unívoca. Las ID de conexión y los DB de instancia se agrupan por pares y deben ser unívocos para cada conexión.

Figura 6-9 MB_CLIENT

Figura 6-10 MB_SERVER

5. Cargue la configuración hardware y el programa de usuario en la CPU.



Servidor Modbus TCP como gateway a Modbus RTU Si se utiliza un servidor Modbus TCP como gateway a un protocolo Modbus RTU, el dispositivo esclavo debe direccionarse en la red serie mediante el parámetro estático MB_UNIT_ID. El parámetro MB_UNIT_ID equivale al campo de la dirección de esclavo en el protocolo Modbus RTU. En tal caso, el parámetro MB_UNIT_ID reenviaría la petición a la dirección de esclavo Modbus RTU correcta.

La función de gateway debe programarla el propio usuario.

El parámetro MB_UNIT_ID se encuentra en el bloque de datos de instancia correspondiente a la instrucción MB_CLIENT.

Para más información acerca del parámetro MB_UNIT_ID, consulte la Ayuda en pantalla de STEP 7.

Comunicación Modbus TCP entre dos CPU S7-1500 La programación y parametrización de la comunicación Modbus TCP entre dos CPU S7-1500 se describe en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/94766380).


Open User Communication 6.8 Configuración de la comunicación por correo electrónico


6.8 Configuración de la comunicación por correo electrónico

Creación de una conexión en el programa de usuario para correo electrónico Para la comunicación a través de correo electrónico, el propio usuario debe crear el bloque de datos del tipo de datos del sistema correspondiente, parametrizarlo y llamarlo directamente en la instrucción. El procedimiento se describe a continuación.

Procedimiento para configurar la comunicación por correo electrónico Una CPU puede enviar mensajes de correo electrónico. Para enviar mensajes de correo electrónico desde el programa de usuario de la CPU, utilice la instrucción TMAIL_C.

Requisitos: se puede acceder al servidor SMTP a través de la red IPv4.

1. En la vista de redes del editor Dispositivos y redes de STEP 7, configure un sistema de automatización S7-1500 con CPU.

2. Parametrice la instrucción TMAIL_C, introduzca el asunto del correo en Subject, por ejemplo.

3. Cree una variable del tipo TMAIL_v4, TMAIL_v6 (solo CP 1543-1) o bien TMAIL_FQDN (solo CP 1543-1) en un bloque de datos global.

4. Configure los parámetros de la conexión TCP en la columna "Valor de arranque" de la variable. P. ej., introduzca la dirección IPv4 del servidor de correo en "MailServerAdress" (para TMAIL_v4).

Nota

Parámetros de conexión InterfaceId e ID

Tenga en cuenta que, a partir de la implementación V5.0 de la instrucción TMAIL_C, puede introducir el valor "0" para InterfaceId e ID en el tipo de datos TMAIL_V4_SEC. En este caso, la CPU busca ella misma una interfaz local adecuada de la CPU o una ID de conexión libre.

Interconecte la variable con el parámetro MAIL_ADDR_PARAM de la instrucción TMAIL_C.



● los tipos de datos del sistema;



Open User Communication 6.9 Configuración de la comunicación vía FTP


6.9 Configuración de la comunicación vía FTP

Creación de una conexión en el programa de usuario para FTP Para la comunicación vía FTP, el propio usuario debe crear el bloque de datos del tipo de datos del sistema correspondiente, parametrizarlo y llamarlo directamente en la instrucción. El procedimiento se describe a continuación.

Funcionalidad de cliente y servidor FTP Pueden enviarse archivos desde una CPU a un servidor FTP y recibirse desde este. En el S7-1500, la comunicación vía FTP solo es posible a través del CP 1543-1. El CP puede ser servidor FTP, cliente FTP o ambas cosas. Los clientes FTP también pueden ser sistemas de terceros o PC.

Para la funcionalidad de servidor FTP, configure el CP en STEP 7 de la manera correspondiente.

La funcionalidad de cliente FTP permite, p. ej., establecer y deshacer una conexión FTP, así como transferir y borrar archivos del servidor. Para la funcionalidad de cliente FTP, utilice la instrucción FTP_CMD.



Procedimiento para configurar la funcionalidad de servidor FTP Requisitos: se puede acceder al servidor FTP a través de la red IPv4. 1. Configure un sistema de automatización S7-1500 con CPU y CP 1543-1 en la vista de

dispositivos del editor Dispositivos y redes de STEP 7.

Al mismo tiempo, deberá activar la casilla "Permitir acceso vía comunicación PUT/GET del interlocutor remoto (PLC, HMI, OPC...)" en la configuración hardware de la CPU S7-1500, en la navegación local "Protección", apartado "Mecanismos de conexión".

2. Realice los siguientes ajustes en las propiedades del CP, en "Configuración FTP":

– Seleccione la casilla de verificación "Utilice un servidor FTP para datos de una CPU S7".

– Asigne la CPU, un bloque de datos y un nombre de archivo con el que se guardará el DB para FTP.

Figura 6-11 Crear la configuración FTP

3. Cargue la configuración hardware en la CPU.



Procedimiento para configurar la funcionalidad de cliente FTP Requisitos: se puede acceder al servidor FTP a través de la red IPv4.

1. Configure un sistema de automatización S7-1500 con CPU y CP 1543-1 en la vista de dispositivos del editor Dispositivos y redes de STEP 7.

Al mismo tiempo, deberá activar la casilla "Permitir acceso vía comunicación PUT/GET del interlocutor remoto (PLC, HMI, OPC...)" en la configuración hardware de la CPU S7-1500, en la navegación local "Protección", apartado "Mecanismos de conexión".

2. Llame la instrucción FTP_CMD en el programa de usuario de la CPU.

3. Configure los parámetros de conexión para el servidor FTP en la instrucción FTP_CMD.

4. Cree un DB global y, dentro de él, una variable del tipo FTP_CONNECT_IPV4, FTP_CONNECT_IPV6 o bien FTP_CONNECT_NAME.

5. Interconecte la variable en el bloque de datos con la instrucción FTP_CMD.

6. Para la conexión con el servidor FTP, indique en el DB:

– el nombre de usuario, la contraseña y la dirección IP para el acceso FTP en el tipo de datos correspondiente (FTP_CONNECT_IPV4, FTP_CONNECT_IPV6 o FTP_CONNECT_NAME)


Ejemplos de aplicación ● Ejemplo de aplicación: Comunicación FTP con S7-1500 y CP 1543-1

Encontrará el ejemplo de aplicación en Internet (https://support.industry.siemens.com/cs/ww/es/view/103550797).

● Ejemplo de aplicación: Evaluación de la comunicación mediante cliente FTP con S7-1200/1500 Encontrará el ejemplo de aplicación en Internet (https://support.industry.siemens.com/cs/ww/es/view/81367009).


● los tipos de datos del sistema;





Open User Communication 6.10 Establecer y deshacer relaciones de comunicación


6.10 Establecer y deshacer relaciones de comunicación

Establecimiento y desconexión de relaciones de comunicación En la tabla siguiente se muestra el establecimiento y la desconexión de relaciones de comunicación en el contexto de la comunicación abierta.

Tabla 6- 5 Establecimiento y desconexión de relaciones de comunicación

Crear la conexión Establecer la relación de comunicación Deshacer la relación de comunicación En el programa de usuario Después de cargar el programa de usuario

en las CPU: El interlocutor pasivo crea el acceso local llamando TSEND_C/TRCV_C o TCON. La llamada de TSEND_C/TRCV_C o TCON en el interlocutor activo inicia el establecimiento de la conexión. Si la conexión se ha podido establecer, se emite una notificación positiva en las instrucciones del programa de usua-rio. Tras deshacer la conexión con la instrucción T_RESET, la conexión vuelve a establecer-se. En caso de interrumpirse la conexión, el interlocutor activo intenta volver a establecer la conexión creada. Esto solo es válido si previamente se ha establecido correctamen-te la conexión con TCON.

• Con las instrucciones TSEND_C/TRCV_C, TDISCON y T_RESET

• Cuando la CPU pasa del estado operati-vo RUN a STOP

• Tras un POWER OFF/POWER ON en una CPU

En la configuración de co-nexiones

Después de cargar la configuración de co-nexiones y el programa de usuario en las CPU.

Borrando la configuración de conexiones de STEP 7 y cargando la configuración modifi-cada en la CPU.

Open User Communication 6.11 Secure Open User Communication


6.11 Secure Open User Communication

6.11.1 Secure OUC de una CPU S7-1500 como cliente TLS a un PLC externo (servidor TLS)

A continuación se describe cómo configurar una Secure Open User Communication mediante TCP desde una CPU S7-1500 en funciones de cliente TLS hasta un servidor TLS.

Configurar una conexión TCP segura desde una CPU S7-1500 como cliente TLS hasta un servidor TLS

A partir de la versión de firmware V2.0, las CPU S7-1500 soportan Secure Communication con direccionamiento a través de un Domain Name System (DNS).

Para la comunicación TCP segura a través del nombre de dominio, el usuario debe crear un bloque de datos del tipo de datos del sistema TCON_QDN_SEC, parametrizarlo y llamarlo directamente en la instrucción TSEND_C, TRCV_C o TCON.

Requisitos:

● La fecha y hora actuales están ajustadas en la CPU.

● En la red existe al menos un servidor DNS.

● Se ha configurado al menos un servidor DNS para la CPU S7-1500.

● El cliente TLS y el servidor TLS disponen de todos los certificados necesarios.



Para crear una conexión TCP segura con un servidor TCP, haga lo siguiente:


2. Defina en el bloque de datos global una variable del tipo de datos TCON_QDN_SEC.

El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "DNS ConnectionSEC" del tipo de datos TCON_QDN_SEC.

Figura 6-12 Tipo de datos TCON_QDN_SEC

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "RemoteQDN" el nombre de dominio completo (FQDN) del servidor TLS.



4. Configure los parámetros para Secure Communication en la columna "Valor de arranque".

– "ActivateSecureConn": Activación de Secure Communication para esta conexión. Si este parámetro tiene el valor FALSE, los parámetros de seguridad siguientes son irrelevantes. En tal caso es posible crear una conexión TCP o UDP no segura.

– "ExtTLSCapabilities": Si se introduce el valor 1, el cliente valida el subjectAlternateName en el certificado X.509-V3 del servidor para comprobar la identidad del servidor. Esta validación se realiza en el contexto de la instrucción.

– "TLSServerCertRef": ID del certificado X.509-V3 (habitualmente un certificado CA) que el cliente TLS utiliza para validar la autenticación del servidor TLS. Si este parámetro es 0, para validar la autenticación del servidor el cliente TLS utiliza todos los certificados (CA) que hay actualmente cargados en el Certificate Store del cliente.

Figura 6-13 Administración de certificados desde el punto de vista de S7-1500 como cliente

TLS

– "TLSClientCertRef": ID del certificado X.509-V3 propio.



5. Cree una instrucción TSEND_C, TRCV_C o TCON en el editor de programas.

6. Interconecte el parámetro CONNECT de una de las instrucciones TSEND_C, TRCV_C o TCON con la variable del tipo de datos TCON_QDN_SEC.

En el siguiente ejemplo, el parámetro CONNECT de la instrucción TCON está interconectado con la variable "DNS connectionSEC" (tipo de datos TCON_QDN_SEC).


Información adicional Encontrará más información acerca del tipo de datos del sistema TCON_QDN_SEC en la Ayuda en pantalla de STEP 7.

Encontrará más información sobre la comunicación segura en el capítulo Secure communication (Página 36).

6.11.2 Secure OUC de una CPU S7-1500 como servidor TLS a un PLC externo (cliente TLS)

A continuación se describe cómo configurar una Secure Open User Communication mediante TCP desde una CPU S7-1500 en funciones de servidor TLS hasta un cliente TLS.

Configurar una conexión TCP segura mediante el nombre de dominio del interlocutor A partir de la versión de firmware V2.0, las CPU S7-1500 soportan Secure Communication con direccionamiento a través de un Domain Name System (DNS).

Para la comunicación TCP segura a través del nombre de dominio, el usuario debe crear un bloque de datos del tipo de datos del sistema TCON_QDN_SEC, parametrizarlo y llamarlo directamente en la instrucción TSEND_C, TRCV_C o TCON.

Requisitos:


● En la red existe al menos un servidor DNS.



● Se ha configurado al menos un servidor DNS para la CPU S7-1500.




Para crear una conexión TCP segura con un cliente TLS, haga lo siguiente:


2. Defina en el bloque de datos global una variable del tipo de datos TCON_QDN_SEC.

El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "DNS ConnectionSEC" del tipo de datos TCON_FDL_SEC.

Figura 6-15 TCON_QDN_SEC_Server

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "ID" la ID local de la conexión TCP.





– "TLSServerReqClientCert": Solicitud de un certificado X.509-V3 del cliente TLS.

– "TLSServerCertRef": ID del certificado X.509-V3 propio.

Figura 6-16 Administración de certificados desde el punto de vista de S7-1500 como servidor

TLS

– "TLSClientCertRef": ID del certificado X.509-V3 (o de un grupo de certificados X.509-V3) que el servidor TLS utiliza para validar la autenticación del cliente TLS. Si este parámetro es 0, para validar la autenticación del cliente el servidor TLS utiliza todos los certificados (CA) que hay actualmente cargados en el Certificate Store del servidor.




6. Interconecte el parámetro CONNECT de una de las instrucciones TSEND_C, TRCV_C o TCON con la variable del tipo de datos TCON_QDN_SEC.

En el siguiente ejemplo, el parámetro CONNECT de la instrucción TCON está interconectado con la variable "DNS connectionSEC" (tipo de datos TCON_QDN_SEC).


Información adicional Encontrará más información acerca de los tipos de datos del sistema TCON_QDN_SEC en la Ayuda en pantalla de STEP 7.


6.11.3 Secure OUC entre dos CPU S7-1500 A continuación se describe cómo configurar una Secure Open User Communication mediante TCP entre dos CPU S7-1500. Una de las CPU S7-1500 actúa como cliente TLS (establecimiento activo de la conexión) y la otra CPU S7-1500 como servidor TLS (establecimiento pasivo de la conexión).



Configurar una conexión TCP segura entre dos CPU S7-1500 Para la comunicación TCP segura entre dos CPU S7-1500, el usuario debe crear en cada CPU un bloque de datos del tipo de datos del sistema TCON_IPv4_SEC, parametrizarlo y llamarlo directamente en la instrucción TSEND_C, TRCV_C o TCON.

Requisitos:


● Las dos CPU S7-1500 tienen la versión de firmware V2.0 o superior


Figura 6-18 Administración de certificados con Secure OUC entre dos CPU S7-1500



Configuración en el cliente TLS

Para crear una conexión TCP segura en el cliente TLS, haga lo siguiente:


2. Defina en el bloque de datos global una variable del tipo de datos TCON_IP_V4_SEC.

El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "SEC connection 1 TLS-Client" del tipo de datos TCON_IP_V4_SEC.

Figura 6-19 IP_V4_SEC_Client

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "RemoteAdress" la dirección IPv4 del servidor TLS.

Nota


Tenga en cuenta que puede introducir el valor "0" para InterfaceId e ID en el tipo de datos TCON_V4_SEC. En este caso, la CPU busca ella misma una interfaz local adecuada de la CPU o una ID de conexión libre.





– "TLSServerCertRef": Introduzca el valor 2 (referencia al certificado CA del proyecto en el TIA Portal (SHA256) o el valor 1 (referencia al certificado CA del proyecto en el TIA Portal (SHA1)). Si utiliza otro certificado CA, introduzca la ID correspondiente del administrador de certificados de los ajustes globales de seguridad.



6. Interconecte el parámetro CONNECT de la instrucción TSEND_C, TRCV_C o TCON con la variable del tipo de datos TCON_IP_V4_SEC.

Configuración en el servidor TLS

Para crear una conexión TCP segura en el servidor TLS, haga lo siguiente:



El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "SEC connection 1 TLS-Server" del tipo de datos TCON_IP_V4_SEC.

Figura 6-20 IP_V4_SEC_Server

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "RemoteAdress" la dirección IPv4 del cliente TLS.





– "TLSServerReqClientCert": Solicitud de un certificado X.509-V3 del cliente TLS. Introduzca el valor "true".


– "TLSClientCertRef": Introduzca el valor 2 (referencia al certificado CA del proyecto en el TIA Portal (SHA256) o el valor 1 (referencia al certificado CA del proyecto en el TIA Portal (SHA1)). Si utiliza otro certificado CA, introduzca la ID correspondiente del administrador de certificados de los ajustes globales de seguridad.



En el siguiente ejemplo, el parámetro CONNECT de la instrucción TSEND_C está interconectado con la variable "SEC connection 1 TLS-Client" (tipo de datos TCON_IP_V4_SEC).

Figura 6-21 TSEND_C

Información adicional Encontrará más información acerca de los tipos de datos del sistema TCON_IP_V4_SEC en la Ayuda en pantalla de STEP 7.




6.11.4 Secure OUC a través de interfaz CP A continuación van a describirse las particularidades que deben tenerse en cuenta con Secure Open User Communication a través de una interfaz CP. Al menos una estación es una estación S7-1500 con los siguientes módulos:

● CPU S7-1500 con versión de firmware V2.0 o superior (excepto controlador por software S7-1500)

● CP 1543-1 con versión de firmware V2.0 o superior, o CP 1543SP-1 con versión de firmware V1.0 o superior

En una estación S7-1500, el CP actúa como cliente TLS (establecimiento activo de la conexión) o como servidor TLS (establecimiento pasivo de la conexión).

El procedimiento fundamental y el concepto de utilización de Secure Communication a través de una interfaz CP es similar a Secure Communication a través de las interfaces de las CPU S7-1500. Esencialmente es necesario asignar los certificados al CP, en su función de servidor TLS o de cliente TLS, y no a la CPU. De ahí que se apliquen otras reglas y procedimientos, que van a describirse a continuación.

Gestión de certificados para CP En general se aplica lo siguiente: en el administrador de certificados debe haber iniciado sesión en los ajustes globales de seguridad. Tampoco es posible crear certificados autofirmados sin haber iniciado sesión en los ajustes globales de seguridad. Es necesario disponer de derechos suficientes como usuario (administrador o usuario con función "Estándar" con derecho "Configurar seguridad").

Para crear o asignar certificados en el CP se parte del área "Seguridad> Propiedades de seguridad". En esta área se inicia sesión en los ajustes globales de seguridad.

Procedimiento:

1. En la vista de redes de STEP 7 seleccione el CP, y en la ventana de inspección elija el área "Seguridad > Propiedades de seguridad".

2. Haga clic en el botón "Inicio de sesión de usuario".

3. Inicie sesión con nombre de usuario y contraseña.

4. Active la opción "Activar funciones de seguridad".

Se inicializan las funciones de seguridad.

5. Haga clic en la primera fila de la tabla "Certificados de dispositivo" para crear un nuevo certificado de dispositivo o para seleccionar un certificado de dispositivo ya existente.

6. Si el interlocutor de comunicación es también una estación S7-1500 es necesario asignar también al interlocutor un certificado de dispositivo con STEP 7, como se ha descrito aquí o para la CPU S7-1500.



Ejemplo: establecer una conexión TCP segura entre dos CPU S7-1500 a través de interfaces CP Para la comunicación TCP segura entre dos CP S7-1500, el usuario debe crear en cada CPU un bloque de datos del tipo de datos del sistema TCON_IPv4_SEC, parametrizarlo y llamarlo directamente en la instrucción TSEND_C, TRCV_C o TCON.

Requisitos:

● Ambas CPU S7-1500 tienen como mínimo versión de firmware V2.0; si se utiliza el CP 1543SP-1: versión de firmware V1.0 o superior.

● Ambos CP (p. ej., CP 1543-1) tienen como mínimo versión de firmware V2.0.


– Debe haberse creado para el CP un certificado de dispositivo (certificado de entidad final) y hallarse en el almacén de certificados del CP. Si un interlocutor de comunicación es un dispositivo de terceros (p. ej. un sistema MES o ERP), debe contar también con un certificado de dispositivo.

– El certificado raíz (certificado CA) con el que está firmado el certificado de dispositivo del interlocutor de comunicación debe hallarse en el almacén de certificados del CP o del dispositivo de terceros. Si se utilizan certificados intermedios, es necesario asegurarse de que en el dispositivo que va a validarse existe la ruta completa del certificado. Un dispositivo utiliza estos certificados para validar el certificado de dispositivo del interlocutor de comunicación.

● Además es necesario direccionar el interlocutor de comunicación fundamentalmente mediante su dirección IPv4, no a través de su nombre de dominio.

La figura siguiente muestra los diferentes certificados de los dispositivos para el caso de que ambos interlocutores se comuniquen a través de un CP 1543-1. Además, la figura muestra la transmisión de los certificados de dispositivo al establecer la conexión ("Hello").

Figura 6-22 Administración de certificados con Secure OUC entre dos CPU S7-1500 a través de

interfaces CP



Configuración en el cliente TLS

Para crear una conexión TCP segura en el cliente TLS, haga lo siguiente:


2. Defina en el bloque de datos global una variable del tipo de datos TCON_IP_V4_SEC. Para ello, en la columna "Tipo de datos" introduzca la secuencia de caracteres "TCON_IP_V4_SEC".

El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "SEC connection 1 TLS-Client" del tipo de datos TCON_IP_V4_SEC.

La ID de interfaz tiene el valor de la ID de hardware de la interfaz IE del CP local (cliente TLS).

Figura 6-23 IP_V4_SEC_Client

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "RemoteAdress" la dirección IPv4 del servidor TLS.


– "ActivateSecureConn": activación de Secure Communication para esta conexión. Si este parámetro tiene el valor FALSE, los parámetros de seguridad siguientes son irrelevantes. En tal caso es posible crear una conexión TCP o UDP no segura.

– "TLSServerCertRef": Introduzca el valor 2 (referencia al certificado CA del proyecto en el TIA Portal (SHA256) o el valor 1 (referencia al certificado CA del proyecto en el TIA Portal (SHA1)). Si utiliza otro certificado CA, introduzca la ID correspondiente del administrador de certificados de los ajustes globales de seguridad.






Configuración en el servidor TLS

Para crear una conexión TCP segura en el servidor TLS, haga lo siguiente:



El ejemplo siguiente muestra el bloque de datos global "Data_block_1" en el que está definida la variable "SEC connection 1 TLS-Server" del tipo de datos TCON_IP_V4_SEC.

La ID de interfaz tiene el valor de la ID de hardware de la interfaz IE del CP local (servidor TLS).

Figura 6-24 IP_V4_SEC_Server

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca en "RemoteAdress" la dirección IPv4 del cliente TLS.




– "ActivateSecureConn": activación de Secure Communication para esta conexión. Si este parámetro tiene el valor FALSE, los parámetros de seguridad siguientes son irrelevantes. En tal caso es posible crear una conexión TCP o UDP no segura.

– "TLSServerReqClientCert": Solicitud de un certificado X.509-V3 del cliente TLS. Introduzca el valor "true".


– "TLSClientCertRef": introduzca el valor 2 (referencia al certificado CA del proyecto en el TIA Portal (SHA256) o el valor 1 (referencia al certificado CA del proyecto en el TIA Portal (SHA1)). Si utiliza otro certificado CA, introduzca la ID correspondiente del administrador de certificados de los ajustes globales de seguridad.



Carga del dispositivo como estación nueva Si se carga como estación nueva una configuración con certificados y Secure Open User Communication configurada en el proyecto STEP 7, no se cargarán los certificados del CP, a diferencia de lo que ocurre con los certificados de la CPU. Después de cargar el dispositivo como estación nueva, en las tablas correspondientes de los CP ya no hay certificados de dispositivo.

Después de la carga es necesario realizar de nuevo la configuración de los certificados. En caso contrario, una nueva carga de la configuración provoca que se borren los certificados originalmente existentes en el CP y que no funcione la Secure Communication.

Conexiones Secure OUC a través de interfaces de CPU y de CP - Características comunes ● Recursos de conexión:

No hay diferencias entre OUC y Secure OUC. Una conexión Secure OUC programada consume un recurso de conexión, igual que una conexión OUC, independientemente de la interfaz IE o PROFINET a través de la que se comunique la estación.

● Diagnóstico de conexiones: No hay diferencias entre el diagnóstico de conexiones OUC y Secure OUC.

● Cargar en la CPU proyectos con conexiones Secure OUC: Solo es posible con la CPU en STOP, suponiendo que se hayan cargado también certificados. Recomendación: Cargar en dispositivo > Hardware y software Motivo: garantizar la coherencia entre el programa con Secure OUC, la configuración hardware y los certificados. Los certificados se cargan con la configuración hardware, motivo por el que la carga requiere que la CPU esté en STOP. Solo es posible recargar bloques que utilizan otras conexiones Secure OUC si la CPU está en RUN, y si en el módulo ya se encuentran los certificados necesarios.



6.11.5 Secure OUC con Modbus TCP Para la conexión Modbus TCP segura, el usuario debe crear un bloque de datos del tipo de datos del sistema TCON_IP_V4_SEC o TCON_QDN_SEC, parametrizarlo y llamarlo directamente en la instrucción MB_Server o MB_CLIENT.

Requisitos ● CPU S7-1500 a partir de la versión de firmware V2.5

● El cliente Modbus (cliente TLS) puede acceder al servidor Modbus (servidor TLS) en la red a través de comunicación IP.

● El cliente TLS y el servidor TLS poseen todos los certificados necesarios.

Ejemplo de establecimiento de conexión Modbus TCP segura con un servidor Modbus TCP A continuación se describe cómo configurar una Secure Open User Communication a través de Modbus TCP entre un cliente Modbus TCP y un servidor Modbus TCP.

Para crear una conexión segura entre un cliente Modbus TCP (cliente TLS) y un servidor Modbus TCP (servidor TLS) a través de la dirección IPv4 del servidor de correo, haga lo siguiente:


2. Defina una variable del tipo de datos TCON_IP_V4_SEC en el bloque de datos global.

Figura 6-25 TCON_IP_V4_SEC

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca la dirección IPv4 del servidor de correo en "MailServerAdress".



4. Configure los parámetros para Secure Communication en la columna "Valor de arranque". P. ej., introduzca la ID de certificado del certificado CA del interlocutor en "TLSServerCertRef".

– "ActivateSecureConn": Activación de Secure Communication para esta conexión. Si este parámetro tiene el valor FALSE, los parámetros de seguridad siguientes son irrelevantes. En tal caso es posible crear una conexión Modbus TCP no segura.

– "TLSServerCertRef": Referencia al certificado X.509 V3 (CA) del servidor Modbus TCP, que utilizará el cliente TLS para validar la autenticación del servidor Modbus TCP.

5. Cree una instrucción MB_Client en el editor de programas.

6. Interconecte el parámetro CONNECT de la instrucción MB_Client con la variable del tipo de datos TCON_IP_V4_SEC.

6.11.6 Secure OUC mediante correo electrónico

Conexión segura con un servidor de correo a través de la interfaz de la CPU Para la conexión segura con un servidor de correo, el usuario debe crear un bloque de datos del tipo de datos del sistema TMAIL_V4_SEC o TMAIL_QDN_SEC, parametrizarlo y llamarlo directamente en la instrucción TMAIL_C.

Requisitos ● Instrucción TMAIL_C a partir de la implementación V5.0

● STEP 7 V15 o superior

● CPU S7-1500 V2.5 o superior

● Se han asignado a la CPU (cliente TLS) todos los certificados CA del servidor de correo (servidor TLS) y se ha cargado la configuración en la CPU.




Procedimiento para establecer la conexión segura con el servidor de correo Puede elegir entre dos procedimientos para establecer la conexión segura con el servidor de correo:

● SMTPS: El cliente intenta establecer inmediatamente una conexión TLS con el servidor de correo (procedimiento "handshake"). Si el servidor de correo no admite TLS, no se establece la conexión.

● STARTTLS: El cliente establece una conexión TCP con el servidor de correo. El cliente envía una consulta a través de la conexión TCP para convertir la conexión existente en una conexión TLS segura ("upgrade"). Si el servidor de correo admite TLS, enviará al cliente la orden de establecer una conexión segura. El servidor de correo utiliza para ello el comando SMTP "STARTTLS". Tras ello, el cliente establece una conexión segura con el servidor de correo. Ventaja: Si el servidor de correo no admite TLS, el cliente y el servidor de correo pueden comunicarse entre sí de manera no segura.

El procedimiento que se utilizará para la comunicación se define con el ajuste "Remote Port" en el tipo de datos de parámetro de bloque "MAIL_ADDR_PARAM".

Tabla 6- 6 Números de puerto para los procedimientos SMTPS y STARTTLS

Procedimiento Puerto SMTPS 4651

STARTTLS cualquiera (≠465)2 1 La instrucción TMAIL_C utiliza SMTPS solo para el puerto 465. Para todos los demás puertos

utiliza STARTTLS. 2 Según RFC, los servidores de correo utilizan los puertos 25 y 587 para las conexiones seguras

con STARTTLS. El uso de otros números de puerto para SMTP no es conforme con RFC, por lo que en tal caso no se garantiza la comunicación correcta con el servidor de correo.



Ejemplo: Configurar una conexión segura a un servidor de correo a través de IPv4 A continuación se describe cómo configurar una conexión segura a un servidor de correo IPv4 con la instrucción de comunicación TMAIL_C.

Para configurar una conexión segura mediante la dirección IPv4 del servidor de correo, haga lo siguiente:


2. Defina en el bloque de datos global una variable del tipo de datos TMAIL_V4_SEC.

El ejemplo siguiente muestra el bloque de datos global "MailConnDB" en el que está definida la variable "MailConnectionSEC" del tipo de datos TMAIL_V4_SEC.

Figura 6-26 Tipo de datos TMAIL_V4_SEC

3. Configure los parámetros de la conexión TCP en la columna "Valor de arranque". P. ej., introduzca la dirección IPv4 del servidor de correo en "MailServerAdress".

Nota


Tenga en cuenta que, a partir de la implementación V5.0 de la instrucción TMAIL_C, puede introducir el valor "0" para InterfaceId e ID en el tipo de datos TMAIL_V4_SEC. En este caso, la CPU busca ella misma una interfaz local adecuada de la CPU o una ID de conexión libre.



4. Configure los parámetros para Secure Communication en la columna "Valor de arranque". P. ej., introduzca la ID de certificado del certificado CA del interlocutor en "TLSServerCertRef".


– "TLSServerCertRef": Referencia al certificado X.509 V3 (CA) del servidor de correo, que será utilizada por el cliente TLS para validar la autenticación del servidor de correo.

5. Cree una instrucción TMAIL_C en el editor de programas.

6. Interconecte el parámetro MAIL_ADDR_PARAM de la instrucción TMAIL_C con la variable del tipo de datos TMAIL_V4_SEC.

En el siguiente ejemplo, el parámetro MAIL_ADDR_PARAM de la instrucción TMAIL_C está interconectado con la variable "MailConnectionSEC" (tipo de datos TMAIL_V4_SEC).

Figura 6-27 Instrucción TMAIL_C

Conexión segura a un servidor de correo a través de la interfaz de un módulo de comunicación Para la conexión segura a un servidor de correo a través de un módulo de comunicación, el usuario debe crear un bloque de datos del tipo de datos del sistema TMAIL_V4_SEC, TMAIL_QDN_SEC o TMAIL_V6_SEC (solo CP), parametrizarlo y llamarlo directamente en la instrucción TMAIL_C.

Requisitos:

● Instrucción TMAIL_C con implementación V4.0

● CPU S7-1500 con versión de firmware V2.0 o superior, con módulo de comunicación CP 1543-1 con versión de firmware V2.0 o superior

● CPU ET 200SP con versión de firmware V2.0 o superior, con módulo de comunicación CP 1542SP-1 (IRC) con versión de firmware V1.0 o superior

● Se han asignado al CP (cliente TLS) todos los certificados CA del servidor de correo (servidor TLS) y se ha cargado la configuración en la CPU.


El modo de definir la conexión segura a un servidor de correo a través de la interfaz de un módulo de comunicación se describe en la ayuda en pantalla de STEP 7.



Ejemplo de aplicación La forma de crear una conexión segura con un servidor de correo electrónico a través del CP de una estación S7-1500 o S7-1200 y de enviar un correo electrónico con la instrucción estándar "TMAIL_C" desde la CPU S7 está descrita en este ejemplo de aplicación (https://support.industry.siemens.com/cs/ww/es/view/46817803).

Información adicional Encontrará más información acerca de los tipos de datos del sistema TMail_V4_SEC y TMAIL_QDN_SEC en la ayuda en pantalla de STEP 7.




Comunicación S7 7

Características de la comunicación S7 La comunicación S7, como comunicación homogénea de SIMATIC, se caracteriza por una comunicación específica del fabricante entre las CPU SIMATIC (no es un estándar abierto). La comunicación S7 sirve para la migración y conexión a los sistemas existentes (S7-300, S7-400).

Para la transferencia de datos entre dos sistemas de automatización S7-1500, recomendamos utilizar la comunicación abierta (véase el capítulo Open User Communication (Página 67)).

Características de la comunicación S7 A través de la comunicación S7, la CPU intercambia datos con otra CPU. En cuanto el usuario recibe los datos en la CPU receptora, se envía automáticamente una confirmación de la recepción de los datos a la CPU emisora.

El intercambio de datos se realiza a través de conexiones S7 configuradas. Las conexiones S7 pueden configurarse de forma unilateral o bilateral.

La comunicación S7 puede llevarse a cabo a través de:

● la interfaz PROFINET o PROFIBUS DP integrada de una CPU;

● la interfaz de un CP/CM.

Conexiones S7 configuradas de forma unilateral En una conexión S7 configurada de forma unilateral, la configuración para esta conexión se realiza solamente en un interlocutor y se carga únicamente en él.

Es posible configurar una conexión S7 unilateral con una CPU que solo es servidor de una conexión S7 (p. ej., CPU 315-2 DP). La CPU está configurada, con lo que se conocen los parámetros de dirección y las interfaces.

Además, puede configurarse una conexión S7 unilateral con un interlocutor que no existe en el proyecto, con lo que no se conocen ni sus parámetros de dirección ni su interfaz. La dirección debe introducirla el usuario; STEP 7 no la comprueba. El interlocutor no está especificado inicialmente (al crear la conexión S7, la dirección del interlocutor aún no está introducida). Al indicarse la dirección, es "desconocido" (es decir, está especificado pero es desconocido para el proyecto).

Con ello, existe la posibilidad de establecer conexiones S7 no limitadas al proyecto. El interlocutor es desconocido para el proyecto local (sin especificar) y se configura en otro proyecto STEP 7 o en un proyecto externo.

Comunicación S7


Conexiones S7 configuradas de forma bilateral En una conexión S7 configurada de forma bilateral, la configuración y la carga de los parámetros de conexión S7 configurados se realiza en ambos interlocutores.

Instrucciones para la comunicación S7 Para la comunicación S7 en S7-1500 se utilizan las siguientes instrucciones:

● PUT/GET

La instrucción PUT permite escribir datos en una CPU remota. La instrucción GET permite leer datos de una CPU remota. Las instrucciones PUT y GET son unilaterales, es decir, solo son necesarias en un interlocutor. Las instrucciones PUT y GET pueden configurarse cómodamente en la parametrización de la conexión.

Nota

Bloques de datos para instrucciones PUT/GET

Al utilizar las instrucciones PUT/GET, solo pueden utilizarse bloques de datos con direccionamiento absoluto. El direccionamiento simbólico de bloques de datos no es posible.

Además, este servicio debe habilitarse en el área "Protección" de la configuración de la CPU.

La configuración y programación de una conexión S7 y de las instrucciones PUT y GET para el intercambio de datos entre dos CPU S7-1500 se describe en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/82212115).

● BSEND/BRCV

La instrucción BSEND envía datos a una instrucción del interlocutor remoto del tipo BRCV. La instrucción BRCV recibe datos de una instrucción del interlocutor remoto del tipo BSEND. La comunicación S7 con el par de instrucciones BSEND/BRCV se utiliza para la transferencia segura de datos.

● USEND/URCV

La instrucción USEND envía datos a una instrucción del interlocutor remoto del tipo URCV. La instrucción URCV recibe datos de una instrucción del interlocutor remoto del tipo USEND. La comunicación S7 con el par de instrucciones USEND/URCV se utiliza para la transferencia rápida y no segura de datos, independientemente del procesamiento de tiempos del interlocutor (p. ej., para avisos de operación y mantenimiento).


Comunicación S7


Comunicación S7 mediante interfaz PROFIBUS DP en modo esclavo En las propiedades de la interfaz PROFIBUS DP de los módulos de comunicación (p. ej., CM 1542-5) de STEP 7 se encuentra la casilla de verificación "Test, puesta en servicio, routing". Ajuste mediante esta casilla de verificación si la interfaz PROFIBUS DP del esclavo DP es un dispositivo activo o pasivo en PROFIBUS.

● Casilla de verificación activada: el esclavo DP es un dispositivo activo en PROFIBUS.

● Casilla de verificación desactivada: el esclavo DP es un dispositivo pasivo en PROFIBUS. Para este esclavo DP pueden crearse solamente conexiones S7 configuradas de forma unilateral.

Figura 7-1 Casilla de verificación "Test, puesta en marcha, routing"

Parametrización de conexiones S7 para instrucciones PUT/GET En la parametrización de conexiones de las instrucciones PUT y GET es posible crear y parametrizar las conexiones S7. La parametrización de la conexión comprueba inmediatamente si los valores modificados presentan errores de entrada.

Requisitos: se ha creado una instrucción PUT o GET en el editor de programación.

Para configurar una conexión S7 mediante instrucciones PUT/GET, haga lo siguiente:

1. Seleccione la llamada de la instrucción PUT o GET en el editor de programación.

2. Abra la ficha "Propiedades > Configuración" en la ventana de inspección.

Comunicación S7


3. Seleccione el grupo "Parámetros de la conexión". Mientras no se haya seleccionado ningún interlocutor, solo estará activa la lista desplegable vacía del punto final del interlocutor. Todas las demás entradas posibles estarán desactivadas.

Se mostrarán los parámetros de conexión que ya se conocen:

– Nombre del punto final local

– Interfaz del punto final local

– Dirección IPv4 del punto final local

Figura 7-2 Parametrización de la conexión para la instrucción PUT

Comunicación S7


4. Seleccione un interlocutor en la lista desplegable del punto final del interlocutor. El interlocutor puede ser un dispositivo sin especificar o una CPU del proyecto.

Los siguientes parámetros se introducen automáticamente en cuanto se selecciona el interlocutor:

– Nombre del punto final del interlocutor

– Interfaz del punto final del interlocutor. Si se dispone de varias interfaces, se puede cambiar de interfaz en caso necesario.

– Tipo de interfaz del punto final del interlocutor

– Nombre de la subred de ambos puntos finales

– Dirección IPv4 del punto final del interlocutor

– Nombre de la conexión que se utiliza para la comunicación.

5. En caso necesario, cambie el nombre de la conexión en el campo de entrada "Nombre de conexión". Si desea crear una nueva conexión o editar una conexión ya existente, haga clic en el botón "Seleccione conexión" ubicado a la derecha junto al campo de entrada del nombre de la conexión.

Nota

Las instrucciones PUT y GET entre dos interlocutores no funcionarán hasta que no se haya cargado en el hardware tanto la configuración hardware como la parte del programa destinada al punto final del interlocutor. Para que la comunicación funcione, asegúrese de no cargar en el dispositivo únicamente la descripción de la conexión de la CPU local, sino también la de la CPU interlocutora.

Configuración de conexiones S7 (para BSEND/BRCV, p. ej.) Si, p. ej., desea utilizar las instrucciones de BSEND/BRCV para la comunicación S7, deberá configurar primero una conexión S7.

Para configurar una conexión S7, haga lo siguiente:


2. Seleccione el botón "Conexiones" y, en la lista desplegable, la entrada "Conexión S7".

3. Conecte los interlocutores entre sí mediante la función de arrastrar y soltar (a través de la interfaz o el punto final local). Si todavía no existe la subred S7 correspondiente, se creará de forma automática.

Como alternativa, también puede crear una conexión con interlocutores no especificados.

4. En la ficha "Conexiones", seleccione la fila de la conexión S7.

5. Si es necesario, en el área "General", ficha "Propiedades", configure las propiedades de la conexión S7, p. ej., el nombre de la conexión y las interfaces utilizadas de los interlocutores.

Ajuste la dirección del interlocutor para las conexiones S7 con un interlocutor sin especificar.

Comunicación S7


La ID local se encuentra en el área "ID local" (referencia a la conexión S7 en el programa de usuario).

6. Seleccione en el árbol del proyecto la carpeta "Bloques de programa" de una de las dos CPU y abra el OB 1 en la carpeta haciendo doble clic. Se abre el editor de programación.

7. En el editor de programación, llame las instrucciones correspondientes para la comunicación S7 en el programa de usuario del interlocutor (unilateral) o en los programas de usuario de los interlocutores (bilateral). Seleccione, p. ej., en la Task Card "Instrucciones", en el área "Comunicación", las instrucciones BSEND y BRCV y arrástrelas a un segmento del OB 1 mediante arrastrar y soltar.

8. Asigne en el parámetro ID de la instrucción la ID local de la conexión configurada que debe utilizarse para la transferencia de datos.

9. Parametrice las instrucciones, qué datos se escriben dónde o de dónde se leen.

10.Cargue la configuración hardware y el programa de usuario en la(s) CPU.

Comunicación S7


Comunicación S7 mediante CP 1543-1 Si configura la comunicación S7 a través de la interfaz Industrial Ethernet del CP 1543-1, puede seleccionar el protocolo de transporte para la transferencia de datos en las propiedades de la conexión S7, en "General":

● Casilla de verificación "TCP/IP" activada (predeterminada): ISO-on-TCP (RFC1006): para la comunicación S7 entre CPU S7-1500

● Casilla de verificación "TCP/IP" desactivada: protocolo ISO (IEC8073): direccionamiento con direcciones MAC

Figura 7-3 Selección del protocolo de transporte CP 1543-1

Comunicación S7


Procedimiento para configurar una conexión S7 a través de diferentes subredes S7 Es posible utilizar una conexión S7 a través de varias subredes S7 (PROFIBUS, PROFINET/Industrial Ethernet) (Routing S7 (Página 235)).


2. Seleccione el botón "Conectar en red".

3. Conecte las interfaces correspondientes con las respectivas subredes S7 (PROFIBUS o PROFINET/Industrial Ethernet) mediante la función de arrastrar y soltar.

Comunicación S7


4. Seleccione el botón "Conexiones" y, en la lista desplegable, la entrada "Conexión S7".

5. En el caso del ejemplo, conecte el PLC_1 de la subred S7 de la izquierda (PROFIBUS) con el PLC_3 de la subred S7 de la derecha (PROFINET) mediante la función de arrastrar y soltar.

Se ha configurado la conexión S7 de la CPU 1 a la CPU 3.

Figura 7-4 Conexiones S7 mediante distintas subredes

Comunicación S7


ET 200SP Open Controller como router para conexiones S7 Si se asigna la interfaz "PROFINET onboard [X2]" de CPU 1515SP PC (F) a la estación SIMATIC PC, es posible utilizar la CPU 1515SP PC (F) como router para conexiones S7. Si se utiliza la interfaz CP para "Ningún ajuste u otro ajuste de Windows", no se puede utilizar el Open Controller como router para conexiones enrutadas S7.

Una conexión S7 existente y enrutada por la CPU 1515SP PC (F) queda invalidada cuando la asignación de la interfaz de la CPU 1515SP PC (F) cambia de "Estación PC SIMATIC" a "Ningún ajuste u otro ajuste de Windows". Puesto que ahora el PLC ya no se encarga de enrutar esta conexión, al compilar la CPU 1515SP PC (F) no aparece ninguna indicación de que la conexión no es válida. La conexión S7 enrutada e invalidada se muestra solo después de compilados los puntos finales de la conexión.

Las interfaces necesarias para conexiones S7 enrutadas tienen que permanecer asignadas explícitamente en la CPU 1515SP PC (F) . La asignación de la interfaz de la CPU 1515SP PC (F) se edita en las propiedades, en "PROFINET onboard [X2] > Asignación de interfaz".

Figura 7-5 Routing S7 de estación PC

Información adicional En la Ayuda en pantalla de STEP 7 encontrará más información sobre la configuración de conexiones S7 y sobre cómo utilizar las instrucciones para la comunicación S7 en el programa de usuario.


Acoplamiento punto a punto 8

Funcionalidad La comunicación mediante acoplamiento punto a punto en S7-1500, ET 200MP y ET 200SP se realiza mediante módulos de comunicaciones (CM) con interfaces serie (RS232, RS422 o RS485):

● S7-1500/ET 200MP:

– CM PtP RS232 BA

– CM PtP RS422/485 BA

– CM PtP RS232 HF

– CM PtP RS422/485 HF

● ET 200SP:

– CM PtP

El intercambio de datos bidireccional mediante acoplamiento punto a punto funciona entre módulos de comunicaciones o sistemas y equipos de terceros aptos para la comunicación. Para la comunicación se necesitan al menos 2 interlocutores ("punto a punto"). Con RS422 y RS485 puede haber más de dos interlocutores.

Protocolo para la comunicación mediante acoplamiento punto a punto ● Protocolo Freeport (también llamado protocolo ASCII)

● Procedimiento 3964(R)

● Protocolo Modbus en formato RTU (RTU: Remote Terminal Unit)

● Protocolo USS (protocolo de interfaz serie universal)

Los protocolos utilizan diferentes capas según el modelo de referencia ISO/OSI:

● Freeport: utiliza la capa 1 (capa física)

● 3964(R), USS y Modbus: utilizan las capas 1 y 2 (capa física y capa de seguridad, para conseguir una mayor seguridad de transferencia que con Freeport). USS y Modbus utilizan adicionalmente la capa 4.

Características del protocolo Freeport ● El receptor reconoce el fin de la transferencia de datos mediante un criterio de fin

parametrizable (p. ej., tiempo de retardo de caracteres transcurrido, recepción de carácter de fin, recepción de número de datos fijo).

● El emisor no puede detectar si los datos enviados han llegado correctamente al receptor.

Acoplamiento punto a punto


Características del procedimiento 3964(R) ● En la transmisión se agregan caracteres de control a los datos (de inicio, fin y control).

Hay que tener en cuenta que estos caracteres de control no están disponibles como datos en el telegrama.

● La conexión se establece y deshace mediante caracteres de control.

● Si se producen errores de transmisión, la transferencia de datos se repite automáticamente.

Intercambio de datos mediante comunicación Freeport o 3964(R) Los datos enviados se guardan en bloques de datos (búfer de transmisión) en el programa de usuario de la CPU correspondiente. En el módulo de comunicaciones existe un búfer de recepción para los datos recibidos. Compruebe las propiedades del búfer de recepción y modifíquelas en caso necesario. Cree un bloque de datos para la recepción en la CPU.

En el programa de usuario de la CPU, las instrucciones "Send_P2P" y "Receive_P2P" se encargan de la transferencia de datos entre la CPU y el CM.

Procedimiento de configuración de la comunicación Freeport o 3964(R) 1. En la vista de dispositivos del editor Dispositivos y redes de STEP 7, configure un

sistema S7-1500 con CPU y CM.

2. Seleccione la interfaz del CM en la vista de dispositivos de STEP 7.

3. Parametrice la interfaz (p. ej., comunicación de conexión, configuración del envío de mensajes) en la ventana de inspección de STEP 7, apartado "Propiedades" >"General".

4. En la Task Card "Instrucciones", apartado "Comunicación" > "Procesador de comunicaciones", seleccione las instrucciones "Send_P2P" o "Receive_P2P" y arrastre la instrucción mediante arrastrar y soltar al programa de usuario (p. ej., a un FB).

5. Parametrice las instrucciones según sus especificaciones.


Alternativa: Parametrización dinámica del módulo de comunicación En determinados campos de aplicación es ventajoso configurar la comunicación de forma dinámica, es decir, controlada por una aplicación específica.

Pueden verse casos de aplicación típicos, p. ej., en los fabricantes de maquinaria de serie. Para ofrecer a sus clientes interfaces de usuario lo más cómodas posible, estos fabricantes adaptan los servicios de comunicación a las correspondientes órdenes de mando.



Instrucciones para la comunicación Freeport Existen 3 instrucciones para la configuración dinámica en el programa de usuario para la comunicación Freeport. Lo siguiente se aplica a estas 3 instrucciones: los datos de configuración válidos hasta el momento se sobrescriben, pero no se guardan de forma permanente en el sistema de destino. ● La instrucción "Port_Config" sirve para la configuración controlada por programa de los

puertos correspondientes del módulo de comunicaciones.

● La instrucción "Send_Config" sirve para la configuración dinámica, p. ej., de intervalos y pausas en la transferencia (parámetros de transferencia serie) para el puerto correspondiente.

● La instrucción "Receive_Config" sirve para la configuración dinámica, p. ej., de condiciones de inicio y fin de un mensaje que se va a transferir (parámetros de recepción serie) para el puerto correspondiente.

Instrucciones para la comunicación 3964(R) Existen 2 instrucciones para la configuración dinámica en el programa de usuario para la comunicación 3964(R). Para las instrucciones se aplica lo siguiente: los datos de configuración válidos hasta el momento se sobrescriben, pero no se guardan de forma permanente en el sistema de destino. ● La instrucción "Port_Config" sirve para la configuración controlada por programa de los

puertos correspondientes del módulo de comunicaciones.

● La instrucción "P3964_Config" sirve para la configuración dinámica de parámetros de protocolo.

Características del protocolo USS ● Protocolo serie de transferencia de datos con tráfico cíclico de tramas o telegramas en

modo semidúplex, adaptado a las necesidades de la tecnología de accionamientos. ● La transferencia de datos funciona según el principio de maestro-esclavo.

– El maestro tiene acceso a las funciones del accionamiento y puede, entre otras cosas, controlar el accionamiento, leer valores de estado, así como leer y escribir los parámetros de accionamiento.

Intercambio de datos mediante comunicación USS El módulo de comunicaciones es el maestro. El maestro envía tramas (telegramas) de forma continua (tramas de petición) a los hasta 16 accionamientos y espera una trama de respuesta de cada accionamiento activado.

Un accionamiento envía una trama de respuesta cuando se dan las siguientes condiciones:

● Cuando se ha recibido una trama sin errores

● Cuando el accionamiento se ha direccionado en esta trama

Un accionamiento no tiene permitido transmitir si no se cumplen las condiciones mencionadas o si el accionamiento ha sido activado en difusión (Broadcast).

Para el maestro, la conexión con el accionamiento en cuestión está establecida cuando recibe una trama de respuesta del accionamiento tras un tiempo de procesamiento definido (tiempo de retardo de respuesta).



Procedimiento para configurar la comunicación USS 1. En la vista de dispositivos del editor Dispositivos y redes de STEP 7, configure un


2. Seleccione en el árbol del proyecto de la CPU la carpeta "Bloques de programa" y abra el OB 1 en la carpeta haciendo doble clic. Se abre el editor de programación.

3. Seleccione, p. ej., en la Task Card "Instrucciones", en el área "Comunicación", carpeta "Procesador de comunicaciones", las instrucciones para la comunicación USS según la tarea planteada, y arrástrelas a un segmento del OB 1 mediante arrastrar y soltar:

– La instrucción "USS_Port_Scan" permite la comunicación a través de la red USS.

– La instrucción "USS_Drive_Control" prepara datos que enviar al accionamiento y evalúa los datos de respuesta de este.

– La instrucción "USS_Read_Param" sirve para leer parámetros del accionamiento.

– La instrucción "USS_Write_Param" sirve para modificar parámetros del accionamiento.



Propiedades del protocolo Modbus (RTU) ● La comunicación se realiza mediante transmisiones serie asíncronas con una velocidad

de transferencia de hasta 115,2 kbits/s, semidúplex.

● La transferencia de datos funciona según el principio de maestro-esclavo.

● El maestro Modbus puede enviar peticiones de lectura y escritura de operandos al esclavo Modbus:

– Lectura de entradas, temporizadores, contadores, salidas, marcas, bloques de datos

– Escritura de salidas, marcas, bloques de datos

● Es posible la difusión (Broadcast) a todos los esclavos.

Intercambio de datos mediante comunicación Modbus (RTU) El módulo de comunicaciones puede ser maestro Modbus o esclavo Modbus. Un maestro Modbus se puede comunicar con uno o varios esclavos Modbus (el número depende de la física de la interfaz). Solo el esclavo Modbus direccionado de forma explícita por el maestro Modbus puede enviar datos al maestro. El esclavo detecta el final de la transferencia y la confirma. En caso de error, pone un código de error a disposición del maestro.



Procedimiento para configurar la comunicación Modbus (RTU) 1. En la vista de dispositivos del editor Dispositivos y redes de STEP 7, configure un


2. Seleccione en el árbol del proyecto de la CPU la carpeta "Bloques de programa" y abra el OB 1 en la carpeta haciendo doble clic. Se abre el editor de programación.

3. Seleccione en la Task Card "Instrucciones", en el área "Comunicación", carpeta "Procesador de comunicaciones", las instrucciones para la comunicación Modbus según la tarea planteada y arrástrelas a un segmento del OB 1 mediante arrastrar y soltar:

– La instrucción "Modbus_Comm_Load" configura el puerto del CM para la comunicación Modbus.

– La instrucción "Modbus_Master" se utiliza para la funcionalidad de maestro Modbus.

– La instrucción "Modbus_Slave" se utiliza para la funcionalidad de esclavo Modbus.



Información adicional ● Encontrará más información sobre la comunicación a través del acoplamiento punto a

punto y los principios básicos de la transferencia de datos serie en el manual de funciones CM PtP - Configuraciones para acoplamientos punto a punto (http://support.automation.siemens.com/WW/view/es/59057093).

● En la Ayuda en pantalla de STEP 7 se describe cómo utilizar las instrucciones mencionadas para el acoplamiento punto a punto en el programa de usuario.

● Para más información sobre los módulos de comunicaciones con interfaz serie, consulte el manual de producto del módulo de comunicaciones correspondiente.



Comunicación OPC UA 9 9.1 Información importante sobre OPC UA

9.1.1 OPC UA e Industria 4.0

Estándar unificado para el intercambio de datos Denominamos Industrie 4.0 al uso, evaluación y análisis intensivos de numerosos datos procedentes de la producción en sistemas TI del nivel de empresa. Industria 4.0 hará aumentar el intercambio de datos entre los niveles de producción y de empresa. Sin embargo, para garantizar su éxito será necesario un estándar unificado de intercambio de datos.

El estándar OPC UA (OPC Unified Architecture) resulta idóneo para el intercambio de datos entre distintos niveles gracias a su independencia respecto de sistemas operativos, su método de transferencia seguro y la descripción semántica de los datos. OPC UA no solo proporciona datos, sino también información sobre ellos (tipos de datos), lo que permite interpretar de manera automatizada los datos a los que se accede.

9.1.2 Estructura de la descripción En OPC UA, un sistema actúa como servidor proporcionando datos y métodos a otros sistemas (clientes).

Los clientes OPC UA tienen acceso de lectura y escritura a datos de un servidor OPC UA. Los clientes OPC UA llaman a métodos en el servidor OPC UA.

Un sistema puede ser tanto cliente como servidor.

Servidor OPC UA de la CPU S7-1500 Las CPU S7-1500 a partir de la versión de firmware V2.0 cuentan con un servidor OPC UA.

En los siguientes capítulos se describe cómo configurar el servidor OPC UA de la CPU S7-1500 y proporcionar así datos y métodos a los clientes OPC UA, de modo que estos puedan acceder en lectura y escritura a las variables PLC y llamar a métodos del servidor.

Además, los capítulos siguientes muestran cómo incorporar las especificaciones Companion al espacio de direccionamiento del servidor OPC UA.

Comunicación OPC UA 9.1 Información importante sobre OPC UA


Clientes OPC UA en general Para explicar el manejo de los clientes OPC UA, la siguiente descripción utiliza diversos clientes OPC UA:

● "UaExpert" de Unified Automation. Un cliente extenso que puede utilizarse de forma gratuita: Enlace para descargar UaExpert. (https://www.unified-automation.com/downloads/opc-ua-clients.html)

● "UA Sample Client" de OPC Foundation. Este cliente está disponible de forma gratuita para usuarios que están registrados en OPC Foundation : Enlace para descargar el cliente de ejemplo de la OPC Foundation (https://opcfoundation.org).

Ejemplo de aplicación en el Industry Online Support Siemens Industry Online Support ofrece un ejemplo de aplicación gratuito con una API de cliente. Con las funciones de esta interfaz, un desarrollador de .NET puede acceder al servidor OPC UA de un S7-1500. La API de cliente se basa en la pila .NET OPC UA de la OPC Foundation.

El ejemplo de aplicación muestra a modo de ejemplo cómo se establecen las conexiones entre servidor y cliente. El ejemplo muestra también la lectura y escritura de variables PLC.

Enlace para descargar el cliente OPC UA .NET para el servidor OPC UA SIMATIC S7-1500 (http://support.automation.siemens.com/WW/view/es/109737901)

https://www.unified-automation.com/downloads/opc-ua-clients.html

https://www.unified-automation.com/downloads/opc-ua-clients.html

https://opcfoundation.org/




9.1.3 Propiedades generales de OPC UA

Las principales características de OPC UA ● OPC UA no depende de ninguna plataforma determinada de sistema operativo.

Por ejemplo, OPC UA puede utilizarse con Windows, Linux, Mac OS X, un sistema operativo en tiempo real o un sistema operativo para móvil (por ejemplo, Android).

● OPC UA está implementado en distintos lenguajes de programación.

OPC Foundation ha implementado el estándar OPC UA en varios lenguajes de programación: hay disponibles pilas para ANSI C, .NET y Java.

● La OPC Foundation proporciona las pilas para Java y .Net, así como algunos programas de ejemplo, en modalidad Open Source. Ver Github (https://github.com/opcfoundation (https://github.com/opcfoundation)).

● Varias empresas ofrecen Software Development Kits (SDK) que contienen las pilas de la OPC Foundation y otras funciones que facilitan el desarrollo de soluciones.

Ventajas del uso de SDK:

– Asistencia por parte del proveedor

– Software probado

– Documentación detallada

– Condiciones de licencia claras (importante para la venta posterior de soluciones)

● Escalabilidad

OPC UA puede utilizarse tanto en sensores como en sistemas integrados, en controladores, en sistemas de PC y smartphones o en servidores que utilizan aplicaciones MES o ERP.

También es posible utilizar conjuntamente OPC UA y PROFINET. Ambos protocolos utilizan la misma infraestructura de red.

● Principio cliente-servidor sencillo

Un servidor OPC UA proporciona información dentro de una red, y un cliente OPC UA solicita dicha información.

https://github.com/opcfoundation



● Mecanismos de seguridad integrados

OPC UA utiliza mecanismos de seguridad a distintos niveles:

– El establecimiento de conexiones seguras entre un servidor OPC UA y un cliente OPC UA solo es posible si el cliente y el servidor pueden iniciar sesión mediante certificados X.509-v3 y reconocen mutuamente los certificados (seguridad a nivel de aplicación). Son posibles diferentes directivas de seguridad, incluso una conexión no segura entre servidor y cliente (Security Policy: "Ninguna seguridad")

– Para que el usuario acceda a información, un servidor puede exigirle lo siguiente:

- un certificado (no configurable en STEP 7)

- nombre de usuario y contraseña

- ninguna legitimación del usuario

Los mecanismos de seguridad son opcionales y configurables.

● Independencia de cualquier capa de transporte

Actualmente OPC UA soporta los mecanismos de transporte siguientes:

– Transferencia de mensajes en flujo binario directamente a través de TCP/IP

– Transferencia de mensajes con XML a través de TCP/IP y HTTP. Solo permite una transferencia lenta, por lo que su uso es poco frecuente. No puede configurarse en STEP 7 y no es soportada por las CPU S7-1500.

Todas las aplicaciones OPC UA (prescritas por la especificación OPC UA) soportan el intercambio de datos binario.

● Mapeo de las variables PLC

La información del servidor OPC UA (p. ej., las variables PLC) está modelada en forma de nodos (nodes) unidos entre sí mediante referencias. Esto hace posible navegar con un cliente OPC UA de nodo en nodo y conocer qué contenidos pueden leerse, observarse o escribirse.

● Información

Los servidores OPC UA proporcionan mucha información, p. ej. sobre la CPU, sobre el propio servidor OPC UA, sobre los datos y sobre los tipos de datos.

● Concepto de instancia

OPC UA se basa en un concepto de tipo-instancia. Durante el tiempo de ejecución están disponibles tanto las instancias como sus definiciones de tipos.

● Diferenciación de las funciones mediante perfiles: S7-1500 soporta, p. ej., el perfil de servidor Embedded UA-Server

Consulte también Unified Automation (https://www.unified-automation.com)

OPC Foundation (https://opcfoundation.org)

https://www.unified-automation.com/

https://opcfoundation.org/



9.1.4 De la interfaz OPC clásica a OPC UA

Interfaz unificada La OPC clásica solo funciona en sistemas operativos Windows.

Para solventar esta limitación, OPC Foundation desarrolló el estándar OPC UA.

El estándar no está ligado a ninguna plataforma y utiliza un protocolo binario optimizado basado en TCP para aplicaciones de alto rendimiento

Por ello pueden intercambiar datos entre sí diversos sistemas, p. ej.:

● controladores con sistemas MES y ERP

● controladores de SIEMENS con controladores de otros fabricantes

● smartphones con controladores

● sistemas integrados con controladores

● sensores inteligentes con controladores

9.1.5 El servidor OPC UA de las CPU S7-1500 Las CPU S7-1500 con versión de firmware 2.0 o superior cuentan con un servidor OPC UA. Además de las CPU S7-1500 estándar, aquí también se incluyen las variantes S7-1500F, S7-1500T, S7-1500C, las CPU S7-1500pro, las CPU ET 200SP, el controlador por software SIMATIC S7-1500 y PLCSIM Advanced.

Convención: el término "CPU S7-1500" incluye todas las variantes de CPU citadas arriba.

Principios básicos del servidor OPC UA de la CPU S7-1500 Es posible acceder al servidor OPC UA de la CPU a través de todas las interfaces PROFINET integradas de la CPU S7-1500.

A través del CP o CM no es posible acceder directamente a través del bus de fondo al servidor OPC UA de la CPU.

Para el acceso por clientes, el servidor guarda las variables PLC habilitadas y otra información en forma de nodos (véase Configurar acceso a variables PLC (Página 166)). Estos nodos están conectados entre sí y forman una red. OPC UA define puntos de acceso a esa red (well-known nodes) que permiten navegar hasta nodos subordinados.

Con un cliente OPC UA es posible leer, observar o escribir valores de variables del programa del PLC, además de llamar a métodos proporcionados por el servidor. A partir de la versión de firmware 2.5 existe la posibilidad de implementar métodos; consulte Métodos de servidor (Página 193).



Clases de nodos Los servidores OPC UA proporcionan información en forma de nodos (nodes). Un nodo puede ser, por ejemplo, un objeto, una variable o un método.

El siguiente ejemplo muestra el área de direcciones del servidor OPC UA de una CPU S7-1500 (extracto del cliente OPC UA "UaExpert" de Unified Automation).

Figura 9-1 Ejemplo del espacio de direcciones del servidor OPC UA de una CPU S7-1500

En la figura superior se ha seleccionado (sobre fondo gris) la variable "MyValue". Esta variable se encuentra bajo el nodo "Memory", que pertenece a la clase de nodo "Object". A su vez, "Memory" se encuentra bajo el nodo ""PLC_1" (asimismo un "Object").

Espacio de direcciones Los nodos están unidos entre sí mediante referencias, por ejemplo mediante la referencia "HasComponent", que refleja una relación jerárquica entre un nodo y sus nodos subordinados. Mediante sus referencias, los nodos componen una red que puede tener, por ejemplo, forma de árbol. Una red formada por nodos también se denomina área de direcciones. Partiendo de la raíz se accede a todos los nodos del área de direcciones.



9.1.6 Direccionamiento de nodos Los nodos del espacio de direcciones OPC UA se definen unívocamente mediante un NodeId (ID de nodo o Node Identifier).

El NodeId está compuesto por un identificador, un tipo de identificador y un índice de espacio de nombres. Los espacios de nombres se utilizan para evitar conflictos de nombres. OPC Foundation ha definido una serie de nodos que dan información sobre el correspondiente servidor OPC UA. Esos nodos pueden encontrarse en el espacio de nombres de la OPC Foundation y tienen el índice 0.

Además, la OPC Foundation ha definido tipos de datos y de variables.

Namespace Todas las variables y métodos de un S7-1500 están en el espacio de nombres (Namespace) "http://www.siemens.com/simatic-s7-opcua". El índice predeterminado para este espacio de nombres es 3. El índice puede cambiar si posteriormente se agregan nuevos espacios de nombres en el servidor o se elimina alguno de los existentes. Por ello es necesario consultar el índice actual del espacio de nombres en el servidor antes de leer o escribir valores.

En la figura siguiente se muestra el resultado de tal solicitud. Se usa como ejemplo el programa "UaClient" de Siemens, véase Manual de funciones Comunicación S7-1500 (https://support.industry.siemens.com/cs/ww/es/view/59192925).

Identifier El Identifier es el nombre de la variable PLC entre comillas. Las comillas son el único signo que no está permitido en STEP 7 dentro de un nombre. Mediante las comillas se evitan conflictos de nombres.

En el ejemplo siguiente se lee el valor de la variable "StartTimer":




El Identifier puede constar de varios componentes. En ese caso, los distintos componentes van separados por un punto. En el ejemplo siguiente se lee el bloque de datos Array "MyDB" completo. En este bloque de datos se encuentra un array con diez valores enteros. Los diez valores deben leerse simultáneamente. Por ello se ha introducido "0:9" como Array Range.



Variables PLC en el área de direcciones del servidor OPC UA La figura siguiente muestra dónde se encuentran las variables PLC del ejemplo en el espacio de direcciones del servidor OPC UA (parte de UA Client):

El bloque de datos "MyDB" es un bloque de datos global. Por ello el bloque de datos se encuentra debajo del nodo "DataBlocksGlobal". "StartTimer" es una variable de marcas y por ello se almacena debajo del nodo "Memory".

Figura 9-2 Variables PLC en el área de direcciones del servidor OPC UA



Métodos en el área de direcciones del servidor OPC UA Si se implementa un método mediante el programa de usuario, tendrá el aspecto siguiente en el espacio de direcciones del servidor OPC UA (consulte Instrucciones del servidor OPC UA para la implementación de métodos (Página 198)):

Figura 9-3 Métodos en el área de direcciones del servidor OPC UA



9.1.7 Mapeado de tipos de datos

Tipos de datos SIMATIC y OPC UA Los tipos de datos SIMATIC no siempre coinciden con los tipos de datos OPC UA.

Las CPU S7-1500 proporcionan al propio servidor OPC UA variables SIMATIC (con tipos de datos SIMATIC) como tipos de datos OPC UA, de modo que los clientes OPC UA puedan acceder a través de de la interfaz del servidor a esas variables con tipos de datos OPC UA.

Un cliente puede leer en dicha variable el atributo "Datatype" y reconstruir en SIMATIC el tipo de datos original.

Ejemplo

Una variable tiene el tipo de datos SIMATIC "COUNTER". En la tabla se lee COUNTER → UInt16. Ahora se sabe que no es necesario recodificar; el valor COUNTER recorre la línea como tipo de datos UInt16.

El cliente puede reconocer por el atributo "Datatype" que realmente es un tipo de datos COUNTER, y por tanto puede reconstruirlo.

Tabla 9- 1 Tipos de datos SIMATIC y OPC UA

Tipo de datos SIMATIC Tipo de datos OPC UA BOOL Boolean BYTE BYTE

→ Byte WORD WORD

→ UInt16 DWORD DWORD

→ UInt32 LWORD LWORD

→ UInt64 SINT SByte INT Int16 DINT Int32 LINT Int64 USINT Byte UINT UInt16 UDINT UInt32 ULINT UInt64 REAL Float LREAL Double S5TIME S5TIME

→ UInt16 TIME TIME

→ Int32



Tipo de datos SIMATIC Tipo de datos OPC UA LTIME LTIME

→ Int64 DATE DATE

→ UInt16 TIME_OF_DAY (TOD) TOD

→ UInt32 LTIME_OF_DAY (LTOD) LTOD

→ UInt64 DATE_AND_TIME (DT) DT

→ Byte[8] LDT DateTime DTL mapeado como estructura CHAR CHAR

→ Byte WCHAR WCHAR

→ UInt16 STRING (página de códigos 1252 o Windows-1252)

STRING → String

WSTRING (UCS-2; Universal Coded Character Set)

String

TIMER TIMER → UInt16

COUNTER COUNTER → UInt16

Matrices Una orden de lectura o escritura en OPC UA es siempre un acceso matricial, es decir, básicamente provisto de índice y longitud, de manera que una variable individual no es más que un caso particular de matriz (índice 0 y longitud 1). En la línea, el tipo de datos se envía varias veces consecutivamente. En las variables el atributo "Datatype" apunta al tipo de datos básico. De los atributos "ValueRank" y "ArrayDimensions" se deduce si se trata de una matriz y cuál es su tamaño.

Estructuras Las estructuras se transfieren como ExtensionObject. El servidor del S7-1500 utiliza la representación binaria para transferir el ExtensionObjects a través de la línea, y los diversos elementos de la estructura se encuentran uno detrás del otro. Delante se encuentra el NodeId del tipo de datos, que sirve para que un cliente averigüe la organización de la estructura.

Para ello, en el caso de la especificación OPC UA con versión V1.03 o inferior, un cliente debe leer, descodificar e interpretar el DataTypeDictionary completo (salvo que lo haya aprendido antes offline mediante una importación XML).



Información adicional Encontrará información más detallada sobre el mapeo de los tipos de datos básicos, y también sobre las matrices y estructuras, en la especificación de OPC UA Part 6, "Mappings", véase OPC UA BINARY.

9.1.8 Puntos finales de los servidores OPC UA Los puntos finales del servidor OPC UA definen el nivel de seguridad para una conexión. Según la finalidad de aplicación o el nivel de seguridad deseado, en el punto final deben realizarse los ajustes correspondientes a la conexión.

Distintos ajustes de seguridad Antes de establecer una conexión segura los clientes OPC UA solicitan al servidor información sobre qué ajustes de seguridad son necesarios para establecer conexiones. El servidor devuelve una lista con todos los ajustes de seguridad (puntos finales) que ofrece.

Configuración de puntos finales Los puntos finales constan de los siguientes componentes:

● Identificación para OPC: "opc.tcp"

● Dirección IP: 192.168.178.151 (en el ejemplo)

● Número de puerto para OPC UA: 4840 (puerto estándar)

El número de puerto es configurable, consulte "Ajustes del servidor OPC UA (Página 175)".

● Ajuste de seguridad para mensajes (Message Security Modus): None, Sign, SignAndEncrypt.

● Procedimiento de cifrado y hash (Security Policy): None, Basic128Rsa15, Basic256, Basic256Sha256 (en el ejemplo).

La figura siguiente muestra el programa "UA Sample Client" de OPC Foundation.



El cliente ha establecido una conexión segura con el servidor OPC UA de una CPU S7-1500, con el punto final "opc.tcp://192.168.178.151:4840 - [SignAndEndCrypt: Basic128Rsa15:Binary]". El punto final contiene los ajustes de seguridad "SignAndEndCrypt:Basic128Rsa15".

Nota Seleccionar un punto final con la mayor directiva de seguridad (Security Policy) posible

Seleccione para los puntos finales una directiva de seguridad (Security Policy) adecuada a la aplicación y desactive en el servidor OPC UA la directiva de seguridad menor.

Para los dos puntos finales más seguros (Basic256Sha256) del servidor OPC UA de la CPU S7-1500 se necesita un certificado Sha256.

Figura 9-4 Programa "UA Sample Client" de la OPC Foundation

Una conexión con un punto final del servidor solo se establece si el cliente OPC UA cumple los ajustes de seguridad exigidos para el punto final.



Información proporcionada por el servidor OPC UA Los servidores OPC UA proporcionan numerosos datos:

● Los valores de variables PLC y de componentes de DB a los que pueden acceder los clientes.

● Los tipos de datos de esas variables PLC y componentes de DB.

● Datos sobre el propio servidor OPC UA y sobre la CPU.

Con ella, los clientes pueden hacerse una visión general y leer información específica. No se necesitan conocimientos previos sobre el programa PLC ni sobre los datos de la CPU. No es necesario preguntar al desarrollador del programa PLC cuándo deben leerse las variables PLC. En el propio servidor están guardados todos los datos necesarios (por ejemplo, los tipos de datos de las variables PLC).

Visualización de la información del servidor OPC UA Existen las siguientes posibilidades:

● Online: Toda la información disponible se visualiza durante el tiempo de ejecución del servidor OPC UA. Para ello, navegue por el área de direcciones del servidor.

● Offline: Exporte un archivo XML basado en los esquemas XML de la OPC Foundation.

No se exportan conjuntamente los métodos de servidor (instancia de FB que puede ser llamada por un cliente OPC UA) creados (STEP 7 (TIA Portal) V15), consulte Proporcionar métodos en el servidor OPC UA (Página 193).

● Offline con la API Openness: En el programa se utiliza la API (Application programming interface) del TIA Portal para ejecutar la función de exportación de todas las variables PLC que puede leer el OPC UA. Para ello se necesita .NET Framework 4.0, véase TIA Portal Openness, Automatización de proyectos SIMATIC mediante scripts (https://support.industry.siemens.com/cs/ww/en/view/109477163).

● Si ya se conoce la sintaxis y el programa PLC puede accederse al servidor OPC UA sin averiguaciones previas.

https://support.industry.siemens.com/cs/ww/en/view/109477163



9.1.9 Comportamiento del servidor OPC UA durante el funcionamiento

El servidor OPC UA en funcionamiento El servidor OPC UA de la CPU S7-1500 arranca cuando se activa el servidor y se carga el proyecto en la CPU.

Aquí (Página 171) se describe cómo activar el servidor OPC UA.

Reacción a STOP de la CPU

Un servidor OPC UA permanece en funcionamiento aunque la CPU cambie al estado operativo "STOP". Entonces el servidor OPC UA continúa respondiendo a consultas de clientes OPC UA.

Comportamiento concreto del servidor:

● Cuando se consultan valores de variables PLC se obtienen los valores actuales antes de que la CPU cambiara al estado operativo "STOP".

● Si se escriben valores en el servidor OPC UA, el servidor OPC UA aplica dichos valores.

Pero la CPU no procesa los valores porque el programa de usuario no se ha ejecutado en el estado operativo "STOP".

Sin embargo, un cliente OPC UA puede leer los valores nuevos del servidor OPC UA de la CPU.

● Cuando se llama a un método de servidor se recibe el mensaje de error 16#00AF_0000 (BadInvalidState), porque no se puede ejecutar el método de servidor (programa de usuario).

Reinicio del servidor El servidor OPC UA se detiene en cada operación de carga en la CPU (p. ej., tras cargar una configuración o un bloque) y luego se reinicia. Según sea el volumen de la estructura de datos es posible que el reinicio del servidor OPC UA requiera cierto tiempo.



Leer el estado operativo de la CPU a través del servidor OPC UA El servidor OPC UA permite leer el estado operativo de la CPU, consulte la figura siguiente:

Figura 9-5 Leer el estado operativo de la CPU a través del servidor OPC UA

Además del estado operativo de la CPU, también es posible leer el estado (State) del servidor.

9.1.10 Información importante sobre clientes OPC UA

Principios básicos de los clientes OPC UA Los clientes OPC UA son programas que efectúan lo siguiente:

● Leen y escriben información de un servidor OPC UA, p. ej., una CPU S7-1500

● Hacen que el servidor OPC UA ejecute métodos

Sin embargo, los clientes OPC UA solo pueden acceder a datos que están habilitados para tal fin (consulte "Administrar derechos de escritura y lectura (Página 166)").

Para establecer una conexión con un servidor OPC UA se necesita el punto final del servidor (consulte "Puntos finales de los servidores OPC UA (Página 145)").



Leer información del servidor OPC UA Si existe una conexión con un punto final del servidor, es posible utilizar la función de navegación del cliente: se navega desde un punto inicial definido (desde el nodo raíz "Root") por el área de direcciones del servidor.

De este modo se obtienen, entre otras, la información siguiente:

● Las variables PLC habilitadas, los bloques de datos y los componentes de bloque de datos

● El índice de espacio de nombres y los identificadores de estas variables PLC, bloques de datos y componentes de DB

● Los tipos de datos de las variables PLC y de los componentes de DB

● El número de componentes en arrays (necesario para leer y escribir arrays)

Además se obtiene información sobre el propio servidor OPC UA e información sobre el S7-1500 conforme al estándar "OPC UA for Devices" de OPC Foundation, por ejemplo, el número de serie, la versión del firmware.

Leer datos del servidor y escribir datos en el servidor Ya conoce el índice del espacio de nombres, el identificador y el tipo de datos de las variables PLC. De este modo pueden leerse selectivamente tanto variables PLC y componentes de DB individuales como matrices y estructuras completas. Encontrará ejemplos de lectura de variables booleanas y bloques de datos Array en Direccionamiento de nodos (Página 139).

Con la información obtenida navegando por el área de direcciones del servidor (índice, identificador y tipo de datos), también puede transferir valores a S7-1500 con el cliente OPC UA. El siguiente ejemplo sobrescribe los tres primeros valores del bloque de datos Array "MyDB".

En "Array Range" se indica qué componentes del array se desea sobrescribir. El código de estado "Good" indica que se han podido transferir los valores correctamente. Sin embargo, solo es posible escribir los valores en el S7-1500 y no los sellos de tiempo de dichos valores. Los sellos de tiempo solo pueden leerse.



Acceso más rápido mediante registro Los ejemplos anteriores utilizan como Identifier cadenas de caracteres, por ejemplo, "MyBD2"."THIS". Sin embargo, pueden acelerarse notablemente los accesos si se usa como Identifier una NodeID numérica en lugar de una NodeID de string. Por ello, si se va a acceder con frecuencia a determinadas variables, conviene utilizar las funciones "RegisteredRead" y "RegisteredWrite".

En ese caso, el cliente primero registra la variable PLC en el servidor. Y el servidor devuelve un Identifier que el cliente utilizará para el acceso propiamente dicho. Este Identifier es válido exclusivamente para la sesión actual y debe solicitarse nuevamente en caso de que se deshaga/pierda la sesión.

En el ejemplo siguiente se ha registrado primero la variable "StartTimer" en en servidor. A continuación se utiliza la función rápida "RegisteredWrite" para activar el valor.

Esta misma lógica puede aplicarse también con la función "RegisteredRead", lo cual es aconsejable en especial para los datos que se leen de modo reiterativo. Sin embargo, tenga en cuenta que, según la aplicación, puede ser más aconsejable usar una Subscription.

Recomendación: Lo más recomendable es efectuar registros en el programa de arranque del cliente OPC UA, ya que el registro ocupa tiempo.

Recuerde que en las propiedades de la CPU S7-1500 es posible ajustar el número máximo de nodos registrados y que los clientes deben tener en cuenta dicho número; consulte Ajustes generales del servidor OPC UA (Página 175).

Suscripción Con la función "Subscription", solo se transmitirán las variables para las que un cliente OPC UA se haya registrado en el servidor OPC UA. El servidor OPC UA enviará un mensaje al cliente OPC UA para estas variables registradas (Subscriptions) únicamente si se ha modificado un valor. Gracias a la vigilancia de estas variables, no es necesario enviar consultas continuamente desde el cliente OPC UA, lo que reduce la carga de la red.

Para utilizar esta función, hay que crear una Subscription. Para ello, especifique en el cliente UA el intervalo de transmisión ("Publishing Interval") y haga clic en el botón "Create". El intervalo de transmisión es el intervalo de tiempo durante el que se envían valores nuevos al cliente.



En el siguiente ejemplo se ha creado una suscripción: En este caso, el cliente recibe cada 50 milisegundos un mensaje con los valores nuevos (intervalo de transmisión 50 ms).

Protección del servidor contra sobrecarga

Con el parámetro "Mínimo intervalo de envío" puede configurarse el servidor OPC UA de la CPU S7-1500 de manera que no utilice los intervalos de envío extremadamente cortos que solicita el cliente, consulte Ajustes del servidor OPC UA (Página 175).

Ejemplo: un cliente desea funcionar como se ha descrito anteriormente con un intervalo de envío de 50 ms. Sin embargo, un intervalo de envío tan corto provocaría una elevada carga en la red y en el servidor. Por ello, ajuste un "Mínimo intervalo de envío" de 1000 ms en el servidor. De este modo, los clientes que en su suscripción exigen un intervalo de envío menor se "frenan" hasta 1000 ms, y el servidor queda protegido contra sobrecarga.

Vigilancia de variables PLC Una vez creada la Subscription, informe al servidor sobre qué variables debe vigilar con esta. En el ejemplo siguiente se ha agregado la variable "Voltage" a la suscripción.

La variable "Voltage" contiene el valor de una magnitud de tensión capturada por una CPU S7-1500 (a través de un módulo de entradas analógicas AI 4xU/I 2-wire).

El intervalo de muestreo (Sampling Intervall) contiene un valor negativo (-1). Con ello se establece que el servidor OPC UA comprobará si hay modificaciones en el intervalo más breve posible.

Aquí en el ejemplo, la longitud de la cola está ajustada a "1": Se lee un solo valor, respectivamente, a intervalos de 50 milisegundos desde la CPU y a continuación se envía al cliente OPC UA si el valor ha cambiado.

En el ejemplo, el parámetro "Deadband" es "0,1": Los cambios de valor deben ser al menos de 0,1 voltios para que el servidor envíe el valor nuevo al cliente. El servidor no envía cambios de valor más pequeños que el indicado. Este parámetro permite, por ejemplo, suprimir el ruido: pequeñas variaciones de una magnitud de proceso que se consideran insignificantes.

Comunicación OPC UA 9.2 Seguridad en OPC UA


9.2 Seguridad en OPC UA

9.2.1 Ajustes de seguridad

Afrontar riesgos OPC UA permite el intercambio de datos entre sistemas diferentes, tanto en los niveles de proceso y producción como con sistemas del nivel de control y a nivel empresarial.

Esta posibilidad entraña también riesgos de seguridad. Por ello, OPC UA utiliza una serie de mecanismos de seguridad:

● verificación de la identidad de servidores y clientes OPC UA;

● verificación de la identidad de los usuarios;

● Intercambio de datos firmado/cifrado entre servidores y clientes OPC UA.

Los ajustes de seguridad solo deben soslayarse en casos fundados:

● Durante la puesta en marcha

● En proyectos aislados sin conexión vía Ethernet con el exterior

Si, p. ej., en el "UA Sample Client" de la OPC Foundation se selecciona el punto final "None", el programa emite una advertencia clara:

Nota Desactivar directivas de seguridad (Security Policies) no deseadas

Si en la configuración del canal de seguridad del servidor OPC UA del S7-1500 se han activado todas las directivas de seguridad (ajuste predeterminado), y por tanto también el punto final "None" (Ninguna seguridad), también es posible un intercambio de datos no seguro entre el servidor y el cliente (sin firma y sin cifrar). El servidor OPC UA de la CPU S7-1500 envía incluso con "None" (Ninguna seguridad) su certificado público al cliente. Y algunos clientes verifican este certificado. Sin embargo, el cliente no envía ningún certificado al servidor. Con "None" la identidad del cliente es desconocida. En tal caso todos los clientes OPC UA pueden conectarse al servidor, con independencia de todos los ajustes de seguridad que sigan.

En la configuración del servidor OPC UA tenga en cuenta que solo están activadas las directivas de seguridad compatibles con el concepto de protección para la máquina o instalación. Es necesario desactivar todas las demás directivas de seguridad.

Recomendación: Utilice el ajuste "Basic256Sha256" para el que el servidor solo acepta certificados Sha256.



Otras reglas de seguridad ● Utilice el punto final "None" solo en casos excepcionales.

● Utilice la "Autenticación de huésped" del usuario solo en casos excepcionales.

● Permita el acceso a variables PLC y componentes de DB a través de OPC UA solo si es realmente necesario.

● En la configuración del cliente OPC US del S7-1500 utilice las listas de clientes de confianza para permitir el acceso únicamente a determinados clientes.

9.2.2 Certificados según X.509 de la UIT En OPC UA hay integrados mecanismos de seguridad en varias capas. Los certificados digitales desempeñan un papel importante. Un cliente OPC UA solo puede establecer una conexión segura con un servidor OPC UA si el servidor acepta el certificado digital del cliente y lo clasifica como certificado de confianza.

Consulte el capítulo "Configurar servidor OPC UA del S7-1500 (Página 171)".

Además, el cliente también debe comprobar el certificado del servidor y confiar en él. Servidor y cliente deben identificarse y demostrar que son realmente quienes afirman ser: Deben probar su identidad. La autenticación recíproca de cliente y servidor impide, por ejemplo, ataques mediante "man in the middle".

Ataques por un "man in the middle" Entre el servidor y el cliente podría encontrarse un "man in the middle", un programa que intercepta la comunicación entre el servidor y el cliente y afirma ser el cliente o el servidor, con lo cual puede obtener información importante sobre el programa S7 o activar valores en la CPU y, por tanto, atacar una máquina o instalación.

En OPC UA se emplean certificados digitales acordes con el estándar X.509 de la Unión Internacional de Telecomunicaciones (UIT).

Dichos certificados permiten demostrar (autenticar) la identidad de un programa, un equipo o una organización.



Certificados X.509 Un certificado X.509 contiene, entre otras, la información siguiente:

● Número de versión del certificado

● Número de serie del certificado

● Información sobre el algoritmo utilizado por la entidad emisora para firmar el certificado

● Nombre de la entidad emisora

● Inicio y final de la validez del certificado

● Nombre del programa, de la persona o de la organización para el que la entidad emisora ha firmado el certificado

● La clave pública del programa, la persona o la organización

Por tanto, un certificado X.509 relaciona una identidad (nombre de un programa, una persona o una organización) con la clave pública del programa, la persona o la organización.

Comprobación al establecer la conexión

Al establecer la conexión entre el cliente y el servidor los dispositivos comprueban toda la información del certificado que es necesaria para determinar la integridad, p. ej., firma, validez, nombre de aplicación (URN).

Firma y cifrado Para poder supervisar si un certificado ha sido manipulado, los certificados se firman.

Existen distintos procedimientos:

● Dirigirse a una entidad emisora (CA) para que firme el certificado.

En este caso la entidad emisora comprueba la identidad del solicitante y firma el certificado con la clave privada de la entidad emisora. Envíe para ello un certificado CSR (Certificate Signing Request) a la entidad emisora. El método para crear uno mismo un CSR con la herramienta OpenSSL se describe aquí (Página 158).

● El propio usuario crea un certificado y lo firma.

Para ello utilice, por ejemplo, el programa "Opc.Ua.CertificateGenerator" de la OPC Foundation. El procedimiento correspondiente se describe aquí (Página 36). O bien se utiliza OpenSSL: Encontrará las instrucciones en Autogeneración de parejas de claves PKI y de certificados (Página 159).

● La posibilidad más sencilla: dentro del TIA Portal se dispone de las dos posibilidades El TIA Portal puede generar y firmar certificados. Si el proyecto está protegido y se inicia sesión como usuario con derecho de función para cambiar un ajuste de seguridad, podrán utilizarse también los ajustes globales de seguridad. Los ajustes globales de seguridad permiten el acceso al administrador de certificados, y por tanto también a la entidad emisora (CA) del TIA Portal.



Excurso: tipos de certificados ● Certificado autofirmado:

Cualquier dispositivo genera su propio certificado y lo firma. Ejemplos de aplicaciones: configuración estática con número limitado de interlocutores de comunicación.

De un certificado autofirmado no pueden derivarse certificados nuevos. Sin embargo, es necesario cargar en la CPU (debe estar en STOP) todos los certificados autofirmados de los interlocutores.

● Certificado CA:

Todos los certificados son generados y firmados por una entidad emisora. Ejemplos de aplicaciones: instalaciones que crecen dinámicamente

Solo es necesario cargar en la CPU el certificado de la entidad emisora. La entidad emisora puede generar nuevos certificados (es posible agregar interlocutores sin que la CPU esté en STOP).

Firma La firma permite verificar la integridad y el origen de un mensaje, como se describe a continuación.

En la firma, lo primero que hace el emisor es formar un valor hash a partir del texto explícito (mensaje explícito). Después, el emisor cifra el valor hash con su clave privada y finalmente transfiere al receptor el texto explícito junto con el valor hash cifrado. Para comprobar la firma, el receptor necesita la clave pública del emisor (está incluida en el certificado X.509 del emisor). Con la clave pública del emisor, el receptor descifra el valor hash recibido. Después, el receptor forma su propio valor hash a partir del texto explícito recibido (el procedimiento hash está incluido en el certificado del emisor). A continuación, el receptor compara ambos valores hash:

● Si los dos valores hash son idénticos, entonces el texto explícito ha llegado al destinatario sin alteraciones y sin haber sido manipulado.

● Si los dos valores hash no se corresponden, entonces el texto explícito recibido por el destinatario no es idéntico al enviado. El texto explícito ha sido manipulado o ha sido falsificado durante la transferencia.

Cifrado El cifrado de datos permite evitar que personas no autorizadas conozcan el contenido. Los certificados X.509 no se cifran, son públicos y accesibles a cualquiera.

En el cifrado, el emisor cifra el mensaje explícito utilizando la clave pública del receptor. Para ello, el emisor necesita el certificado X.509 del receptor, puesto que contiene la clave pública del receptor. El receptor descifra el mensaje utilizando su clave privada. El receptor es el único que puede descifrar el mensaje. Es el único que posee la clave privada. Por ello no está permitido transmitir la clave privada.



Secure Channel (canal seguro) OPC UA utiliza las claves privadas y públicas de cliente y servidor para establecer una conexión segura, el canal seguro (secure channel). Una vez establecida la conexión segura, cliente y servidor generan una clave interna que solo ellos conocen y que ambos utilizan para firmar y cifrar mensajes. Este procedimiento simétrico (una clave común) es mucho más rápido que un procedimiento asimétrico (claves privada y pública).

9.2.3 Certificados en OPC UA

Uso de certificados X.509 en OPC UA Para establecer una conexión entre cliente y servidor, OPC UA utiliza tres tipos de certificados X.509:

● Certificados de aplicación OPC UA

Estos certificados X.509 identifican la instancia de software, la instalación correspondiente de un software de cliente o de servidor. En el atributo "Organisation Name" se introduce el nombre de la empresa que utiliza el software.

Nota

El servidor OPC UA del S7-1500 utiliza certificados de aplicación incluso con el ajuste de seguridad "None" (Ninguna seguridad). De este modo se garantiza la compatibilidad con OPC UA V1.1 y versiones anteriores.

● Certificados de software OPC UA

Este certificado X.509 identifica una versión concreta del software de cliente o servidor. Estos certificados contienen atributos que describen qué pruebas ha superado la versión de software en la certificación realizada por OPC Foundation (o el laboratorio de prueba reconocido). En el atributo "Organisation Name" se introduce el nombre de la empresa que ha desarrollado el software (o que lo distribuye).

Nota

En STEP 7 V15 no se soportan certificados de software.

● Certificados de usuario OPC UA

Este certificado X.509 identifica al usuario concreto que, por ejemplo, solicita datos de proceso del servidor OPC UA de una CPU S7-1500. Este certificado no es obligatorio si el usuario puede demostrar que tiene autorización mediante una contraseña o si se ha configurado un acceso anónimo.

Nota

En STEP 7 V15 no se soportan certificados de usuario.

Estos certificados son certificados de entidad final (end-entity): Identifican, por ejemplo, una entidad, una persona, una organización, una empresa, una instancia (instalación) de un software.



9.2.4 Crear certificados autofirmados El siguiente capítulo solo es relevante si se utiliza un cliente OPC UA que no genere certificados de cliente.

Con STEP 7 pueden crearse certificados autofirmados.

Proceda del siguiente modo:

1. En las propiedades de la CPU, en "Protección y seguridad > Administrador de certificados > Certificados de dispositivo", haga doble clic en "<Agregar nuevo>".

2. Haga clic en "Agregar".

3. En el cuadro de diálogo "Generar nuevo certificado", seleccione en "Finalidad de uso" la opción "Cliente OPC UA".

4. Haga clic en "Aceptar".

En el siguiente capítulo se describe cómo crear certificados autofirmados con otras herramientas distintas de STEP 7.

En el campo "Nombre alternativo del solicitante" (Subject Alternative Name), STEP 7 introduce automáticamente la URI del certificado creado. P. ej., al crear el certificado mediante técnicas de programación a través de la pila .Net de OPC Foundation, el campo se llama p. ej. "ApplicationUri", y en otras herramientas de creación de certificados puede tener otro nombre.

Uso del generador de certificados de OPC Foundation Un certificado autofirmado de cliente se puede generar, por ejemplo, con el OPC.UA.CertificateGenerator .


1. Descargue la herramienta desde la web de OPC Foundation. Encontrará el programa en la página web de la OPC Foundation (https://opcfoundation.org/developer-tools/developer-kits-unified-architecture), por ejemplo con "Ressources > Samples / Code > Unified Architecture" en "Sample Applications".

2. Instale en su PC las aplicaciones de ejemplo de la OPC Foundation.

3. Abra con el explorador de Windows el directorio de instalación: Lo encontrará en "C:\Program Files (x86)\OPC Foundation\UA 1.02\Sample Applications".

4. Mantenga pulsada la tecla Mayúsculas y haga clic con el botón derecho del ratón en el directorio, de modo que aparezca el menú contextual.

5. Seleccione "Abrir símbolo del sistema aquí".

6. En la ventana de comandos introduzca el comando siguiente en el indicador de comandos: "Opc.Ua.CertificateGenerator -cmd issue -sp . -an MyClient"

https://opcfoundation.org/developer-tools/developer-kits-unified-architecture

https://opcfoundation.org/developer-tools/developer-kits-unified-architecture



7. Pulse la tecla Intro.

8. El programa crea para "MyClient.":

– En la subcarpeta "certs", el certificado "MyClient" con la clave pública del cliente

– En la subcarpeta "private", la clave privada del cliente

"MyClient" es solo un ejemplo. Suponiendo que su cliente OPC UA se denomine "SuperClient", introduzca en el indicador de comandos la siguiente línea: "Opc.Ua.CertificateGenerator -cmd issue -sp . -an SuperClient". La figura siguiente muestra la entrada en la línea de comandos:

Ayuda con otras versiones de generador La descripción está basada en el "Opc.Ua.CertificateGenerator" de OPC Foundation del 25 de junio de 2015. En otras versiones del generador puede que sea necesaria otra entrada. Para obtener información sobre la entrada necesaria, proceda del siguiente modo:

1. Introduzca en el indicador de comandos el comando siguiente: "Opc.Ua.CertificateGenerator -?"

Se muestra la ayuda.

2. Utilice las opciones introducidas en "Create a self-signed Application Certificate".

9.2.5 Autogeneración de parejas de claves PKI y de certificados Este capítulo solo es relevante cuando se quiere utilizar un cliente OPC UA que no es capaz de generar por sí mismo una pareja de claves PKI y un certificado de cliente. En tal caso, con OpenSSL se crea una clave privada y una pública, se genera un certificado X.509 y se autofirma el certificado.

Utilizar OpenSSL OpenSSL es una herramienta para generar certificados. También es posible utilizar otras herramientas, p. ej. XCA, un software de administración de claves con interfaz gráfica para tener una mejor visión de los certificados emitidos.

Para trabajar con OpenSSL en Windows, proceda del modo siguiente:

1. Instale OpenSSL en Windows. Si se utiliza una versión del sistema operativo de 64 bits, instale OpenSSL, por ejemplo, en el directorio "C:\OpenSSL-Win64". Puede descargar OpenSSL-Win64 de distintos proveedores de software de código abierto.

2. Cree un directorio, por ejemplo "C:\demo".



3. Abra el la línea de comando (cmd.exe). Para ello, haga clic en "Start" y en el campo de búsqueda introduzca "cmd". En la lista de resultados, haga clic con el botón derecho del ratón en "cmd.exe" y ejecute el programa como administrador: Windows abrirá la línea de comando (prompt de DOS).

4. Vaya al directorio "C:\demo". Para ello, introduzca el comando siguiente: "cd C:\demo".

5. Active las variables de entorno siguientes:

– set RANDFILE=c:\demo\.rnd

– set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg

La figura siguiente muestra la línea de comando con los comandos:

6. Inicie OpenSSL. Si OpenSSL se había instalado en el directorio C:\OpenSSL-Win64 ,

introduzca: C:\OpenSSL-Win64\bin\openssl.exe. La figura siguiente muestra la línea de comando con el comando:

7. Genere una clave privada. Guarde la clave en el archivo "myKey.key". En este ejemplo la

clave tiene 1024 bits de longitud; para aumentar la seguridad de RSA, en la práctica utilice 2048 bits. Introduzca el comando siguiente: "genrsa -out myKey.key 2048" (en el ejemplo "genrsa -out myKey.key 1024"). La figura siguiente muestra la línea de comando con el comando y la respuesta de OpenSSL:



8. Genere una CSR (Certificate Signing Request), una petición de firma para un certificado. Para ello, introduzca el comando siguiente: "req -new -key myKey.key -out myRequest.csr". Mientras se ejecuta este comando, OpenSSL le preguntará datos de su certificado:

– Country Name: por ejemplo "DE" para Alemania, "FR" para Francia

– State or Province Name: p. ej. "Baviera"

– Location Name: p. ej. "Augsburgo"

– Organisation Name: Introduzca el nombre de su empresa.

– Organisational Unit Name: p. ej. "IT"

– Common Name: p. ej. "Cliente OPC UA de la máquina A"

– Email Address:

Importante: En la columna "Nombre alternativo del firmante" (Subject Alternative Name) del certificado creado debe estar depositada la dirección IP del programa de cliente; en caso contrario, la CPU no acepta el certificado.

sus datos se agregarán al certificado. La figura siguiente muestra la línea de comando con el comando y la respuesta de OpenSSL:

El comando crea en el directorio C:\demo un archivo que contiene la Certificate Signing Request (CSR); en el ejemplo, "myRequest.csr".

Uso de la CSR Es posible utilizar una CSR de dos formas:

● Enviando la CSR a una entidad emisora (CA): Tenga en cuenta las indicaciones de la correspondiente entidad emisora. La entidad emisora (CA) comprueba sus datos y su identidad (autenticación) y firma el certificado con la clave privada de la entidad emisora. Recibirá el certificado X.509 firmado y lo podrá utilizar, por ejemplo, para OPC UA, HTTPS o Secure OUC (secure open user communication). Sus interlocutores comprueban mediante la clave pública de la entidad emisora si su certificado ha sido realmente emitido y firmado por dicha entidad (es decir, que sus datos han sido confirmados en el certificado por la entidad emisora).

● Autofirmando la CSR: Para ello, utilice su clave privada. Esta posibilidad se muestra en el paso siguiente.



Autofirma de certificados Para poder generar y firmar su propio certificado (certificado autofirmado) introduzca el comando siguiente: "x509 -req -days 365 -in myRequest.csr -signkey myKey.key -out myCertificate.crt".

La figura siguiente muestra la línea de comando con el comando y la respuesta de OpenSSL:

El comando genera un certificado X.509 con los atributos que se han transferido con la CSR (en el ejemplo, "myRequest.csr"), p. ej. con una validez de un año (-days 365). Además, el comando firma el certificado con su clave privada (en el ejemplo, "myKey.key"). Sus interlocutores pueden comprobar mediante su clave pública (contenidas en el certificado) si el certificado procede efectivamente de usted. De este modo se excluye la posibilidad de que el certificado haya sido manipulado por un atacante.

En los certificados autofirmados el propio usuario certifica que los datos del certificado son correctos. No hay ninguna entidad independiente que verifique los datos.

9.2.6 Transferencia segura de mensajes

Establecimiento de conexiones seguras en OPC UA OPC UA utiliza conexiones seguras entre cliente y servidor. Para ello, OPC UA comprueba la identidad de los interlocutores. Para autenticar a cliente y servidor, OPC UA utiliza certificados acordes con X.509-V3 de la UIT (International Telecommunication Union). Excepción: Con la Security Policy "Ninguna seguridad" no se establece una conexión segura.



Message Security Modus OPC UA utiliza las siguientes Security Policies para la protección de mensajes:

● Ninguna seguridad

Ningún mensaje está protegido. Para utilizar esta directiva de seguridad (Security Policy), establezca una conexión con un punto final None de un servidor.

● Firma

Todos los mensajes se firman. De este modo se comprueba la integridad de los mensajes recibidos. Se detectan las manipulaciones. Para utilizar esta Security Policy, establezca una conexión con un punto final Sign de un servidor.

● Firmar y cifrar

Todos los mensajes se firman y cifran. De este modo se comprueba la integridad de los mensajes recibidos. Se detectan las manipulaciones. Además, ningún atacante puede leer el contenido del mensaje. (Protección de la confidencialidad). Para utilizar esta directiva de seguridad (Security Policy), establezca una conexión a un punto final "SignAndEncrypt" de un servidor.

Las directivas de seguridad se denominan adicionalmente según los algoritmos utilizados. Ejemplo: "Basic256Sha256 - Firmar y cifrar" significa: Punto final protegido, soporta una serie de algoritmos para hashing de 256 bits y cifrado de 256 bits.

Capas necesarias La figura siguiente muestra las tres capas (capa de transporte, canal seguro y sesión) que son necesarias siempre para establecer una conexión.

Figura 9-6 Capas necesarias: capa de transporte, Secure Channel y Session



● Capa de transporte:

Esta capa envía y recibe mensajes. Para ello, OPC UA emplea un protocolo binario optimizado basado en TCP. La capa de transporte es la base para el canal seguro subsiguiente.

● Secure Channel (canal seguro)

El canal seguro recibe de la capa de transporte los datos recibidos y los reenvía a la sesión. El canal seguro reenvía a la capa de transporte los datos de sesión que deben enviarse.

En el modo de seguridad "Sign", el canal seguro firma los datos (mensajes) que se envían. Cuando se reciben mensajes, el canal seguro verifica la firma para detectar posibles manipulaciones.

Con una Security Policy "SignAndEncrypt", el canal seguro firma y cifra los datos que se envían. Los datos recibidos los descifra el canal seguro. A continuación el canal seguro verifica la firma.

Con la Security Policy "Sin seguridad", los paquetes de mensajes pasan por el canal seguro sin modificaciones (los mensajes se reciben y emiten en texto explícito).

● Session

La sesión reenvía los mensajes desde el canal seguro a la aplicación, o recibe de la aplicación los mensajes que deben enviarse. La aplicación utiliza los valores de proceso o proporciona los valores.

Establecimiento del canal seguro El canal seguro se establece del modo siguiente:

1. El servidor comienza a establecer el canal seguro cuando recibe una orden del cliente. Esta petición está firmada o firmada y cifrada, o bien el mensaje se ha enviado en texto explícito (modo de seguridad del punto final servidor seleccionado). Con "Firmar" y "Firmar y cifrar", el cliente envía un "secreto" (un número aleatorio) junto con la petición (request).

2. El servidor valida el certificado del cliente (incluido sin cifrar en la petición) y comprueba la identidad del cliente. Si el servidor confía en el certificado del cliente,

– descifra el mensaje y comprueba la firma ("Firmar y cifrar")

– o comprueba tan solo la firma ("Firmar")

– o deja el mensaje sin modificar ("Ninguna seguridad").

3. Después el servidor envía una respuesta al cliente (protegida de igual forma que la petición). En la respuesta se incluye el secreto del servidor. A partir del secreto de cliente y servidor, ambos calculan una clave simétrica. De este modo se ha establecido el canal seguro.

La clave simétrica se utiliza solo para firmar y cifrar mensajes (en lugar de las claves privadas y públicas de cliente y servidor).



Establecimiento de la sesión La sesión se establece del modo siguiente:

1. El cliente inicia el establecimiento de la sesión enviando una CreateSessionRequest al servidor. Dicho mensaje incluye un Nonce, un número aleatorio utilizado una sola vez. El servidor debe firmar este número aleatorio (Nonce) para demostrar que es el titular de la clave privada. La clave privada corresponde al certificado utilizado por el servidor al establecer el canal seguro. Este mensaje (al igual que todos los siguientes) está protegido conforme a los ajustes de seguridad del punto final seleccionado del servidor (Security Policies seleccionadas).

2. El servidor responde con la CreateSession Response. Este mensaje contiene la clave pública del servidor y el Nonce firmado. El cliente comprueba el Nonce firmado.

3. Si el servidor ha superado la prueba, el cliente envía al servidor una SessionActivateRequest. Este mensaje contiene los datos que son necesarios para la legitimación del usuario:

– o nombre de usuario y contraseña

– o el certificado X.509 del usuario (no soportado en STEP 7 V15)

– o ningún dato (si se ha configurado un acceso anónimo).

4. Si el usuario dispone de los derechos necesarios, el servidor devuelve un mensaje al cliente (ActivateSessionResponse). De este modo se activa la sesión.

La conexión segura entre el cliente y el servidor OPC UA está establecida.

Establecimiento de una conexión con bloques de función PLCopen La especificación PLCopen ha definido una serie de bloques de función IEC 61131 para clientes OPC UA. La instrucción UA_Connect inicia tanto un canal seguro como una sesión según el patrón descrito anteriormente.

Comunicación OPC UA 9.3 Uso de la CPU S7-1500 como servidor OPC UA


9.3 Uso de la CPU S7-1500 como servidor OPC UA

9.3.1 Configurar el acceso a variables PLC

9.3.1.1 Administrar derechos de escritura y lectura

Habilitar variables PLC y variables DB para OPC UA Los clientes OPC UA pueden acceder a variables PLC y variables DB en modo de lectura y escritura si las variables están habilitadas para OPC UA (ajuste predeterminado). Las variables habilitadas tienen activada la casilla de verificación "Accesible desde HMI/OPC UA".

El ejemplo siguiente muestra un bloque de datos Array:

Figura 9-7 Habilitar variables PLC y variables DB para OPC UA

Los clientes OPC UA pueden leer todo el array en una sola operación (véase Direccionamiento de nodos (Página 139)). En todos los componentes del array están activadas las casillas de verificación "Accesible desde HMI/OPC UA" y "Escribible desde HMI/OPC UA".

Resultado: los clientes OPC UA pueden leer estos componentes y escribir en ellos.

Suprimir derechos de escritura Si desea proteger una variable contra accesos de escritura, desactive en dicha variable la opción "Escribible desde HMI/OPC UA". De este modo se retira a los clientes OPC UA y a los dispositivos HMI el derecho de escritura.

Resultado: los clientes OPC UA y los dispositivos HMI únicamente tienen acceso de lectura. Los clientes OPC UA no pueden asignar valores a esa variable, ni por tanto influir en la ejecución del programa S7.



Suprimir derechos de escritura y lectura Para proteger una variable contra accesos de escritura y lectura, desactive en dicha variable la opción "Accesible desde HMI/OPC UA" (marca de verificación no activada). De este modo, el servidor OPC UA elimina la variable de su área de direcciones. Los clientes OPC UA ya no ven esta variable de CPU.

Resultado: Los clientes OPC UA y los dispositivos HMI no pueden ni leer ni escribir la variable.

Derechos de escritura y lectura de estructuras Si se retira el derecho de escritura o lectura a un componente de una estructura, ya no se podrá escribir ni leer la estructura o el bloque de datos como una unidad.

Si se retiran derechos de escritura y de lectura a componentes concretos de un tipo de datos PLC (UDT) también se les retiran de un bloque de datos basado en el UDT.

Visible en HMI Engineering La opción "Visible en HMI Engineering" se refiere a herramientas de ingeniería de Siemens. Si se desactiva la opción "Visible en HMI Engineering" (marca de verificación no activada), ya no se podrá configurar la variable en WinCC (TIA Portal).

La opción no tiene repercusión en OPC UA.

Reglas ● No permita en STEP 7 accesos de lectura a variables PLC y variables de bloques de

datos más que cuando sea necesario para la comunicación con otros sistemas (controladores, sistemas integrados, MES).

No deben habilitarse otras variables PLC.

● Garantice accesos de escritura a través de OPC UA solo si los derechos de escritura son realmente necesarios con determinadas variables PLC y variables de bloques de datos.

● Si ha desactivado la opción "Accesible desde HMI/OPC UA" para todos los elementos de un bloque de datos, en el espacio de direcciones del servidor OPC UA de la CPU S7-1500 este bloque de datos dejará de estar visible para el cliente OPC UA.

● También es posible evitar centralizadamente el acceso a un bloque de datos completo (consulte Información importante sobre clientes OPC UA (Página 149)). Este ajuste prevalece sobre los ajustes de los componentes en el editor de DB.

9.3.1.2 Administrar derechos de escritura y lectura para un DB completo

Ocultar DB o contenidos de DB para clientes OPC UA A partir de STEP 7 V15 existe la posibilidad de impedir de manera sencilla que un cliente OPC UA acceda a un bloque de datos completo.

De esta forma, los datos del respectivo DB, también DB de instancia de bloques de función, se mantienen ocultos para los clientes OPC UA.

El ajuste predeterminado es que los bloques de datos de clientes OPC UA sean legibles y escribibles.



Procedimiento Para ocultar por completo un bloque de datos a los clientes OPC UA, o para protegerlo contra accesos de escritura de clientes OPC UA, proceda del siguiente modo:

1. En el árbol del proyecto, seleccione el bloque de datos que desea proteger.

2. Seleccione el menú contextual "Propiedades".

3. Seleccione el área "Atributos".

4. Active o desactive la casilla de verificación "DB accesible desde OPC UA" según sus necesidades.

Figura 9-8 Ocultar DB o contenidos de DB para clientes OPC UA

Nota Influencia sobre los ajustes en el editor de DB

Si se oculta un DB mediante el atributo DB aquí descrito, los ajustes de los componentes en el editor de DB dejan de ser relevantes; ya no se podrá acceder a componentes concretos ni escribir en ellos.



9.3.1.3 Posibilidades de acceso a datos del servidor OPC UA

Alto rendimiento en función del caso de aplicación OPC UA está concebido para la transferencia de un gran volumen de datos en corto tiempo. Se puede incrementar notablemente el rendimiento si, en lugar de acceder a variables PLC concretas, se leen y escriben arrays y estructuras completas.

El acceso más rápido es a matrices. Por ello, para los clientes OPC UA deben agruparse los datos en matrices.

Recomendaciones para que el cliente OPC UA acceda al servidor OPC UA

● Para el acceso único u ocasional a los datos, utilice el acceso normal de lectura o escritura.

● Para el acceso cíclico a unos pocos datos (aprox. cada 5 segundos como máximo), utilice suscripciones.

Optimice en el servidor OPC UA los ajustes para el mínimo intervalo de envío y el mínimo intervalo de muestreo.

● Si se accede regularmente (con frecuencia) a determinadas variables, utilice las funciones "RegisteredRead" y "RegisteredWrite".

Otorgue a la CPU más carga de comunicación aumentando el valor de "Carga del ciclo por comunicación". Asegúrese de que la aplicación continúa funcionando correctamente con los ajustes modificados.

Procedimiento para crear un DB Array Existe la posibilidad de crear matrices, p. ej., en bloques de datos globales, en el bloque de datos de instancia de un bloque de función o como DB Array. A continuación se explica cómo crear un DB Array.

Para crear un bloque de datos con una matriz (bloque de datos Array), proceda del siguiente modo:

1. En el árbol del proyecto, seleccione la CPU con el servidor OPC UA.

2. Haga doble clic en "Bloques de programa".

3. Haga doble clic en "Agregar nuevo bloque".

4. Haga clic en el botón "Bloque de datos".

5. Asigne un nombre unívoco al bloque de datos o seleccione uno de los nombres que ya existen.

6. Seleccione para "Tipo" la entrada "DB de Array" en la lista desplegable.

7. Seleccione en la lista desplegable para "Tipo de datos Array" el tipo de datos de los distintos componentes de la matriz.

8. Introduzca el límite superior de la matriz en "Límite de Array".

9. Haga clic en el botón "Aceptar".



9.3.1.4 Exportar archivo XML con las variables PLC habilitadas

Crear archivo de exportación OPC UA Para configurar offline un cliente OPC UA puede utilizarse un archivo XML en el que se describan todas las variables PLC habilitadas.

El archivo XML OPC UA puede exportarse con STEP 7 (TIA Portal) desde el proyecto; el archivo está estructurado conforme a la especificación OPC UA.

Para crear y exportar el archivo XML, proceda del siguiente modo:

1. Seleccione la CPU. Para ello, haga clic en el icono de la CPU (p. ej., en la vista de redes).

2. Haga clic en las propiedades de la CPU en "General > OPC UA > Servidor > Exportar".

3. Haga clic en el botón "Exportar archivo XML OPC UA".

4. Seleccione el directorio en el que desea guardar el archivo de exportación.

5. Elija un nuevo nombre para el archivo. O conserve el nombre que ya se había introducido.

6. Haga clic en "Guardar".

Nota

Los métodos de servidor no están incluidos en el archivo de exportación OPC UA.

Exportar por separado todos los elementos de matriz Si en las propiedades de la CPU "OPC UA > Servidor > Exportar" está activada la opción "Exportar todos los elementos de matriz como nodos separados", el archivo XML OPC UA contendrá todos los elementos de matrices como elementos XML individuales.

La opción está activada por defecto y no puede modificarse.

Además, en el archivo XML cada una de las matrices propiamente dichas están descritas en un elemento XML.

El archivo XML puede ser muy extenso si la matriz contiene muchos elementos.

Consejo En la siguiente FAQ encontrará un convertidor que le permitirá convertir el archivo de exportación al formato CSV. Así obtendrá una lista de las variables de la CPU accesibles para OPC UA.

Encontrará las FAQ en Internet (https://support.industry.siemens.com/cs/ww/es/view/109742903).




9.3.2 Configurar el servidor OPC UA de la CPU S7-1500

9.3.2.1 Activar servidor OPC UA

Requisitos ● Se ha adquirido una licencia Runtime para el uso del servidor OPC UA, véase Licencias

para el servidor OPC UA (Página 193).

● Cuando se utilizan certificados para la comunicación segura (p. ej. HTTPS, Secure OUC, OPC UA), hay que asegurarse de que los módulos afectados tengan la hora y fecha actuales. De lo contrario, los módulos considerarán los certificados utilizados no válidos y la comunicación segura no funcionará.

Poner en funcionamiento el servidor OPC UA En el ajuste básico, el servidor OPC UA de la CPU no está habilitado por motivos de seguridad: Los clientes OPC UA no tienen acceso de lectura ni de escritura a la CPU S7-1500.

Para activar el servidor OPC UA de la CPU, proceda del siguiente modo.


2. Haga clic en las propiedades de la CPU en "OPC UA > Servidor".

3. Active el servidor OPC UA de la CPU.

4. Confirme las consignas de seguridad.

5. En las propiedades de la CPU seleccione el área "Licencias Runtime" y ajuste la licencia Runtime adquirida para el servidor OPC UA.

6. Compile el proyecto.

7. Cargue el proyecto en la CPU.

Se inicia el servidor OPC UA de la CPU.

Los ajustes continúan guardados Si ya se ha activado el servidor y se han realizado ajustes, estos no se perderán si se desactiva el servidor. Los ajustes continúan guardados y estarán de nuevo disponibles cuando se active nuevamente el servidor.



Nombre de aplicación El nombre de aplicación es el nombre de la aplicación OPC UA (servidor). El nombre se visualiza en "OPC UA > General":

● El ajuste predeterminado del nombre del servidor es: "SIMATIC.S7-1500.OPC-UAServer:PLC1".

● El ajuste predeterminado se compone de "SIMATIC.S7-1500.OPC-UAServer:" y del nombre de la CPU que se seleccionó en "General > Información del producto > Nombre", en este caso "PLC_1".

● Los clientes identifican al servidor por el nombre de la aplicación.

El siguiente ejemplo procede de UaExpert:

Tras activar el servidor, también puede utilizar otro nombre descriptivo dentro de su proyecto.

Cambiar el nombre de aplicación Para cambiar el nombre del servidor OPC UA, proceda del siguiente modo:


2. Haga clic en las propiedades de la CPU en "OPC UA > General".

3. Introduzca un nombre descriptivo.

Tenga en cuenta que el nombre de la aplicación también está registrado en el certificado (Subject Alternative Name) y que después de cambiar el nombre de la aplicación podría tener que crear de nuevo un certificado ya creado anteriormente.



9.3.2.2 Acceso al servidor OPC UA

Direcciones de servidores Se puede acceder al servidor OPC UA de la CPU S7-1500 a través de todas las interfaces PROFINET internas de la CPU (a partir del firmware V2.0), pero no a través de las interfaces PROFINET del CP/CM.

En los controladores por software SIMATIC S7-1500 solo es posible acceder al servidor OPC UA a través de las interfaces PROFINET asignadas al PLC por software.

En el ejemplo es posible establecer conexiones con el servidor OPC UA de la CPU a través de las URL (Uniform Resource Locator) siguientes:

Las URL tienen la siguiente estructura:

● Identificador de protocolo "opc.tcp://"

● Dirección IP

– 192.168.178.151

Dirección IP a través de la cual puede accederse al servidor OPC UA desde la subred Ethernet 192.168.178.

– 192.168.1.1

Dirección IP a través de la cual puede accederse al servidor OPC UA desde la subred Ethernet 192.168.1.

● Número de puerto TCP

– Ajuste predeterminado: 4840 (puerto estándar)

El número de puerto puede cambiarse en "OPC UA > Servidor > Ajustes > Puerto".



Direcciones IP dinámicas En el ejemplo siguiente aún no está definida la dirección IP de la interfaz PROFINET [X2].

En la tabla aparece el comodín "<dynamically>".

La dirección IP de esta interfaz PROFINET se activará posteriormente en el dispositivo. Puede conocerse la dirección IP asignada a la interfaz PROFINET [X2] (fuera del TIA Portal), entre otras posibilidades, buscando con un cliente OPC UA servidores OPC UA disponibles. Se obtiene una lista de los servidores disponibles junto con las direcciones IP.

Activar la interfaz estándar del servidor SIMATIC Si está activada la opción "Activar la interfaz estándar del servidor SIMATIC", el servidor OPC UA de la CPU proporcionará a los clientes las variables PLC y los métodos de servidor habilitados, tal como se define en la especificación OPC UA.

Esta opción está activada en el ajuste predeterminado.

Deje activada la opción para que los clientes OPC UA tengan la posibilidad de conectarse automáticamente al servidor OPC UA de la CPU e intercambiar datos.

Además de la interfaz estándar del servidor SIMATIC, existe la posibilidad de importar y activar otras interfaces de servidor; consulte Uso de modelos de información OPC UA (Página 217).



Soporte para clientes OPC UA con OPC UA V1.03 o anterior La especificación OPC UA (<= V1.03) define mecanismos para poder leer definiciones de tipos de datos, p. ej. para estructuras definidas por el usuario (UDT), en un servidor utilizando TypeDictionaries.

Al inicio de la entrega de STEP 7 Professional (TIA Portal) V15 y CPU S7-1500 con versión de firmware 2.5, la especificación OPC UA estaba disponible como Release Candidate V1.04 . Esta versión actualizada de la especificación OPC UA permite un mejor acceso a estructuras, por ejemplo.

ADVERTENCIA

Acceso a datos (p. ej. estructuras) con clientes que utilizan la especificación OPC UA V1.04

El acceso mediante mecanismos definidos en la especificación OPC UA V1.04 no es compatible con CPU S7-1500 con firmware 2.5. Los clientes que utilicen estos mecanismos para acceder a datos del servidor OPC UA pueden estar trabajando con valores erróneos.

9.3.2.3 Ajustes generales del servidor OPC UA

Puerto TCP para OPC UA De manera estándar OPC UA utiliza el puerto TCP 4840.

Sin embargo, también se puede seleccionar otro puerto. Son posibles las entradas de 1024 a 49151.

Sin embargo, hay que asegurarse de que no se produzcan conflictos con otras aplicaciones.

Al establecer la conexión, los clientes OPC UA deben utilizar el puerto seleccionado.

En el ejemplo siguiente se ha seleccionado el puerto 48400:



Ajustes para sesiones ● Timeout máximo para sesiones

En este campo se define cuál debe ser el máximo intervalo de tiempo hasta que el servidor OPC UA desconecte una sesión sin intercambio de datos.

El valor puede estar comprendido entre 1 y 600000 segundos.

● Número máximo de sesiones OPC UA

En este campo se define cuántas sesiones como máximo establecerá y gestionará simultáneamente el servidor OPC UA de la CPU.

El número máximo de sesiones depende de la capacidad funcional de la CPU. Cada sesión acapara recursos.

Número máximo de nodos registrados En este campo se define cuántos nodos (nodes) como máximo registrará el servidor OPC UA.

El número máximo de nodos registrados depende de la capacidad funcional de la CPU y se muestra al configurar el contenido del campo (colocar el puntero del ratón sobre el campo). Cada registro acapara recursos.

Nota No hay in mensaje de error al intentar registrar más nodos que el número máximo configurado de nodos registrables

Si un cliente pretende registrar en tiempo de ejecución más nodos del número máximo configurado de nodos registrables, el servidor de la CPU S7-1500 registrará solo el número máximo configurado. A partir del número máximo configurado de nodos registrables, el servidor devuelve al cliente los ID de nodo de string regulares, de manera que el registro de dichos nodos hace que se pierda la ventaja de velocidad. El cliente no recibe ningún mensaje de error.

En la configuración asegúrese de disponer de reserva suficiente, o haga que antes del registro el cliente determine el número máximo de nodos registrables.

Consulte también ¿Qué puertos utilizan los diferentes servicios para la transferencia de datos vía TCP y UDP y qué debe tenerse en cuenta al utilizar routers y cortafuegos? (https://support.industry.siemens.com/cs/ww/es/view/8970169)




9.3.2.4 Ajustes del servidor para suscripciones

Suscripción en lugar de consulta cíclica Una alternativa a la consulta cíclica de una variable PLC (polling) es la observación del valor. Para ello, utilice una Subscription (suscripción): el servidor informa al cliente cuando cambia el valor de las variables PLC. Consulte "El cliente OPC UA (Página 149)".

Habitualmente un servidor supervisa muchos valores del PLC. Por ello el servidor envía al cliente a intervalos regulares mensajes (notificación) que contienen los nuevos valores de las variables PLC.

¿Con qué frecuencia envía mensajes el servidor?

Al crear una Subscription, el cliente OPC UA indica el intervalo con el que desea recibir los valores nuevos cuando cambien los valores. Para limitar la carga de comunicación por OPC UA, defina un valor que no esté permitido sobrepasar para el intervalo de tiempo entre los mensajes. Para ello se utilizan los parámetros para el mínimo intervalo de envío y el mínimo intervalo de muestreo.

Mínimo intervalo de envío En "Mínimo intervalo de envío" se ajusta el tiempo (intervalo) al cabo del cual, cuando cambie un valor, el servidor enviará al cliente un mensaje con el nuevo valor.

En la figura siguiente se utiliza como "Mínimo intervalo de muestreo" el valor 250 ms. Como "Mínimo intervalo de envío" se ha registrado el valor 200 ms.

En el ejemplo, al producirse un cambio de valor el servidor OPC UA envía un mensaje nuevo cada 200 ms en caso de que el cliente OPC UA solicite una actualización.

Si, p. ej., el cliente OPC UA solicita una actualización cada 1000 ms, el servidor OPC UA solo enviará un mensaje con los valores nuevos cada 1000 ms (un segundo).

Si el cliente solicita una actualización cada 100 ms, el servidor la enviará aún así solo cada 200 ms (mínimo intervalo de envío).



Mínimo intervalo de muestreo En "Mínimo intervalo de muestreo" se define el tiempo (intervalo) al cabo del cual el servidor OPC UA registra el valor de una variable de CPU y lo compara con el valor anterior para detectar un cambio de valor.

Si se ha seleccionado un intervalo de muestreo menor que el intervalo de envío y un cliente OPC UA solicita esa velocidad de muestreo para determinadas variables PLC, por cada intervalo de envío podrán producirse dos o más valores.

En ese caso, el servidor OPC UA escribirá los cambios de valores en la cola y enviará todos los cambios de valores al cliente una vez transcurrido el intervalo de transmisión. Si se producen más cambios de valores en el intervalo de envío que los que caben en la cola, el servidor OPC UA sobrescribirá los valores más antiguos (en función de la "Discard Policy" ajustada; en este caso la opción "Discard Oldest" debe estar activada). Se enviarán al cliente los últimos valores.

Número máximo de elementos vigilados (Monitored Items) En este campo se define el número máximo de elementos que el servidor OPC UA de la CPU vigilará simultáneamente para detectar un cambio de valor.

La vigilancia acapara recursos. El número máximo de elementos vigilados depende de la CPU utilizada.



9.3.2.5 Manejo de certificados de cliente y de servidor Solo se produce una conexión segura entre un servidor OPC UA y un cliente OPC UA si el servidor puede identificarse ante el cliente. Para ello se utiliza el certificado del servidor.

Certificado del servidor OPC UA Si se ha activado el servidor OPC UA y se han confirmado las consignas de seguridad, STEP 7 crea automáticamente el certificado para el servidor y lo guarda en el directorio local de certificados de la CPU. Este directorio puede verse y administrarse con el administrador local de certificados de la CPU (exportar o borrar certificados).

La figura siguiente muestra el administrador local de certificados de la CPU con el certificado generado automáticamente para el servidor OPC UA:

Figura 9-9 Administrador local de certificados de la CPU

Alternativamente el usuario también puede crear un certificado de servidor.

El certificado del servidor se transfiere desde el servidor al cliente en el momento de establecer una conexión. El cliente comprueba el certificado.



El usuario del cliente decide si confía en el certificado del servidor En el lado del cliente, el usuario debe decidir ahora si confía en el certificado de servidor. Si el usuario confía en el certificado de servidor, el cliente lo guardará en el directorio que contiene los certificados de servidor que le merecen confianza.

El ejemplo siguiente muestra un cuadro de diálogo del cliente "UA Sample Client". Si el usuario hace clic en el botón "Sí", el cliente confía en el certificado del servidor:

Figura 9-10 Cuadro de diálogo del cliente "UA Sample Client"

Consulte también

Crear certificados de servidor con STEP 7 (Página 186)

Transferencia segura de mensajes (Página 162)

¿De dónde viene el certificado de un cliente? Si utiliza clientes UA de fabricantes o de la OPC Foundation, durante la instalación o la primera llamada del programa se crea automáticamente un certificado de cliente. Estos certificados deben importarse a STEP 7 mediante el administrador global de certificados y utilizarse para la respectiva CPU (como se muestra más arriba).

Si el propio usuario programa un cliente OPC UA, puede generar certificados mediante técnicas de programación, consulte "Certificado de instancia para el cliente (Página 145)". También es posible generar certificados usando herramientas, por ejemplo OpenSSL o el generador de certificados de la OPC Foundation:

● Consulte cómo proceder con OpenSSL aquí: "Autogeneración de parejas de claves PKI y de certificados (Página 159)".

● Consulte cómo trabajar con el generador de certificados de la OPC Foundation aquí: "Crear certificados autofirmados (Página 158)".



Notificar al servidor certificados del cliente Para poder establecer una conexión segura es necesario poner los certificados del cliente a disposición del servidor.


1. Active la opción "Utilizar ajustes globales de seguridad para el administrador de certificados" en el administrador local de certificados del servidor. De este modo está disponible el administrador global de certificados.

Encontrará esta opción en las propiedades de la CPU que hace de servidor, en "Protección y seguridad > Administrador de certificados".

Si el proyecto aún no está protegido, en "Ajustes de seguridad > Ajustes" del "Árbol del proyecto" de STEP 7 haga clic en el botón "Proteger este proyecto" e inicie sesión.

En el "Árbol del proyecto" de STEP 7 aparece la entrada "Ajustes globales de seguridad" en "Ajustes de seguridad".

2. Haga doble clic en "Ajustes globales de seguridad".

3. Haga doble clic en "Administrador de certificados".

STEP 7 abre el administrador global de certificados.

4. Haga clic en la ficha "Certificados de dispositivo".

5. Haga clic con el botón derecho del ratón en un área vacía de la ficha (no en un certificado).

6. Elija la opción "Importar" del menú contextual.

Se abre el cuadro de diálogo para importar certificados.

7. Seleccione el certificado de cliente en el que debe confiar el servidor.

8. Haga clic en el botón "Abrir" para importar el certificado.

El certificado del cliente está ahora guardado en el administrador global de certificados.

Tome nota de la ID del certificado de cliente que acaba de importar.

9. A continuación haga clic en la ficha "General" de las propiedades de la CPU que hace de servidor.

10.Haga clic en el área "OPC UA > Servidor > Seguridad > Secure Channel".

11.Desplácese hacia abajo en el cuadro de diálogo "Secure Channel" (canal seguro) hasta la sección "Clientes de confianza".

12.En la tabla, haga doble clic en la fila vacía "<agregar nuevo>". En la fila se muestra un botón con tres puntos.

13.Haga clic en dicho botón.

14.Seleccione el certificado de cliente que importó previamente.

15.Haga clic en el botón con la marca de verificación verde.

16.Compile el proyecto.

17.Cargue la configuración en la CPU S7-1500.



Resultado El servidor ahora confía en el cliente. Si, además, el certificado de servidor se considera de confianza, servidor y cliente pueden establecer una conexión segura.

Aceptar automáticamente certificados de cliente Si activa la opción "Aceptar automáticamente certificados de cliente durante el tiempo de ejecución" (debajo de la lista "Clientes de confianza"), entonces el servidor aceptará todos los certificados de cliente.

ATENCIÓN

Ajuste tras la puesta en marcha

Para evitar riesgos de seguridad, vuelva a desactivar la opción "Aceptar automáticamente los certificados de cliente durante el tiempo de ejecución" después de la puesta en marcha.

Configurar los ajustes de seguridad del servidor La figura siguiente muestra los ajustes de seguridad disponibles del servidor para firmar y cifrar mensajes.

Figura 9-11 Configurar los ajustes de seguridad del servidor



En el ajuste predeterminado se crea un certificado de servidor que utiliza la firma SHA256. Se habilitan las siguientes directivas de seguridad:

● Ningún punto final desprotegido

Nota

Desactivar directivas de seguridad (Security Policies) no deseadas

Si en la configuración del Secure Channel (canal seguro) del servidor OPC UA del S7-1500 se han activado todas las directivas de seguridad (Security Policy) (ajuste predeterminado), por tanto también el punto final "Ninguna seguridad", también es posible el tráfico de datos no seguro entre el servidor y el cliente (sin firma y sin cifrar). Con "Ninguna seguridad" la identidad del cliente es desconocida. En tal caso todos los clientes OPC UA pueden conectarse al servidor, con independencia de todos los ajustes de seguridad que sigan.

En la configuración del servidor OPC UA tenga en cuenta que solo están activadas las directivas de seguridad compatibles con el concepto de protección para la máquina o instalación. Es necesario desactivar todas las demás directivas de seguridad.

Recomendación: En la medida de lo posible, utilice el ajuste "Basic256Sha256".

● Basic128Rsa15 - Firmar Punto final protegido, permite una serie de algoritmos que utilizan el algoritmo de hash RSA15 y el cifrado de 128 bits. Este punto final asegura la integridad de los datos mediante firma.

● Basic128Rsa15 - Firmar y cifrar Punto final protegido, permite una serie de algoritmos que utilizan el algoritmo de hash RSA15 y el cifrado de 128 bits. Este punto final asegura la integridad y confidencialidad de los datos mediante firmar y cifrar.

● Basic256Rsa15 - Firma Punto final protegido, permite una serie de algoritmos que utilizan el algoritmo de hash RSA15 y el cifrado de 256 bits. Este punto final asegura la integridad de los datos mediante firmar.

● Basic256Rsa15 - Firma y cifrado Punto final protegido, permite una serie de algoritmos que utilizan el algoritmo de hash RSA15 y el cifrado de 256 bits. Este punto final asegura la integridad y confidencialidad de los datos mediante firmar y cifrar.

● Basic256Sha256 - Firma Punto final protegido, soporta una serie de algoritmos para hashing de 256 bits y cifrado de 256 bits. Este punto final asegura la integridad de los datos mediante firma.

● Basic256Sha256 - Firma y cifrado Punto final protegido, soporta una serie de algoritmos para hashing de 256 bits y cifrado de 256 bits. Este punto final asegura la integridad y confidencialidad de los datos mediante firma y cifrado.



Para habilitar un ajuste de seguridad haga clic en la casilla de verificación de la fila correspondiente.

Nota

Si se utilizan los ajustes "Basic256Sha256 - Firma" y "Basic256Sha256 - Firma y cifrado", el servidor OPC UA y los clientes OPC UA deben utilizar certificados firmados con "SHA256".

Con los ajustes "Basic256Sha256 - Firma" y "Basic256Sha256 - Firma y cifrado", la entidad emisora de STEP 7 firma los certificados automáticamente con "SHA256".

9.3.2.6 Tratamiento de los certificados de cliente de la CPU S7-1500

¿De dónde viene el certificado del cliente? Si utiliza el cliente OPC UA de una CPU S7-1500 CPU (cliente OPC UA activado), podrá crear certificados para estos clientes con STEP 7 a partir de la versión V15, tal como se describe en los apartados siguientes.

Si utiliza clientes UA de fabricantes o de la OPC Foundation, durante la instalación o la primera llamada del programa se crea automáticamente un certificado de cliente. Estos certificados deben importarse a STEP 7 mediante el administrador global de certificados y utilizarse para la CPU en cuestión.

Si el propio usuario programa un cliente OPC UA, puede generar certificados mediante técnicas de programación, consulte "Certificado de instancia para el cliente (Página 145)". También es posible generar certificados usando herramientas, por ejemplo OpenSSL o el generador de certificados de la OPC Foundation:

● Consulte cómo proceder con OpenSSL aquí: "Autogeneración de parejas de claves PKI y de certificados (Página 159)".

● Consulte cómo trabajar con el generador de certificados de la OPC Foundation aquí: "Crear certificados autofirmados (Página 158)".

Certificado del cliente OPC UA de la CPU S7-1500 Solo se produce una conexión segura entre el servidor OPC UA y un cliente OPC UA si el servidor considera de confianza el certificado del cliente.

Para ello, el certificado del cliente debe darse a conocer al servidor.

Los apartados siguientes describen la forma de generar primero un certificado para el cliente OPC UA de la CPU S7-1500 y ponerlo a disposición del servidor a continuación.



1. Generar y exportar un certificado para el cliente Para una conexión segura hay que generar un certificado de cliente y exportarlo.


1. En el "Árbol del proyecto", seleccione la CPU que actúa de cliente.

2. Haga doble clic en "Configuración de dispositivos".

3. En las propiedades de la CPU haga clic en "Protección y seguridad > Administrador de certificados".

4. Haga doble clic en "<agregar nuevo>" en la tabla "Certificados de dispositivos".

STEP 7 abre un cuadro de diálogo.

5. Haga clic en el botón "Agregar".

6. En "Finalidad de uso", seleccione la entrada "Cliente OPC UA" de la lista.

Atención:

En "Titular del certificado alternativo (SAN)" debe estar indicada la dirección IP desde la que se accede a la CPU en la instalación.

También hay que configurar la interfaz IP de la CPU antes de crear un certificado de cliente.

7. Haga clic en "Aceptar".

STEP 7 muestra el certificado de cliente en la tabla "Certificados de dispositivos".

8. Haga clic con el botón derecho del ratón en esta fila y seleccione la entrada "Exportar certificado" del menú contextual.

9. Seleccione un directorio para guardar el certificado de cliente.

2. Dar a conocer el certificado del cliente al servidor Para poder establecer una conexión segura es necesario poner el certificado del cliente a disposición del servidor.


1. Active la opción "Utilizar ajustes globales de seguridad para el administrador de certificados" en el administrador local de certificados del servidor. De este modo está disponible el administrador global de certificados.

Encontrará esta opción en las propiedades de la CPU que hace de servidor, en "Protección y seguridad > Administrador de certificados".

Si el proyecto aún no está protegido, en "Ajustes de seguridad > Ajustes" del "Árbol del proyecto" de STEP 7 haga clic en el botón "Proteger este proyecto" e inicie sesión.

En el "Árbol del proyecto" de STEP 7 aparece la entrada "Ajustes globales de seguridad" en "Ajustes de seguridad".

2. Haga doble clic en "Ajustes globales de seguridad".

3. Haga doble clic en "Administrador de certificados".

STEP 7 abre el administrador global de certificados.



4. Haga clic en la ficha "Certificados de dispositivo".

5. Haga clic con el botón derecho del ratón en un área vacía de la ficha (no en un certificado).

6. Elija la opción "Importar" del menú contextual.

Se abre el cuadro de diálogo para importar certificados.

7. Seleccione el certificado de cliente en el que debe confiar el servidor.

8. Haga clic en el botón "Abrir" para importar el certificado.

El certificado del cliente está ahora guardado en el administrador global de certificados.

Tome nota de la ID del certificado de cliente que acaba de importar.

9. A continuación haga clic en la ficha "General" de las propiedades de la CPU que hace de servidor.

10.Haga clic en el área "OPC UA > Servidor > Seguridad > Secure Channel".

11.Desplácese hacia abajo en el cuadro de diálogo "Secure Channel" (canal seguro) hasta la sección "Clientes de confianza".

12.En la tabla, haga doble clic en la fila vacía "<agregar nuevo>". En la fila se muestra un botón con tres puntos.

13.Haga clic en dicho botón.

14.Seleccione el certificado de cliente que importó previamente.

15.Haga clic en el botón con la marca de verificación verde.

16.Compile el proyecto.

17.Cargue la configuración en la CPU S7-1500.

Resultado El servidor ahora confía en el cliente. Si, además, el certificado de servidor se considera de confianza, servidor y cliente pueden establecer una conexión segura.

9.3.2.7 Crear certificados de servidor con STEP 7 La siguiente descripción muestra la forma de proceder para crear nuevos certificados con STEP 7 y se aplica en principio para diversos usos de los certificados. Dependiendo del área de propiedades de la CPU desde la que se abra el siguiente cuadro de diálogo, STEP 7 ya ajusta la finalidad adecuada (en este caso, "Cliente y servidor OPC UA").

Recomendación: Para poder utilizar todas las funciones de seguridad del servidor OPC UA, utilice los ajustes globales de seguridad.

Los ajustes globales de seguridad se activan en las propiedades de la CPU, en el área "Protección y seguridad > Administrador de certificados".



Personalizar los certificados del servidor Al activar el servidor, STEP 7 crea automáticamente un certificado para el servidor OPC UA del S7-1500 (véase "Activar servidor OPC UA (Página 171)"). Para los parámetros del certificado, STEP 7 utiliza valores predeterminados. Si desea modificar los parámetros, proceda del siguiente modo:

1. En las propiedades de la CPU, haga clic en el botón con tres puntos que figura en "General > OPC UA > Servidor > Seguridad > Secure Channel > Certificado de servidor". Se abre un cuadro de diálogo que muestra los certificados locales existentes.

2. Haga clic en el botón "Agregar".

3. Se abre el cuadro de diálogo para crear certificados nuevos (figura siguiente). Los valores para un ejemplo ya están introducidos:

Figura 9-12 Personalizar los certificados del servidor

4. Utilice otros parámetros si fuera necesario debido a los requisitos de seguridad en su empresa o por parte de su cliente.



Explicación de los campos de generación de certificados ● CA

Elija si el certificado debe autofirmarse o ser firmado por otro certificado CA disponible en el TIA Portal. Los certificados se describen en "Certificados en OPC UA (Página 157)". Si desea crear un certificado firmado por uno de los certificados CA del TIA Portal, el proyecto deberá estar protegido y previamente se deberá haber iniciado sesión como usuario con los derechos de función requeridos. Encontrará más información en "Principios básicos de la administración de usuarios en el TIA Portal".

● Titular del certificado

El ajuste predeterminado está formado por el nombre del proyecto y "\OPCUA-1". En el ejemplo, el nombre del proyecto es "PLC1". En las propiedades de la CPU especifique el nombre del proyecto en "General > Información del proyecto > Nombre". Conserve el ajuste predeterminado o introduzca en "Titular del certificado" otro nombre para el servidor OPC UA que sea más descriptivo en el proyecto.

● Firma

Seleccione aquí el procedimiento hash y de cifrado que debe utilizarse para firmar el certificado de servidor. Están disponibles las siguientes entradas:

– "sha1RSA",

– "sha256RSA".

● Válido desde

Introduzca aquí la fecha y la hora que marcan el inicio del período de validez del certificado de servidor.

● Válido hasta

Introduzca aquí la fecha y la hora que marcan el final del período de validez del certificado de servidor. Asegúrese de que la validez del certificado no sea solo de un año o pocos años. En este ejemplo el certificado tiene una validez de 30 años. No obstante, por motivos de seguridad debería renovar el certificado en intervalos mucho más cortos. La prolongada validez, sin embargo, le ofrece la posibilidad de elegir el instante adecuado para renovar el certificado, por ejemplo, cuando sea necesario hacer mantenimiento a una instalación.



● Finalidad

El ajuste predeterminado es "Cliente y servidor OPC UA". Conserve este ajuste predeterminado para el servidor OPC UA. El cuadro de diálogo "Generar nuevo certificado" puede llamarse desde varios puntos en STEP 7. Si, por ejemplo, se abre el cuadro de diálogo para el servidor web de la CPU, en "Finalidad de uso" se introduce "Servidor web". En la lista desplegable correspondiente a la finalidad están disponibles las opciones siguientes:

– "Cliente OPC UA"

– "Cliente y servidor OPC UA"

– "Servidor OPC UA"

– "TLS"

– "Servidor web"

● Nombre alternativo del titular del certificado

En el ejemplo anterior está especificado: "URI:urn:SIMATIC.S7-1500.OPC-UAServer:PLC1,IP:192.168.178.151,IP:192.168.1.1". También sería válida la entrada siguiente: "IP: 192.168.178.151, IP: 192.168.1.1". Es importante que figuren aquí las direcciones IP a través de las cuales se accede al servidor OPC UA de la CPU (consulte "Acceso al servidor OPC UA (Página 173)"). De este modo, los clientes OPC UA verifican si realmente debe establecerse una conexión con el servidor OPC UA del S7-1500, o si posiblemente un atacante está intentando enviar valores manipulados al cliente OPC UA desde otro PC.



9.3.2.8 Autenticación del usuario

Tipos de autenticación del usuario En el servidor OPC UA del S7-1500 puede ajustarse cómo debe legitimarse un usuario del cliente OPC UA si desea acceder al servidor.

Para ello, existen las siguientes posibilidades:

● Autenticación de huésped

El usuario no tiene que demostrar que tiene autorización (acceso anónimo). El servidor OPC UA no comprueba el permiso del usuario del cliente.

Si desea utilizar este tipo de autenticación del usuario, active la opción "Activar autenticación de huésped" en "OPC UA > Servidor > Seguridad > Autenticación de usuario".

Nota

Para aumentar la seguridad, el acceso al servidor OPC UA solo debería permitirse con autenticación de usuario.

● Autenticación mediante nombre de usuario y contraseña

El usuario tiene que demostrar que tiene autorización (acceso no anónimo). El servidor OPC UA comprueba si el usuario cliente está autorizado a acceder al servidor. Como prueba sirven el nombre de usuario con la contraseña correcta.

Si desea utilizar este tipo de autenticación del usuario, active la opción "Activar autenticación con nombre de usuario y contraseña" en "OPC UA > Servidor > Seguridad > Autenticación de usuario".

Desactive la autenticación de invitados.

Introduzca los usuarios en la tabla "Administración de usuarios".

Para ello, haga clic en cada caso en la entrada "<Agregar usuario>" y agregue el nombre de usuario y la contraseña correspondiente. Se puede introducir un máximo de 21 usuarios.



● Administración de usuarios adicional desde la configuración de seguridad del proyecto

Si activa esta opción, la administración de usuarios del proyecto abierto se utilizará también para la autenticación de usuarios del servidor OPC UA: En OPC UA serán entonces válidos los mismos nombres de usuario y contraseñas que en el proyecto actual. Para activar la administración de usuarios del proyecto, haga lo siguiente: – En el "Árbol del proyecto" haga clic en "Ajustes de seguridad > Ajustes".

– Haga clic en el botón "Proteger este proyecto".

– Introduzca su nombre de usuario y contraseña.

– Introduzca otros usuarios en "Ajustes de seguridad > Usuarios y funciones".

● Si configura otro servidor OPC UA en su proyecto, active también en el proyecto la opción "Activar la administración de usuarios adicional desde la configuración de seguridad del proyecto". De esta forma no será necesario introducir de nuevo los nombres de usuario y contraseñas.

9.3.2.9 Usuarios y roles con derechos de función OPC UA La opción siguiente para la autenticación de usuarios recurre a ajustes centrales para usuarios del proyecto:

Al parametrizar las propiedades de la CPU (OPC UA > Servidor > Seguridad > Autenticación de usuarios). Allí es la opción "Activar la administración de usuarios adicional desde la configuración de seguridad del proyecto".

Requisitos Para poder editar los ajustes de seguridad, el proyecto debe estar protegido y se debe haber iniciado sesión con derechos suficientes, p. ej., de administrador.

Ajustes en el árbol del proyecto > "Ajustes de seguridad" En el proyecto protegido se accede a los ajustes centrales de usuarios y roles en el árbol del proyecto, sección "Ajustes de seguridad". Aquí se definen centralizadamente usuarios con sus nombres de usuario, contraseña y derechos de funciones. Estos ajustes pueden reutilizarse en otro lugar.



Reutilizar los ajustes centrales de seguridad Ejemplo de reutilización:

● Selección de usuarios para la autenticación de usuarios en el servidor OPC UA

En este ajuste se notifica al servidor qué cliente (usuario) está autorizado a acceder al servidor, y con qué nombre de usuario y qué contraseña.

Derechos de acceso a las funciones para el servidor OPC UA Para los usuarios con función de servidor en una CPU S7-1500 deben estar activados también los correspondientes derechos de funciones para el servidor. No basta con depositar centralizadamente el nombre de usuario y la contraseña.

Un ejemplo explica este tipo de administración de derechos.

1. En la ficha "Roles" de la sección "Ajustes de seguridad > Usuarios y roles" se define un nuevo rol, p. ej. con el nombre "PLC-opcua-role-all-inclusive".

2. En la sección "Categorías de derechos de funciones" desplácese hasta los derechos de Runtime, después hasta los derechos de funciones de la CPU y seleccione la CPU cuyos derechos de funciones desea configurar, p. ej., PLC_2.

3. En el área "Derechos de funciones" encontrará el siguiente derecho de función:

– Acceso de servidor OPC UA

Este derecho actúa en el servidor OPC UA de la CPU S7-1500. Solo si está seleccionada esta opción, un usuario del servidor de la CPU PLC_2 al que se le ha asignado el rol "PLC-opcua-role-all-inclusive" tendrá el derecho siguiente: Para establecer una sesión con el servidor desde el cliente fuerza la autenticación con un nombre de usuario definido centralmente (y cargado en la CPU) y la contraseña correspondiente.

Es necesario asignar el rol "PLC-opcua-role-all-inclusive" a los usuarios correspondientes (ficha "Usuarios" en el área "Ajustes de seguridad" del árbol del proyecto).



9.3.2.10 Licencias para el servidor OPC UA

Licencias runtime Para operar el servidor OPC UA de la CPU S7-1500 se requiere una licencia. El tipo de la licencia requerida depende del rendimiento de la respectiva CPU. Se distinguen los siguientes tipos de licencia:

● SIMATIC OPC UA S7-1500 small (necesaria para CPU 1511, CPU 1512, CPU 1513, CPU ET 200SP, CPU 1515SP PC)

● SIMATIC OPC UA S7-1500 medium (necesaria para CPU 1515, CPU 1516, controlador por software CPU 1507, CPU 1516pro-2PN)

● SIMATIC OPC UA S7-1500 large (necesaria para CPU 1517, CPU 1518)

El tipo de licencia requerida se muestra en "Propiedades > General > Licencias runtime > OPC UA > Tipo de licencia necesaria":

Para confirmar la compra de la licencia requerida, proceda del siguiente modo:

1. Haga clic en las propiedades de la CPU en "Licencias runtime > OPC UA".

2. Seleccione la licencia necesaria en la lista desplegable "Tipo de licencia adquirida".

9.3.3 Proporcionar métodos en el servidor OPC UA

9.3.3.1 Métodos de servidor

Proporcionar el programa de usuario para métodos de servidor En el servidor OPC UA de una CPU S7-1500 (a partir de la versión del firmware V2.5) existe la posibilidad de proporcionar métodos mediante el programa de usuario. Estos métodos pueden utilizarlos los clientes OPC UA, p. ej. para iniciar una orden de producción llamando al método de la CPU S7-1500.

Los métodos OPC UA, una implementación de "Remote Procedure Calls", ofrecen un mecanismo eficaz para la interacción entre diferentes interlocutores. El mecanismo proporciona tanto una confirmación de la orden como valores de respuesta, lo que ahorra tener que programar mecanismos de handshaking.

Con métodos OPC UA es posible, p. ej., una transferencia coherente sin bits de disparo o handshake, o activar determinadas acciones en el controlador.



¿Cómo funciona un método OPC UA?

Un método OPC UA funciona en principio como un bloque de función protegido por know-how que es llamado por un cliente OPC UA externo en tiempo de ejecución.

El cliente OPC UA solamente "ve" las entradas y salidas definidas. El interior del bloque de función, el método o el algoritmo permanecen ocultos para el cliente OPC UA externo. El cliente OPC UA recibe una señal de respuesta de la correcta ejecución y valores de respuesta proporcionados por el bloque de función (método). O bien un mensaje de error en caso de que la ejecución no sea correcta.

El programador tiene el pleno control y la total responsabilidad sobre el contexto del programa en el que se ejecute el método OPC UA.

Reglas para la programación de un método y comportamiento en tiempo de ejecución

● Asegúrese de que los valores de respuesta devueltos con el método OPC UA son coherentes con los valores de entrada proporcionados por el cliente OPC UA.

● Tenga en cuenta las reglas de asignación de nombres y de estructuración de parámetros, así como los tipos de datos que pueden utilizarse (consulte la descripción de las instrucciones del servidor OPC UA).

● Comportamiento en tiempo de ejecución: el servidor OPC UA acepta una llamada por instancia. La instancia del método no podrá ser llamada por otros clientes OPC UA hasta que la llamada haya sido procesada por el programa de usuario o se haya producido un timeout.

A continuación va a mostrarse el procedimiento básico para implementar un programa de usuario como método de servidor.



Implementación de un método de servidor

Un programa (bloque de función) para implementar un método de servidor tiene la estructura siguiente:

1. Consultar la llamada del método de servidor con OPC_UA-ServerMethodPre

En su programa de usuario (es decir, en su método de servidor) llame primero a la instrucción "OPC_UA_ServerMethodPre".

Esta instrucción cumple las siguientes tareas:

– Con esta instrucción puede consultar en el servidor OPC UA de la CPU si su método de servidor ha sido llamado por un cliente OPC UA.

– Si el método ha sido llamado y el método de servidor dispone de parámetros de entrada, su método de servidor obtendrá ahora los parámetros de entrada.

Los parámetros de entrada del método de servidor proceden del cliente OPC UA llamante.

2. Editar el método de servidor

En esta sección del método de servidor se pone a disposición el programa de usuario propiamente dicho.

Aquí tiene las mismas posibilidades que en otros programas de usuario (por ejemplo, el acceso a otros bloques de función o a bloques de datos globales).

Si el método de servidor utiliza parámetros de entrada, dispondrá de los parámetros de entrada del método de servidor.

Esta sección del método de servidor solo debe ejecutarse si un cliente OPC UA ha llamado al método de servidor.

Una vez ejecutado el método correctamente, active los parámetros de salida del método de servidor, siempre que el método de servidor tenga parámetros de salida.

3. Responder al método de servidor con OPC_UA_ServerMethodPost

Para concluir el método de servidor, llame a la instrucción "OPC_UA_ServerMethodPost".

A través de los parámetros informe a la instrucción "OPC_UA_ServerMethodPost" sobre si se ha ejecutado o no el programa de usuario.

A través de los parámetros correspondientes se informa al servidor OPC UA sobre si el programa de usuario se ha ejecutado correctamente. El servidor OPC UA enviará al cliente OPC UA los parámetros de salida del método de servidor.

Llame a las instrucciones "OPC_UA_ServerMethodPre" y "OPC_UA_ServerMethodPost" siempre por parejas, con independencia de que el programa de usuario se ejecute entre ambas instrucciones o se continúe en el ciclo siguiente.

Encontrará un ejemplo de implementación de un método de servidor en el capítulo sobre las instrucciones del servidor OPC UA.



Integración del método de servidor El gráfico siguiente muestra cómo un cliente OPC UA (A) llama al método de servidor "Cool":

La CPU ejecuta en el programa de usuario cíclico la instancia "Cool1" del método de servidor "Cool" ⑥.

Primero, la CPU pregunta con la instrucción "OPC_UA_ServerMethodPre" ④ si un cliente OPC UA ha llamado al método de servidor "Cool" ①.

● Si no se ha llamado al método de servidor, la ejecución del programa retorna directamente al programa de usuario cíclico a través de ④ y ⑥. Tras "Cool1", la CPU continúa el programa de usuario cíclico.

● Si se ha llamado al método de servidor, esta información retorna al método de servidor Cool a través de ④. Allí se ejecutan las funciones propiamente dichas, consulte "<Funcionalidad de métodos>" en el gráfico.

A continuación, el método de servidor comunica mediante la instrucción "OPC_UA_ServerMethodPost" ⑤ del firmware (B) que se ha ejecutado ③.



El firmware devuelve dicha información a través de ② al cliente OPC UA llamante (A).

Tras "Cool1", la CPU continúa el programa de usuario cíclico.

A Llamada del método de servidor y gestión de la información "Done" (método concluido) ① Llamada asíncrona al método de servidor ② Información "Done" asíncrona del método llamado (método concluido) B Espera a llamadas de cliente OPC UA, gestión de llamadas en cola de espera, retransmisión al cliente OPC UA

de información procedente del programa de usuario cíclico. ③ Transferencia de datos del servidor OPC UA a la instancia del método del programa de usuario, y viceversa. C Comprobación de si se ha llamado al método.

En caso afirmativo, hacer llegar los datos de entrada del servidor OPC UA a la instancia del método del programa de usuario y responder a la instancia del método que se ha llamado al método ("called")

④ Llamada síncrona de la instrucción OPC_UA_ServerMethodPre como multinstancia, indicando el área de memoria para los datos de entrada del servidor OPC UA. El Return-Value informa sobre si el método ha sido llamado por el cliente OPC UA.

⑤ Comprobación sobre si el método ha concluido o continúa activo ("busy"). D Comprobación sobre si se ha concluido el método.

En caso afirmativo, los datos de salida de la instancia del método se hacen llegar al servidor OPC UA y se res-ponde a la instancia que el método ha concluido. Se mantiene informado al servidor OPC UA.

⑥ Llamada del FB de método (aquí: FB Cool) con la instancia y los parámetros de proceso deseados.

Figura 9-13 Integración del método de servidor

Nota Los métodos no se tienen en cuenta durante la exportación OPC UA-XML Al exportar el modelo de información OPC UA, los métodos creados según el patrón descrito más arriba no se incluyen en el archivo XML exportado.

Consulte también Programa de ejemplo para proporcionar un método para clientes OPC UA (Página 205)



9.3.4 Instrucciones del servidor OPC UA para la implementación de métodos

9.3.4.1 OPC_UA_ServerMethodPre

Introducción Este capítulo describe la instrucción "OPC_UA_ServerMethodPre".

Puesto que las instrucciones "OPC_UA_ServerMethodPre" y "OPC_UA_ServerMethodPost" deben llamarse siempre de dos en dos en el programa de usuario, consulte también el capítulo sobre la instrucción "OPC_UA_ServerMethodPost".

Función de la instrucción La instrucción "OPC_UA_ServerMethodPre" pregunta al sistema operativo si se ha llamado el método de servidor.

Si es el cliente quien ha llamado al método de servidor, la instrucción "OPC_UA_ServerMethodPre" proporciona los parámetros de entrada para dicho método.

Declaración de las variables Declare una instancia de la instrucción "OPC_UA_ServerMethodPre" y las variables con las que se suministren valores a los parámetros de la instrucción; consulte también Programa de ejemplo para proporcionar un método para clientes OPC UA (Página 205).



Para la declaración son importantes los siguientes puntos:

● Cree la instrucción "OPC_UA_ServerMethodPre" como multiinstancia en el bloque de función llamante.

Nota

Nombre de la multiinstancia

La multiinstancia debe llevar forzosamente el nombre "OPC_UA_ServerMethodPre_Instance", de lo contrario no se creará ningún método en el servidor.

Para ello, arrastre la instrucción desde la carpeta "Instrucciones > Comunicación > OPC UA > Servidor OPC UA" hasta el editor con Drag&Drop.

A continuación, haga clic en "Multiinstancia".

● Si el método de servidor tiene uno o varios parámetros de entrada, debe declararse una variable con el nombre "UAMethod_InParameters".

En primer lugar, cree un tipo de datos definido por el usuario (UDT) para los parámetros de entrada del método del servidor.

Utilice este UDT para la variable "UAMethod_InParameters".

El tipo de datos del ejemplo se llama "UDT_OpenDoorInArguments" y contiene el elemento Number.

Alternativa:

También puede asignar el tipo de datos "Struct" a la variable "UAMethod_InParameters". En tal caso, cree los componentes de dicho tipo de datos en función de los parámetros de entrada del método de servidor (mismos nombres y tipos de datos).



Parámetros de "OPC_UA_ServerMethodPre"

Tabla 9- 2 Los parámetros de la instrucción "OPC_UA_ServerMethodPre"

Parámetros Declaración Tipo de datos Significado Done Output BOOL Estado de ejecución:

• 0: Ejecución de la instrucción interrumpida, no finalizada o no iniciada.

• 1: Ejecución de la instrucción finalizada sin errores

Busy Output BOOL Parámetro sobre el estado de la ejecución: • 0: La instrucción no se está

ejecutando • 1: Instrucción ejecutándose en

estos momentos

Error Output BOOL Indicación de errores • 0: Ningún error • 1: Se ha producido un error.

Consulte el parámetro "Status".

Status Output DWORD Causa del error, consulte más abajo "Códigos de error de Status".

UAMethodCalled Output BOOL Un cliente OPC UA ha llamado al método proporcionado.

UAMethod_InParameters InOut VARIANT Puntero hacia una variable que contiene los parámetros de entrada para el método proporcionado.

Códigos de error de Status El parámetro "Status" informa sobre errores que pueden producirse durante la ejecución de la instrucción.

En la siguiente tabla se describen las diferentes categorías de los códigos de error.

Tabla 9- 3 Códigos de error de Status

Código de error (valores hexadecimales)

Explicación

0000_0000 Instrucción finalizada correctamente 8xxx_xxxx Error específico de OPC UA Axxx_xxxx Error específico de PLCopen B080_C300 Recursos insuficientes B08x_yz00 Error específico de SIMATIC Encontrará más códigos de error en Códigos de error (Página 208)



Asignación de tipos de datos (SIMATIC - OPC UA) En lo referente a los parámetros de entrada y salida de los métodos tenga en cuenta las explicaciones relacionadas con las reglas de los tipos de datos utilizables que figuran en el apartado "Mapeado de tipos de datos" (Utilización de especificaciones OPC UA Companion (Página 217)).

Suministro de tipos de datos estructurados con matrices anidadas Si un tipo de datos estructurado (Struct/UDT) contiene una matriz, el servidor OPC UA no proporciona información sobre la longitud de dicha matriz.

Si se utiliza una estructura de este tipo, p. ej. como parámetro de entrada o salida de un método de servidor, hay que asegurarse de que a la matriz anidada reciba la longitud correcta al llamar al método.

Si no se observa esta regla, el método fallará con el código de error "BadInvalidArgument".

9.3.4.2 OPC_UA_ServerMethodPost

Introducción Este capítulo describe la instrucción "OPC_UA_ServerMethodPost".

Puesto que las instrucciones "OPC_UA_ServerMethodPre" y "OPC_UA_ServerMethodPost" deben llamarse siempre de dos en dos en el programa de usuario, consulte también el capítulo sobre la instrucción "OPC_UA_ServerMethodPre".

Función de la instrucción La instrucción "OPC_UA_ServerMethodPost" informa al sistema operativo de que se ha ejecutado el método de servidor y de que los valores de los parámetros de salida son válidos.



Declaración de las variables Declare una instancia de la instrucción "OPC_UA_ServerMethodPost" y las variables con las que se suministren valores a los parámetros de la instrucción; consulte también Programa de ejemplo para proporcionar un método para clientes OPC UA (Página 205).

Para la declaración son importantes los siguientes puntos:

● Cree la instrucción "OPC_UA_ServerMethodPost" como multiinstancia en el bloque de función llamante.

Nota

Nombre de la multiinstancia

La multiinstancia debe llevar forzosamente el nombre "OPC_UA_ServerMethodPost_Instance", de lo contrario no se creará ningún método en el servidor.

Para ello, arrastre la instrucción desde la carpeta "Instrucciones > Comunicación > OPC UA > Servidor OPC UA" hasta el editor con Drag&Drop. A continuación, haga clic en "Multiinstancia".

● Si el método de servidor posee uno o varios parámetros de salida, debe declararse una variable con el nombre "UAMethod_OutParameters".

En primer lugar, cree un tipo de datos definido por el usuario (UDT) para los parámetros de salida del método de servidor.

Utilice este UDT para la variable "UAMethod_OutParameters".

El tipo de datos del ejemplo se llama "UDT_OpenDoorOutArguments"; el único parámetro de salida es Result.

Alternativa:

También puede asignar el tipo de datos "Struct" a la variable "UAMethod_OutParameters". En tal caso, cree los componentes de dicho tipo de datos en función de los parámetros de salida del método de servidor (mismos nombres y tipos de datos).

Figura 9-14 Declaración de las variables



Parámetros de "OPC_UA_ServerMethodPost"

Tabla 9- 4 Los parámetros de la instrucción "OPC_UA_ServerMethodPost"

Parámetros Declaración Tipo de datos Significado Done Output BOOL Estado de ejecución:

• 0: Ejecución de la instrucción interrumpida, no finalizada o no iniciada.

• 1: Ejecución de la instrucción finalizada sin errores

Busy Output BOOL Parámetro sobre el estado de la ejecución: • 0: La instrucción no se está

ejecutando • 1: Instrucción ejecutándose en

estos momentos

Error Output BOOL Indicación de errores • 0: Ningún error • 1: Se ha producido un error.

Consulte el parámetro "Status"

Status Output DWORD Causa del error, consulte más abajo "Códigos de error de Status".

UAMethod_Result Input DWORD Códigos de error para el servidor OPC UA, proporcionados por el programa de usuario. Recomendación: Para notificar errores, utilice códigos que empie-cen por 0xFF. Para OPC UA están definidos los rangos siguientes: • Good: de 0x0000_0000 a

0x3FFF_ FFFF • Uncertain: de 0x4000_0000 a

0x7FFF_FFFF • Bad: de 0x8000_0000 a

0xFFFF_FFFF Según el cliente es posible que los códigos de los rangos "Good" y "Uncertain" no se emitan.

UAMethod_Finished Input BOOL Ponga el valor del parámetro a TRUE si se ha ejecutado el método proporcionado.

UAMethod_OutParameters InOut VARIANT Puntero hacia una variable que contiene los parámetros de salida del método proporcionado.



Códigos de error de Status El parámetro "Status" informa sobre errores que pueden producirse durante la ejecución de la instrucción.

En la siguiente tabla se describen las diferentes categorías de los códigos de error.

Tabla 9- 5 Códigos de error de Status

Código de error (valores hexadecimales)

Explicación

0000_0000 Instrucción finalizada correctamente 8xxx_xxxx Error específico de OPC UA Axxx_xxxx Error específico de PLCopen B080_C300 Recursos insuficientes B08x_yz00 Error específico de SIMATIC Encontrará más códigos de error en Códigos de error (Página 208)

Asignación de tipos de datos (SIMATIC - OPC UA) En lo referente a los parámetros de entrada y salida de los métodos tenga en cuenta las explicaciones relacionadas con las reglas de los tipos de datos utilizables que figuran en el apartado "Mapeado de tipos de datos" (Utilización de especificaciones OPC UA Companion (Página 217)).

Suministro de tipos de datos estructurados con matrices anidadas Si un tipo de datos estructurado (Struct/UDT) contiene una matriz, el servidor OPC UA no proporciona información sobre la longitud de dicha matriz.

Si se utiliza una estructura de este tipo, p. ej. como parámetro de entrada o salida de un método de servidor, hay que asegurarse de que a la matriz anidada reciba la longitud correcta al llamar al método.

Si no se observa esta regla, el método fallará con el código de error "BadInvalidArgument".



9.3.4.3 Programa de ejemplo para proporcionar un método para clientes OPC UA

Programa de ejemplo para un método de servidor Este capítulo contiene el código de programa completo para el programa de ejemplo "OpenDoor".

El ejemplo muestra cómo un programa de usuario emplea las instrucciones "OPC_UA_ServerMethodPre" y "OPC_UA_ServerMethodPost".

Las instrucciones se describen en los capítulos OPC_UA_ServerMethodPre (Página 198) y OPC_UA_ServerMethodPost (Página 201).

El programa proporciona un método de servidor para clientes OPC UA: El programa pone el parámetro de salida "Result" al valor 1 cuando el parámetro de entrada "Number" tiene el valor 1.

Para que el ejemplo siga siendo sencillo y claro, se ha renunciado a una evaluación de errores detallada (parámetro "Status").

Estructura del programa

El programa se divide en las secciones siguientes:

1. Llamada de la instrucción "OPC_UA_ServerMethodPre" para determinar si un cliente ha llamado al método de servidor.

2. Si se ha llamado el método de servidor, se ejecuta dicho método. Define la funcionalidad propiamente dicha en la llamada del método por un cliente OPC UA.

3. Cuando el método de servidor ha finalizado, se llama a la instrucción "OPC_UA_ServerMethodPost". Esta sección informa al sistema operativo de que se ha ejecutado el método de servidor.

Declaración La figura siguiente muestra la declaración de las variables locales para el programa de ejemplo:

Figura 9-15 Declaración de las variable locales



Programa SCL El programa siguiente muestra cómo se utilizan las instrucciones OPC UA para proporcionar un método para clientes OPC UA que se ejecute en el programa de usuario (método de servidor).

Llamada de la instrucción "OPC_UA_ServerMethodPre"

Primero se llama a la instrucción "OPC_UA_ServerMethodPre" para preguntar al sistema operativo si se ha llamado al método de servidor desde un cliente OPC UA (líneas 2 a 5).

Si se ha llamado al método de servidor, la variable "#Method_Called" es igual a "TRUE" (en la línea 3).

Si además la instrucción "OPC_UA_ServerMethodPre" se ha ejecutado correctamente (#Pre_Done = TRUE), la línea 10 pone la variable "#Started" a "TRUE".

Método de servidor

Si la variable "#Started" tiene el valor "TRUE", entonces se ejecuta el verdadero programa de usuario (líneas 15 a 31).

En esta sección se dispone de todas las posibilidades de programación: Pueden leerse o emitirse valores de proceso, puede accederse a bloques de datos globales, puede llamarse a funciones y bloques de función, etc.

El programa de usuario puede durar varios ciclos.

Para indicar el final del programa de usuario, ponga la variable "#Method_Finished" a "TRUE".

Con "#Method_Result" se transmite un código de error definido por el usuario que se utiliza en el parámetro de bloque "UAMethod_Result" de la instrucción "OPC_UA_ServerMethodPost".

Llamada de la instrucción "OPC_UA_ServerMethodPost"

En la línea 21 o 29 (método de servidor) se ha activado la variable "#Method_Finished" para guardar el estado que indica que se ha ejecutado el programa de usuario (líneas 15 a 31).

Esta variable se utiliza en la instrucción "OPC_UA_ServerMethodPost" para informar al sistema operativo de si se ha ejecutado el método de servidor o no (líneas 33 a 45).



Seguidamente, el sistema operativo se encarga de acusar recibo al cliente que ha llamado el método.

Figura 9-16 Llamada de la instrucción "OPC_UA_ServerMethodPost"



Borrar un método Si ya no se dispone de un método de servidor y debe borrarse, no solo hay que eliminar la llamada del FB correspondiente sino también borrar el bloque de datos de instancia.

Si no se borra el bloque de datos de instancia, el método es visible en el espacio de direcciones y las variables no reciben valores.

Consulte también Métodos de servidor (Página 193)

9.3.4.4 Códigos de error

Códigos de error de Siemens

Códigos de error SIMATIC para instrucciones OPC UA En la tabla siguiente encontrará los códigos de error de Siemens para las instrucciones OPC UA:

Tabla 9- 6 Códigos de error SIMATIC para instrucciones OPC UA

Código de error (hex) Descripción B080_C300 InsufficientResources:

No hay recursos suficientes. Puede ser (a) error en la asignación de memoria o (b) demasiadas instancias del SFB

B080_0B00 ArrayElements_TooMany: El array posee demasiados elementos.

B080_B000 TooManyMethods: Se ha excedido el número máximo de métodos de servidor o el número máximo de instancias del método de servidor (Llamadas de las instrucciones OPC_UA_ServerMethodPre, OPC_UA_ServerMethodPost): • Para S7-1510 hasta S7-1513 ...: máx. 20 • Para S7-1515, S7-1516...: máx. 50 • Para S7-1517, S7-1518, S7-1507S...: máx. 100 • (consulte también Notas sobre capacidades al usar interfaces

de servidores (Página 233))



Códigos de error de la OPC Foundation Códigos de error

La tabla siguiente contiene los códigos de error de la OPC Foundation.

Los nombres y las explicaciones de los errores se muestran en su versión original. Solo están disponibles en inglés.

Códigos de error

Tabla 9- 7 Códigos de error de la OPC Foundation

Estado "Good" (0000_0000 - 3FFF_FFFF) Número de error (hex)

Nombre Significado

00000000 Good Success, no error. 002D0000 GoodSubscriptionTransfe-

rred The subscription was transferred to another session.

002E0000 GoodCompletesAsynchro-nously

The processing will complete asynchronously.

002F0000 GoodOverload Sampling has slowed down due to resource limitations. 00300000 GoodClamped The value written was accepted but was clamped. 00960000 GoodLocalOverride The value has been overridden. 00A20000 GoodEntryInserted The data or event was successfully inserted into the historical database. 00A30000 GoodEntryReplaced The data or event field was successfully replaced in the historical database. 00A50000 GoodNoData No data exists for the requested time range or event filter. 00A60000 GoodMoreData The data or event field was successfully replaced in the historical database. 00A70000 GoodCommunicationEvent The communication layer has raised an event. 00A80000 GoodShutdownEvent The system is shutting down. 00A90000 GoodCallAgain The operation is not finished and needs to be called again. 00AA0000 GoodNonCriticalTimeout A non-critical timeout occurred. 00BA0000 GoodResultsMayBeIncom-

plete The server should have followed a reference to a node in a remote server but did not. The result set may be incomplete.

00D90000 GoodDataIgnored The request pecifies fields which are not valid for the EventType or cannot be saved by the historian.

00DC0000 GoodEdited The value does not come from the real source and has been edited by the server.

00DD0000 GoodPostActionFailed There was an error in execution of these post-actions. 00E00000 GoodDependentValueChan-

ged A dependent value has been changed but the change has not been applied to the device.




Estado "Uncertain" (4000_0000 - 7FFF_FFFF) Número de error (hex)

Nombre Significado

406C0000 UncertainReferenceOutOf-Server

One of the references to follow in the relative path references to a node in the address space in another server.

408F0000 UncertainNoCommunica-tionLastUsableValue

Communication to the data source has failed. The variable value is the last value that had a good quality.

40900000 UncertainLastUsableValue Whatever was updating this value has stopped doing so. 40910000 UncertainSubstituteValue The value is an operational value that was manually overwritten. 40920000 UncertainInitialValue The value is an initial value for a variable that normally receives its value

from another variable. 40930000 UncertainSensorNotAccurate The value is at one of the sensor limits. 40940000 UncertainEngineeringUni-

tsExceeded The value is outside of the range of values defined for this parameter.

40950000 UncertainSubNormal The value is derived from multiple sources and has less than the required number of Good sources.

40A40000 UncertainDataSubNormal The value is derived from multiple values and has less than the required number of Good values.

40BC0000 UncertainReferenceNotDele-ted

The server was not able to delete all target references.

40C00000 UncertainNotAllNodesAvai-lable

The list of references may not be complete because the underlying system is not available.

40DE0000 UncertainDominantVa-lueChanged

The related EngineeringUnit has been changed but the Variable Value is still provided based on the previous unit.

40E20000 UncertainDependentVa-lueChanged

A dependent value has been changed but the change has not been applied to the device. The quality of the dominant variable is uncertain.


Estado "Bad" (8000_0000 - FFFF_FFFF) Número de error (hex)

Nombre Significado

80010000 BadUnexpectedError An unexpected error occurred 80020000 BadInternalError An internal error occurred as a result of a programming or configuration

error. 80030000 BadOutOfMemory Not enough memory to complete the operation. 80040000 BadResourceUnavailable An operating system resource is not available 80050000 BadCommunicationError A low level communication error occurred. 80060000 BadEncodingError Encoding halted because of invalid data in the objects being serialized. 80070000 BadDecodingError Decoding halted because of invalid data in the stream. 80080000 BadEncodingLimits-

Exceeded The message encoding/decoding limits imposed by the stack have been exceeded.

80090000 BadUnknownResponse An unrecognized response was received from the server. 80B80000 BadRequestTooLarge The request message size exceeds limits set by the server.




Nombre Significado

80B90000 BadResponseTooLarge The response message size exceeds limits set by the client. 800A0000 BadTimeout The operation timed out. 800B0000 BadServiceUnsupported The server does not support the requested service. 800C0000 BadShutdown The operation was cancelled because the application is shutting down. 800D0000 BadServerNotConnected The operation could not complete because the client is not connected to the

server. 800E0000 BadServerHalted The server has stopped and cannot process any requests. 800F0000 BadNothingToDo There was nothing to do because the client passed a list of operations with

no elements. 80100000 BadTooManyOperations The request could not be processed because it specified too many opera-

tions. 80110000 BadDataTypeIdUnknown The extension object cannot be (de)serialized because the data type id is

not recognized. 80120000 BadCertificateInvalid The certificate provided as a parameter is not valid. 80130000 BadSecurityChecksFailed An error occurred verifying security. The certificate provided as a parameter

is not valid. 80140000 BadCertificateTimeInvalid The Certificate has expired or is not yet valid. 80150000 BadCertificateIssuer

TimeInvalid An Issuer Certificate has expired or is not yet valid.

80160000 BadCertificateHost NameInvalid

The HostName used to connect to a Server does not match a HostName in the Certificate.

80170000 BadCertificateUriInvalid The URI specified in the Application Description does not match the URI in the Certificate.

80180000 BadCertificateUseNotA-llowed

The Certificate may not be used for the requested operation.

80190000 BadCertificateIssuerUse NotAllowed

The Issuer Certificate may not be used for the requested operation.

801A0000 BadCertificateUntrusted The Certificate is not trusted. 801B0000 BadCertificateRevocation

Unknown It was not possible to determine if the Certificate has been revoked.

801C0000 BadCertificateIssuer RevocationUnknown

It was not possible to determine if the Issuer Certificate has been revoked.

801D0000 BadCertificateRevoked The Certificate has been revoked. 801E0000 BadCertificateIssuerRevoked The Issuer Certificate has been revoked. 801F0000 BadUserAccessDenied User does not have permission to perform the requested operation. 80200000 BadIdentityTokenInvalid The user identity token is not valid. 80210000 BadIdentityTokenRejected The user identity token is valid but the server has rejected it. 80220000 BadSecureChannelIdInvalid The specified secure channel is no longer valid. 80230000 BadInvalidTimestamp The timestamp is outside the range allowed by the server. 80240000 BadNonceInvalid The nonce does appear to be not a random value or it is not the correct

length. 80250000 BadSessionIdInvalid The session id is not valid. 80260000 BadSessionClosed The session was closed by the client.




Nombre Significado

80270000 BadSessionNotActivated The session cannot be used because ActivateSession has not been called. 80280000 BadSubscriptionIdInvalid The subscription id is not valid. 802A0000 BadRequestHeaderInvalid The header for the request is missing or invalid. 802B0000 BadTimestampsTo

ReturnInvalid The timestamps to return parameter is invalid.

802C0000 BadRequestCancelled ByClient

The request was cancelled by the client.

80310000 BadNoCommunication Communication with the data source is defined, but not established, and there is no last known value available.

80320000 BadWaitingForInitialData Waiting for the server to obtain values from the underlying data source. 80330000 BadNodeIdInvalid The syntax of the node id is not valid. 80340000 BadNodeIdUnknown The node id refers to a node that does not exist in the server address space. 80350000 BadAttributeIdInvalid The attribute is not supported for the specified Node. 80360000 BadIndexRangeInvalid The syntax of the index range parameter is invalid. 80370000 BadIndexRangeNoData No data exists within the range of indexes specified. 80380000 BadDataEncodingInvalid The data encoding is invalid. 80390000 BadDataEncoding

Unsupported The server does not support the requested data encoding for the node.

803A0000 BadNotReadable The access level does not allow reading or subscribing to the Node. 803B0000 BadNotWritable The access level does not allow writing to the Node. 803C0000 BadOutOfRange The value was out of range. 803D0000 BadNotSupported The requested operation is not supported. 803E0000 BadNotFound A requested item was not found or a search operation ended without suc-

cess. 803F0000 BadObjectDeleted The object cannot be used because it has been deleted. 80400000 BadNotImplemented Requested operation is not implemented. 80410000 BadMonitoringModeInvalid The monitoring mode is invalid. 80420000 BadMonitoredItemIdInvalid The monitoring item id does not refer to a valid monitored item. 80430000 BadMonitoredItem

FilterInvalid The monitored item filter parameter is not valid.

80440000 BadMonitoredItem FilterUnsupported

The server does not support the requested monitored item filter.

80450000 BadFilterNotAllowed A monitoring filter cannot be used in combination with the attribute specified. 80460000 BadStructureMissing A mandatory structured parameter was missing or null. 80470000 BadEventFilterInvalid The event filter is not valid. 80480000 BadContentFilterInvalid The content filter is not valid. 80490000 BadFilterOperandInvalid The operand used in a content filter is not valid. 804A0000 BadContinuation

PointInvalid The continuation point provide is longer valid.

804B0000 BadNoContinuationPoints The operation could not be processed because all continuation points have been allocated.

804C0000 BadReferenceTypeIdInvalid The operation could not be processed because all continuation points have been allocated.




Nombre Significado

804D0000 BadBrowseDirectionInvalid The browse direction is not valid. 804E0000 BadNodeNotInView The node is not part of the view. 804F0000 BadServerUriInvalid The ServerUri is not a valid URI. 80500000 BadServerNameMissing No ServerName was specified 80510000 BadDiscoveryUrlMissing No DiscoveryUrl was specified. 80520000 BadSempahoreFileMissing The semaphore file specified by the client is not valid. 80530000 BadRequestTypeInvalid The security token request type is not valid. 80540000 BadSecurityModeRejected The security mode does not meet the requirements set by the Server. 80550000 BadSecurityPolicyRejected The security policy does not meet the requirements set by the Server. 80560000 BadTooManySessions The server has reached its maximum number of sessions. 80570000 BadUserSignatureInvalid The user token signature is missing or invalid. 80580000 BadApplicationSignature

Invalid The signature generated with the client certificate is missing or invalid.

80590000 BadNoValidCertificates The client did not provide at least one software certificate that is valid and meets the profile requirements for the server.

805A0000 BadRequestCancelled ByRequest

The request was cancelled by the client with the Cancel service.

805B0000 BadParentNodeIdInvalid The parent node id does not to refer to a valid node. 805C0000 BadReferenceNotAllowed The reference could not be created because it violates constraints imposed

by the data model. 805D0000 BadNodeIdRejected The requested node id was reject because it was either invalid or server

does not allow node ids to be specified by the client. 805E0000 BadNodeIdExists The requested node id is already used by another node. 805F0000 BadNodeClassInvalid The node class is not valid. 80600000 BadBrowseNameInvalid The browse name is invalid. 80610000 BadBrowseNameDuplicated The browse name is not unique among nodes that share the same relation-

ship with the parent. 80620000 BadNodeAttributesInvalid The node attributes are not valid for the node class. 80630000 BadTypeDefinitionInvalid The type definition node id does not reference an appropriate type node. 80640000 BadSourceNodeIdInvalid The source node id does not reference a valid node. 80650000 BadTargetNodeIdInvalid The target node id does not reference a valid node. 80660000 BadDuplicateReference

NotAllowed The reference type between the nodes is already defined.

80670000 BadInvalidSelfReference The server does not allow this type of selfreference on this node. 80680000 BadReferenceLocalOnly The reference type is not valid for a reference to a remote server. 80690000 BadNoDeleteRights The server will not allow the node to be deleted. 806A0000 BadServerIndexInvalid The server index is not valid. 806B0000 BadViewIdUnknown The view id does not refer to a valid view node. 806D0000 BadTooManyMatches The requested operation has too many matches to return. 806E0000 BadQueryTooComplex The requested operation requires too many resources in the server. 806F0000 BadNoMatch The requested operation has no match to return. 80700000 BadMaxAgeInvalid The max age parameter is invalid.




Nombre Significado

80710000 BadHistoryOperationInvalid The history details parameter is not valid. 80720000 BadHistoryOperation

Unsupported The server does not support the requested operation.

80730000 BadWriteNotSupported The server not does support writing the combination of value, status and timestamps provided.

80740000 BadTypeMismatch The value supplied for the attribute is not of the same type as the attribute's value.

80750000 BadMethodInvalid The method id does not refer to a method for the specified object. 80760000 BadArgumentsMissing The client did not specify all of the input arguments for the method. 80770000 BadTooManySubscriptions The server has reached its maximum number of subscriptions. 80780000 BadTooManyPublish

Requests The server has reached the maximum number of queued publish requests.

80790000 BadNoSubscription There is no subscription available for this session. 807A0000 BadSequenceNumber

Unknown The sequence number is unknown to the server.

807B0000 BadMessageNotAvailable The requested notification message is no longer available. 807C0000 BadInsufficientClientProfile The Client of the current Session does not support one or more Profiles that

are necessary for the Subscription. 80BF0000 BadStateNotActive The sub-state machine is not currently active. 807D0000 BadTcpServerTooBusy The server cannot process the request because it is too busy. 807E0000 BadTcpMessageTypeInvalid The type of the message specified in the header invalid. 807F0000 BadTcpSecureChannel

Unknown The SecureChannelId and/or TokenId are not currently in use.

80800000 BadTcpMessageTooLarge The size of the message specified in the header is too large. 80810000 BadTcpNotEnough

Resources There are not enough resources to process the request.

80820000 BadTcpInternalError An internal error occurred. 80830000 BadTcpEndpointUrlInvalid The Server does not recognize the QueryString specified. 80840000 BadRequestInterrupted The request could not be sent because of a network interruption. 80850000 BadRequestTimeout Timeout occurred while processing the request. 80860000 BadSecureChannelClosed The secure channel has been closed. 80870000 BadSecureChannelToken

Unknown The token has expired or is not recognized.

80880000 BadSequenceNumberInvalid The sequence number is not valid. 80890000 BadConfigurationError There is a problem with the configuration that affects the usefulness of the

value. 808A0000 BadNotConnected The variable should receive its value from another variable, but has never

been configured to do so. 808B0000 BadDeviceFailure There has been a failure in the device/data source that generates the value

that has affected the value. 808C0000 BadSensorFailure There has been a failure in the sensor from which the value is derived by the

device/data source. 808D0000 BadOutOfService The source of the data is not operational.




Nombre Significado

808E0000 BadDeadbandFilterInvalid The dead band filter is not valid. 80970000 BadRefreshInProgress This Condition refresh failed, a Condition refresh operation is already in

progress. 80980000 BadConditionAlreadyDisa-

bled This condition has already been disabled.

80990000 BadConditionDisabled Property not available, this condition is disabled. 809A0000 BadEventIdUnknown The specified event id is not recognized. 809B0000 BadNoData No data exists for the requested time range or event filter. 809D0000 BadDataLost Data is missing due to collection started/stopped/lost. 809E0000 BadDataUnavailable Expected data is unavailable for the requested time range due to an un-

mounted volume an off-line archive or tape or similar reason for temporary unavailability.

809F0000 BadEntryExists The data or event was not successfully inserted because a matching entry exists.

80A00000 BadNoEntryExists The data or event was not successfully updated because no matching entry exists.

80A10000 BadTimestampNotSupported The client requested history using a timestamp format the server does not support (i. e. requested ServerTimestamp when server only supports SourceTimestamp).

80AB0000 BadInvalidArgument One or more arguments are invalid. 80AC0000 BadConnectionRejected Could not establish a network connection to remote server. 80AD0000 BadDisconnect The server has disconnected from the client. 80AE0000 BadConnectionClosed The network connection has been closed. 80AF0000 BadInvalidState The operation cannot be completed because the object is closed uninitial-

ized or in some other invalid state. 80B00000 BadEndOfStream Cannot move beyond end of the stream. 80B10000 BadNoDataAvailable No data is currently available for reading from a non-blocking stream. 80B20000 BadWaitingForResponse The asynchronous operation is waiting for a response. 80B30000 BadOperationAbandoned The asynchronous operation was abandoned by the caller. 80B40000 BadExpectedStreamToBlock The stream did not return all data requested (possibly because it is a non-

blocking stream). 80B50000 BadWouldBlock Non-blocking behavior is required and the operation would block. 80B60000 BadSyntaxError A value had an invalid syntax. 80B70000 BadMaxConnections

Reached The operation could not be finished because all available connections are in use.

80BB0000 BadEventNot Acknowledgeable

The event cannot be acknowledged.

80BD0000 BadInvalidTimestamp Argument

The defined timestamp to return was invalid.

80BE0000 BadProtocolVersion Unsupported

The applications do not have compatible protocol versions.

80C10000 BadFilterOperatorInvalid An unrecognized operator was provided in a filter. 80C20000 BadFilterOperator

Unsupported A valid operator was provided, but the server does not provide support for this filter operator.




Nombre Significado

80C30000 BadFilterOperandCount Mismatch

The number of operands provided for the filter operator was less than ex-pected for the operand provided.

80C40000 BadFilterElementInvalid The referenced element is not a valid element in the content filter. 80C50000 BadFilterLiteralInvalid The referenced literal is not a valid value. 80C60000 BadIdentityChangeNotSup-

ported The Server does not support changing the user identity assigned to the session.

80C80000 BadNotTypeDefinition The provided Nodeid was not a type definition nodeid. 80C90000 BadViewTimestampInvalid The view timestamp is not available or not supported. 80CA0000 BadViewParameterMismatch The view parameters are not consistent with each other. 80CB0000 BadViewVersionInvalid The view version is not available or not supported. 80CC0000 BadConditionAlready

Enabled This condition has already been enabled.

80CD0000 BadDialogNotActive The dialog condition is not active. 80CE0000 BadDialogResponseInvalid The response is not valid for the dialog. 80CF0000 BadConditionBranch

AlreadyAcked The condition branch has already been acknowledged.

80D00000 BadConditionBranch AlreadyConfirmed

The condition branch has already been confirmed.

80D10000 BadConditionAlreadyShel-ved

The condition has already been shelved.

80D20000 BadConditionNotShelved The condition is not currently shelved. 80D30000 BadShelvingTimeOutOfRan-

ge The shelving time not within an acceptable range.

80D40000 BadAggregateListMismatch The requested number of Aggregates does not match the requested number of NodeIds.

80D50000 BadAggregateNotSupported The requested Aggregate is not support by the server. 80D60000 BadAggregateInvalidInputs The aggregate value could not be derived due to invalid data inputs. 80DB0000 BadTooManyMonitoredItems The request could not be processed because there are too many monitored

items in the subscription. 80D70000 BadBoundNotFound No data found to provide upper or lower bound value. 80D80000 BadBoundNotSupported The server cannot retrieve a bound for the variable. 80DA0000 BadAggregateConfiguration

Rejected The aggregate configuration is not valid for specified node.

80E10000 BadDominantValueChanged The related EngineeringUnit has been changed but this change has not been applied to the device. The Variable Value is still dependent on the previous unit but its status is currently bad.

80E30000 BadDependentValueChan-ged

A dependent value has been changed but the change has not been applied to the device. The quality of the dominant variable is bad.

80E40000 BadRequestNotAllowed The request was rejected by the server because it did not meet the criteria set by the server.

80E50000 BadTooManyArguments Too many arguments were provided. 80E60000 BadSecurityModeInsufficient The operation is not permitted over the current secure channel. 810D0000 BadCertificateChainIncom-

plete The certificate chain is incomplete.




Nombre Significado

810E0000 BadLicenseExpired The server requires a license to operate in general or to perform a service or operation, but existing license is expired.

810F0000 BadLicenseLimitsExceeded The server has limits on number of allowed operations / objects, based on installed licenses, and these limits where exceeded.

81100000 BadLicenseNotAvailable The server does not have a license which is required to operate in general or to perform a service or operation.

81110000 BadNotExecutable The executable attribute does not allow the execution of the method. 81120000 BadNumericOverflow The number was not accepted because of a numeric overflow. 81130000 BadRequestNotComplete The request has not been processed by the server yet.

9.3.5 Uso de modelos de información OPC UA

9.3.5.1 Utilización de especificaciones OPC UA Companion

Introducción OPC UA puede utilizarse universalmente: el propio estándar no realiza, p. ej., ninguna afirmación sobre cómo debe llamarse a las variables PLC. Asimismo cada usuario (desarrollador de aplicaciones) puede decidir libremente programar y nombrar métodos de servidor que puedan llamarse a través de OPC UA.

Modelado de información y estandarización para dispositivos y ramos

Para aplicaciones similares existe la posibilidad de estandarizar la interfaz del dispositivo o de la máquina con el "kit OPC UA".

Muchos son los gremios y sectores que han impulsado la estandarización y elaborado diferentes especificaciones Companion.

En estas especificaciones se define:

● con qué objetos, métodos y variables debe describirse un dispositivo típico o una máquina típica;

● qué espacio de nombres está previsto para los objetos mencionados.

Las máquinas se estructuran típicamente en unidades funcionales o tecnológicas que se estandarizan.

Las especificaciones Companion ofrecen a los operadores de máquinas e instalaciones la ventaja de una interfaz unívoca. Por ejemplo, todos los lectores RFID que cumplan la especificación AutoID pueden integrarse del mismo modo. Es decir, los clientes OPC UA pueden responder de igual modo a todos los lectores RFID que conforme a la especificación son AutoID, con independencia del fabricante de los lectores RFID.

Otro ejemplo de especificación Companion en el ámbito de las máquinas de moldeo por inyección es la especificación Euromap 77 Companion.

El capítulo siguiente describe, tomando como ejemplo Euromap 77, cómo se aplica una especificación Companion en STEP 7 (TIA Portal) creando para ello variables PLC.



Ejemplo Euromap 77 Euromap 77 normaliza el intercambio de datos entre las máquinas de moldeo por inyección y el MES (manufacturing execution system) de nivel superior. Esto permite que el MES integre uniformemente todas las máquinas de moldeo por inyección subyacentes.

La interfaz de datos unificada facilita la integración de las máquinas de moldeo por inyección en una instalación.

Las especificaciones Companion utilizan: sinopsis Euromap 77 se describe en el archivo XML de OPC UA "Opc_Ua.EUROMAP77.NodeSet2.xml".

Nota Euromap 77, Euromap 83 y OPC UA for Devices (DI)

Con la versión Candidate 2, parte de las definiciones de Euromap se transfirieron a Euromap 83. Por ello, también es necesario importar la interfaz del servidor OPC UA de Euromap 83.

"OPC UA for Devices" es un modelo de información de validez general para configurar componentes hardware y software. El modelo de información también sirve de base para otros estándares Companion, por lo que también se importa.

Obtendrá los archivos XML OPC UA aquí:

Euromap77 (http://www.euromap.org/euromap77)

Euromap83 (http://www.euromap.org/euromap83)

OPC UA for Devices (https://opcfoundation.org/UA/schemas/DI/)

Los archivos XML OPC UA de Euromap definen la interfaz del servidor OPC UA de una máquina de moldeo por inyección que es conforme con el estándar Companion Euromap 77.

Para modelar el servidor OPC UA de la CPU S7-1500 según el estándar Euromap 77, proceda del siguiente modo:

1. Cree un archivo XML, y cree en él una instancia del tipo "IMM_MES_InterfaceType".

"IMM_MES_InterfaceType" es el nodo superior de Euromap 77: Este tipo de datos deriva directamente del tipo de datos OPC UA "BaseObjectType".

Por debajo de "IMM_MES_InterfaceType" todas las variables y métodos de Euromap 77 (83) están definidos.

En el "Paso 1" se describe en detalle cómo proceder.

2. Asigne a las variables y métodos de Euromap 77 (al modelo de información de Euromap 77) variables PLC e instancias de FB (métodos de servidor) de la CPU S7-1500.


http://www.euromap.org/euromap77

http://www.euromap.org/euromap83

https://opcfoundation.org/UA/schemas/DI/



3. Importe el archivo XML como "interfaz del servidor".


Compile el proyecto STEP 7.

Cargue el proyecto en la CPU que funciona como controlador de una máquina de moldeo por inyección.

4. Cree en el proyecto STEP 7 las variables PLC y los métodos de servidor a los que ha asignado variables y métodos de Euromap 77 en el punto 2.

Las variables PLC deben tener tipos de datos compatibles, consulte "Mapeo de los tipos de datos".

Permita a los clientes OPC UA el acceso de lectura y escritura a estas variables PLC conforme a Euromap 77.

P. ej., cree las variables PLC en un bloque de datos.


Resultado: las variables y los métodos de servidor según Euromap 77 están disponibles para clientes OPC UA en el espacio de direcciones del servidor OPC UA de la CPU.

Paso 1: Crear instancia La descripción de ejemplo que sigue utiliza el programa "UaModeler" de Unified Automation. También es posible utilizar otras herramientas para crear el archivo XML de OPC UA (interfaz del servidor). Las herramientas para el diseño de modelos de información se perfeccionan permanentemente. Por ello, para el manejo utilice siempre la documentación proporcionada por el fabricante. La documentación prevalece sobre la descripción aquí aportada.

El programa "UaModeler" puede cargarse desde aquí: Unified_Automation_Download (https://www.unified-automation.com/downloads/opc-ua-development.html)

UaModeler permite diseñar los modelos de información y espacios de direcciones para el servidor OPC UA y crear nuevos tipos e instancias de nodos OPC UA. UaModeler también puede utilizarse para definir extensiones de variables UA y métodos UA con el fin de mapear variables UA y métodos UA en variables PLC y bloques de función PLC (instancias).

Para crear un archivo XML con una instancia de "IMM_MES_InterfaceType", proceda del siguiente modo:

1. Cree los archivos "Opc_Ua.EUROMAP77.NodeSet2.xml" y "Opc_Ua_EUROMAP83_NodeSet2.xml" desde la página web de Euromap (véase más arriba).

2. Cree un proyecto nuevo en UaModeler e introduzca un nombre de proyecto.

En el ejemplo utilice "Demo" como nombre de proyecto.

3. En "Generate Code" haga clic en "modeling > v1_0" y después en el botón "Next".

4. En "Choose Base Models" haga clic en el botón "Find another model" si todavía no están cargados el archivo "Ua.EUROMAP77.NodeSet2.ua" o "Opc_Ua_EUROMAP83_NodeSet2.xml".

UaModeler guarda los archivos XML en un formato interno con extensión ".ua".

https://www.unified-automation.com/downloads/opc-ua-development.html



5. En el cuadro de diálogo "Add Information Model" seleccione el tipo de datos "Information Model (*.xml)". A continuación seleccione el archivo XML "Opc_Ua.EUROMAP77.NodeSet2.xml" y "Opc_Ua_EUROMAP83_NodeSet2.xml" en el sistema de archivos del equipo.

6. Se mostrará una advertencia indicando que el modelo seleccionado se basa en más de un modelo. Haga clic en "Yes".

De este modo se seleccionará adicionalmente el modelo "Opc.Ua.Di.Nodset2.ua" que sirve de base.

7. Se muestra el cuadro de diálogo "New Model".

En el ejemplo no modifique los valores ajustados y haga clic en "Finish" para aplicar los valores.

En "Namespace URI" está registrado "http://yourorganisation.org/Demo/".

Utilice en el proyecto un espacio de nombres que sea significativo para su empresa.

8. UaModeler abre el proyecto.

En "Information Model" haga clic con el botón derecho del ratón en "DeviceSet" y después en "Add Instance".

9. En el ejemplo utilice cadenas de caracteres para NodeIds.

Para ello, seleccione en "Additonal Attributes" en la lista desplegable "String". En caso de que no pueda utilizarse el formato para NodId, compruebe el ajuste "Enable editing of NodeIds" en la configuración; la opción debe estar activada.

En el ejemplo introduzca la NodeId "MyIMM_MES_Interface".

10.En la lista desplegable de "Type Definition" seleccione la entrada "IMM_MES_InterfaceType" e introduzca un nombre para la instancia.

En el ejemplo utilice el nombre ""MyIMM_MES_Interface".

11.Haga clic en el botón "Aceptar" situado en la parte inferior derecha de UaModeler.



12.Abra el nuevo nodo "MyIMM_MES_Interface":

Para ello, haga clic en la flecha que precede a "MyIMM_MES_Interface":

Resultado: En el espacio de direcciones del servidor OPC UA se encuentra un objeto según Euromap 77 o Euromap 83 que representa la máquina de moldeo por inyección, p. ej., para un MES (Management Execution System). Del mismo modo es posible generar otros objetos subordinados u otras configuraciones cualesquiera, diseñando así el servidor OPC UA como sea necesario.

13.Guarde el proyecto.

14.En "Proyecto" seleccione el proyecto de demostración:

15.Haga clic con el botón derecho del ratón en "demo.ua" y seleccione la entrada "Export

XML" en el menú contextual.

UaModeler exporta el proyecto al archivo "demo.xml".

16.Cierre UaModeler.



Paso 2: asignar variables PLC La descripción que sigue muestra con el ejemplo de una variable cómo se asignan determinadas variables PLC y métodos de servidor a las variables y métodos de Euromap 77.


1. Abra con un editor el archivo "demo.xml" que se ha creado en el "paso 1".

Busque en el archivo XML la variable UA con NodeId="ns=1;s=MyIMM_MES_Interface.InjectionUnits.NodeVersion".

En el paso siguiente asigne una variable PLC a esta variable.

2. Para asignar una variable PLC a esta variable OPC UA, agregue una extensión al elemento XML de la variable OPC UA.

A su vez, agregue un elemento del tipo "<si:VariableMapping>" a dicha extensión:

3. El elemento XML "<si:VariableMapping>" está definido en el espacio de nombres XML

"http://www.siemens.com/OPCUA/2017/SimaticNodeSetExtensions".

Por este motivo es necesario agregar este espacio de nombres al elemento XML "<UANodeSet>", p. ej. una única vez al principio del archivo XML mediante la siguiente línea de código:

Si no se agrega el espacio de nombres, en el archivo se desconoce el elemento "<si:VariableMapping>".

4. Guarde el archivo "demo.xml" y cierre el editor.



Excurso: asignar métodos PLC Además de variables, también es posible asignar métodos a una instancia de FB (programa de usuario o bloque de función como representación del método).

Para asignar una instancia de FB a un método OPC UA es necesario agregar una extensión al archivo XML OPC UA según el patrón que se expone más abajo. Tenga en cuenta que el sufijo ".Method" debe agregarse al nombre de la instancia sin utilizar comillas.

Agregue un elemento del tipo "<si:MethodMapping>" a la extensión.

Las propiedades de un método OPC UA con nombre de navegador "InputArguments" o "OutputArguments" son variables OPC UA y no se asignan.

Paso 3: Importar interfaces de servidor Para importar un archivo XML OPC UA como "interfaz de servidor", proceda del siguiente modo:

1. Abra el proyecto STEP 7.

2. Haga clic en "Comunicación OPC UA > Interfaces de servidor".

3. Haga doble clic en "Importar interfaz del servidor".

4. En el cuadro de diálogo "Importar" seleccione el archivo que desee importar como interfaz del servidor.

En este ejemplo es el archivo "demo.xml".



5. Haga clic en el botón "Importar".

6. Importe también los archivos "Opc.Ua.Di.NodeSet2.xml", "Opc_Ua.EUROMAP77.NodeSet2.xml" y "Opc_Ua.EUROMAP83.NodeSet2.xml".

El archivo "demo.xml" se refiere a los archivos mencionados en primer lugar.

Utilice siempre versiones actuales de dichos archivos, puesto que STEP 7 no compila archivos XML OPC UA defectuosos.

La imagen de la máquina creada más arriba según las especificaciones Euromap 77 está ahora en el espacio de direcciones del servidor OPC UA.

Paso 4: Crear variables PLC y métodos de servidor en el proyecto de STEP 7 En el ejemplo se ha asignado la variable PLC "MyIMM_MES_Interface"."InjecionUnits.NodeVersion" a la variable UA con NodeId="ns=1;s=MyIMM_MES_Interface.InjectionUnits.NodeVersion", véase "Paso 2: asignar variables PLC".

Para crear con STEP 7 (TIA Portal) la variable necesaria, proceda del siguiente modo:

1. Cree un bloque de datos "MyIMM_MES_Interface".

2. Cree el elemento de DB "InjectionUnits.NodeVersion". Utilice el tipo de datos SIMATIC compatible con el tipo de datos OPC UA. La variable UA del ejemplo posee el tipo de datos OPC UA "String" (DataType="String"). . El tipo de datos SIMATIC compatible es WSTRING.

3. Compile el proyecto.

4. Cargue el proyecto en la CPU.



Importación de archivos XML OPC UA exportados a una CPU S7-1500 Al importar interfaces de servidores que provengan de la exportación XML OPC UA de un S7-1500, tenga en cuenta la siguiente nota.

Nota Importación bloqueada para el espacio de nombres "http://www.siemens.com/simatic-s7-opcua"

No es posible importar a una CPU S7-1500 una interfaz de servidor con espacio de nombres "http://www.siemens.com/simatic-s7-opcua", puesto que dicho espacio de nombres está reservado para las CPU S7-1500 (interfaz estándar de servidor SIMATIC) y está bloqueado para la importación.

Si se desea importar una interfaz de servidor con el espacio de nombres "http://www.siemens.com/simatic-s7-opcua", abra la interfaz de servidor que vaya a importarse (archivo XML OPC UA) y modifique el espacio de nombres donde sea preciso. A continuación podrá importarse el archivo modificado.

Integridad de los archivos XML OPC UA Los archivos XML OPC UA representan el espacio de direcciones del servidor. Estos archivos, una vez adaptados a la aplicación, se importan como interfaz del servidor, p. ej., en el contexto de las especificaciones de OPC UA Companion, se cargan con la configuración hardware en la CPU S7-1500 y se prueban.

ADVERTENCIA

No se comprueban los archivos XML OPC UA importados

Estos archivos XML OPC UA deben protegerse de manipulaciones no autorizadas, pues STEP 7 no comprueba su integridad.

Recomendación

Para minimizar riesgos en caso de ampliar o modificar el espacio de direcciones del servidor, proceda del siguiente modo:

1. Proteja el proyecto (árbol del proyecto: Ajustes de seguridad > Ajustes).

2. Exporte la interfaz de servidor correspondiente antes de la ampliación o modificación.

3. Revise este archivo XML OPC UA.

4. Vuelva a importar el archivo como interfaz del servidor.



Mapeado de los tipos de datos La tabla siguiente muestra el tipo de datos SIMATIC compatible con cada tipo de datos OPC UA.

Los tipos de datos deben asignarse tal como se indica más adelante (tipo de datos SIMATIC - tipo de datos OPC UA). No se permiten otras asignaciones. STEP 7 no comprueba si se ha observado esta regla y no impide asignaciones erróneas. El usuario es responsable de seleccionar y asignar los tipos de datos conforme a las reglas.

Los tipos de datos listados también se pueden utilizar, p. ej., como elementos de estructuras/UDT para parámetros de entrada y salida de métodos de servidor creados por el usuario (UAMethod_InParameters y UAMethod_OutParameters).

Tabla 9- 10 Mapeado de los tipos de datos

Tipo de datos SIMATIC Tipo de datos OPC UA BOOL Boolean SINT SByte INT Int16 DINT Int32 LINT Int64 USINT Byte UINT UInt16 UDINT UInt32 ULINT UInt64 REAL Float LREAL Double LDT DateTime WSTRING String DINT Enumeration (Encoding Int32) y todos los tipos de datos

derivados Se requiere un tipo de datos definido por el usuario (UDT, user-defined data type) El tipo de datos definido por el usuario debe crearse con el prefijo "Union_", p. ej. "Union_MyDatatype", consulte el ejemplo de la tabla más abajo. El primer elemento (Selector) de este UDT debe tener el tipo de datos "UDINT".

UNION y todos los tipos de datos derivados



Se requiere un tipo de datos definido por el usuario para UNION

La figura siguiente muestra la variable "MyVariable", que tiene el tipo de datos "Union_MyDatatype".

Este tipo de datos SIMATIC se corresponde con una variable OPC UA con tipo de datos UNION.

La figura muestra un ejemplo de la declaración: Con Selector = 1, la Union toma una ByteString, con Selector = 2 una WString.

Utilizar otros tipos de datos básicos OPC UA Además de los tipos de datos OPC UA indicados en el capítulo "Mapeado de tipos de datos" y sus correspondencias en SIMATIC, también se pueden utilizar los siguientes tipos de datos básicos OPC UA:

● OpcUa_NodeId

● OpcUa_QualifiedName

● OpcUa_Guid

● OpcUa_LocalizedText

● OpcUa_ByteString

● OpcUa_XmlElement

Requisitos para el uso de los tipos de datos básicos arriba indicados como variables en el programa de usuario: Los tipos de datos básicos deben existir como tipos de datos compuestos y estructurados del mismo modo que los correspondientes tipos de datos básicos OPC UA.

● OpcUa_NodeId y OpcUa_QualifiedName existen como tipo de datos del sistema, por lo que también se pueden utilizare para variables individuales o como elementos de una estructura.

● Para los restantes tipos de datos básicos hay que crear un tipo de datos PLC conforme a la especificación OPC UA y, a continuación, utilizarlo como elemento dentro de una estructura para que los elementos puedan resolverse a través del Typedictionary. A continuación se explica cómo tiene que ser el tipo de datos PLC para cada tipo de datos básico. Un ejemplo de estructura de datos en la que se utiliza p. ej. el UDT "LocalizedText" es "EUInformation". EUInformation contiene información sobre EngineeringUnits. Al final de las descripciones de los tipos de datos PLC encontrará un ejemplo de aplicación de la estructura de datos EUInformation.



Tipo de datos del sistema "OPC_UA_NodeId"

Consulte el significado de los parámetros del tipo de datos básico OPC UA "OpcUa_NodeId" en la tabla siguiente. OPC_UA_NodeId se utiliza para identificar un nodo en el servidor OPC UA. Parámetro Tipo de datos S7 Significado NamespaceIndex UINT Índice del espacio de nombres del nodo en el servidor

OPC UA. Un nodo puede ser, por ejemplo, una variable.

Identifier WSTRING[254] La denominación del nodo (objeto o variable) depen-de del tipo de identificador: • Identificador numérico: El nodo se designa con un

número, por ejemplo "12345678". • Identificador de string: El nodo se designa con un

nombre, por ejemplo "MiVariable". Se distingue entre mayúsculas y minúsculas.

IdentifierType UDINT Tipo de identificador • 0: Identificador numérico • 1: identificador de string • 2: GUID • 3: Opaque

Tipo de datos del sistema "OPC_UA_QualifiedName"

Consulte en la tabla siguiente la estructura del tipo de datos del sistema "OPC_UA_QualifiedName": Nombre Tipo de datos S7 Significado NamespaceIndex UINT El índice del espacio de nombres del

nombre. Name WSTRING[64] Nombre del nodo o de la variable.

UDT "Guid"

Cree el siguiente tipo de datos PLC para el tipo de datos básico "Guid": Los valores predeterminados utilizados a modo de ejemplo también se pueden ajustar de otro modo.



UDT "LocalizedText"

Cree el siguiente tipo de datos PLC para el tipo de datos básico "LocalizedText":

El EncodingByte indica los campos (Locale o Text) que hay: EncodingByte Significado 0 Los campos Locale y Text están vacíos 1 El campo Locale tiene contenido, el campo Text está vacío 2 El campo Locale está vacío, el campo Text tiene contenido 3 Los campos Locale y Text tienen contenido

UDT "ByteString"

Cree el siguiente tipo de datos PLC para el tipo de datos básico "ByteString"; en este caso se ha seleccionado p. ej. una matriz ByteString de 12 elementos:

UDT "XmlElement"

Un XmlElement es un fragmento XML serializado (cadena UTF-8).

Cree el siguiente tipo de datos PLC para el tipo de datos básico "XmlElement":



Ejemplo: Estructura de EUInformation con el UDT "LocalizedText"

Atributo MinimumSamplingInterval de variables Además de "Value", "DataType" y "AccessLevel" también se puede activar el atributo "MinimumSamplingInterval" para una variable en el archivo XML que representa el espacio de direcciones del servidor. El atributo indica la rapidez con la que el servidor puede explorar el valor de la variable.

Para el servidor OPC UA de la CPU S7-1500 rige la siguiente regla en lo que respecta a los valores posibles del MinimumSamplingInterval:

● Utilice únicamente enteros positivos entre 0 y 4294967.

Los decimales (p. ej. 0,55) no están permitidos, porque se interpretan erróneamente. Con decimales de hasta 7 cifras se elimina la coma, mientras que con más de 7 cifras el valor se ajusta al máximo: 4294967,295.

Los números negativos se ajustan al valor máximo posible de 4294967,295.

9.3.5.2 Coordinar derechos de escritura y lectura para variables de CPU

Definición de derechos de escritura y lectura en el modelo de información (XML OPC UA) En el modelo de información OPC UA el acceso a las variables lo regula el atributo "AccessLevel".

AccessLevel está definido bit a bit:

Bit 0 = CurrentRead y Bit 1 = CurrentWrite. El significado de las combinaciones de bits es el siguiente:

● AccessLevel = 0: ningún acceso

● AccessLevel = 1: read only

● AccessLevel = 2 write only

● AccessLevel = 3: read+write



Ejemplo de asignación de derechos de escritura y lectura (read+write)

Definición de derechos de escritura y lectura en STEP 7 Al definir variables defina los derechos de acceso con las propiedades "Accesible desde HMI/OPC UA“ y "Escribible desde HMI/OPC UA".

Ejemplo de asignación de derechos de escritura y lectura

Interacción de derechos de escritura y lectura Si se ha importado una interfaz de servidor OPC UA y en este archivo XML OPC UA hay activados atributos AccessLevel, los derechos de escritura y lectura resultantes derivan de la siguiente regla: son efectivos los derechos de acceso más limitados de ambas configuraciones.

Ejemplo

● AccessLevel = 1 (read only) en la interfaz del servidor OPC UA

● Tanto "Accesible desde HMI/OPC UA“ como "Escribible desde HMI/OPC UA" están activados en la tabla de variables PLC

Resultado: la variable solo se lee.



Reglas Si se requieren derechos de escritura:

● AccessLevel = 2 o 3

● "Escribible desde HMI/OPC UA" activado

Si se requieren derechos de lectura:

● AccessLevel = 1 (AccessLevel: 3 también es posible, pero induce a error. El ajuste sugiere que un cliente OPC UA tiene derechos de escritura y de lectura)

● "Accesible desde HMI/OPC UA“ activado, "Escribible desde HMI/OPC UA" desactivado

Si no deben concederse ni derechos de lectura ni de escritura (ningún acceso):

● AccessLevel = 0

● "Accesible desde HMI/OPC UA“ desactivado

Para bloquear cualquier acceso debe cumplirse una de las dos condiciones. En tal caso piense si la variable es realmente necesaria en la interfaz del servidor OPC UA.

Tabla de accesos "Accesible desde HMI/OPC UA" debe estar activado para que sea posible el acceso vía OPC UA. "Escribible desde HMI/OPC UA" debe estar activado para que un cliente OPC UA pueda escribir en una variable o en un elemento de DB.

En la tabla se consulta el derecho de acceso resultante.

Tabla 9- 11 Tabla de accesos

OPC UA-XML STEP 7 (TIA Portal) p. ej. tabla de variables AccessLevel Accesible desde

HMI/OPC UA Escribible desde HMI/OPC UA

Derecho de acceso resultante

0 x x ningún acceso x 0 x ningún acceso 1 activado x read only 2 activado desactivado ningún acceso 3 activado desactivado read only 2 activado activado write only 3 activado activado read+write

(x = don't care)



9.3.5.3 Notas sobre capacidades al usar interfaces de servidores Si se utilizan interfaces de servidores OPC UA, dependiendo de cuál sea la clase de capacidad funcional de la CPU S7-1500 será necesario tener en cuenta límites superiores para los objetos siguientes:

● Número de interfaces de servidores

● Número de nodos OPC UA

● Cantidad de datos de los objetos de carga

● Si se han implementado métodos: número de métodos de servidor o número de instancias del método de servidor

Capacidades para interfaces de servidores OPC UA En la tabla siguiente se indican las capacidades de las CPU S7-1500 que es necesario tener en cuenta al compilar y cargar una configuración.

Si se sobrepasan las capacidades se confirma con un mensaje de error.

Tabla 9- 12 Capacidades para interfaces de servidores OPC UA

Dato técnico CPU 1510SP (F) CPU 1511 (C/F/T/TF) CPU 1512C CPU 1512SP (F) CPU 1513 (F)

CPU 1505 (S/SP/SP F/SP T/SP TF) CPU 1515 (F/T/TF) CPU 1515 SP PC (F/T/TF) CPU 1516 (F/T/TF)

CPU 1507S (F) CPU 1517 (F/T/TF) CPU 1518 (F)

Número máximo de interfaces de servidores OPC UA (modelos de información)

10 10 10

Número máximo de nodos OPC UA 1000 5000 30000 Tamaño máximo de interfaces de servidores OPC UA que pueden cargarse

1024 KB 5120 KB 15 360 KB

Número máximo de métodos de servidor utilizables o número máximo de instancias del método de servidor (instrucciones OPC_UA_ServerMethodPre, OPC_UA_ServerMethodPost)

20 50 100



Nota Utilice Memory Cards con suficiente capacidad

Dependiendo del número y la capacidad de las interfaces de servidores que vayan a cargarse, puede darse el caso de que la carga de la configuración hardware en la CPU se interrumpa con un mensaje de error.

La causa de la interrupción no se indica en el búfer de diagnóstico.

Utilice una Memory Card con suficiente capacidad y no desactive las interfaces de servidores necesarias (propiedades de la interfaz del servidor, opción "Activar interfaz del servidor y cargar en la CPU").


Routing 10 10.1 Routing S7

Definición de routing S7 Por "routing S7" se entiende la transferencia de datos más allá de los límites de las subredes S7. Un emisor puede enviar información a un receptor a través de diferentes subredes S7. El paso de una subred S7 a otra u otras tiene lugar en el router S7. El router S7 es un dispositivo que dispone de las interfaces a las subredes S7 correspondientes. El routing S7 es posible a través de varias subredes S7 (PROFINET/Industrial Ethernet o PROFIBUS).

Requisitos para el routing S7 ● Todos los dispositivos accesibles de una red se han configurado y cargado en un

proyecto en STEP 7.

● Todos los dispositivos implicados en el routing S7 deben recibir información sobre a qué subredes S7 puede accederse y a través de qué routers S7 (= información de routing). Los dispositivos reciben la información de routing mediante la carga de la configuración hardware en las CPU, ya que las CPU cumplen la función de un router S7.

Si la topología presenta varias subredes S7 sucesivas, debe respetarse el siguiente orden durante la carga: cargue primero la configuración hardware en las CPU conectadas directamente a la misma subred S7 que la programadora o el PC y, después, cargue sucesivamente las CPU de las subredes S7 posteriores, desde la subred S7 más próxima hasta la más lejana.

● La programadora o el PC con el que desee establecer una conexión a través de un router S7 deberá estar asignado a la misma subred S7 a la que está conectado físicamente. La programadora o PC puede asignarse en STEP 7 en Online y diagnóstico > Accesos online > Conexión con interfaz/subred.

● Para subredes S7 del tipo PROFIBUS: la CPU debe estar configurada como maestro DP o, en el caso de que lo esté como esclavo DP, debe estar activada la casilla de verificación "Test, puesta en servicio, routing" en las propiedades de la interfaz DP del esclavo DP.

● El routing S7 para conexiones HMI es posible a partir de STEP 7 V13 SP1.

Nota Cortafuegos y routing S7

Un cortafuegos no reconoce la dirección IP del emisor en el routing S7 si el emisor está fuera de la subred S7 que limita con el cortafuegos.

Routing 10.1 Routing S7


Encontrará una sinopsis de los dispositivos que soportan la función "Routing S7" en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/584459).

Routing S7 para conexiones online Con la programadora o el PC puede accederse a dispositivos a través de varias subredes S7 para, p. ej.:

● cargar programas de usuario,

● cargar una configuración hardware,

● ejecutar funciones de test y diagnóstico.

En la siguiente figura, la CPU 1 actúa como router S7 entre la subred S7 1 y la subred S7 2.

Figura 10-1 Routing S7: PROFINET - PROFINET




La siguiente figura ilustra el acceso desde una programadora a PROFIBUS a través de PROFINET. La CPU 1 actúa como router S7 entre la subred S7 1 y la subred S7 2; la CPU 2 actúa como router S7 entre la subred S7 2 y la subred S7 3.

Figura 10-2 Routing S7: PROFINET - PROFIBUS

Routing S7 para conexiones HMI Existe la posibilidad de establecer una conexión S7 entre un HMI y una CPU a través de diferentes subredes (PROFIBUS y PROFINET o Industrial Ethernet). En la siguiente figura, la CPU 1 actúa como router S7 entre la subred S7 1 y la subred S7 2.

Figura 10-3 Routing S7 mediante conexión HMI



Routing S7 para la comunicación CPU-CPU Existe la posibilidad de establecer una conexión S7 entre dos CPU a través de subredes distintas (PROFIBUS y PROFINET o Industrial Ethernet). El procedimiento se describe por medio de ejemplos en el capítulo Comunicación S7 (Página 118).

Figura 10-4 Routing S7 con comunicación CPU-CPU

Utilización del routing S7 Para la CPU, seleccione la interfaz PG/PC y la subred S7 en el cuadro de diálogo "Establecer conexión online" de STEP 7. El routing S7 se realiza de forma automática.

Número de conexiones para routing S7 El número de conexiones disponibles para routing S7 en los routers S7 (las CPU, CM y CP) se indica en los Datos técnicos de los manuales de producto de la CPU/CM/CP correspondiente.



Routing S7: ejemplo de aplicación La siguiente figura muestra a modo de ejemplo el mantenimiento remoto de una instalación desde una programadora. En este caso, la conexión se establece mediante un módem a través de dos subredes S7.

Mediante "Accesos online" y "Establecer conexión online" se puede configurar en STEP 7 una conexión remota a través TeleService.

Figura 10-5 Asistencia técnica a distancia de una instalación a través de TeleService

Información adicional ● La asignación de recursos de conexión en el routing S7 se describe en el capítulo

Asignación de recursos de conexión (Página 246).

● Para más información sobre la configuración de TeleService, consulte la Ayuda en pantalla de STEP 7.

● Encontrará más información sobre routing S7 y los adaptadores TeleService con la función de búsqueda de los siguientes enlaces de Internet:

– Manual de producto Industrie Software Engineering Tools TS Adapter IE Basic (http://support.automation.siemens.com/WW/view/es/51311100)

– Descargas del TS Adapter (http://support.automation.siemens.com/WW/view/es/10805406/133100)

Consulte también Comunicación HMI (Página 65)


http://support.automation.siemens.com/WW/view/es/10805406/133100

Routing 10.2 Routing de registros


10.2 Routing de registros

Definición de routing de juegos de datos Pueden enviarse datos desde una estación de ingeniería de PROFINET hasta aparatos de campo a través de diferentes redes. Puesto que la estación de ingeniería accede a los aparatos de campo mediante juegos de datos normalizados y estos juegos de datos son enrutados mediante dispositivos S7, se ha acuñado el término "Routing de juegos de datos" para este tipo de enrutamiento.

Los datos enviados en el routing de juegos de datos contienen no solo la parametrización de los aparatos de campo implicados (esclavos DP), sino también información específica de los mismos, p. ej. valores nominales, valores límite, etc.

El routing de juegos de datos se emplea, p. ej., cuando se utilizan aparatos de campo de diferentes fabricantes. Se accede a los aparatos de campo mediante juegos de datos normalizados (PROFINET) para la parametrización y el diagnóstico.

Routing de juegos de datos con STEP 7 Con STEP 7 puede efectuarse un routing de juegos de datos accediendo a una herramienta de dispositivos (p. ej., PCT) mediante la interfaz TCI (Tool Calling Interface) y transfiriendo parámetros de llamada. Para comunicarse con el aparato de campo, la herramienta de dispositivos utiliza las mismas vías de comunicación que STEP 7.

Aparte de la instalación de la herramienta TCI en el equipo con STEP 7, para este tipo de routing no se requiere ninguna configuración.

Ejemplo: routing de juegos de datos con Port Configuration Tool (PCT) La Port Configuration Tool (PCT) permite configurar los maestros IO-Link del ET200 y parametrizar los dispositivos IO-Link conectados. Las subredes están conectadas a través de routers de juegos de datos. Los routers de juegos de datos pueden ser CPU, CP, IM o maestros IO-Link, p. ej.

Las constelaciones de routers de juegos de datos soportadas por la PCT pueden consultarse en esta FAQ (http://support.automation.siemens.com/WW/view/es/87611392).


Routing 10.2 Routing de registros


La siguiente figura muestra una configuración de ejemplo para el routing de juegos de datos con PCT.

Figura 10-6 Configuración de ejemplo para routing de juegos de datos con PCT

Información adicional ● La diferencia entre el routing "normal" y el routing de juegos de datos se describe en esta

FAQ (https://support.industry.siemens.com/cs/ww/es/view/7000978).

● Consulte el manual de producto correspondiente para saber si la CPU, el CP o el CM utilizados soportan el routing de juegos de datos.

● La asignación de recursos de conexión en el routing de juegos de datos se describe en el capítulo Asignación de recursos de conexión (Página 246).

● Para más información sobre la configuración con STEP 7, consulte la Ayuda en pantalla de STEP 7.



Recursos de conexión 11 11.1 Recursos de conexión de una estación

Introducción Algunos servicios de comunicación requieren conexiones. Las conexiones ocupan recursos en el sistema de automatización (estación). La estación recibe los recursos de conexión de las CPU, los procesadores de comunicaciones (CP) y los módulos de comunicación (CM).

Recursos de conexión de una estación Los recursos de conexión disponibles dependen de las CPU, los CP o los CM utilizados y no deben rebasar un número máximo por estación.

La CPU determina el número máximo de recursos de una estación.

Cada CPU incorpora recursos de conexión reservados para la comunicación PG, HMI y de servidor web. De este modo se garantiza, p. ej., que una PG siempre pueda establecer al menos una conexión online con la CPU, independientemente de cuántos otros servicios de comunicación ocupen ya recursos de conexión.

Además existen recursos dinámicos. La diferencia entre el número máximo de recursos de conexión y el número de recursos de conexión reservados es el número máximo de recursos de conexión dinámicos. Los servicios de comunicación, como comunicación PG, HMI, S7, web, Open User Communication y cualquier otra comunicación, se sirven del grupo de recursos de conexión dinámicos (p. ej., OPC UA).

Recursos de conexión 11.1 Recursos de conexión de una estación


La figura siguiente muestra un ejemplo de cómo los diferentes componentes ponen a disposición los recursos de conexión de una estación S7-1500.

① Recursos de conexión disponibles de la estación, de los cuales

A Recursos de conexión reservados de la estación A + B Recursos de conexión de la CPU 1518 C Recursos de conexión del módulo de comunicación CM 1542-1 D Recursos de conexión del procesador de comunicaciones CP 1543-1 ② Recursos de conexión máximos de la estación tomando como ejemplo una configuración for-

mada por CPU 1518, CM 1542-1 y CP 1543-1

Figura 11-1 Recursos de conexión de una estación



Número de recursos de conexión de una estación

Tabla 11- 1 Máximos recursos de conexión soportados para algunos tipos de CPU

Recursos de conexión de una estación

1511 1511C

1512C 1513

1515 1516 1517 1518

Recursos de conexión má-ximos de la estación

96 128 192 256 320 384

de los cuales reservados 10 de los cuales dinámicos 86 118 182 246 310 374 Recursos de conexión de la CPU

64 88 108 128 160 192

Número máx. de recursos de conexión utilizables adicio-nalmente al insertar CM/CP

32 40 84 128 160 192

Recursos de conexión adi-cionales del CM 1542-1

64

Recursos de conexión adi-cionales del CP 1543-1

118

Recursos de conexión adi-cionales del CM 1542-5

40

Recursos de conexión adi-cionales del CP 1542-5

16

El volumen de recursos soportado por una CPU o un módulo de comunicación se indica en los datos técnicos de los correspondientes manuales de producto.

Ejemplo Se ha configurado una CPU 1518-4PN/DP con un módulo de comunicación CM 1542-1 y un procesador de comunicaciones CP 1542-5.

● Recursos de conexión máximos de la estación: 384

● Recursos de conexión disponibles:

– CPU 1518-4 PN/DP: 192

– CM 1542-1: 64

– CP 1542-5: 16

– Total: 272

La instalación dispone de 272 recursos de conexión. Si se agregan otros módulos de comunicación, la estación puede soportar como máximo otros 112 recursos de conexión.



Recursos de conexión reservados Para estaciones con CPU S7-1500, CPU ET 200SP y CPU ET 200pro basadas en S7-1500 hay reservados 10 recursos de conexión:

● 4 para la comunicación PG, que STEP 7 necesita, p. ej., para las funciones de test y diagnóstico o para la carga en la CPU

● 4 para la comunicación HMI, que son ocupados por las primeras conexiones HMI configuradas en STEP 7

● 2 para comunicación con el servidor web

Recursos de conexión 11.2 Asignación de recursos de conexión


11.2 Asignación de recursos de conexión

Sinopsis - Asignación de recursos de conexión La figura siguiente muestra la forma en que diferentes conexiones ocupan los recursos de la S7-1500.

① Comunicación HMI: véase más abajo ② Open User Communication: Las conexiones de la Open User Communication ocupan un re-

curso de conexión en cada punto final. ③ Comunicación S7: Las conexiones de la comunicación S7 ocupan un recurso de conexión en

cada punto final. ④ Comunicación web: La conexión del servidor web ocupa como mínimo un recurso de conexión

en la estación. El número de conexiones asignadas varía en función del navegador. ⑤ Comunicación PG: La conexión PG ocupa un recurso de conexión en la estación. ⑥ Comunicación OPC UA: Por lo general, cada sesión que el servidor OPC UA de la CPU esta-

blece con un cliente OPC UA ocupa un recurso de conexión (Otra comunicación) en la esta-ción.

Recurso de conexión para la comunicación HMI

Recurso de conexión para la Open User Communication

Recurso de conexión para la comunicación S7

Recurso de conexión para la comunicación web

Recurso de conexión para la comunicación PG

Recurso de conexión para Otra comunicación (p. ej., OPC UA)

Figura 11-2 Asignación de recursos de conexión



Recursos de conexión para la comunicación HMI En la comunicación HMI, la asignación de recursos de conexión en la estación depende del dispositivo HMI utilizado.

Tabla 11- 2 Máximo número de recursos de conexión asignados para distintos dispositivos HMI

Dispositivo HMI Máximo número de recursos de conexión de la estación ocupados por conexión HMI

Basic Panel 1 Comfort Panel 21 RT Advanced 21 RT Professional 3 1 Si no se utilizan el diagnóstico de sistema ni la configuración de avisos, la estación solo asigna un

recurso de conexión por conexión HMI.

Ejemplo: Se han configurado las siguientes conexiones HMI para una CPU 1516-3 PN/DP:

● Dos conexiones HMI con un HMI TP700 Comfort. (2 recursos de conexión para cada una)

● Una conexión HMI con un HMI KTP1000 Basic. (1 recurso de conexión)

En total se han asignado en la CPU 5 recursos de conexión para la comunicación HMI.



Recursos de conexión para el routing Para la transferencia de datos a través de varias subredes S7 ("routing S7"), se establece una conexión S7 entre dos CPU. Las subredes S7 están conectadas entre sí mediante pasarelas denominadas "routers S7". En S7-1500, las CPU, los CM y los CP actúan como router S7.

A la hora de establecer una conexión S7 enrutada, debe tenerse en cuenta lo siguiente:

● Una conexión enrutada ocupa un recurso de conexión en cada uno de los dos puntos finales. STEP 7 muestra estos recursos de conexión en la tabla "Recursos de conexión".

● En el router S7 se ocupan dos recursos de conexión especiales para el routing S7. STEP 7 no muestra los recursos de conexión especiales para routing S7 en la tabla "Recursos de conexión". El número de recursos para el routing S7 depende de la CPU. Encontrará los recursos para el routing S7 en los datos técnicos de la CPU, en "Número de conexiones de routing S7".

Recurso de conexión para la comunicación S7

Recurso de conexión especial para el routing S7

Figura 11-3 Recursos de conexión en routing S7

El routing de juegos de datos también permite transferir datos a través de varias subredes S7 (desde una estación de ingeniería conectada a PROFINET hasta diversos aparatos de campo vía PROFIBUS).

Igual que en el routing S7, en el routing de juegos de datos también se ocupan dos de los recursos de conexión especiales para routing S7 en cada router de juegos de datos.

Nota Recursos de conexión para routing de juegos de datos

Para el routing de juegos de datos se ocupan dos recursos de conexión especiales para el routing S7 en el router de juegos de datos. En la tabla de recursos de conexión no se muestran ni la conexión de juegos de datos ni los recursos de conexión asignados.



¿Cuándo se asignan recursos de conexión? El momento de la asignación de recursos de conexión dependerá de cómo se cree la conexión (consulte el capítulo Crear una conexión (Página 29)).

● Creación programada de una conexión: En cuanto se llama una instrucción para establecer una conexión (TSEND_C/TRCV_C o TCON) en el programa de usuario de la CPU, se asigna un recurso de conexión.

Después de la transferencia de datos se puede deshacer la conexión y liberar el recurso parametrizando adecuadamente el parámetro CONT de las instrucciones TSEND_C/TRCV_C o la llamada de la instrucción TDISCON. Al deshacerse la conexión, los recursos de conexión vuelven a estar disponibles en la CPU/CP/CM.

● Conexiones configuradas (p. ej., conexión HMI): Si se ha configurado una conexión en STEP 7, el recurso de conexión queda ocupado en cuanto se carga la configuración hardware en la CPU.

Tras utilizar una conexión configurada para transferir datos, la conexión no se deshace. El recurso de conexión queda ocupado de forma permanente. Para volver a liberar el recurso de conexión, debe borrarse la conexión configurada en STEP 7 y cargar la configuración modificada en la CPU.

● Conexión PG: Tan pronto como se conecta la programadora a una CPU en modo online en STEP 7, quedan asignados recursos de conexión.

● Servidor web: Mientras el servidor web de la CPU permanece abierto en un navegador, se asignan recursos de conexión en la CPU.

● Servidor OPC UA: Mientras exista una sesión entre el servidor OPC UA de la CPU y un cliente OPC UA, se ocupará un recurso de conexión en la CPU.

Vigilancia del máximo número posible de recursos de conexión

Offline

Durante la configuración de conexiones, STEP 7 vigila la asignación de recursos de conexión. STEP 7 notifica que se ha rebasado el número máximo de recursos de conexión con la correspondiente advertencia.

Online

La CPU vigila el consumo de recursos de conexión del sistema de automatización. Si en el programa de usuario se establecen más conexiones que recursos de conexión proporciona el sistema de automatización, la CPU responde con un error a la instrucción de establecimiento de conexión.

Recursos de conexión 11.3 Visualización de los recursos de conexión


11.3 Visualización de los recursos de conexión

indicación de los recursos de conexión en STEP 7 (vista offline) En la configuración hardware se pueden ver los recursos de conexión de un sistema de automatización. Los recursos de conexión figuran en la ventana de inspección, en las propiedades de la CPU.

Figura 11-4 Ejemplo: Recursos de conexión reservados y disponibles (vista offline)

① Recursos de conexión específicos de la estación

Las columnas de los recursos de conexión específicos de la estación informan sobre los recursos de conexión que utiliza y de los que dispone la estación.

En el ejemplo, el sistema de automatización dispone como máximo de 256 recursos de conexión específicos de la estación.

● 10 recursos de conexión reservados, 4 de los cuales ya se utilizan y 6 siguen disponibles. Los recursos utilizados se reparten del siguiente modo:

– 4 recursos para la comunicación HMI

● 246 recursos de conexión dinámicos, 81 de los cuales ya se utilizan y 165 siguen disponibles. Los recursos utilizados se reparten del siguiente modo:

– 6 recursos para la comunicación HMI

– 23 recursos para la comunicación S7

– 52 recursos para Open User Communication



El triángulo de advertencia en la columna de los recursos dinámicos de la estación aparece porque la suma del número máximo de recursos de conexión disponibles de CPU, CP y CM (= 294) rebasa el límite de la estación de 256.

Nota Rebase de los recursos de conexión disponibles

Si se sobrepasa el número de recursos de conexión específicos de una estación, STEP 7 lo notifica con una advertencia. Si se agotan los recursos de conexión disponibles de la CPU, el CP y el CM, debe utilizarse una CPU con un límite superior de recursos de conexión disponibles específicos de la estación o bien debe reducirse el número de conexiones de comunicación.

② Recursos de conexión específicos del módulo

Las columnas de los recursos de conexión específicos del módulo informan sobre el uso de los recursos en las CPU, los CP y los CM de un sistema de automatización:

La visualización es granular por módulos y no por interfaces.

En el ejemplo, la CPU pone a disposición un máximo de 128 recursos de conexión, 47 de los cuales ya se utilizan y 81 siguen disponibles: Los recursos utilizados se reparten del siguiente modo:

● 6 recursos para la comunicación HMI

● 2 recursos para la comunicación S7

● 39 recursos para Open User Communication



Visualización de los recursos de conexión en STEP 7 (vista online) Si existe una conexión online con la CPU, en "Información de la conexión" se ve también cuántos recursos se utilizan actualmente en cada caso.

Figura 11-5 Recursos de conexión: online

Además de la vista offline, la vista online de la tabla "Recursos de conexión" contiene columnas con los recursos de conexión utilizados actualmente. En la vista online se muestran todos los recursos utilizados en el sistema de automatización, con independencia de cómo se haya activado la conexión.

En la fila "Otros tipos de comunicación" se muestran los recursos ocupados para comunicación con dispositivos de terceros. La tabla se actualiza de forma automática.

Nota

Si una conexión S7 enrutada pasa por una CPU, los recursos de conexión de la CPU necesarios para ello no se muestran en la tabla de recursos de conexión.



Visualización de los recursos de conexión para HMI Puede consultarse información sobre la disponibilidad y ocupación de recursos para conexiones HMI en la vista offline del dispositivo HMI (en el área "Recursos de conexión" dentro de Propiedades de la ventana de inspección).

Figura 11-6 Recursos de conexión - comunicación HMI

En el área Recursos de conexión se muestra lo siguiente:

● Número de conexiones disponibles en HMI que están reservadas para la comunicación HMI y la comunicación HTTP

● Número de recursos de conexión utilizados offline en HMI para la comunicación HMI y la comunicación HTTP

Si se rebasa el número máximo de recursos de conexión disponibles para un dispositivo HMI, STEP 7 emite el aviso correspondiente.

● "Número máximo de recursos PLC utilizados por conexión HMI": Este parámetro es un factor que debe multiplicarse por el número de conexiones HMI utilizadas offline. El producto da como resultado el número de recursos HMI ocupados por la CPU.

Visualización de los recursos de conexión en el servidor web Los recursos de conexión no solo pueden visualizarse en STEP 7, sino también con un navegador que muestre la página correspondiente del servidor web.

Encontrará más información acerca de la visualización de los recursos de conexión en el servidor web en el manual de funciones Servidor Web (http://support.automation.siemens.com/WW/view/es/59193560).



Diagnóstico de conexiones 12

Tabla de conexiones en la vista online Cuando se selecciona una CPU en el editor Dispositivos y redes de STEP 7, en la vista online de la tabla de conexiones se muestra el estado de sus conexiones.

Figura 12-1 Vista online de la tabla de conexiones

Al seleccionar una conexión en la tabla de conexiones, se muestra la información detallada de diagnóstico en la ficha "Información de la conexión".

Diagnóstico de conexiones


Ficha "Información de la conexión": Detalles de conexión

Figura 12-2 Diagnóstico de conexiones: detalles de la conexión



Ficha "Información de la conexión": Detalles de direcciones

Figura 12-3 Diagnóstico de conexiones: detalles de direcciones

Diagnóstico mediante servidor web El servidor web integrado de una CPU permite evaluar la información de diagnóstico de la CPU mediante un navegador web.

En las distintas fichas de la página web "Comunicación" encontrará la siguiente información sobre la comunicación con PROFINET:

● Información sobre las interfaces PROFINET de la CPU (p. ej., direcciones, subredes o propiedades físicas)

● Información sobre la calidad de la transferencia de datos (p. ej., número de paquetes de datos enviados/recibidos correctamente)

● Información sobre la asignación/disponibilidad de recursos de conexión

● La página "Conexiones" es similar a la vista online en STEP 7 y proporciona también una vista general de todas las conexiones junto con una vista detallada



Diagnóstico en el programa de usuario Si programa la instrucción T_DIAG, podrá evaluar información de diagnóstico sobre las conexiones configuradas y programadas de la CPU en el programa de usuario.

Información adicional Encontrará una descripción de la funcionalidad de servidor web en el manual de funciones Servidor web (http://support.automation.siemens.com/WW/view/es/59193560).



Industrial Ethernet Security con CP 1543-1 13

La protección general que ofrece Industrial Ethernet Security Industrial Ethernet Security permite proteger dispositivos individuales, células de automatización o segmentos de red de una red Ethernet. Además, la combinación de distintas medidas de seguridad permite proteger la transferencia de datos ante:

● espionaje de datos;

● manipulación de datos;

● accesos no autorizados.

Medidas de seguridad ● Cortafuegos

– cortafuegos IP con Stateful Packet Inspection (capa 3 y 4);

– cortafuegos también para telegramas Ethernet "no IP" según IEEE 802.3 (capa 2);

– limitación del ancho de banda;

– reglas globales del cortafuegos.

Todos los nodos de la red que se encuentran en el segmento interno de red de un CP 1543-1 están protegidos por su cortafuegos.

● Registro de datos

Para la vigilancia, los eventos se pueden guardar en archivos de registro que se pueden leer con ayuda de la herramienta de configuración o enviar de forma automática a un servidor Syslog.

● HTTPS

Para la transferencia cifrada de páginas web, p. ej., en el control de procesos.

● FTPS (modo explícito)

Para la transferencia cifrada de archivos.

● NTP seguro

Para la sincronización y transferencia horarias seguras.

● SNMPv3

Para la transferencia a prueba de espionaje de datos de análisis de red.

Industrial Ethernet Security con CP 1543-1


● Grupos VPN Mediante configuración, puede agruparse el CP 1543-1 con otros módulos de seguridad para formar grupos VPN. Entre todos los módulos de seguridad de un grupo VPN se establecen túneles IPsec (VPN). Todos los nodos internos de estos módulos de seguridad pueden comunicarse entre sí de manera segura a través de estos túneles.

● Protección para equipos y segmentos de red

Las funciones de protección del cortafuegos y los grupos VPN pueden extenderse a equipos individuales, varios equipos o incluso segmentos de red completos.

Información adicional Encontrará una sinopsis con enlaces a los artículos más importantes sobre Industrial Security en esta FAQ (https://support.industry.siemens.com/cs/ww/es/view/92651441).


Industrial Ethernet Security con CP 1543-1 13.1 Cortafuegos


13.1 Cortafuegos

Funciones del cortafuegos La función del cortafuegos es proteger las redes y estaciones de intromisiones externas y fallos. Para ello, solo se permiten determinadas relaciones de comunicación definidas previamente.

Para filtrar el tráfico de datos pueden utilizarse, por ejemplo, direcciones IPv4, subredes IPv4, números de puerto o direcciones MAC.

La funcionalidad de cortafuegos puede configurarse para los siguientes niveles de protocolo:

● cortafuegos IP con Stateful Packet Inspection (capa 3 y 4);

● cortafuegos también para telegramas Ethernet "no IP" según IEEE 802.3 (capa 2).

Reglas del cortafuegos Las reglas del cortafuegos describen qué paquetes se permiten o no en qué sentido.

13.2 Registro de datos

Funcionalidad El módulo de seguridad dispone de funciones de diagnóstico y registro de datos para vigilancia y pruebas.

● Funciones de diagnóstico

A continuación se describen distintas funciones de sistema y estado que se pueden utilizar en el modo online.

● Funciones de registro de datos

Consiste en el registro de eventos del sistema y de seguridad. El registro se realiza, según el tipo de evento, en búferes locales volátiles o permanentes del CP 1543-1. De forma alternativa, el registro también se puede realizar en un servidor de red.

La parametrización y evaluación de estas funciones requiere una conexión de red.

Industrial Ethernet Security con CP 1543-1 13.3 Cliente NTP


Registrar eventos con funciones de registro de datos Los ajustes de registro permiten definir qué eventos deben registrarse. Pueden configurarse las siguientes variantes de registro:

● Registro de datos local

Los eventos se registran en búferes locales del CP 1543-1. En el cuadro de diálogo online de la Security Configuration Tool se puede acceder a estos registros, hacerlos visibles y archivarlos en la Service Station.

● Syslog de red

En el Syslog de red se utiliza un servidor Syslog existente en la red. Este servidor registra los eventos según la configuración de los ajustes de registro.

13.3 Cliente NTP

Funcionalidad La fecha y la hora se registran en el CP 1543-1, al igual que en la CPU, para comprobar la vigencia de un certificado y para el sellado de tiempo de las entradas del registro. Esta hora se puede sincronizar mediante NTP. El CP 1543-1 transmite la hora sincronizada a la CPU a través del bus de fondo del sistema de automatización. De este modo, la CPU obtiene también una hora sincronizada para los eventos de tiempo en el procesamiento del programa de usuario.

El ajuste automático y la sincronización periódica de la hora se realizan mediante un servidor NTP seguro o no seguro. Al CP 1543-1 se le pueden asignar como máximo 4 servidores NTP. No es posible una configuración que combine servidores NTP seguros y no seguros.

Industrial Ethernet Security con CP 1543-1 13.4 SNMP


13.4 SNMP

Funcionalidad El CP 1543-1 soporta, al igual que la CPU, la transferencia de información de gestión a través del Simple Network Management Protocol (SNMP). Para ello, se ha instalado en el CP/la CPU un "SNMP-Agent" que recibe y responde las peticiones SNMP. La información sobre las propiedades de los equipos aptos para SNMP se almacena en los denominados "archivos MIB" (Management Information Base), para los que el usuario debe tener los derechos necesarios.

Con SNMPv1 también se transmite la "Community String". La "Community String" es como una contraseña que se envía junto con la petición SNMP. Si la "Community String" es correcta, se envía la información solicitada. Si la String es incorrecta, se descarta la petición.

Con SNMPv3 los datos pueden transferirse encriptados. Para ello, seleccione bien un procedimiento de autenticación, bien uno de autenticación y encriptación.

Posible selección:

● Algoritmo de autenticación: ninguno, MD5, SHA-1

● Algoritmo de encriptación: ninguno, AES-128, DES

Puede desactivar el uso de SNMP para el CP/la CPU. Desactive SNMP si las normas de seguridad de su red no admiten SNMP o si utiliza una solución de SNMP propia.

Encontrará información sobre cómo desactivar SNMP para la CPU en el capítulo Desactivar SNMP (Página 58).

13.5 VPN

Funcionalidad Para los módulos de seguridad que protegen la red interna, los túneles VPN (Virtual Private Network) ofrecen una conexión de datos segura a través de la red externa insegura.

El módulo de seguridad utiliza el protocolo IPsec (modo túnel de IPsec) para la formación de túneles.

En STEP 7 pueden asignarse módulos de seguridad a grupos VPN. Entre todos los módulos de un grupo VPN se forman automáticamente túneles VPN. Un módulo de un proyecto puede pertenecer paralelamente a varios grupos VPN distintos.


Glosario

Acoplamiento punto a punto Intercambio de datos bidireccional entre exactamente dos interlocutores a través de módulos de comunicación con interfaz serie.

Aparatos de campo → Dispositivo

Bus Medio de transmisión que interconecta varias estaciones. Los datos se pueden transferir eléctricamente o a través de un cable de fibra óptica, en ambos casos tanto en serie como en paralelo.

Certificado de CA intermedio Es el certificado de una entidad emisora que está firmado con la clave privada de una entidad emisora raíz.

Dicha entidad emisora intermedia firma con su clave privada los certificados de entidad final.

La firma de estos certificados de entidad final se comprueba con la clave pública de la entidad emisora intermedia.

Los atributos "Solicitante" y "Emisor" del certificado de CA intermedio no pueden ser idénticos: La entidad emisora no ha autofirmado el certificado.

En el campo "CA" debe poner "True".

Certificado de CA raíz → Ver también Certificado raíz

Certificado de entidad final → Ver también Certificado de dispositivo

Glosario


Certificado raíz Es el certificado de una entidad emisora: la entidad firma con su clave privada los certificados de entidad final y los certificados CA intermedios.

Los atributos "Solicitante" y "Emisor" de este certificado deben ser idénticos: la entidad emisora ha autofirmado el certificado.

En el campo "CA" debe poner "True".

El TIA Portal V14 posee un certificado de CA raíz:

Al configurar en el TIA Portal el servidor OPC UA de un S7-1500, el TIA Portal genera para el servidor OPC UA un certificado de entidad final y lo firma con su propia clave privada.

La firma de ese certificado de entidad final puede verificarse con la clave pública del TIA Portal. Esta clave está incluida en el certificado de CA raíz del TIA Portal.

Certificados autofirmados Son certificados que cada usuario firma con su clave privada y que se utilizan como certificados de entidad final.

La firma de estos certificados se comprueba con la clave pública de cada usuario.

Los atributos "Solicitante" y "Emisor" de los certificados autofirmados deben ser idénticos: El titular ha autofirmado su certificado.

En el campo "CA" debe poner "False".

Los certificados autofirmados se pueden utilizar, por ejemplo, como certificados de aplicación para un cliente OPC UA.

La creación de un certificado autofirmado con el generador de certificados de la OPC Foundation se describe aquí (Página ).

Certificados de dispositivos Estos certificados son firmados por una entidad emisora (CA).

La firma de un certificado de entidad final se comprueba con la clave pública del certificado de la entidad emisora.

Los atributos "Solicitante" y "Emisor" no pueden ser idénticos.

En "Solicitante" figura, por ejemplo, el nombre de un programa, como sucede en el certificado de aplicación OPC UA.

En "Emisor" está la entidad emisora que ha firmado el certificado.

En el campo "CA" debe poner "False".

Cliente Estación de una red que solicita un servicio a otra estación de la red (servidor).

Glosario


CM → Módulo de comunicaciones

Controlador IO, controlador PROFINET IO Aparato central de un sistema PROFINET, por lo general un autómata programable convencional o un PC. El controlador IO crea conexiones a los dispositivos IO, intercambia datos con ellos y, por lo tanto, controla el sistema.

CP → Procesador de comunicaciones

CPU Central Processing Unit = módulo central del sistema de automatización S7 con unidad de control y cálculo, memoria, sistema operativo e interfaz para la programadora.

Datos coherentes Datos cuyo contenido está interrelacionado, siendo inseparables al transferirlos.

Dirección IP Número binario utilizado como dirección unívoca en redes de ordenadores de acuerdo con el protocolo de Internet (IP). Permite direccionar los dispositivos unívocamente y acceder a ellos individualmente. Una dirección IPv4 puede evaluarse mediante una máscara de subred binaria que define qué parte se refiere a la red y qué parte al host. La representación textual de una dirección IPv4 guardada consiste, por ejemplo, en 4 números decimales comprendidos en un rango entre 0 y 255. Los números decimales están separados por un punto.

Dirección MAC Identificación unívoca en el mundo para todos los dispositivos Ethernet. La dirección MAC viene asignada por el fabricante y tiene 3 bytes para la identificación del fabricante y 3 bytes para la identificación del dispositivo como número correlativo.

Dirección PROFIBUS Identificación unívoca de un dispositivo conectado a PROFIBUS. Para direccionar un dispositivo se transfiere la dirección PROFIBUS en la trama o telegrama.

Glosario


Dispositivo Término genérico para:

● Sistemas de automatización (p. ej., PLC, PC)

● Sistemas de periferia descentralizada

● Aparatos de campo (p. ej., PLC, PC, aparatos hidráulicos y neumáticos) y

● Componentes de red activos (p. ej., switches, routers)

● Pasarelas a PROFIBUS, AS-Interface o a otros sistemas en bus de campo

Dispositivo IO, dispositivo PROFINET IO Dispositivo de la periferia descentralizada de un sistema PROFINET que se controla desde un controlador IO (p. ej., entradas/salidas descentralizadas, islas de válvulas, convertidores de frecuencia, switches).

Dispositivo PROFIBUS Dispositivo con al menos una interfaz PROFIBUS, ya sea eléctrica (p. ej., RS485) u óptica (p. ej., fibra óptica de polímero).

Dispositivo PROFINET Dispositivo que siempre dispone de una interfaz PROFINET (eléctrica, óptica, inalámbrica).

Dúplex Método de transferencia de datos; se distingue entre método dúplex y semidúplex.

Semidúplex: se dispone de un canal para un intercambio de datos alternante (envío y recepción alternantes, en un sentido respectivamente).

Dúplex: se dispone de dos canales para un intercambio de datos simultáneo en ambos sentidos (envío y recepción simultáneos en ambos sentidos).

Esclavo Dispositivo descentralizado de un sistema de bus de campo que solo puede intercambiar datos con un maestro tras solicitarlo este.

→ Ver también Esclavo DP

Esclavo DP Esclavo de la periferia descentralizada que funciona en PROFIBUS con el protocolo PROFIBUS DP y que se comporta según la norma EN 50170, parte 3.

→ Ver también Maestro DP

Glosario


Ethernet Tecnología estándar internacional para redes locales (LAN) basada en frames. Define tipos de cable y señalización para el nivel físico, así como formatos de paquete y protocolos para el control de acceso al medio.

FETCH/WRITE Servicios de servidor vía TCP/IP, ISO-on-TCP e ISO para el acceso a áreas de memoria de sistema de CPU S7. El acceso (función de cliente) es posible desde un SIMATIC S5 o un equipo de terceros/PC. FETCH: lectura directa de datos; WRITE: escritura directa de datos.

Freeport Protocolo ASCII programable; en este caso para la transferencia de datos mediante acoplamiento punto a punto.

FTP File Transfer Protocol o protocolo de transferencia de archivos; un protocolo de red para la transferencia de archivos vía redes IP. FTP se utiliza para descargar archivos del servidor al cliente o para cargarlos desde el cliente al servidor. Asimismo, el protocolo FTP permite crear y leer directorios, borrar directorios y archivos, o cambiarles el nombre.

HMI Human Machine Interface o interfaz hombre-máquina, dispositivo para la visualización y el control de procesos de automatización.

IE → Industrial Ethernet

IM → Módulo de interfaz

Imagen de proceso Rango de direcciones de un autómata programable (PLC) en el que están guardados los estados de señal de las entradas y los estados lógicos de las salidas de los módulos conectados.

Industrial Ethernet Directiva para configurar redes Ethernet en entornos industriales. En comparación con el estándar Ethernet, la principal diferencia radica en la solicitación mecánica y en la inmunidad contra perturbaciones de los distintos componentes.

Glosario


Instrucción La unidad independiente más pequeña de un programa de usuario, caracterizada por su estructura, función o uso previsto como parte acotada del programa de usuario. La instrucción representa una orden de trabajo para el procesador.

Interfaz PROFINET Interfaz de un módulo apto para comunicación (p. ej., CPU, CP) con uno o varios puertos. A la interfaz se le asigna ya de fábrica una dirección MAC. Junto con la dirección IP y el nombre del dispositivo (tomados de la configuración individual), esta dirección de la interfaz garantiza una identificación unívoca del dispositivo PROFINET en la red. La interfaz puede ser eléctrica, óptica o inalámbrica.

Maestro Dispositivo de nivel superior activo en la comunicación o la subred PROFIBUS. Si el maestro posee derechos de acceso al bus (token o testigo), puede solicitar y enviar datos.

→ Ver también Maestro DP

Maestro DP En PROFIBUS DP, maestro de la periferia descentralizada que se comporta según la norma EN 50170, parte 3.

→ Ver también Esclavo DP

Máscara de subred IPv4 Máscara binaria con la que se divide una dirección IPv4 (como número binario) en una "parte de red" y una "parte de host".

Modbus RTU Remote Terminal Unit; protocolo de comunicación abierto para interfaces serie basado en una arquitectura maestro/esclavo.

Modbus TCP Transmission Control Protocol; protocolo de comunicación abierto para Ethernet basado en una arquitectura maestro/esclavo. Los datos se transfieren como paquetes TCP/IP.

Módulo de comunicaciones Módulo para tareas de comunicación que se utiliza en un sistema de automatización como ampliación de la interfaz de la CPU (p. ej., PROFIBUS) o que ofrece opciones de comunicación adicionales (PtP).

Glosario


Módulo de interfaz Módulo del sistema de periferia descentralizada. El módulo de interfaz conecta el sistema de periferia descentralizada con la CPU (controlador IO/maestro DP) a través de un bus de campo y procesa los datos destinados a los módulos de periferia.

NTP El Network Time Protocol (NTP) es un estándar para la sincronización de relojes en sistemas de automatización vía Industrial Ethernet. NTP utiliza el protocolo de transporte sin conexión UDP para Internet.

OPC UA OPC Unified Automation es un protocolo para la comunicación entre máquinas, desarrollado por la OPC Foundation.

Organización de usuarios de PROFIBUS Comité técnico que define y desarrolla los estándares PROFIBUS y PROFINET.

PG → Programadora

PNO → Organización de usuarios de PROFIBUS

Procesador de comunicaciones Módulo para tareas de comunicación avanzadas que cubre casos de aplicación especiales, p. ej., en el ámbito Security.

PROFIBUS Process Field Bus - norma europea de bus de campo.

PROFIBUS DP Un PROFIBUS con el protocolo DP que se comporta de acuerdo con la norma EN 50170. DP es la abreviatura alemana de Periferia Descentralizada (rápida, apta para tiempo real, intercambio cíclico de datos). Desde el punto de vista del programa de usuario, la periferia descentralizada se direcciona del mismo modo que la periferia centralizada.

Glosario


PROFINET Sistema de comunicación industrial abierto basado en componentes sobre la base de Ethernet para sistemas de automatización distribuidos. Tecnología de comunicación fomentada por la organización de usuarios de PROFIBUS.

PROFINET IO IO es la abreviatura de Input/Output (entrada/salida); periferia descentralizada (rápida, apta para tiempo real, intercambio cíclico de datos). Desde el punto de vista del programa de usuario, la periferia descentralizada se direcciona del mismo modo que la periferia centralizada.

Así pues, PROFINET IO, entendido como un estándar de automatización basado en Ethernet de PROFIBUS & PROFINET International, define un modelo de comunicación, automatización e ingeniería no propietario.

Con PROFINET IO se aplica una tecnología de conmutación que permite a cualquier dispositivo acceder a la red en todo momento. Así, la red permite un uso mucho más efectivo gracias a la transmisión de datos simultánea de varias estaciones. El modo dúplex del sistema Switched Ethernet permite transmitir y recibir simultáneamente.

PROFINET IO se basa en Switched Ethernet con modo dúplex y un ancho de banda de 100 Mbits/s.

Programa de usuario En SIMATIC se hace distinción entre el sistema operativo de la CPU y los programas de usuario. El programa de usuario contiene todas las instrucciones, declaraciones y datos que permiten controlar una instalación o un proceso. El programa de usuario está asignado a un módulo programable (p. ej., CPU, FM) y se puede dividir en unidades más pequeñas.

Programadora Las programadoras son esencialmente PC aptos para aplicaciones industriales, compactas y portátiles. Se caracterizan por su equipamiento hardware y software especialmente apropiado para autómatas programables.

Protocolo Estándar conforme a cuyas reglas se establece la comunicación entre dos o más interlocutores.

Protocolo ISO Protocolo de comunicación para la transferencia de datos orientada a mensajes o paquetes en Ethernet. Este protocolo está orientado al hardware, es muy rápido y admite longitudes de datos dinámicas. El protocolo ISO está especialmente indicado para volúmenes de datos medianos y grandes.

Glosario


Protocolo ISO-on-TCP Protocolo de comunicación apto para routing S7 para la transferencia de datos orientada a paquetes en Ethernet; ofrece direccionamiento de red. El protocolo ISO-on-TCP está indicado para volúmenes de datos medianos y grandes, y admite longitudes de datos dinámicas.

PtP Point-to-Point o punto a punto; interfaz o protocolo de transferencia para el intercambio de datos bidireccional entre exactamente dos interlocutores.

Puerto Posibilidad de conexión física de dispositivos de la red PROFINET. Las interfaces PROFINET disponen de uno o varios puertos.

Red Una red se compone de una o varias subredes enlazadas con cualquier número de estaciones. Puede haber varias redes paralelamente.

Router Nodo de red con identificación unívoca (nombre y dirección) que interconecta subredes y transfiere datos a estaciones de la red identificadas unívocamente.

Routing S7 Comunicación entre sistemas de automatización S7, aplicaciones S7 o estaciones PC en distintas subredes S7 a través de uno o varios nodos de red que actúan como routers S7.

RS232, RS422 y RS485 Estándar para interfaces serie.

RTU Modbus RTU (RTU: Remote Terminal Unit o unidad terminal remota) transfiere los datos en formato binario; permite transferir un volumen de datos considerable. Los datos deben convertirse a un formato legible antes de poder evaluarse.

Glosario


Security (seguridad informática) Término genérico para todas las medidas de protección contra

● pérdida de confidencialidad debido al acceso no autorizado a los datos

● pérdida de integridad por manipulación de los datos

● pérdida de disponibilidad por destrucción de los datos

Servicio SDA Send Data with Acknowledge o envío de datos con confirmación. SDA es un servicio básico que permite que un iniciador (p. ej., maestro DP) envíe un mensaje a otra estación y a cambio reciba inmediatamente un acuse de recibo.

Servicio SDN Send Data with No Acknowledge o envío de datos sin confirmación. Este servicio se utiliza sobre todo para enviar datos a varias estaciones, por lo que no obtiene confirmación. Indicado para tareas de sincronización y avisos de estado.

Servidor Un dispositivo o, por lo general, cualquier objeto capaz de llevar a cabo determinados servicios, que se realizan a partir de la solicitud de un cliente.

Servidor web Software/servicio de comunicación para el intercambio de datos a través de Internet. El servidor web transfiere los documentos a un navegador web a través de protocolos de transferencia estandarizados (HTTP, HTTPS). Los documentos pueden ser estáticos o puede componerlos el servidor web de forma dinámica a partir de distintas fuentes tras solicitarlo el navegador web.

Sincronización de la hora Capacidad para transferir una hora de sistema estándar desde una fuente individual a todos los dispositivos del sistema, de modo que sus relojes se puedan ajustar en función de la hora estándar.

Sistema de automatización Autómata programable que permite regular y controlar cadenas de proceso en las industrias de procesos y la producción. Los componentes y funciones integradas del sistema de automatización varían en función de la tarea de automatización.

Glosario


Sistema operativo Software que permite el uso y el funcionamiento de un ordenador. El sistema operativo administra recursos como la memoria o los dispositivos de entrada y salida, y controla la ejecución de programas.

SNMP Simple Network Management Protocol o protocolo simple de administración de red; utiliza el protocolo de transporte UDP sin conexión. SNMP funciona de forma similar al modelo cliente/servidor. El administrador SNMP vigila los nodos de la red. Los agentes SNMP recopilan en los diversos nodos la información específica de la red y la hacen accesible y controlable de forma estructurada en la MIB (Management Information Base). Con esta información, un sistema de administración de red puede realizar un diagnóstico detallado de la red.

Subred Parte de una red cuyos parámetros deben sincronizarse en sus estaciones (p. ej., en PROFINET). Una subred abarca todos los componentes de bus y todas las estaciones conectadas. Las subredes pueden acoplarse a una red, por ejemplo, mediante pasarelas o routers.

Switch Componente de red para conectar varios terminales o segmentos de red en una red local (LAN).

Tarjeta de red Ethernet Circuito electrónico para conectar un ordenador a una red Ethernet. Permite el intercambio de datos/la comunicación dentro de una red.

TCP/IP Transmission Control Protocol/Internet Protocol, protocolo de red orientado a la conexión; estándar de validez general para el intercambio de datos en redes heterogéneas.

Topología en anillo Todas las estaciones de una red están conectadas en forma de anillo.

Topología en árbol Topología de red caracterizada por una estructura ramificada: a cada estación de bus se conectan dos o más estaciones de bus.

Glosario


Topología en línea Topología de red caracterizada por la disposición de las estaciones de bus en línea.

Twisted Pair Fast Ethernet con cables de par trenzado se basa en el estándar IEEE 802.3u (100 Base-TX). El medio de transmisión es un cable de 2x2 hilos, trenzado y apantallado con una impedancia de 100 ohmios (AWG 22). Las características de transmisión de este cable tienen que cumplir las exigencias de la categoría 5.

La longitud máxima de la conexión entre el terminal y el componente de red no puede ser superior a 100 m. Las conexiones se realizan según el estándar 100 Base-TX con el sistema de conexión RJ45.

UDP User-Datagram-Protocol o protocolo de datagrama de usuario; protocolo de comunicación para la transferencia de datos rápida y sencilla, sin confirmación. Se prescinde de mecanismos de seguridad como los presentes en TCP/IP.

USS Protocolo de interfaz serie universal; define un procedimiento de acceso de acuerdo con el principio maestro-esclavo para la comunicación a través de un bus serie.


Índice alfabético

A Acoplamiento punto a punto, 20, 128 Advanced Encryption Algorithm, 39 AES, 39 Archivo de exportación para OPC UA, 170 Asignación de recursos de conexión, 249 Ataque Man-In-The-Middle, 42

B BRCV, 119 BSEND, 119

C Certificado de entidad final, 45 Certificado de servidor, 187 Certificado raíz, 45 Certificados autofirmados, 42 Certificados digitales, 42 Cifrado asimétrico, 39 Cifrado simétrico, 39 cliente OPC UA

Principios básicos, 149 Cliente OPC UA

Certificado, 184 CM, 15 Coherencia de datos, 33, 33 Comunicación

Acoplamiento punto a punto, 128 Comunicación abierta, 67 Comunicación HMI, 65 Comunicación PG, 62 Comunicación S7, 118 Establecer y deshacer, 94 Open User Communication, 67 Protocolos de comunicación, 68 Routing de juegos de datos, 240 Routing S7, 235

Comunicación a través de la instrucción PUT/GET Crear y parametrizar la conexión, 120

Comunicación abierta Configurar correo electrónico, 90 Configurar FTP, 91

Parametrización de la conexión, 77 TCP, ISO-on-TCP, UDP, configurar, 77

Comunicación HMI, 20, 65 Comunicación PG, 20, 62 Comunicación S7, 20, 118, 248 Conexión

Diagnóstico, 254 Instrucciones para Open User Communication, 70

Correo electrónico, 20, 69, 90 Cortafuegos, 260 CP, 15 Crear una conexión, 29

Conexión ISO con CP 1543-1, 83 Por configuración, 81

D Diagnóstico de conexión, 254

E Entidades emisoras, 42 Establecimiento y desconexión de una comunicación, 94

F FDL, 69 Fetch, 20 Firma, 43 FTP, 20, 69, 90, 91

G GET, 119

H Handshake Protocol, 41

I IM, 19 Industrial Ethernet Security, 258 Interfaces de comunicación, 16

Índice alfabético


Interfaces de módulos de comunicaciones Acoplamiento punto a punto, 18

Interfaces de procesadores de comunicación, 17 ISO, 20, 68 ISO-on-TCP, 68, 77

M Medidas de seguridad, 258

Cortafuegos, 260 NTP, 261 Registro de datos, 260 SNMP, 262

Modbus TCP, 69 Módulo de comunicaciones, 15 Módulo de interfaz, 19

N NTP, 20, 261

O OPC UA

Ajustes de seguridad, 145 Certificados X.509, 157 Conexión segura, 162 Espacio de nombres, 139 Firma y cifrado, 155 Generador de certificados, 158 Identificador, 139 Introducción, 134, 135, 137 Mecanismos de seguridad, 153 Modelo de capas, 163 OpenSSL, 159 Puntos finales, 145 Secure Channel (canal seguro), 162 Variables DB, 166 Variables PLC, 166

Opciones de comunicación Resumen, 20

Open User Communication Características, 67 Instrucciones, 70 Protocolos, 68

OpenSSL, 159

P PCT, 240

Private Key, 37 Procedimiento 3964(R), 128 Procesador de comunicaciones, 15 Protocolo Freeport, 128 Protocolo Modbus (RTU), 128 Protocolo USS, 128 Protocolos para Open User Communication, 68 Public Key, 37 PUT, 119

R Record Protocol, 41 Recursos de conexión

Asignar, 249 Comunicación HMI, 247 Específicos de la estación, 250 Específicos del módulo, 251 Indicación en STEP 7, 250 Resumen, 28 Routing de juegos de datos (registros), 248 Routing S7, 248 Sinopsis, 242 Visualización en el servidor web, 253

Registro de datos, 260 RFC 5280, 37 Routing de juegos de datos, 240 Routing S7, 235

Recursos de conexión, 248

S Secure communication, 37 Secure Socket Layer, 41 Security, 258 Servicios de comunicación

Recursos de conexión, 28 Servidor OPC UA

Adaptar certificado de servidor, 187 Ajustes de seguridad, 182 Archivo de exportación XML, 170 Área de direcciones, 141 Aumento del rendimiento, 169 Autenticación, 190 Derechos de escritura y lectura, 166 Direccionamiento, 173 Generar certificado de servidor, 179 Intervalo de envío, 177 Intervalo de muestreo, 178 Licencias runtime, 193 Nombre de aplicación, 172

Índice alfabético


Principios básicos, 137 Puerto TCP, 175, 177 Puesta en marcha, 171 Rendimiento, 169 Suscripción, 176

Servidor web, 20 Sincronización de la hora, 20 SNMP, 20, 262 Solicitante, 42 SSL, 41 Syslog, 261

T TCON, 70 TCP, 20, 68, 77 TDISCON, 70 Tipo de datos del sistema, 71 Titular del certificado, 42 TLS, 41 Transport Layer Security, 41 TRCV, 70 TRCV_C, 70 TSEND, 70 TSEND_C, 70

U UDP, 20, 68, 77 URCV, 119 USEND, 119

W Write, 20

X X.509, 37

ORGANIZATION_BLOCK "Startup" TITLE = "Complete Restart" { S7_Optimized_Access := 'TRUE' } VERSION : 0.1 BEGIN REPEAT "WRREC_DB_1" (REQ := "Deactivate SNMP".snmp_deactivate, //(Transfer data record) INDEX:=16#B071, //(Data record number for SNMP deactivation) ID:="Local~PROFINET_interface_1", //(any integrated PROFINET Interface) DONE => "Deactivate SNMP".snmp_done, ERROR => "Deactivate SNMP".snmp_error, STATUS => "Deactivate SNMP".snmp_status, RECORD := "Deactivate SNMP".snmp_record); //(Data record) UNTIL "Deactivate SNMP".snmp_done OR "Deactivate SNMP".snmp_error END_REPEAT;END_ORGANIZATION_BLOCK

DATA_BLOCK "WRREC_DB_1" {OriginalPartName := 'WRREC'; VersionGUID := 'bc169451-58cd-44a3-855b-3f78cc0623c8'; S7_Optimized_Access := 'TRUE' } AUTHOR : SIMATIC FAMILY : DP NAME : WRREC VERSION : 1.0 NON_RETAIN WRREC BEGINEND_DATA_BLOCK

DATA_BLOCK "Deactivate SNMP" { S7_Optimized_Access := 'TRUE' } VERSION : 0.1 NON_RETAIN VAR RETAIN snmp_deactivate : Bool; //(Tag for deactivation) snmp_record : Struct BlockID : UInt; BlockLenght : UInt; "Version" : USInt; Subversion : USInt; Reserved : UInt; SNMPControl : UDInt; END_STRUCT; END_VAR VAR snmp_done : Bool; snmp_error : Bool; snmp_status : DWord; END_VAR BEGIN snmp_deactivate := true; snmp_record.BlockID := 16#F003; snmp_record.BlockLenght := 8; snmp_record."Version" := 1; snmp_record.Subversion := 0; snmp_record.SNMPControl := 0;

END_DATA_BLOCK

comunicación - siemens ag · industrial ethernet security con cp 1543-1 13 . siemens ag division...

Documents