Tareas de fábrica

La fabricación de dispositivos conectados que incorporan hardware Azure Sphere implica las siguientes tareas de fábrica para preparar los dispositivos para el envío:

• Conectar cada chip de Azure Sphere a un equipo de fábrica
• Obtener detalles del dispositivo y grabarlos para su uso posterior
• Actualizar azure Sphere OS, si es necesario
• Actualice el almacén de claves de confianza, si es necesario
• Cargando software en el dispositivo
• Ejecutar pruebas funcionales para comprobar la operación correcta del producto
• Realizar pruebas y calibración de radiofrecuencias (RF)
• Comprobar Wi-Fi comunicación
• Configuración del dispositivo para Ethernet
• Finalizar el dispositivo Azure Sphere para su envío

Primero debes conectar el chip al equipo, obtener los detalles del dispositivo en segundo lugar y finalizar el dispositivo en último lugar, pero puedes realizar las otras tareas en cualquier orden que se adapte a tu entorno de fabricación.

Conectar cada chip de Azure Sphere a un equipo de fábrica

Durante la fabricación, debes conectar cada chip Azure Sphere a un equipo de fábrica. Si desea conectar simultáneamente varios dispositivos Azure Sphere a un único EQUIPO, consulte Equipo para tareas de fábrica en las tareas de preparación de la fabricación.

La mayoría de las tareas de fábrica implican el comando az sphere device . Cuando tenga varios dispositivos conectados al equipo, debe especificar el dispositivo en el que debe aplicar el comando az sphere device incluyendo el --device parámetro establecido en la dirección IP del dispositivo o en la ruta de conexión del dispositivo. El comando producirá un error si se omite el --device parámetro y se adjuntan varios dispositivos. Para obtener la dirección IP o la ruta de conexión, consulta Obtener detalles del dispositivo.

Obtener detalles del dispositivo

Debe registrar el id. de dispositivo de cada chip de Azure Sphere que su empresa incorpora a los productos fabricados. Necesitarás el id. de dispositivo para las tareas de configuración de la nube.

Si tiene varios dispositivos conectados al equipo de fábrica, también debe registrar la dirección IP o la ruta de conexión de los dispositivos conectados para su uso posterior en las tareas de fábrica. Como se explica en Conectar cada chip de Azure Sphere, se requiere una dirección IP o una ruta de conexión para especificar el dispositivo de destino cuando hay varios dispositivos conectados.

Para obtener el id. de dispositivo, la dirección IP y la ruta de conexión de los dispositivos conectados, use el comando az sphere device list-attached . Las descripciones siguientes proporcionan detalles esenciales sobre el id. de dispositivo, la dirección IP y la ruta de conexión.

• Id. de dispositivo: el fabricante de placas crea el identificador de dispositivo, lo almacena en el chip y lo registra en Microsoft. Este registro de dispositivo garantiza que Microsoft tenga en cuenta todos los chips de Azure Sphere y que solo se puedan usar chips legítimos en dispositivos conectados.

• Dirección IP — La dirección IP se asigna cuando una interfaz de dispositivo basada en FTDI se asocia al PC; no indica que haya un dispositivo con capacidad de respuesta. La dirección IP continúa mientras la interfaz de dispositivo basada en FTDI se conecta al equipo, incluso si se conecta otro dispositivo Azure Sphere a la interfaz. Sin embargo, después de reiniciar el equipo, la dirección IP puede cambiar. A la primera interfaz de dispositivo FTDI-basada que se asociará se le asigna la dirección 192.168.35.2. A cada dispositivo se le asigna una dirección IP, incluso si no responde, por lo que puedes usar la dirección IP para identificar un dispositivo que requiera recuperación.

• Ruta de conexión — La ruta de conexión es un ID de ubicación FTDI que identifica la conexión USB. El id. de ubicación persiste mientras que la interfaz de dispositivo basada en FTDI se conecta al mismo puerto USB en el mismo concentrador USB, y a su vez al mismo puerto en el PC. Por lo tanto, continúa durante el reinicio. Sin embargo, cualquier cambio en el cableado entre el equipo y el dispositivo puede dar lugar a cambios en la ruta de conexión. Al igual que la dirección IP, no cambia incluso si un dispositivo Azure Sphere diferente está conectado a la interfaz FTDI.

Actualizar el so Azure Sphere

Cada chip azure sphere se carga con el sistema operativo Azure Sphere cuando se envía desde el fabricante de placas. Según la versión del SO Azure Sphere en los chips disponibles de su proveedor y según los requisitos de la versión del sistema operativo de su aplicación, es posible que deba actualizar el so Azure Sphere durante la fabricación del dispositivo conectado. Puedes actualizar el sistema operativo instalando imágenes de recuperación específicas, que ya deberían estar presentes en el equipo. Vea Prepararse para una actualización del sistema operativo en las tareas de preparación de fabricación. Las muestras de fabricación incluyen un script de ejemplo que realiza la recuperación en paralelo de varios dispositivos.

Puede actualizar el sistema operativo en el dispositivo Azure Sphere emitiendo el comando az sphere device recover . Usa el --images parámetro para instalar imágenes de recuperación específicas:

az sphere device recover --images <path-to-images> [--device <IP-address or connection-path>]

Actualizar el almacén de claves de confianza

Como requisito previo para cargar software en el dispositivo, es posible que tenga que actualizar el almacén de claves de confianza en el dispositivo. Esto solo es necesario si el sistema operativo del dispositivo es más antiguo que el software y solo si la clave de firma de la imagen de Azure Sphere usada por AS3 se actualizó entre el sistema operativo que se está publicando y el software firmado en producción. Para evitar este paso y reducir el tiempo de fabricación, considere la posibilidad de actualizar la versión del sistema operativo que usa durante la fabricación.

Puede determinar fácilmente si necesita actualizar el almacén de claves de confianza si intenta cargar el software según las instrucciones de la sección siguiente. Si la carga se realiza correctamente, no es necesario actualizar el almacén de claves de confianza. Si se produce un error de carga con el mensaje que comienza con Internal device error: Image not trusted by device un almacén de claves de confianza obsoleto es la causa.

Para actualizar el almacén de claves de confianza, debe haber adquirido el archivo de almacén de claves de confianza actualizado. A continuación, como parte de los scripts de fabricación, use el comando az sphere device sideload deploy para cargar el almacén de claves de confianza actualizado antes de cargar el software de la aplicación, reemplazando <path-to-trusted-keystore.bin> por la ruta de acceso al archivo de almacén de claves de confianza:

az sphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]

Cargar software de dispositivo

Todo el software que cargue, independientemente de si se trata de una imagen de configuración de placa, una aplicación de prueba o una aplicación de producción, debe estar firmado en producción. Si carga una aplicación temporal para las pruebas, debe eliminarla una vez completada la prueba.

Todas las imágenes firmadas en producción que necesite durante el proceso de fábrica deben guardarse en su PC de fábrica antes de comenzar el proceso, como se describe en Obtener imágenes firmadas por la producción en las tareas de preparación de fabricación.

Durante la fabricación, los dispositivos Azure Sphere no deben requerir ninguna funcionalidad de dispositivo especial, como la funcionalidad de desarrollo de aplicaciones, que permite la depuración. La adquisición de capacidades para dispositivos individuales reduce la seguridad del dispositivo y requiere conectividad a Internet, que suele ser no deseada en la fábrica.

Para cargar software en un dispositivo de fábrica o para eliminar software temporal de un dispositivo una vez completada la prueba, usa el comando az sphere device sideload de la siguiente manera:

• Usa az sphere device sideload deploy para cargar una imagen, reemplazando <file-path> con el nombre y la ruta de acceso al archivo de imagen firmado por producción:

  az sphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
  

• Usa az sphere device sideload delete para eliminar una imagen temporal, reemplazando <component-id> por el id. de componente de la imagen que se va a eliminar:

  az sphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
  

Ejecutar pruebas funcionales

Las pruebas funcionales son necesarias para comprobar que el producto funciona correctamente. Ejecute las aplicaciones que ha desarrollado para pruebas funcionales como parte de las tareas de preparación de fabricación. Consulte Desarrollar aplicaciones para pruebas funcionales.

Si sus pruebas funcionales requieren comunicación con el chip que se está probando, conecte los UART periféricos MT3620 (ISU0, ISU1, ISU2 o ISU3) a su PC de fábrica o equipo de prueba externo a través de circuitos adecuados de su propio diseño.

Realizar pruebas y calibración de radiofrecuencias (RF)

Los chips de Azure Sphere pueden usar Wi-Fi para recibir actualizaciones de software y comunicarse con Internet. Si el producto usa Wi-Fi e incorpora un diseño de chip-down o un módulo que no está certificado por RF, debes realizar pruebas de RF y calibración para cada dispositivo. El equipo y las herramientas necesarios para esta tarea se describen en Equipo y software para pruebas y calibración de RF en las tareas de preparación de fabricación.

El paquete de herramientas de RF incluye utilidades y una biblioteca de API de C para su uso durante las pruebas. Puede usar la biblioteca de API de C para programar la configuración de RF específica del producto en fusibles electrónicos. Por ejemplo, los fusibles electrónicos están programados para configurar la antena y la frecuencia, para ajustar los dispositivos y obtener un rendimiento óptimo, y para habilitar los canales de Wi-Fi. En el tema Herramientas de prueba de RF se describe cómo usar las herramientas de RF.

Programe fusibles electrónicos para habilitar canales de Wi-Fi

Azure Sphere OS selecciona canales de Wi-Fi según el código de región programado en los fusibles electrónicos MT3620 en las direcciones de desplazamiento 0x36 y 0x37. Para obtener más información sobre los fusibles electrónicos en el MT3620, consulta el documento Mediatek de directrices de contenido de fusibles electrónicos MT3620 .

El código de región es un código ASCII de dos letras. Azure Sphere OS usa la configuración de código de región en los fusibles electrónicos para buscar la región en la base de datos de normativas inalámbricas de Linux y, a continuación, selecciona los canales permitidos para esa región. Si no se programa ningún código de región en los fusibles electrónicos, en cuyo caso los fusibles electrónicos permanecen configurados en 0x00 0x00, o si se programan los caracteres "00", el sistema operativo establece de forma predeterminada un conjunto conservador de canales que se permiten generalmente en todas las regiones. Los canales permitidos para la región "00" se especifican en la base de datos reguladora inalámbrica de Linux.

La configuración del código de región de los fusibles electrónicos no necesita coincidir con el país donde se usará el dispositivo. Los fabricantes pueden elegir cualquier código de región que se asigne a un conjunto de canales permitido para la región de funcionamiento. Las distintas regiones y países suelen adoptar normativas similares o idénticas, que pueden permitir que los códigos de región se usen indistintamente.

Ejemplo: Para indicar al sistema operativo Azure Sphere que seleccione Wi-Fi canales para la región "DE" (Alemania), programe 0x44=D y 0x45=E en los fusibles electrónicos de las direcciones 0x36 y 0x37. Los canales permitidos para Alemania, extraídos de la base de datos de normativas inalámbricas de Linux, se muestran a continuación. La mayoría de los países de la Unión Europea (UE) permiten el mismo conjunto de canales.

country DE: DFS-ETSI
        (2400 - 2483.5 @ 40), (100 mW)
        (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
        (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
        (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
        # short range devices (ETSI EN 300 440-1)
        (5725 - 5875 @ 80), (25 mW)
        # 60 GHz band channels 1-4 (ETSI EN 302 567)
        (57000 - 66000 @ 2160), (40)

Comprobar la configuración de RF

Use rfSettingsTool para comprobar que las opciones de configuración de radio como la potencia de transmisión de destino, el código de región y la dirección Access Control multimedia (MAC) de Wi-Fi se han establecido correctamente. La documentación de la herramienta de configuración de RF proporciona más información sobre el uso de esta herramienta.

Comprobar Wi-Fi comunicación

Considera la posibilidad de conectarte a un punto de acceso Wi-Fi para comprobar que la aplicación de producto es capaz de comunicarse a través de Wi-Fi. Asegúrate de que la conexión Wi-Fi no tenga acceso a Internet, ya que puede producirse una actualización por el aire si el chip se conecta a un punto de acceso habilitado para Internet.

Para conectar un dispositivo a un punto de acceso Wi-Fi, siga las instrucciones de la pestaña Inicio rápido (pestaña CLI). Si hay varios dispositivos conectados al equipo, debe incluir el --device parámetro en el comando az sphere wifi show-status y el comando az sphere wifi add . Para obtener más información sobre el uso del comando az sphere device con varios dispositivos conectados, consulta Conectar cada chip de Azure Sphere a un equipo de fábrica.

Después de Wi-Fi las pruebas, debes quitar los puntos de acceso Wi-Fi utilizados para las pruebas desde el chip para que estos no sean visibles para los clientes. La recuperación de dispositivos quita todos los datos de configuración Wi-Fi del chip.

Configurar el dispositivo para Ethernet

Un dispositivo Azure Sphere puede comunicarse a través de Ethernet. El dispositivo requiere un adaptador Ethernet externo y una imagen de configuración de placa para la comunicación a través de Ethernet.

Para configurar un dispositivo Azure Sphere para Ethernet, conecte un adaptador Ethernet al dispositivo Azure Sphere, como se describe en Conectar adaptadores Ethernet.

Dos dispositivos Ethernet son compatibles con el sistema operativo Azure Sphere.

1. Microchip ENC28J60. Este es un adaptador 10Base-T (10mbps). Se puede cablear con un indicador LED a velocidad de dúplex medio, o sin un indicador LED a velocidad de doble cara completa. Los devkits mirados están cableados para el funcionamiento a doble cara.
2. Wiznet W5500. Se trata de un adaptador de 100Base-TX (100mpbs). Admite una pila TCP/IP integrada y modos de paso a través de NIC, pero Azure Sphere solo admite el paso de NIC al usar el W5500 para la conectividad a Internet. Debido a las limitaciones de ancho de banda de bus, la velocidad completa de 100mbps puede no ser alcanzada por el dispositivo MT3620.

La interfaz Ethernet se habilitará automáticamente una vez cargada la configuración de la placa, como se describe en Cargar software de dispositivo, y se reinicia el dispositivo. Todas las interfaces utilizan direcciones IP dinámicas de forma predeterminada.

Finalizar el dispositivo Azure Sphere

La finalización garantiza que el dispositivo Azure Sphere se encuentra en un estado seguro y está listo para enviarse a los clientes. Debes finalizar el dispositivo antes de enviarlo. La finalización implica:

• Ejecutar comprobaciones listas para enviar para asegurarse de que se instalan el software del sistema y la aplicación de producción correctos y se deshabilitan las herramientas de RF.

• Establecer el estado de fabricación del dispositivo para bloquear las herramientas de calibración y configuración de RF y evitar infracciones de seguridad.

Ejecutar comprobaciones listas para envío

Es importante ejecutar comprobaciones listas para enviar antes de enviar un producto que incluya un dispositivo Azure Sphere. Se deben realizar comprobaciones diferentes para diferentes estados de fabricación. Los controles listos para enviar garantizan lo siguiente:

• El estado de fabricación del dispositivo está configurado correctamente para esa fase de fabricación.
• Azure Sphere OS en el dispositivo es válido y la versión esperada. Esto solo se puede comprobar si hay dispositivos que aún no tienen el estado DeviceComplete.
• Las imágenes proporcionadas por el usuario en el dispositivo coinciden con la lista de imágenes esperadas. Esto solo se puede comprobar si hay dispositivos que aún no tienen el estado DeviceComplete.
• No hay redes Wi-Fi inesperadas configuradas en el dispositivo. Esto solo se puede comprobar si hay dispositivos que aún no tienen el estado DeviceComplete.
• El dispositivo no contiene ningún certificado de capacidad especial. Para los dispositivos basados en MT3620, esto solo se puede comprobar en dispositivos que no están en estado en blanco.

Se deben realizar diferentes comprobaciones en diferentes etapas de fabricación, ya que el estado de fabricación del dispositivo determina las capacidades del dispositivo.

Las comprobaciones que ejecute también dependerán de si está diseñando un módulo o un dispositivo conectado. Por ejemplo, como fabricante de un módulo, puede optar por dejar el chip en el estado Fabricación en blanco para que el cliente del módulo pueda realizar pruebas de radio y configuración adicionales.

Usar device_ready.py para realizar comprobaciones

El paquete muestras de fabricación incluye una herramienta denominada device_ready.py, que realiza las comprobaciones anteriores, según corresponda para cada estado de fabricación. Debe ejecutarse para cada uno de los estados de fabricación relevantes para el dispositivo.

En la tabla siguiente se enumeran los parámetros que toma el script device_ready.py:

El ejemplo siguiente es una ejecución de ejemplo de la device_ready.py herramienta con los siguientes argumentos:

• --os 22.07
• --os_components_json_file mt3620an.json
• --expected_mfg_state Module1Complete

device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS

Establecer el estado de fabricación del dispositivo

Las operaciones de fabricación confidenciales, como colocar la radio en modo de prueba y establecer Wi-Fi fusibles electrónicos de configuración, no deben ser accesibles para los usuarios finales de dispositivos que contienen un chip Azure Sphere. El estado de fabricación del dispositivo Azure Sphere restringe el acceso a estas operaciones confidenciales.

Los tres estados de fabricación son los siguientes:

• En blanco. El estado En blanco no limita las operaciones de fabricación en un chip. Los chips en estado En blanco pueden entrar en el modo de prueba de RF y se pueden programar sus fusibles electrónicos. Cuando los chips se envían desde la fábrica de placas, se encuentran en el estado Fabricación en blanco .

• Módulo1Completar. El estado de fabricación Module1Complete está diseñado para limitar los ajustes que los usuarios pueden realizar a los ajustes de configuración de radio, como los niveles máximos de potencia de transmisión y las frecuencias permitidas. Los comandos de RF se pueden usar hasta que se establezca Module1Complete . Es posible que sea necesario restringir el acceso de los usuarios finales a esta configuración para cumplir las directivas normativas relacionadas con el hardware de radio. Este ajuste afecta principalmente a los fabricantes que necesitan probar y calibrar los parámetros de funcionamiento de radio.

  Microsoft recomienda que establezcas este estado de fabricación después de haber completado las pruebas de radio y la calibración; Los comandos RF no se pueden utilizar después de que se establezca. El estado Módulo1Complete protege el dispositivo frente a cambios que pueden interrumpir el correcto funcionamiento de la radio y de otros dispositivos inalámbricos de las inmediaciones.

• DeviceComplete. El estado de fabricación DeviceComplete permite a los fabricantes de productos terminados proteger los dispositivos que se implementan en el campo contra cambios. Una vez que un dispositivo se coloca en el estado DeviceComplete , debe usarse un archivo de funcionalidad específico del dispositivo siempre que realice tareas de carga y configuración de software. La funcionalidad de desalojo de campos te permite realizar instalaciones de prueba de imágenes firmadas por producción, pero no eliminarlas. La funcionalidad de desarrollo de aplicaciones permite la instalación de prueba y la eliminación de imágenes.

  No establezca DeviceComplete para dispositivos o módulos no terminados (módulos Wi-Fi, paneles de desarrollo, etc.) que puedan usarse como parte de un sistema más grande; este estado limita las actividades de fabricación, como pruebas de línea de producción, instalación de software y configuración. Muchos comandos de la CLI no están disponibles después de establecer DeviceComplete y, por lo tanto, algunas comprobaciones listas para enviar deben ejecutarse antes de establecer este estado. Los comandos restringidos se pueden volver a habilitar mediante una funcionalidad de dispositivo como la funcionalidad de desalojo de campos , pero solo para los dispositivos que haya reclamado y, por tanto, esto no es adecuado para su uso en un entorno de fábrica, ya que requiere conectividad en la nube.

En la tabla siguiente se resumen las capacidades del dispositivo que están presentes para cada estado de fabricación.

Cuando se complete la fabricación, usa el comando az sphere device manufacturing-state update para establecer el estado DeviceComplete :

az sphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]