Recomendaciones para la carga de datos iniciales de medida

  • Cuando procese cargas útiles mediante implantaciones de middleware, mantenga el número de dispositivos en 1000 por fichero para que el procesamiento de consumo y eventos a través de Oracle Service Bus sea óptimo. Con un número inferior de dispositivos por fichero el procesamiento tardará más tiempo. Y, por otro lado, un número superior conllevará que haya más basura recopilada esperando y el rendimiento será más deficiente. Tenga en cuenta que el número óptimo de transacciones por fichero puede ser distinto según el sistema de recopilación de datos que se utilice.

  • Las cargas útiles de medidas iniciales deben tener criterios muy selectivos para llegar al componente de medición exacto. En una situación idónea, debería ser el identificador de componente de medición junto con el número de serie del dispositivo. Si no se proporciona, se utilizará la UM/discriminación horaria/identificador de cantidad de servicio configurados en el tipo de componente de medición para recuperar el objeto de negocio exacto del proveedor de servicios que podría tener los mismos valores para varios canales.

  • También se reduce el rendimiento general cuando se rellena la sección de datos sin procesar del registro de datos iniciales de medida. Siempre que sea posible, evite conservar datos “sin formato” en el procesamiento de carga útil de Smart Grid Gateway.

  • El procesamiento de carga útil, durante el que se cargan en el sistema los datos de consumo y eventos, debe ejecutarse de forma independiente del procesamiento de medidas, en el que se crea la validación, edición y estimación y las medidas finales. No ejecute estos procesos de forma simultánea.

  • Cargue las medidas iniciales y realice el procesamiento de validación, edición y estimación cada 4/6 horas para optimizar el rendimiento.

  • La duración de datos iniciales de medida individuales en una carga útil no puede ser menor que el tiempo transcurrido entre la recopilación y la entrega de la carga útil (con un mínimo de 4/6 horas por medida inicial). Por ejemplo, si el sistema recopila y entrega medidas tres veces al día, la duración de las medidas iniciales individuales debe ser, aproximadamente, de ocho horas.

  • Evite cargar un gran número de medidas iniciales para la configuración de un único dispositivo en una única carga útil.

  • Es recomendable configurar un proceso de supervisión en estado Pendiente para los objetos de negocio de medida inicial de carga, de forma que se puedan diferir los procesos de creación de validación, edición y estimación y medidas a un procesamiento por lotes.

    • El procesamiento diferido aporta las siguientes ventajas adicionales:

      1. Permite garantizar el procesamiento cronológico de lecturas escalares, lo que supone un procesamiento más eficiente. El procesamiento de lecturas escalares de forma desordenada puede suponer un trabajo adicional, ya que se crean y procesan medidas iniciales de conciliación para reajustar los cálculos de consumo.

      2. Permite garantizar que los componentes de medición se procesan en orden, según sus relaciones. Por ejemplo, si se configura un canal escalar como el canal de comprobación de un canal de intervalo, se procesará en primer lugar el canal escalar, de forma que haya datos disponibles para la comprobación de suma y para rellenar los saltos de intervalo necesarios.

    • La configuración de un procesamiento diferido implica añadir un control de lotes “Supervisión de datos iniciales de medida – Dispositivos físicos” como proceso de supervisión en estado Pendiente a los siguientes objetos de negocio:

      • D1-InitialLoadIMDInterval

      • D1-InitialLoadIMDScalar

    • Cuando se realiza el procesamiento diferido de medidas iniciales, será necesario programar el control de lotes “Supervisión de datos iniciales de medida – Dispositivos físicos”” con una ejecución más frecuente. Deberá programarse de forma que se ejecute con un recuento de threads superior de forma inmediata tras la finalización del ciclo de lecturas programadas de Itron y con menos threads en el resto del día, para seleccionar otras medidas iniciales que pudieran haberse recibido (como, por ejemplo, las recibidas mediante comandos de lectura bajo demanda).