Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las fases de desarrollo de una solución de IoT pueden abarcar semanas o meses, debido a las realidades de producción, como el tiempo de fabricación, el envío, el proceso aduanero, etc. Además, pueden abarcar actividades en varios roles dados a las distintas entidades implicadas. En este artículo se examina más detalladamente los distintos roles y operaciones relacionados con cada fase y, a continuación, se muestra el flujo en un diagrama de secuencia.
El aprovisionamiento también impone requisitos al fabricante del dispositivo, específicos para habilitar el mecanismo de atestación. Las operaciones de fabricación también pueden producirse independientemente del tiempo de las fases de aprovisionamiento automático, especialmente en los casos en los que los nuevos dispositivos se adquieren después de que ya se haya establecido el aprovisionamiento automático.
Se proporciona una serie de inicios rápidos en la tabla de contenido a la izquierda, para ayudar a explicar el aprovisionamiento automático a través de la experiencia práctica. Para facilitar o simplificar el proceso de aprendizaje, el software se usa para simular un dispositivo físico para la inscripción y el registro. Algunas guías de inicio rápido requieren que realice operaciones para varias funciones, incluidas operaciones para funciones inexistentes, debido a la naturaleza simulada de las guías de inicio rápido.
| Rol | Operation | Description |
|---|---|---|
| Fabricante | Codificación de la identidad y la dirección URL de registro | En función del mecanismo de atestación usado, el fabricante es responsable de codificar la información de identidad del dispositivo y la dirección URL de registro del servicio Device Provisioning. Inicios rápidos: dado que el dispositivo está simulado, no hay ningún rol de fabricante. Consulte el rol Desarrollador para obtener más información sobre cómo obtener esta información, que se usa en la codificación de una aplicación de registro de ejemplo. |
| Proporcionar identidad de dispositivo | Como originador de la información de identidad del dispositivo, el fabricante es responsable de comunicarlo al operador (o un agente designado) o inscribirlo directamente en el servicio Device Provisioning a través de las API. Inicios rápidos: dado que el dispositivo está simulado, no hay ningún rol de fabricante. Consulte el rol Operador para obtener más información sobre cómo obtener la identidad del dispositivo, que se usa para inscribir un dispositivo simulado en la instancia de Device Provisioning Service. |
|
| Operator | Configuración del aprovisionamiento automático | Esta operación corresponde a la primera fase del aprovisionamiento automático. Inicios rápidos: realiza el rol Operador, configurando las instancias de Device Provisioning Service e IoT Hub en la suscripción de Azure. |
| Registro de la identidad del dispositivo | Esta operación corresponde a la segunda fase del aprovisionamiento automático. Guías de inicio rápido: en ellas realiza el rol de operador, inscribiendo el dispositivo simulado en la instancia del servicio Device Provisioning. El método de atestación simulado en el inicio rápido (TPM o X.509) determina la identidad del dispositivo. Consulte el rol de desarrollador para ver los detalles de atestación. |
|
| Servicio de Aprovisionamiento de Dispositivos IoT Hub |
<todas las operaciones> | En el caso de una implementación de producción con dispositivos físicos e inicios rápidos con dispositivos simulados, estos roles se cumplen a través de los servicios de IoT que configure en la suscripción de Azure. Los roles y operaciones tienen exactamente la misma función, ya que los servicios de IoT son indiferentes a la provisión de dispositivos físicos frente a simulados. |
| Developer | Compilación e implementación de software de registro | Esta operación corresponde a la tercera fase del aprovisionamiento automático. El desarrollador es responsable de compilar e implementar el software de registro en el dispositivo mediante el SDK adecuado. Guías de inicio rápido: la aplicación de registro de ejemplo que compila simula un dispositivo real, para la plataforma o el idioma que prefiera, que se ejecuta en la estación de trabajo (en lugar de implementarlo en un dispositivo físico). La aplicación de registro realiza las mismas operaciones que una implementada en un dispositivo físico. Especifique el método de atestación (certificado TPM o X.509), además de la dirección URL de registro y el "Ámbito de identificador" de la instancia de Device Provisioning Service. La lógica de atestación del SDK en tiempo de ejecución determina la identidad del dispositivo, en función del método que especifique:
|
| Device | Inicio y registro | Esta operación corresponde a la tercera fase del aprovisionamiento automático, que cumple el software de registro de dispositivos creado por el desarrollador. Consulte el rol de desarrollador para más detalles. Tras el primer arranque:
|
En el diagrama siguiente se resumen los roles y la secuenciación de operaciones durante el aprovisionamiento automático del dispositivo:
Nota:
Opcionalmente, el fabricante también puede realizar la operación "Inscribir identidad de dispositivo" mediante las API del servicio Device Provisioning (en lugar de a través del operador). Para obtener una explicación detallada de esta secuenciación y mucho más, consulte el vídeo Registro de dispositivos táctiles cero con Azure IoT (a partir del marcador 41:00).
Roles y cuentas de Azure
El modo en que cada rol se asigna a una cuenta de Azure depende del escenario y hay bastantes escenarios que pueden estar implicados. Los siguientes patrones comunes deben ayudar a proporcionar una comprensión general sobre cómo se asignan los roles a una cuenta de Azure.
El fabricante de chip proporciona servicios de seguridad
En este escenario, el fabricante administra la seguridad de los clientes de nivel uno. Este escenario puede ser preferible para estos clientes de nivel uno, ya que no tienen que administrar la seguridad detallada.
El fabricante introduce la seguridad en módulos de seguridad de hardware (HSM). Esta seguridad puede incluir que el fabricante obtenga claves, certificados, etc. de los clientes potenciales que ya tienen instancias de DPS y grupos de inscripción configurados. El fabricante también podría generar esta información de seguridad para sus clientes.
En este escenario, puede haber dos cuentas de Azure implicadas:
Cuenta n.º 1: probablemente se comparta entre los roles de operador y desarrollador hasta cierto punto. Esta entidad podría comprar los chips HSM del fabricante. Estos chips apuntan a instancias de DPS asociadas con la cuenta n.º 1. Con las inscripciones de DPS, esta entidad puede conceder dispositivos a varios clientes de nivel dos mediante la reconfiguración de la configuración de inscripción de dispositivos en DPS. Esta parte también podría tener centros de IoT asignados para que los sistemas back-end del usuario final interactúen y accedan a la telemetría del dispositivo, etc. En este último caso, es posible que no se necesite una segunda cuenta.
Cuenta 2: los usuarios finales, los clientes de nivel dos pueden tener sus propios centros de IoT. La entidad asociada con la cuenta n.º 1 solo señala los dispositivos concedidos al centro correcto en esta cuenta. Esta configuración requiere vincular DPS e IoT Hubs entre cuentas de Azure, que se pueden realizar con plantillas de Azure Resource Manager.
Todo en uno OEM
El fabricante podría ser un "OEM todo en uno" donde solo se necesitaría una sola cuenta de fabricante. El fabricante controla la seguridad y el aprovisionamiento de un extremo a otro.
El fabricante podría proporcionar una aplicación basada en la nube a los clientes que compran dispositivos. Esta aplicación interactuaría con el centro de IoT asignado por el fabricante.
Las máquinas expendedoras o las cafeteras automatizadas representan ejemplos para este escenario.
Pasos siguientes
Es posible que le resulte útil marcar este artículo como punto de referencia, a medida que trabaje a través de los inicios rápidos de aprovisionamiento automático correspondientes.
Comience completando un inicio rápido de "Configuración del aprovisionamiento automático" que mejor se adapte a sus preferencias de herramientas de administración, lo que le guiará a través de la fase "Configuración del servicio":
- Configuración del aprovisionamiento automático mediante la CLI de Azure
- Configuración del aprovisionamiento automático mediante Azure Portal
- Configuración del aprovisionamiento automático mediante una plantilla de Azure Resource Manager (ARM)
A continuación, continúe con un inicio rápido de "Aprovisionamiento de un dispositivo" que se adapte al mecanismo de atestación del dispositivo y a la preferencia de idioma o SDK de Device Provisioning Service. En este inicio rápido, recorrerá las fases "Inscripción de dispositivos" y "Registro y configuración de dispositivos":
| Mecanismo de atestación de dispositivos | Inicio rápido |
|---|---|
| Clave simétrica | Aprovisionamiento de un dispositivo de clave simétrica simulado |
| Certificado X.509 | Aprovisionamiento de un dispositivo X.509 simulado |
| Módulo de plataforma segura simulado (TPM) | Aprovisionamiento de un dispositivo TPM simulado |