Comunicación OPC UA
10.3 Uso de la CPU S7-1500 como servidor OPC UA
Principio
La figura siguiente muestra de forma simplificada el proceso de almacenamiento temporal de
avisos ProgramAlarms para volver a proporcionarlos posteriormente al sistema OPC UA
Alarms and Conditions. Los nodos indicados en la leyenda de la figura son visibles en la figura
subsiguiente del modelo de direcciones.
①
El número de avisos activos es demasiado alto como para que todos los avisos sean accesibles mediante OPC UA
Alarms and Conditions.
②
Se dispara un aviso de sobrecarga (Overloads Alarm). Este aviso de sobrecarga permanece activo hasta que se da la
situación siguiente:
•
No hay más alarmas presentes para el sistema OPC UA Alarms and Conditions (OutstandingProgramAlarms = 0)
y
•
El número de alarmas en el sistema OPC UA Alarms and Conditions < valor máximo depurado por la histéresis
para alarmas OPC UA (= MaxAlarmsInQueue - OverloadHysteresis)
Los avisos que no existen en el sistema OPC UA Alarms and Conditions debido a una situación de sobrecarga son al
macenados temporalmente por la CPU como "OutstandingAlarms".
③
Cuando un cliente OPC UA ejecuta el método ConditionRefresh, no solo se sincronizan todos los objetos de alarma
de la suscripción afectada, sino que también se transfieren los avisos presentes para OPC UA Alarms and Conditions
(OutstandingAlarms) al área de memoria Alarms and Conditions, hasta que se alcanza el número máximo de alar
mas. Las alarmas "más antiguas" se transfieren en primer lugar. A continuación, cada suscripción a estas alarmas
recibe las alarmas transferidas, no solo el cliente OPC UA que ha llamado el método ConditionRefresh.
④
El cliente OPC UA controla el tratamiento de los avisos presentes utilizando la información de los nodos de sobre
carga.
302
Manual de funciones, 11/2022, A5E03735817-AK
Comunicación