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.
Conector de series temporales de ejemplo de fábrica de galletas de AWS IoT TwinMaker
El código completo de la función Lambda de la fábrica de cookies
Ejemplos de tipos de componentes de fábrica de galletas
En un tipo de componente, se definen propiedades comunes que se comparten entre los componentes. Para el ejemplo de la fábrica de cookies, los componentes físicos del mismo tipo comparten las mismas medidas, por lo que podemos definir el esquema de medidas en el tipo de componente. Como ejemplo, el tipo de mezclador se define en el siguiente ejemplo.
{ "componentTypeId": "com.example.cookiefactory.mixer" "propertyDefinitions": { "RPM": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "Temperature": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true } } }
Por ejemplo, un componente físico puede tener mediciones en una base de datos de Timestream, registros de mantenimiento en una base de datos SQL o datos de alarma en sistemas de alarma. Al crear varios componentes y asociarlos a una entidad, se vinculan diferentes orígenes de datos a la entidad y se completa el gráfico entidad-componente. En este contexto, cada componente necesita una telemetryId
propiedad para identificar la clave única del componente en la fuente de datos correspondiente. Especificar la telemetryId
propiedad tiene dos ventajas: la propiedad se puede utilizar en el conector de datos como condición de filtro para consultar únicamente los valores del componente en cuestión y, si se incluye el valor de la telemetryId
propiedad 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.
Si se añade TelemetryId
al tipo de componente como identificador externo, se identifica el componente en la TimeStream
tabla.
{ "componentTypeId": "com.example.cookiefactory.mixer" "propertyDefinitions": { "telemetryId": { "dataType": { "type": "STRING" }, "isTimeSeries": false, "isRequiredInEntity": true, "isExternalId": true, "isStoredExternally": false }, "RPM": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "Temperature": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true } } }
Del mismo modo, tenemos el tipo de componente para el WaterTank
, como se muestra en el siguiente ejemplo JSON.
{ "componentTypeId": "com.example.cookiefactory.watertank", "propertyDefinitions": { "flowRate1": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "flowrate2": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "tankVolume1": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "tankVolume2": { "dataType": { "type": "DOUBLE" }, "isTimeSeries": true, "isRequiredInEntity": false, "isExternalId": false, "isStoredExternally": true }, "telemetryId": { "dataType": { "type": "STRING" }, "isTimeSeries": false, "isRequiredInEntity": true, "isExternalId": true, "isStoredExternally": false } } }
TelemetryType
es una propiedad opcional en el tipo de componente si su objetivo es consultar los valores de las propiedades en el ámbito de la entidad. Para ver un ejemplo, consulte los tipos de componentes definidos en el GitHub repositorio de AWS IoT TwinMaker muestrasTelemetryType
y se extraen propiedades comunes, como TelemetryId
y TelemetryType
a un tipo de componente principal para que otros tipos secundarios las compartan.
Ejemplo de 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. En el siguiente ejemplo de JSON se muestra un ejemplo de solicitud enviada a la .
{ 'workspaceId': 'CookieFactory', 'selectedProperties': ['Temperature'], 'startDateTime': 1648796400, 'startTime': '2022-04-01T07:00:00.000Z', 'endDateTime': 1650610799, 'endTime': '2022-04-22T06:59:59.000Z', 'properties': { 'telemetryId': { 'definition': { 'dataType': { 'type': 'STRING' }, 'isTimeSeries': False, 'isRequiredInEntity': True, 'isExternalId': True, 'isStoredExternally': False, 'isImported': False, 'isFinal': False, 'isInherited': True, }, 'value': { 'stringValue': 'Mixer_22_680b5b8e-1afe-4a77-87ab-834fbe5ba01e' } } 'Temperature': { 'definition': { 'dataType': { 'type': 'DOUBLE' }, 'isTimeSeries': True, 'isRequiredInEntity': False, 'isExternalId': False, 'isStoredExternally': True, 'isImported': False, 'isFinal': False, 'isInherited': False } } 'RPM': { 'definition': { 'dataType': { 'type': 'DOUBLE' }, 'isTimeSeries': True, 'isRequiredInEntity': False, 'isExternalId': False, 'isStoredExternally': True, 'isImported': False, 'isFinal':False, 'isInherited': False } }, 'entityId': 'Mixer_22_d133c9d0-472c-48bb-8f14-54f3890bc0fe', 'componentName': 'MixerComponent', 'maxResults': 100, 'orderByTime': 'ASCENDING' }
El objetivo de la función Lambda es consultar los datos de medición históricos de una entidad determinada. AWS IoT TwinMaker proporciona un mapa de propiedades de los componentes y debe especificar un valor instanciado para el ID del componente. Por ejemplo, para gestionar la consulta a nivel de tipo de componente (que es común en los casos de uso de alarmas) y devolver el estado de alarma de todos los componentes del espacio de trabajo, el mapa de propiedades incluye definiciones de propiedades de tipo de componente.
En el caso más sencillo, como en la solicitud anterior, queremos una serie de muestras de temperatura durante un intervalo de tiempo determinado para el componente en cuestión, en orden temporal ascendente. La declaración de consulta se puede resumir de la siguiente manera:
... SELECT measure_name, time, measure_value::double FROM {database_name}.{table_name} WHERE time < from_iso8601_timestamp('{request.start_time}') AND time >= from_iso8601_timestamp('{request.end_time}') AND TelemetryId = '{telemetry_id}' AND measure_name = '{selected_property}' ORDER BY time {request.orderByTime} ...