Operaciones de fábrica

La fabricación de dispositivos conectados que incorporan hardware de Azure Sphere implica varias operaciones de fábrica:

• Conexión de cada Azure Sphere chip a un equipo de fábrica
• Registro de identificadores de dispositivo
• Actualización del sistema operativo de Azure Sphere si es necesario
• Carga del software
• Ejecución de pruebas funcionales
• Habilitación Wi-Fi canales en mt3620
• Realización de pruebas de radiofrecuencia (RF) y calibración, si es necesario
• Comprobación de la configuración de radiofrecuencia
• Finalización del dispositivo

Lo primero es conectar el chip al equipo y, lo último, finalizar el dispositivo. El resto de operaciones puede realizarlas en el orden que mejor se adapte a su entorno de fabricación.

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

Durante la fabricación, debe conectar cada chip Azure Sphere a un equipo de fábrica. El equipo debe ejecutar Windows 10 v1607 (actualización de aniversario) o una versión más reciente.

Las herramientas de Azure Sphere se ejecutan en el equipo e interactúan con el chip a través de una interfaz de chip a equipo. Decida cómo implementar esta interfaz:

• Diseñe una tarjeta de interfaz que se conecte a su PC durante la fabricación.
• Cree una interfaz en cada dispositivo conectado. Por ejemplo, el diseño de la tarjeta de referencia MT3620 incluye esa interfaz.

La interfaz de depuración y programación de MCU proporciona más información sobre el diseño y los requisitos de la interfaz de chip a equipo.

Deberá instalar el SDK de Azure Sphere para conectar dispositivos a un equipo y realizar otras tareas de fábrica. Consulte Instalación de Azure Sphere para ver las instrucciones.

Puede conectar simultáneamente tantos dispositivos Azure Sphere al equipo como el subsistema USB del equipo lo permita. Las herramientas de Azure Sphere no limitan el número de dispositivos que se pueden conectar a la vez. Le recomendamos que solicite el paquete de ejemplos de fabricación, descrito anteriormente, para ayudarle a realizar tareas de fabricación a gran escala.

La CLI Azure Sphere admite varias características que permiten recopilar información sobre todos los dispositivos conectados a un equipo y realizar operaciones cuando hay varios dispositivos conectados.

Obtención de información sobre los dispositivos conectados

Puedes obtener información sobre todos los dispositivos de Azure Sphere conectados mediante el comando siguiente:

azsphere device list-attached

Este comando devuelve la dirección IP de cada dispositivo de Azure Sphere y un valor que identifica la conexión USB del dispositivo. Si el dispositivo responde, el comando también devuelve el identificador del dispositivo. Por ejemplo, lo siguiente muestra la salida para dos dispositivos:

2 devices attached:
--> Device ID: <deviceID>
  --> Is responsive: yes
  --> IP address: 192.168.35.2
  --> Connection path: 11433

--> Device ID: <deviceID>
  --> Is responsive: yes
  --> IP address: 192.168.35.3
  --> Connection path: 123

La dirección IP se asigna cuando se conecta al equipo una interfaz de dispositivo basada en FTDI; no indica que exista un dispositivo con capacidad de respuesta. La dirección IP persiste mientras la interfaz del dispositivo basada en FTDI está conectada al equipo, incluso si se conecta otro dispositivo de Azure Sphere a la interfaz. Sin embargo, después de reiniciar el equipo, la dirección IP puede cambiar. Al primer dispositivo que se conecta se le asigna la dirección 192.168.35.2.

La ruta de acceso de conexión es un identificador de ubicación de FTDI que identifica la conexión USB. La ubicación se conserva mientras la interfaz de dispositivo basada en FTDI está conectada al mismo puerto USB en el mismo concentrador USB y, a su vez, al mismo puerto en el equipo. Por lo tanto, se conserva al reiniciar. Sin embargo, cualquier cambio en la conexión entre el equipo y el dispositivo puede provocar cambios en la ruta de conexión. Al igual que la dirección IP, no cambia incluso si un dispositivo de Azure Sphere diferente está conectado a la interfaz FTDI.

Realización de operaciones en los dispositivos conectados

El comando azsphere device admite la identificación de un dispositivo por ubicación de FTDI o dirección IP:

• Dirección IP del dispositivo: identifica un dispositivo por su dirección IP, que azsphere device list-attached (solo Windows).
• Ubicación del dispositivo Ubicación de FTDI: identifica un dispositivo por su ruta de conexión, que se devuelve mediante azsphere device list-attached (solo Windows dispositivo).

Utilice cualquiera de estos parámetros para identificar el dispositivo al que se aplica un comando azsphere device<operation> . Puede especificar un único dispositivo por comando. Si hay más de un dispositivo conectado al equipo y no se especifica una dirección IP o una ubicación FTDI, se produce un error en el comando.

A cada dispositivo se le asigna una dirección IP, incluso si no responde, de modo que puede utilizar la dirección IP para identificar un dispositivo que requiere recuperación.

En la siguiente tabla se enumeran las operaciones azsphere con las que puede utilizar estos dos parámetros.

Actualización del sistema operativo de Azure Sphere

Todos los chips de Azure Sphere vienen con el sistema operativo correspondiente cuando el fabricante los envía. Según la versión del sistema operativo de Azure Sphere disponible en los chips del proveedor y según los requisitos de versión del sistema operativo de la aplicación, puede que tenga que actualizarlo durante la fabricación del dispositivo conectado.

Puede obtener los archivos de recuperación del sistema operativo de Azure Sphere más recientes disponibles para hardware basado en MT3620 después de aceptar los términos de la licencia.

Si el chip Azure Sphere no está en línea en la fábrica, puede actualizarlo cargando los archivos de recuperación en el equipo de fábrica y, a continuación, emitiendo el comando azsphere device recover a través de la interfaz de programación y depuración descrita anteriormente. Use el parámetro --images para instalar imágenes de recuperación específicas.

Los ejemplos de fabricación incluyen un script de ejemplo que realiza una recuperación de varios dispositivos en paralelo. Póngase en contacto con su representante de Microsoft para obtener este paquete.

Registro de identificadores de dispositivo

Como parte del proceso de fabricación, debe registrar los identificadores de dispositivo de todos los chips de Azure Sphere que su empresa incorpore en los dispositivos fabricados. Para obtener los iDs de dispositivo de todos los dispositivos conectados, use azsphere device list-attached.

Necesitará los identificadores de dispositivo durante la configuración en la nube para configurar los grupos de dispositivos y las implementaciones.

Carga del software

Todo el software que cargue, independientemente de si se trata de un archivo de configuración de tarjeta, una aplicación de prueba o una aplicación de producción pensada para el usuario final, debe incluir una firma de producción.

Durante la fabricación, los dispositivos de Azure Sphere no requieren funcionalidad de dispositivo especial como, por ejemplo, la funcionalidad appDevelopment, que habilita la depuración. La adquisición de funcionalidades para dispositivos individuales reduce la seguridad de estos y requiere conexión a Internet lo cual, normalmente, no es deseable en la planta de producción.

Obtención de imágenes con firma de producción

El servicio de seguridad de Azure Sphere incluye una firma de producción en cada imagen cuando la carga. Para evitar la necesidad de conexión a Internet, cree las imágenes con la firma de producción una vez, descárguelas del servicio de seguridad de Azure Sphere y guárdelas en un equipo de la fábrica para transferirlas localmente durante la fase de producción.

Para obtener una imagen firmada en producción, cárbala en Azure Sphere Security Service mediante el comando azsphere image:

azsphere image add --image <path-to-image-package>

azsphere image add --filepath <path-to-image-package>

Reemplace <path-to-image-package> por la ruta de acceso y el nombre del paquete de imagen que contiene el software. El servicio de seguridad incluye una firma de producción en la imagen y la conserva.

Las aplicaciones que están diseñadas para su uso durante la fase de pruebas de fábrica se deben identificar explícitamente como imágenes temporales. Esto garantiza que se pueden quitar estas aplicaciones al final del proceso de prueba. No use imágenes temporales para las aplicaciones que permanecerán en el dispositivo después de la fabricación o el proceso de actualización por vía aérea no funcionará correctamente. Para marcar una imagen como temporal, use el parámetro --temporary cuando cargue el archivo para la firma de producción:

azsphere image add --image <path-to-image-package> --temporary

azsphere image add --filepath <path-to-image-package> --temporary

Guarde el identificador del componente que muestra el comando; lo necesitará más adelante para quitar la imagen temporal del dispositivo.

Para descargar la imagen con la firma de producción, use el siguiente comando:

azsphere image download --image <image-id> --destination <file-path>

azsphere image download --imageid <image-id> --output <file-path>

Reemplace por el identificador de la imagen que se va a descargar y reemplace por la ruta de acceso y el nombre de archivo en los que se <image-id> va a guardar la imagen <file-path> descargada. El identificador de imagen aparece en la salida del comando azsphere image add.

Después de guardar la imagen con la firma de producción, ya no volverá a necesitar conexión a Internet.

Implementación y eliminación de imágenes

Para implementar una imagen firmada por producción en un dispositivo de fábrica, use el comando azsphere device sideload:

azsphere device sideload deploy --image-package <file-path> [--device <device IP or device FTDI location>]

azsphere device sideload deploy --imagepackage <file-path> [--deviceip <ip> | --devicelocation <FTDI location>]

Reemplace <file-path> por el nombre y la ruta de acceso al archivo de imagen descargado. Si hay varios dispositivos conectados al equipo, incluya el parámetro para identificar el dispositivo de destino mediante la dirección --device IP o la ubicación de FTDI. Consulte Realización de operaciones en los dispositivos conectados para más información sobre estos parámetros.

Si carga una aplicación temporal para realizar pruebas, use el siguiente comando para eliminarla una vez completadas:

azsphere device sideload delete --component-id <component id> [--device <device IP or device location>]

azsphere device sideload delete --componentid <component id> [--deviceip <ip> | --devicelocation <FTDI location>]

Ejecución de pruebas funcionales

Las pruebas funcionales comprueban que el producto funciona correctamente. Las pruebas concretas que se deben ejecutar dependen del hardware individual.

Puede organizar las pruebas como una sola aplicación de OEM o como una serie de aplicaciones. La documentación para el desarrollo de aplicaciones, los ejemplos de Azure Sphere y las plantillas de Azure Sphere SDK proporcionan información sobre el diseño de la aplicación. Sea cual sea el diseño que elija, esta aplicación debe incluir la firma de producción y se tiene que implementar mediante los pasos descritos en la sección anterior.

Algunos procesos de prueba requieren la comunicación con el chip que se está probando: para notificar errores, datos de registro o pruebas de secuencia. Si el proceso de pruebas requiere comunicación, puede usar UART periféricos en el dispositivo MT3620 (ISU0, ISU1, ISU2 o ISU3). Conecte estos UART al equipo de la fábrica o al equipo de pruebas externo mediante circuitos adecuados diseñados por usted. Si ha creado una tarjeta de interfaz para que se admita la comunicación de chip a equipo, puede que desee agregar estos circuitos a la tarjeta.

Realización de pruebas de radiofrecuencia y calibración

Los chips de Azure Sphere requieren conectividad inalámbrica para recibir actualizaciones de software y comunicarse con Internet. La operación de comprobación y calibración de la radiofrecuencia es, por tanto, una parte fundamental del proceso de fabricación. Si usa un módulo, puede que no se requieran determinados aspectos de las pruebas de radiofrecuencia. Para más información, consulte con el proveedor del módulo.

El paquete de herramientas de radiofrecuencia, disponible a petición, incluye utilidades y una biblioteca de API de C para su uso durante las pruebas. Mediante la biblioteca, puede programar configuraciones de radiofrecuencia (RF) específicas de un producto en fusibles electrónicos, como la configuración y la frecuencia de la antena, y puede ajustar los dispositivos individuales para un rendimiento óptimo. Consulte la siguiente sección Program e-fuses to enable Wi-Fi channels (Programación de e-fuses para habilitar los canales de Wi-Fi) para obtener más información sobre cómo la configuración de los e-fuses habilita los canales Wi-Fi que se permiten en la región de funcionamiento del dispositivo. Si la prueba necesita usar la herramienta para certificar el dispositivo, póngase en contacto con el representante de Microsoft antes de compartir el software con ellos.

La integración entre la biblioteca y el equipo de pruebas es responsabilidad suya. Actualmente, Microsoft se ha asociado con LitePoint para proporcionar una solución completa que integra la biblioteca de pruebas de radiofrecuencia de Azure Sphere con el equipo de LitePoint. Puede que en el futuro haya soluciones de otros proveedores de equipos de prueba.

El tema Herramientas de prueba de radiofrecuencia describe cómo usar las herramientas de radiofrecuencia.

Al mismo tiempo que la calibración de radiofrecuencia y de la red Wi-Fi, considere la posibilidad de conectarse a un punto de acceso Wi-Fi para comprobar que su aplicación de usuario final podrá comunicarse a través de la Wi-Fi. Asegúrese de que la conexión Wi-Fi no tiene acceso a Internet, ya que se puede producir una actualización vía inalámbrica si el chip se conecta a un punto de acceso habilitado para Internet. Después de realizar las pruebas de Wi-Fi, debe quitar los puntos de acceso Wi-Fi utilizados para la prueba del chip para que no sean visibles para los clientes. Para más información acerca de la configuración de Wi-Fi, consulte azsphere device wifi. Tenga en cuenta que la recuperación del dispositivo elimina todos los datos de configuración de Wi-Fi del chip.

Programación de mechas electrónicas para habilitar Wi-Fi canales

El sistema Azure Sphere selecciona Wi-Fi canales en función del código de región que se programa en los e-fuses MT3620 en direcciones de desplazamiento 0x36 y 0x37. Para obtener más información sobre los e-fuses en MT3620, consulte el documento Mediatek E-fuse Content Guidelines (Instrucciones de contenido de E-fuse mt3620).

El código de región es un código ASCII de dos letras. El Azure Sphere operativo usa la configuración de código de región en los fuses electrónicos para buscar la región en la base de datos normativa inalámbrica de Linux y, a continuación, selecciona los canales permitidos para esa región. Si no hay ningún código de región programado en los fuses electrónicos, en cuyo caso los e-fuses permanecen establecidos en 0x00 0x00, o si se programan los caracteres "00", el sistema operativo tiene como valor predeterminado un conjunto conservador de canales que generalmente se permiten en todas las regiones. Los canales permitidos para la región "00" se especifican en la base de datos normativa inalámbrica de Linux.

La configuración del código de región en los dispositivos 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 asigna a un conjunto permitido de canales para la región de funcionamiento. A menudo, diferentes regiones y países adoptan normativas similares o idénticas, lo que puede permitir que los códigos de región se utilicen 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 e-fuses de las direcciones 0x36 y 0x37. A continuación se muestran los canales permitidos para Alemania, extractos de la base de datos normativa inalámbrica de Linux. 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)

Comprobación de la configuración de radiofrecuencia

Utilice RfSettingsTool para comprobar que las opciones de configuración de radiofrecuencia como, por ejemplo, la potencia de transmisión de destino, el código de región y la dirección MAC se han establecido correctamente. La documentación de la herramienta de configuración de radiofrecuencia proporciona más información sobre su uso.

Configuración de Ethernet

Azure Sphere admite conexiones Ethernet mediante el controlador Ethernet ENC28J60. Para más información, consulte Conexión de adaptadores Ethernet a la placa de desarrollo MT3620.

Comportamiento predeterminado de la dirección MAC

La dirección Access Control multimedia (MAC) es una dirección de hardware que identifica de forma única cada placa. La dirección MAC de ENC28J60 se genera aleatoriamente cuando se configura la placa. Aunque la dirección MAC se conserva durante la actualización del sistema operativo o cuando se configura la placa, se aleatoriza durante la recuperación del dispositivo y puede interrumpir las funcionalidades que requieren una dirección MAC estática.

Dirección administrada universalmente

Si necesita establecer la dirección MAC en función de un identificador único organizativo (OUI), están disponibles las siguientes opciones:

La dirección MAC se establece manualmente después de la recuperación del dispositivo

En este caso, la dirección MAC del dispositivo se establece en la fábrica de Azure Sphere y se puede personalizar para permitir que el fabricante use una dirección que se correlaciona con su bloque MAC emitido por IEEE.

Durante la recuperación del dispositivo, se genera una nueva dirección MAC de forma aleatoria y se asigna a la placa. Si el dispositivo se devuelve al fabricante o se recupera, se puede usar la utilidad de línea de comandos Azure Sphere para volver a establecer el dispositivo en la dirección MAC original después de la recuperación mediante la actualización de la interfaz de red Ethernet para el dispositivo.

La dirección MAC se conserva después de la recuperación del dispositivo

En este caso, la dirección MAC original se puede establecer automáticamente después de la recuperación. Debido al hecho de que el almacenamiento no volátil no existe en LA ENC28J60, el fabricante debe agregar almacenamiento adicional (como EEPROM) y el fabricante debe almacenar la dirección MAC como parte del procesamiento de fábrica.

A continuación, se accede a este almacenamiento externo en tiempo de ejecución para leer y establecer la dirección MAC mediante una llamada a la Networking_SetHardwareAddress función. Cuando se recupera el dispositivo y se vuelve a cargar la aplicación, lee desde el almacenamiento externo y establece la dirección MAC del sistema.

Finalización del dispositivo de Azure Sphere

La finalización garantiza que el dispositivo de Azure Sphere se encuentra en un estado protegido y está listo para enviarse a los clientes. Debe finalizar el dispositivo antes de proceder a su envío. La finalización incluye:

• Ejecución de comprobaciones finales previas al envío para asegurarse de que están instalados el software de sistema correcto y la aplicación de producción, y de que las herramientas de radiofrecuencia están deshabilitadas.

• Establecimiento del estado de fábrica del dispositivo para bloquear las herramientas de configuración de RF y calibración y prevenir brechas de seguridad.

Ejecución de comprobaciones listas para enviar

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

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

Se necesita realizar comprobaciones diferentes en distintas fases 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 módulos, puede dejar el chip en estado de fabricación En blanco para que el cliente del módulo pueda realizar pruebas de radio y configuración adicionales.

DeviceReady.py

El paquete ejemplos de fabricación incluye un script de Python de ejemplo deviceready.py, que realiza las comprobaciones anteriores, según corresponda para cada estado de fabricación. También se muestra cómo ejecutar las herramientas de CLI de Azure Sphere para realizar estas comprobaciones de dispositivos mediante programación como parte de un entorno de pruebas automatizadas. El script deviceready.py se puede usar tal y como está o se puede modificar para que se adapte a sus necesidades. Debe ejecutarse para cada uno de los estados de fabricación pertinentes para el dispositivo.

El script deviceready.py toma los dos parámetros siguientes:

• --expected_mfg_state

  Determina qué estado de fabricación se va a comprobar y controla qué pruebas se ejecutan. Si no se especifica este parámetro, el valor predeterminado es "DeviceComplete". Si el estado de fabricación del dispositivo difiere de este valor, se produce un error en la comprobación.

• --images

  Especifica la lista de los IDs de imagen que deben estar presentes en el dispositivo para que la comprobación se haga correctamente. Este parámetro tiene como valor predeterminado la lista vacía si no se especifica. Si la lista de los IDs de imagen instalados en el dispositivo difiere de esta lista, se produce un error en la comprobación. Al comprobar los ID de imagen (en lugar de los de componente), esta comprobación garantiza que existe una versión específica de un componente.

• --os

  Especifica una lista de las versiones del sistema Azure Sphere sistema operativo. Este parámetro tiene como valor predeterminado la lista vacía si no se proporciona. Si la versión del sistema operativo presente en el dispositivo no está en esta lista, se produce un error en esta comprobación.

• --os_components_json_file

  Especifica la ruta de acceso al archivo JSON que enumera los componentes del sistema operativo que definen cada versión del sistema operativo. En el caso de los dispositivos basados en MT3620, este archivo se denomina mt3620an.json. El archivo mt3620an.json no forma parte del paquete de ejemplos de fabricación y solo está disponible mediante la descargade . Si no se especifica, este parámetro tiene como valor predeterminado un archivo denominado "mt3620an.json" en la misma ubicación que el script.

• --azsphere_path

  Especifica la ruta de acceso a la azsphere.exe de acceso. Si no se especifica, este parámetro tiene como valor predeterminado la ubicación de instalación predeterminada para el SDK de Azure Sphere en Windows. Use este parámetro solo si Azure Sphere SDK no está instalado en la ubicación predeterminada.

• --help

  Muestra la ayuda de la línea de comandos.

• --verbose

  Proporciona detalles de salida adicionales.

Una invocación de ejemplo del script deviceready.py, cuando se ejecuta desde la misma carpeta que el archivo deviceready.py y con el archivo mt3620an.json descargado en la misma carpeta, tiene el siguiente aspecto:

> python .\deviceready.py --os 20.10 --images e6ca6889-96d3-4675-bbe5-251e11d02de0 --expected_mfg_state Module1Complete

Establecimiento del estado de fábrica del dispositivo

Las operaciones de fabricación más delicadas, como la colocación del dispositivo de radio en modo de prueba o la configuración de los fusibles electrónicos de configuración de Wi-Fi, no deberían ser accesibles para los usuarios finales de los dispositivos que contienen un chip de Azure Sphere. El estado de fabricación del dispositivo de Azure Sphere restringe el acceso a estas operaciones confidenciales. Los estados de fabricación incluyen:

• Blank. El estado Blank no limita las operaciones de fabricación en un chip. Los chips en estado Blank (En blanco) pueden entrar en el modo de prueba de RF y se pueden programar sus e-fuses. Cuando los chips se envían desde la fábrica de silicon, se encuentran en estado de fabricación en blanco.

• Module1Complete. El estado de fabricación Module1Complete está diseñado para limitar los ajustes que los usuarios pueden realizar en los valores de configuración de radio, como los niveles máximos de energía de transmisión y las frecuencias permitidas. Los comandos rf se pueden usar hasta que se establezca Module1Complete. Es posible que sea necesario restringir el acceso del usuario final a esta configuración para satisfacer las directivas regulatorias sobre hardware de radio. Esta configuración afecta principalmente a los fabricantes que necesitan probar y calibrar parámetros operativos de radio.

  Microsoft recomienda establecer este estado de fábrica después de que se hayan completado las pruebas de radio y la calibración; los comandos de RF no se pueden usar una vez establecido. Module1State protege el dispositivo frente a cambios que pueden interrumpir el funcionamiento correcto de la radio y otros dispositivos inalámbricos en la proximidad.

• DeviceComplete. El estado de fabricación DeviceComplete permite a los fabricantes de productos terminados proteger los dispositivos que se implementan en el campo frente a cambios. Una vez que un dispositivo se coloca en el estado DeviceComplete, se debe usar un archivo de funcionalidad específico del dispositivo siempre que se realice cualquier tarea de carga y configuración de software. La funcionalidad fieldservicing permite realizar la instalación local de imágenes firmadas en producción, pero no eliminarlas. La funcionalidad appdevelopment permite la instalación de pruebas y la eliminación de imágenes.

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

Una vez completada la fabricación, use el comando manufacturing-state update para establecer el estado DeviceComplete:

azsphere device manufacturing-state update --state <desired state> [--device <device IP or device FTDI location>]

azsphere device manufacturing-state update --state <desired state> [--deviceip <ip> | --devicelocation <FTDI location>]