C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

Cómo solucionar el error de WinCC al abrir el proyecto: No especificado en clientes OS

El error 'Error while opening the project: Unspecified' en SIMATIC WinCC V7.5 SP2 y clientes OS de PCS 7 V9.1 ocurre cuando la estación cliente no puede establecer una conexión autenticada con Microsoft SQL Server, adjuntar la base de datos de runtime del proyecto remoto (*.mdf), o resolver recursos compartidos de red Server Message Block (SMB). En entornos de dominio multiusuario que ejecutan Windows Server 2019 y Windows 10, este fallo intermitente es provocado principalmente por servicios de SQL Server Browser detenidos, búsquedas inversas de DNS asimétricas en Active Directory, o la administración de energía de Windows que pone las tarjetas de interfaz de red del cliente en modo de suspensión. Para resolver este error sin reiniciar el servidor, verifique la administración de energía del adaptador de red, confirme la resolución de nombres bidireccional, reinicie los servicios SQL Server (WINCC) y SQL Server Browser, y regenere los archivos de enlace de la base de datos del cliente.

Índice de contenidos

Análisis de causa raíz: por qué los clientes OS fallan con el 'Error no especificado'

En una arquitectura de cliente-servidor multiusuario de PCS 7, un cliente OS no ejecuta una base de datos de control de procesos independiente. Cuando un operador abre un proyecto de cliente (*.mcp), WinCC inicia una secuencia de inicialización compleja:
1. Descubrimiento de red: El cliente utiliza Simatic Shell para verificar la disponibilidad del servidor a través del puerto UDP 5227.
2. Compartición de archivos (SMB): El cliente se conecta al directorio de proyecto compartido del servidor (<ProjectName>.WinCC).
3. Conexión a la base de datos: El cliente se comunica con la instancia de Microsoft SQL Server en el servidor (WINCC) a través del puerto TCP 1433 y SQL Browser (puerto UDP 1434) para consultar los históricos de runtime y las variables de proceso.

Si se rompe cualquier enlace en esta cadena de autenticación y red, el motor de inicialización del runtime del cliente WinCC (CCClient.exe) genera una excepción genérica:
Error while opening the project: Unspecified.

Discrepancias en el dominio de Active Directory y resolución DNS

En las instalaciones industriales modernas gobernadas por controladores de dominio de Active Directory, la latencia en la resolución de nombres es la causa más común de desconexiones intermitentes de los clientes:
* Búsqueda directa vs. inversa: Los componentes de WinCC exigen estrictamente que la resolución DNS directa (nslookup OS_SERVER1) y la resolución DNS inversa (nslookup 192.168.1.10) devuelvan nombres de dominio completos (FQDN) y nombres de host NetBIOS idénticos y que no distingan entre mayúsculas y minúsculas.
* Caché y limpieza DNS (Scavenging): Si el servidor DNS del dominio experimenta retrasos de replicación, o si las reglas de firewall entre el bus de terminal y los controladores de dominio corporativos bloquean las actualizaciones dinámicas de DNS, las búsquedas inversas agotan su tiempo de espera.
* Bloqueo de Simatic Shell: Cuando falla una búsqueda inversa, Simatic Shell no puede verificar que el cliente entrante pertenece al grupo autorizado de Windows SIMATIC HMI, lo que bloquea al cliente y provoca el error de apertura 'Unspecified'.

Administración de energía del adaptador de red y Ethernet de bajo consumo (EEE)

Un problema muyextendido en los clientes OS con Windows 10 es la configuración predeterminada de ahorro de energía del sistema operativo para las tarjetas de interfaz de red (NIC) comerciales:
* Ethernet de bajo consumo (EEE): Las NIC Gigabit modernas de Intel y Realtek cuentan con estados de ahorro de energía (Green Ethernet / EEE). Durante los periodos de inactividad (como por la noche o con baja actividad del operador), Windows reduce la energía del enlace o entra en estados de suspensión de bajo consumo.
* Corte de sockets: Cuando la energía del enlace fluctúa, la conexión de socket TCP persistente entre el cliente y Microsoft SQL Server en el servidor OS se cae sin un paquete TCP FIN limpio.
* Bloqueos fantasma: En el servidor, SQL Server retiene el bloqueo de sesión del cliente. Cuando el operador intenta reiniciar el cliente, SQL Server rechaza la nueva sesión porque la conexión antigua todavía se marca como activa, produciendo el error 'Unspecified' hasta que se reinicia el servidor.

Método: Procedimiento de diagnóstico y recuperación paso a paso

Para resolver permanentemente las desconexiones intermitentes de los clientes y recuperarse del error 'Unspecified' sin reiniciar el servidor:

Paso 1: Deshabilitar la administración de energía del adaptador de red (todos los clientes)

  1. En cada cliente OS con Windows 10, haga clic derecho en el menú Inicio y seleccione Administrador de dispositivos.
  2. Expanda Adaptadores de red, haga clic derecho en la NIC del bus de terminal y seleccione Propiedades.
  3. En la pestaña Administración de energía:
    - Desmarque Permitir que el equipo apague este dispositivo para ahorrar energía.
  4. En la pestaña Opciones avanzadas:
    - Deshabilite Energy Efficient Ethernet, Green Ethernet y Gigabit Lite.
    - Establezca Energy Saving Mode en Deshabilitado (Disabled).

Paso 2: Verificar y reiniciar los servicios SQL del servidor

En lugar de reiniciar el servidor OS de producción, reinicie los daemons de comunicación específicos de WinCC:
1. En el servidor OS, abra services.msc.
2. Localice e inspeccione los siguientes servicios:
- SQL Server (WINCC): Debe estar En ejecución (Automático).
- SQL Server Browser: Debe estar En ejecución (Automático).
3. Si las conexiones de los clientes están bloqueadas, haga clic derecho en SQL Server Browser y seleccione Reiniciar.
4. Asegúrese de que los servicios de Windows Workstation y Server (compartición de archivos SMB) funcionen normalmente.

Paso 3: Forzar la resolución de nombres local LMHOSTS

Para evitar que los tiempos de espera del DNS del dominio bloqueen Simatic Shell:
1. En todos los servidores y clientes, abra C:\Windows\System32\drivers\etc\hosts y lmhosts con privilegios de administrador.
2. Agregue entradas estáticas de IP y nombre de host para todos los servidores, socios redundantes y clientes:
text 192.168.1.10 OS_SRV1 #PRE 192.168.1.11 OS_SRV2 #PRE 192.168.1.20 OS_CLI1 #PRE
3. Abra un símbolo del sistema y ejecute nbtstat -R para purgar y recargar la caché NetBIOS.

Paso 4: Regenerar la caché de enlaces del proyecto de cliente

Si un cliente específico permanece bloqueado:
1. En el cliente OS, cierre todas las aplicaciones de WinCC.
2. En el Explorador de Windows, navegue al directorio del proyecto del cliente local.
3. Localice y elimine el archivo <ProjectName>.dcf.
4. Vuelva a abrir WinCC Explorer y abra el proyecto. WinCC regenerará automáticamente un archivo de caché de base de datos .dcf limpio.

Verificación

Para verificar que la conexión del cliente multiusuario se ha restablecido por completo:

  1. Abra un símbolo del sistema en el cliente y ejecute:
    cmd ping OS_SRV1 -f -l 1472
    Confirme que no hay pérdida de paquetes y que la latencia es inferior a 1 ms sin fragmentación de paquetes.
  2. Abra Simatic Shell en el Explorador de Windows en el cliente. Verifique que todos los servidores OS aparezcan con iconos de computadora azules. Haga clic derecho en el proyecto del servidor y seleccione Abrir.
  3. Verifique que el proyecto del cliente se abra inmediatamente sin mostrar 'Error while opening the project: Unspecified'.
  4. Confirme que WinCC Graphics Runtime se active y muestre los valores de proceso en vivo.

Limitaciones y precauciones operativas

  • No reinicie el servidor activo durante la operación de la planta: Si bien reiniciar los servicios SQL resuelve los bloqueos de los clientes, reiniciar SQL Server (WINCC) en un servidor único activo interrumpirá la recolección de datos SCADA. En parejas de servidores redundantes, ejecute el mantenimiento de los servicios primero en el servidor en espera (standby).
  • Dependencias del controlador de dominio: Si el controlador de dominio de la red industrial falla o se reinicia, los tiques de autenticación de Kerberos caducan. Asegúrese de que los controladores de dominio primario y secundario estén implementados en la red industrial.
  • Bloqueos por actualizaciones de Windows: Asegúrese de que los clientes OS con Windows 10 no ejecuten actualizaciones en segundo plano sin control que restablezcan las propiedades del controlador del adaptador de red a los estados predeterminados de ahorro de energía.

Preguntas frecuentes del ingeniero

¿Por qué reiniciar el servidor OS siempre soluciona el problema temporalmente?
Reiniciar el servidor finaliza todos los bloqueos colgados de la base de datos de SQL Server, vacía las sesiones de red huérfanas y obliga al daemon de SQL Server Browser a volver a vincularse a las interfaces de red.

¿Puede una selección incorrecta del adaptador de red en Simatic Shell causar este error?
Sí. Si Simatic Shell en el servidor o en el cliente está vinculado al adaptador de red incorrecto (p. ej., una segunda NIC no utilizada o un adaptador virtual), el descubrimiento por difusión (broadcast) falla y desencadena el error.

¿Qué permisos de usuario se requieren para evitar este error?
Todos los usuarios del dominio que inicien sesión en los clientes WinCC deben ser miembros del grupo local SIMATIC HMI tanto en la PC cliente local como en el servidor OS remoto.

Referencias técnicas

  • Entrada de Siemens Industry Online Support ID 109742323: SIMATIC Process Control System PCS 7 OS Process Control Manual
  • Entrada de Siemens Industry Online Support ID 109809264: WinCC Client-Server Communication and Name Resolution Guidelines
  • Manual de comunicación de SIMATIC HMI WinCC V7.5 SP2 (N.º de documento 6AV6392-1CA07-5AA0)

Artículos relacionados

Etiquetas relacionadas

  • https://industrialautomation.net/search?query=simatic+wincc
  • https://industrialautomation.net/search?query=pcs7+v9.1
  • https://industrialautomation.net/search?query=client-server
  • https://industrialautomation.net/search?query=sql-server
20 respuestas