Desarrollo de conectores de datos de series temporales AWS IoT TwinMaker - AWS IoT TwinMaker

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Desarrollo de conectores de datos de series temporales AWS IoT TwinMaker

En esta sección se explica cómo desarrollar un conector de datos de series temporales en un step-by-step proceso. Además, presentamos un ejemplo de conector de datos de series temporales basado en toda la muestra de una fábrica de galletas, que incluye modelos 3D, entidades, componentes, alarmas y conectores. La fuente de muestras de Cookie Factory está disponible en el GitHub repositorio de AWS IoT TwinMaker muestras.

AWS IoT TwinMaker requisitos previos del conector de datos de series temporales

Antes de desarrollar el conector de datos de series temporales, le recomendamos que realice las siguientes tareas:

nota

Para ver un ejemplo de un conector completamente implementado, consulte nuestro ejemplo de implementación de una fábrica de cookies.

Antecedentes del conector de datos de series temporales

Imagine que trabaja con una fábrica que tiene un conjunto de mezcladoras de galletas y un depósito de agua. Le gustaría crear gemelos AWS IoT TwinMaker digitales de estas entidades físicas para poder monitorear sus estados operativos comprobando varias métricas de series temporales.

Ha configurado los sensores in situ y ya está transmitiendo los datos de medición a una base de datos de Timestream. Desea poder ver y organizar los datos de medición de AWS IoT TwinMaker con una sobrecarga mínima. Puede realizar esta tarea mediante un conector de datos de series temporales. La siguiente imagen muestra un ejemplo de tabla de telemetría, que se completa mediante el uso de un conector de series temporales.

Un ejemplo de datos de una tabla de telemetría que incluye el identificador del activo, el tipo, la medida, el tiempo y los valores.

Los conjuntos de datos y la tabla Timestream utilizados en esta captura de pantalla están disponibles en el repositorio de muestras.AWS IoT TwinMaker GitHub Consulte también el ejemplo de conector de fábrica de cookies para la implementación, que produce el resultado que se muestra en la captura de pantalla anterior.

Flujo de datos de conector de datos de series temporales

Para las consultas del plano de datos, AWS IoT TwinMaker busca las propiedades correspondientes de los componentes y los tipos de componentes a partir de las definiciones de componentes y tipos de componentes. AWS IoT TwinMaker reenvía las propiedades de las AWS Lambda funciones junto con cualquier parámetro de consulta de API de la consulta.

AWS IoT TwinMaker usa funciones Lambda para acceder y resolver consultas de fuentes de datos y devolver los resultados de esas consultas. Las funciones de Lambda utilizan las propiedades del componente y del tipo de componente del plano de datos para resolver la solicitud inicial.

Los resultados de la consulta de Lambda se asignan a una respuesta de API y se le devuelven.

AWS IoT TwinMaker define la interfaz del conector de datos y la utiliza para interactuar con las funciones de Lambda. Con los conectores de datos, puede consultar su fuente de datos desde la API de AWS IoT TwinMaker sin necesidad de realizar ninguna migración de datos. La siguiente imagen describe el flujo de datos básico descrito en los párrafos anteriores.

Las solicitudes y respuestas de la API utilizan las solicitudes y respuestas del conector 3P que acceden a una fuente de datos.

Desarrollo de un conector de datos de series temporales

El siguiente procedimiento describe un modelo de desarrollo que se convierte gradualmente en un conector de datos de series temporales funcional. Los pasos básicos son los siguientes:

  1. Cree un tipo de componente básico válido

    En un tipo de componente, se definen propiedades comunes que se comparten entre los componentes. Para obtener más información sobre la definición de tipos de componentes, consulte Uso y creación de tipos de componentes.

    AWS IoT TwinMaker utiliza un patrón de modelado de componentes de entidad para que cada componente esté asociado a una entidad. Se recomienda modelar cada elemento físico como una entidad y modelar diferentes fuentes de datos con sus propios tipos de componentes.

    El siguiente ejemplo muestra un tipo de componente de plantilla Timestream con una propiedad:

    {"componentTypeId": "com.example.timestream-telemetry", "workspaceId": "MyWorkspace", "functions": { "dataReader": { "implementedBy": { "lambda": { "arn": "lambdaArn" } } } }, "propertyDefinitions": { "telemetryType": { "dataType": { "type": "STRING" }, "isExternalId": false, "isStoredExternally": false, "isTimeSeries": false, "isRequiredInEntity": true }, "telemetryId": { "dataType": { "type": "STRING" }, "isExternalId": true, "isStoredExternally": false, "isTimeSeries": false, "isRequiredInEntity": true }, "Temperature": { "dataType": { "type": "DOUBLE" }, "isExternalId": false, "isTimeSeries": true, "isStoredExternally": true, "isRequiredInEntity": false } } }

    Los elementos clave del tipo de componente son los siguientes:

    • La telemetryId propiedad identifica la clave única del elemento físico en la fuente de datos correspondiente. El conector de datos utiliza esta propiedad como condición de filtro para consultar únicamente los valores asociados al elemento en cuestión. Además, si incluye el valor de la propiedad telemetryId en la respuesta de la API del plano de datos, el cliente toma el ID y puede realizar una búsqueda inversa si es necesario.

    • El campo lambdaArn identifica la función de Lambda con la que interactúa el tipo de componente.

    • El indicador isRequiredInEntity impone la creación de la ID. Esta marca es necesaria para que, cuando se cree el componente, también se cree una instancia del ID del elemento.

    • TelemetryIdSe agrega al tipo de componente como un identificador externo para que el elemento pueda identificarse en la tabla Timestream.

  2. Cree un componente con el tipo de componente

    Para usar el tipo de componente que creó, debe crear un componente y adjuntarlo a la entidad de la que desea recuperar los datos. Los siguientes pasos detallan el proceso de creación de ese componente:

    1. Vaya a la consola de AWS IoT TwinMaker.

    2. Seleccione y abra el mismo espacio de trabajo en el que creó los tipos de componentes.

    3. Vaya a la página de la entidad.

    4. Cree una entidad nueva o seleccione una entidad existente de la tabla.

    5. Una vez que haya seleccionado la entidad que desea usar, elija Agregar componente para abrir la página Agregar componente.

    6. Asigne un nombre al componente y, para el Tipo, elija el tipo de componente que creó con la plantilla en el punto 1. Cree un tipo de componente básico válido

  3. Haga que su tipo de componente se llame conector Lambda

    El conector Lambda debe acceder al origen de datos y generar la declaración de consulta en función de la entrada y reenviarla al origen de datos. El siguiente ejemplo muestra una plantilla de solicitud JSON que hace esto.

    { "workspaceId": "MyWorkspace", "entityId": "MyEntity", "componentName": "TelemetryData", "selectedProperties": ["Temperature"], "startTime": "2022-08-25T00:00:00Z", "endTime": "2022-08-25T00:00:05Z", "maxResults": 3, "orderByTime": "ASCENDING", "properties": { "telemetryType": { "definition": { "dataType": { "type": "STRING" }, "isExternalId": false, "isFinal": false, "isImported": false, "isInherited": false, "isRequiredInEntity": false, "isStoredExternally": false, "isTimeSeries": false }, "value": { "stringValue": "Mixer" } }, "telemetryId": { "definition": { "dataType": { "type": "STRING" }, "isExternalId": true, "isFinal": true, "isImported": false, "isInherited": false, "isRequiredInEntity": true, "isStoredExternally": false, "isTimeSeries": false }, "value": { "stringValue": "item_A001" } }, "Temperature": { "definition": { "dataType": { "type": "DOUBLE", }, "isExternalId": false, "isFinal": false, "isImported": true, "isInherited": false, "isRequiredInEntity": false, "isStoredExternally": false, "isTimeSeries": true } } } }

    Los elementos clave de la solicitud:

    • selectedProperties es una lista que debe rellenar con las propiedades para las que desea obtener mediciones de Timestream.

    • Los campos startDateTime, startTime, EndDateTime, y endTime especifican un intervalo de tiempo para la solicitud. Esto determina el rango de muestra para las mediciones devueltas.

    • entityId es el nombre de la entidad desde la que se consultan los datos.

    • componentName es el nombre del componente desde el que se consultan los datos.

    • Utilice el campo orderByTime para organizar el orden en el que se muestran los resultados.

    En la solicitud de ejemplo anterior, esperaríamos obtener una serie de muestras de las propiedades seleccionadas durante el intervalo de tiempo determinado para el elemento en cuestión, con el orden temporal seleccionado. La declaración de respuesta se puede resumir de la siguiente manera:

    { "propertyValues": [ { "entityPropertyReference": { "entityId": "MyEntity", "componentName": "TelemetryData", "propertyName": "Temperature" }, "values": [ { "time": "2022-08-25T00:00:00Z", "value": { "doubleValue": 588.168 } }, { "time": "2022-08-25T00:00:01Z", "value": { "doubleValue": 592.4224 } }, { "time": "2022-08-25T00:00:02Z", "value": { "doubleValue": 594.9383 } } ] } ], "nextToken": "..." }
  4. Actualice el tipo de componente para que tenga dos propiedades

    La siguiente plantilla JSON muestra un tipo de componente válido con dos propiedades:

    { "componentTypeId": "com.example.timestream-telemetry", "workspaceId": "MyWorkspace", "functions": { "dataReader": { "implementedBy": { "lambda": { "arn": "lambdaArn" } } } }, "propertyDefinitions": { "telemetryType": { "dataType": { "type": "STRING" }, "isExternalId": false, "isStoredExternally": false, "isTimeSeries": false, "isRequiredInEntity": true }, "telemetryId": { "dataType": { "type": "STRING" }, "isExternalId": true, "isStoredExternally": false, "isTimeSeries": false, "isRequiredInEntity": true }, "Temperature": { "dataType": { "type": "DOUBLE" }, "isExternalId": false, "isTimeSeries": true, "isStoredExternally": true, "isRequiredInEntity": false }, "RPM": { "dataType": { "type": "DOUBLE" }, "isExternalId": false, "isTimeSeries": true, "isStoredExternally": true, "isRequiredInEntity": false } } }
  5. Actualice el conector Lambda para gestionar la segunda propiedad

    La API del plano de AWS IoT TwinMaker datos permite consultar varias propiedades en una sola solicitud y, al AWS IoT TwinMaker enviar una lista deselectedProperties, sigue una única solicitud a un conector.

    La siguiente solicitud de JSON muestra una plantilla modificada que ahora admite una solicitud de dos propiedades.

    { "workspaceId": "MyWorkspace", "entityId": "MyEntity", "componentName": "TelemetryData", "selectedProperties": ["Temperature", "RPM"], "startTime": "2022-08-25T00:00:00Z", "endTime": "2022-08-25T00:00:05Z", "maxResults": 3, "orderByTime": "ASCENDING", "properties": { "telemetryType": { "definition": { "dataType": { "type": "STRING" }, "isExternalId": false, "isFinal": false, "isImported": false, "isInherited": false, "isRequiredInEntity": false, "isStoredExternally": false, "isTimeSeries": false }, "value": { "stringValue": "Mixer" } }, "telemetryId": { "definition": { "dataType": { "type": "STRING" }, "isExternalId": true, "isFinal": true, "isImported": false, "isInherited": false, "isRequiredInEntity": true, "isStoredExternally": false, "isTimeSeries": false }, "value": { "stringValue": "item_A001" } }, "Temperature": { "definition": { "dataType": { "type": "DOUBLE" }, "isExternalId": false, "isFinal": false, "isImported": true, "isInherited": false, "isRequiredInEntity": false, "isStoredExternally": false, "isTimeSeries": true } }, "RPM": { "definition": { "dataType": { "type": "DOUBLE" }, "isExternalId": false, "isFinal": false, "isImported": true, "isInherited": false, "isRequiredInEntity": false, "isStoredExternally": false, "isTimeSeries": true } } } }

    Del mismo modo, la respuesta correspondiente también se actualiza, como se muestra en el siguiente ejemplo:

    { "propertyValues": [ { "entityPropertyReference": { "entityId": "MyEntity", "componentName": "TelemetryData", "propertyName": "Temperature" }, "values": [ { "time": "2022-08-25T00:00:00Z", "value": { "doubleValue": 588.168 } }, { "time": "2022-08-25T00:00:01Z", "value": { "doubleValue": 592.4224 } }, { "time": "2022-08-25T00:00:02Z", "value": { "doubleValue": 594.9383 } } ] }, { "entityPropertyReference": { "entityId": "MyEntity", "componentName": "TelemetryData", "propertyName": "RPM" }, "values": [ { "time": "2022-08-25T00:00:00Z", "value": { "doubleValue": 59 } }, { "time": "2022-08-25T00:00:01Z", "value": { "doubleValue": 60 } }, { "time": "2022-08-25T00:00:02Z", "value": { "doubleValue": 60 } } ] } ], "nextToken": "..." }
    nota

    En cuanto a la paginación, en este caso, el tamaño de página de la solicitud se aplica a todas las propiedades. Esto significa que con cinco propiedades en la consulta y un tamaño de página de 100, si hay suficientes puntos de datos en la fuente, debería esperar ver 100 puntos de datos por propiedad, es decir, 500 puntos de datos en total.

    Para ver un ejemplo de implementación, consulte el ejemplo del conector Snowflake en. GitHub

Mejora de su conector de datos

Tratamiento de excepciones

Es seguro que el conector Lambda genere excepciones. En la llamada a la API del plano de datos, el AWS IoT TwinMaker servicio espera a que la función Lambda devuelva una respuesta. Si la implementación del conector genera una excepción, AWS IoT TwinMaker traduce el tipo de excepción como talConnectorFailure, lo que hace que el cliente de la API sepa que se ha producido un problema dentro del conector.

Gestión de la paginación

En el ejemplo, Timestream proporciona una función de utilidad que puede ayudar a admitir la paginación de forma nativa. Sin embargo, para algunas otras interfaces de consulta, como SQL, puede que sea necesario un esfuerzo adicional implementar un algoritmo de paginación eficiente. Hay un ejemplo de conector Snowflake que gestiona la paginación en una interfaz SQL.

Cuando se devuelve el nuevo token a AWS IoT TwinMaker través de la interfaz de respuesta del conector, el token se cifra antes de devolverlo al cliente de la API. Cuando el token se incluye en otra solicitud, lo AWS IoT TwinMaker descifra antes de reenviarlo al conector Lambda. Se recomienda evitar añadir información confidencial al token.

Prueba del conector

Aunque todavía puede actualizar la implementación después de vincular el conector al tipo de componente, le recomendamos encarecidamente que compruebe el conector Lambda antes de integrarlo con AWS IoT TwinMaker.

Existen varias formas de probar el conector Lambda: puede probar el conector Lambda en la consola Lambda o localmente en la AWS CDK.

Para obtener más información sobre las pruebas de las funciones Lambda, consulte Probar funciones Lambda y Probar aplicaciones localmente. AWS CDK

Seguridad

Para obtener documentación sobre las mejores prácticas de seguridad con Timestream, consulte Seguridad en Timestream.

Para ver un ejemplo de prevención de inyecciones de SQL, consulte el siguiente script de Python en el GitHub repositorio de AWS IoT TwinMaker muestras.

Creación de AWS IoT TwinMaker recursos

Una vez implementada la función Lambda, puede crear AWS IoT TwinMaker recursos como tipos de componentes, entidades y componentes a través de la AWS IoT TwinMaker consola o la API.

nota

Si sigue las instrucciones de configuración del GitHub ejemplo, todos los AWS IoT TwinMaker recursos estarán disponibles automáticamente. Puede comprobar las definiciones de los tipos de componentes en el AWS IoT TwinMaker GitHub ejemplo. Una vez que algún componente utiliza el tipo de componente, las definiciones de propiedades y las funciones del tipo de componente no se pueden actualizar.

Prueba de integración

Recomendamos realizar una prueba integrada AWS IoT TwinMaker para comprobar que la consulta del plano de datos funciona end-to-end. Puede realizarla a través de la GetPropertyValueHistoryAPI o fácilmente en AWS IoT TwinMaker la consola.

Una TwinMaker página de la consola de información sobre el componente muestra el nombre, el tipo, el estado, etc. del componente.

En la AWS IoT TwinMaker consola, vaya a los detalles del componente y, a continuación, en la sección Prueba, verá que todas las propiedades del componente se muestran allí. El área de pruebas de la consola permite probar propiedades y propiedades de series temporales. non-time-series Para las propiedades de series temporales, también puede utilizar la GetPropertyValueHistoryAPI y, para las non-time-series propiedades, utilizar GetPropertyValuela API. Si su conector Lambda admite consultas de propiedades múltiples, puede elegir más de una propiedad.

Parte de la página de una consola de información sobre TwinMaker componentes que muestra la prueba de un componente.

Siguientes pasos

Ahora puede configurar un panel de AWS IoT TwinMaker Grafana para visualizar las métricas. También puede explorar otros ejemplos de conectores de datos en el GitHub repositorio de AWS IoT TwinMaker muestras para ver si se ajustan a su caso de uso.