Tarefas de chão de fábrica
Importante
Esta é a documentação do Azure Sphere (Legado). O Azure Sphere (Legado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (Integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).
A fabricação de dispositivos conectados que incorporam hardware do Azure Sphere envolve as seguintes tarefas de chão de fábrica para preparar dispositivos para envio:
- Ligar cada chip do Azure Sphere a um PC de chão de fábrica
- Obter detalhes do dispositivo e gravá-los para uso posterior
- Atualizando o sistema operacional Azure Sphere, se necessário
- Atualize o armazenamento de chaves confiável, se necessário
- Carregando software no dispositivo
- Execução de testes funcionais para verificar o funcionamento correto do produto
- Realização de testes e calibração de radiofrequência (RF)
- Verificar a comunicação Wi-Fi
- Configurando o dispositivo para Ethernet
- Finalizando o dispositivo Azure Sphere para envio
Você deve conectar o chip ao PC primeiro, obter detalhes do dispositivo em segundo lugar e finalizar o dispositivo por último, mas você pode executar as outras tarefas em qualquer ordem que se adapte ao seu ambiente de fabricação.
Importante
Você deve fazer alguma preparação para ajudar a garantir que suas tarefas de chão de fábrica possam ser concluídas sem atrasos. A preparação inclui a configuração do PC de chão de fábrica e qualquer outro equipamento necessário e a instalação das ferramentas de software de PC necessárias. Todas as tarefas que você deve fazer para se preparar para um processo de fabricação suave são descritas em Preparação do processo de fabricação.
Conecte cada chip do Azure Sphere a um PC de chão de fábrica
Durante a fabricação, você deve conectar cada chip do Azure Sphere a um PC de chão de fábrica. Se você quiser conectar simultaneamente vários dispositivos do Azure Sphere a um único PC, consulte Equipamento para tarefas de chão de fábrica nas tarefas de preparação de fabricação.
A maioria das tarefas de chão de fábrica envolve o comando azsphere device. Quando você tiver vários dispositivos conectados ao PC, deverá especificar o dispositivo no qual aplicar o comando azsphere device incluindo o --device parâmetro definido para o endereço IP do dispositivo ou o caminho de conexão do dispositivo. O comando falhará se o --device parâmetro for omitido e vários dispositivos forem anexados. Para obter o endereço IP ou o caminho de conexão, consulte Obter detalhes do dispositivo.
Importante
A versão do SDK do Azure Sphere 23.05 e versões posteriores oferecem suporte à comunicação com vários dispositivos conectados no Windows e Linux.
Obter detalhes do dispositivo
Você deve registrar a ID do dispositivo de cada chip do Azure Sphere que sua empresa incorpora em produtos fabricados. Você precisará do ID do dispositivo para tarefas de configuração de nuvem.
Se você tiver vários dispositivos conectados ao PC de fábrica, também deverá registrar o endereço IP ou o caminho de conexão dos dispositivos conectados para uso posterior em tarefas de chão de fábrica. Conforme explicado em Conectar cada chip do Azure Sphere, o endereço IP ou o caminho de conexão é necessário para especificar o dispositivo de destino quando há vários dispositivos conectados.
Para obter o ID do dispositivo, o endereço IP e o caminho de conexão dos dispositivos conectados, use o comando azsphere device list-attached . As descrições a seguir fornecem detalhes essenciais sobre a ID do dispositivo, o endereço IP e o caminho de conexão.
ID do dispositivo — O fabricante do silício cria o ID do dispositivo, armazena-o no chip e regista-o na Microsoft. Esse registro de dispositivo garante que a Microsoft esteja ciente de todos os chips do Azure Sphere e que apenas chips legítimos possam ser usados em dispositivos conectados.
Endereço IP — O endereço IP é atribuído quando uma interface de dispositivo baseada em FTDI é conectada ao PC; ele não indica que um dispositivo responsivo está presente. O endereço IP persiste enquanto a interface de dispositivo baseada em FTDI está conectada ao PC, mesmo que um dispositivo diferente do Azure Sphere esteja conectado à interface. Após uma reinicialização do PC, no entanto, o endereço IP pode mudar. A primeira interface de dispositivo baseada em FTDI a ser anexada recebe o endereço 192.168.35.2. A cada dispositivo é atribuído um endereço IP, mesmo que não responda, para que possa utilizar o endereço IP para identificar um dispositivo que necessite de recuperação.
Caminho de conexão — O caminho de conexão é um ID de local FTDI que identifica a conexão USB. O ID de localização persiste enquanto a interface do dispositivo baseada em FTDI está conectada à mesma porta USB no mesmo hub USB e, por sua vez, à mesma porta no PC. Assim, ele persiste durante a reinicialização. No entanto, quaisquer alterações na fiação entre o PC e o dispositivo podem resultar em alterações no caminho de conexão. Como o endereço IP, ele não muda mesmo se um dispositivo diferente do Azure Sphere estiver conectado à interface FTDI.
Atualizar o SO do Azure Sphere
Cada chip do Azure Sphere é carregado com o sistema operacional Azure Sphere quando é enviado do fabricante do silício. Dependendo da versão do sistema operacional Azure Sphere em chips disponíveis em seu fornecedor e dependendo dos requisitos de versão do sistema operacional do seu aplicativo, talvez seja necessário atualizar o sistema operacional Azure Sphere durante a fabricação do dispositivo conectado. Você pode atualizar o sistema operacional instalando imagens de recuperação específicas, que já devem estar presentes no seu PC. Consulte Preparar para uma atualização do sistema operacional nas tarefas de preparação de fabricação. Os exemplos de fabricação incluem um script de exemplo que executa a recuperação paralela de vários dispositivos.
Você pode atualizar o sistema operacional no dispositivo Azure Sphere emitindo o comando azsphere device recover. Use o --images parâmetro para instalar imagens de recuperação específicas:
azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]
Nota
Se vários dispositivos estiverem conectados ao PC, inclua o --device parâmetro para identificar o dispositivo de destino por endereço IP ou caminho de conexão. Consulte Conectar cada chip do Azure Sphere a um PC de chão de fábrica para obter detalhes.
Atualizar o armazenamento de chaves confiável
Como pré-requisito para carregar software no seu dispositivo, pode ser necessário atualizar o armazenamento de chaves confiável no dispositivo. Isso é necessário somente se o sistema operacional no dispositivo for mais antigo do que seu software e somente se a chave de assinatura de imagem do Azure Sphere usada pelo AS3 tiver sido atualizada entre o sistema operacional que está sendo publicado e o software que está sendo assinado em produção. Para evitar essa etapa e reduzir o tempo de fabricação, considere atualizar a versão do sistema operacional que você está usando durante a fabricação.
Você pode determinar facilmente se a atualização do armazenamento de chaves confiável é necessária, tentando carregar seu software de acordo com as instruções na próxima seção. Se o carregamento for bem-sucedido, você não precisará atualizar o armazenamento de chaves confiável. Se o carregamento falhar com a mensagem começando com Internal device error: Image not trusted by device , em seguida, um keystore confiável desatualizado é a causa.
Para atualizar o armazenamento de chaves confiável, você precisa ter adquirido o arquivo de armazenamento de chaves confiável atualizado. Em seguida, como parte de seus scripts de fabricação, use o comando azsphere device sideload deploy para carregar o keystore confiável atualizado antes de carregar o software do aplicativo, substituindo <path-to-trusted-keystore.bin> pelo caminho para o arquivo keystore confiável:
azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]
Carregar software do dispositivo
Todo o software que você carregar, independentemente de ser uma imagem de configuração de placa, um aplicativo de teste ou um aplicativo de produção, deve ser assinado em produção. Se você carregar um aplicativo temporário para teste, deverá excluí-lo após a conclusão do teste.
Todas as imagens assinadas de produção de que você precisa durante o processo de chão de fábrica devem ser salvas em seu PC de chão de fábrica antes de iniciar o processo, conforme descrito em Obter imagens assinadas de produção nas tarefas de preparação de fabricação.
Durante a fabricação, os dispositivos do Azure Sphere não devem exigir nenhum recurso de dispositivo especial, como o recurso de desenvolvimento de aplicativos, que permite a depuração. A aquisição de recursos para dispositivos individuais reduz a segurança do dispositivo e requer conectividade com a Internet, o que normalmente é indesejável no chão de fábrica.
Para carregar software em um dispositivo de fábrica ou excluir software temporário de um dispositivo após a conclusão do teste, use o comando azsphere device sideload da seguinte maneira:
Use azsphere device sideload deploy para carregar uma imagem, substituindo
<file-path>pelo nome e caminho para o arquivo de imagem assinado em produção:azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
Use azsphere device sideload delete para excluir uma imagem temporária, substituindo
<component-id>pelo ID do componente da imagem a ser excluída:azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
Nota
Se vários dispositivos estiverem conectados ao PC, inclua o --device parâmetro para identificar o dispositivo de destino por endereço IP ou caminho de conexão. Consulte Conectar cada chip do Azure Sphere a um PC de chão de fábrica para obter detalhes.
Executar testes funcionais
São necessários testes funcionais para verificar se o produto funciona corretamente. Execute os aplicativos que você desenvolveu para testes funcionais como parte das tarefas de preparação de fabricação. Consulte Desenvolver aplicativos para testes funcionais.
Se seus testes funcionais exigirem comunicação com o chip que está sendo testado, conecte as UARTs periféricas MT3620 (ISU0, ISU1, ISU2 ou ISU3) ao seu PC de chão de fábrica ou equipamento de teste externo através de circuitos adequados de seu próprio design.
Realizar testes e calibração de radiofrequência (RF)
Os chips do Azure Sphere podem usar Wi-Fi para receber atualizações de software e se comunicar com a Internet. Se o seu produto usa Wi-Fi e incorpora um design de chip down ou um módulo que não é certificado por RF, você deve realizar testes e calibração de RF para cada dispositivo. Os equipamentos e ferramentas necessários para esta tarefa estão descritos em Equipamentos e software para testes de RF e calibração nas tarefas de preparação de fabricação.
O pacote RF Tools inclui utilitários e uma biblioteca de API C para uso durante os testes. Você pode usar a biblioteca C API para programar configurações de RF específicas do produto em e-fuses. Por exemplo, os fusíveis eletrónicos são programados para configurar a antena e a frequência, para sintonizar dispositivos para um desempenho ideal e para ativar canais Wi-Fi. O tópico Ferramentas de teste de RF descreve como usar as ferramentas de RF.
Programe fusíveis eletrónicos para ativar canais Wi-Fi
O SO Azure Sphere seleciona canais Wi-Fi com base no código de região programado nos fusíveis eletrónicos MT3620 nos endereços de deslocamento 0x36 e 0x37. Para obter detalhes sobre fusíveis eletrônicos no MT3620, consulte o documento Mediatek MT3620 E-fuse Content Guidelines .
O código de região é um código ASCII de duas letras. O sistema operacional Azure Sphere usa a configuração de código de região nos fusíveis eletrônicos para pesquisar a região no banco de dados regulatório sem fio do Linux e, em seguida, seleciona os canais permitidos para essa região. Se nenhum código de região for programado nos e-fuses, caso em que os e-fusíveis permanecerão definidos como 0x00 0x00, ou se os caracteres "00" forem programados, o sistema operacional assume como padrão um conjunto conservador de canais que geralmente são permitidos em todas as regiões. Os canais permitidos para a região "00" são especificados no banco de dados regulatório sem fio Linux.
A configuração do código de região nos fusíveis eletrônicos não precisa corresponder ao país onde o dispositivo será usado. Os fabricantes podem escolher qualquer código de região que mapeie para um conjunto permitido de canais para a região de operação. Diferentes regiões e países adotam frequentemente regulamentos semelhantes ou idênticos, o que pode permitir que os códigos de região sejam usados indistintamente.
Exemplo: Para instruir o SO Azure Sphere a selecionar canais Wi-Fi para a região "DE" (Alemanha), programe 0x44=D e 0x45=E nos fusíveis eletrónicos nos endereços 0x36 e 0x37. Os canais permitidos para a Alemanha, extraídos do banco de dados regulatório sem fio Linux, são mostrados abaixo. A maioria dos países da União Europeia (UE) permite o mesmo conjunto de canais.
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)
Verificar a configuração de RF
Use o RfSettingsTool para verificar se as opções de configuração de rádio, como potência de transmissão de destino, código de região e endereço MAC (Wi-Fi Media Access Control), foram definidas corretamente. A documentação da ferramenta de configurações de RF fornece mais informações sobre como usar essa ferramenta.
Verificar a comunicação Wi-Fi
Considere conectar-se a um ponto de acesso Wi-Fi para verificar se o aplicativo do produto é capaz de se comunicar por Wi-Fi. Certifique-se de que a ligação Wi-Fi não tem acesso à Internet, porque pode ocorrer uma atualização over-the-air se o chip se ligar a um ponto de acesso com acesso à Internet.
Para conectar um dispositivo a um ponto de acesso Wi-Fi, siga as instruções no Guia de início rápido (guia CLI). Se vários dispositivos estiverem conectados ao PC, você deverá incluir o --device parâmetro no comando azsphere device wifi show-status e no comando azsphere device wifi add. Para obter detalhes sobre como usar o comando azsphere device com vários dispositivos conectados, consulte Conectar cada chip do Azure Sphere a um PC de fábrica.
Após o teste de Wi-Fi, você deve remover todos os pontos de acesso Wi-Fi usados para testes do chip para que eles não fiquem visíveis para os clientes. A recuperação do dispositivo remove todos os dados de configuração Wi-Fi do chip.
Configurar o dispositivo para Ethernet
Um dispositivo Azure Sphere pode se comunicar por Ethernet. O dispositivo requer um adaptador Ethernet externo e uma imagem de configuração da placa para comunicação através de Ethernet.
Para configurar um dispositivo Azure Sphere para Ethernet, conecte um adaptador Ethernet ao dispositivo Azure Sphere, conforme descrito em Conectando adaptadores Ethernet.
Dois dispositivos Ethernet são suportados pelo Sistema Operacional Azure Sphere.
- Microchip ENC28J60. Este é um adaptador 10Base-T (10mbps). Pode ser ligado com um indicador LED à velocidade half-duplex ou sem um indicador LED à velocidade full-duplex. Os devkits Seeed são conectados para operação half-duplex.
- Wiznet W5500. Este é um adaptador 100Base-TX (100mpbs). Ele dá suporte a uma pilha TCP/IP integrada e modos de passagem NIC, mas o Azure Sphere só dá suporte a passagem NIC ao usar o W5500 para conectividade com a Internet. Devido a limitações de largura de banda de barramento, a velocidade total de 100mbps pode não ser alcançável pelo dispositivo MT3620.
A interface Ethernet será ativada automaticamente assim que a configuração da placa for carregada, conforme descrito em Carregar software do dispositivo, e o dispositivo for reinicializado. Todas as interfaces usam endereços IP dinâmicos por padrão.
Finalizar o dispositivo Azure Sphere
A finalização garante que o dispositivo Azure Sphere esteja em um estado seguro e pronto para ser enviado aos clientes. Você deve finalizar o dispositivo antes de enviá-lo. A finalização envolve:
Execução de verificações prontas para envio para garantir que o software do sistema e o aplicativo de produção corretos estejam instalados e as ferramentas de RF estejam desativadas.
Definir o estado de fabricação do dispositivo para bloquear as ferramentas de configuração e calibração de RF e evitar violações de segurança.
Executar verificações prontas para envio
É importante executar verificações prontas para envio antes de enviar um produto que inclua um dispositivo Azure Sphere. Devem ser realizadas verificações diferentes para diferentes estados de fabrico. Os controlos prontos a embarcar asseguram o seguinte:
- O estado de fabricação do dispositivo está definido corretamente para esse estágio de fabricação.
- O sistema operacional Azure Sphere no dispositivo é válido e a versão esperada. Isso só pode ser verificado para dispositivos que ainda não estão no estado DeviceComplete.
- As imagens fornecidas pelo usuário no dispositivo correspondem à lista de imagens esperadas. Isso só pode ser verificado para dispositivos que ainda não estão no estado DeviceComplete.
- Nenhuma rede Wi-Fi inesperada está configurada no dispositivo. Isso só pode ser verificado para dispositivos que ainda não estão no estado DeviceComplete.
- O dispositivo não contém quaisquer certificados de capacidade especial. Para dispositivos baseados em MT3620, isso só pode ser verificado em dispositivos que não estejam no estado em branco.
São necessárias verificações diferentes em diferentes fases de fabrico porque o estado de fabrico do dispositivo determina as capacidades do dispositivo.
As verificações que você executa também dependerão se você está projetando um módulo ou um dispositivo conectado. Por exemplo, como fabricante de módulos, você pode optar por deixar o chip no estado de fabricação em branco para que o cliente do módulo possa realizar testes e configurações de rádio adicionais.
Use device_ready.py para executar verificações
O pacote Manufacturing Samples inclui uma ferramenta chamada device_ready.py, que executa as verificações acima, conforme apropriado para cada estado de fabricação. Ele deve ser executado para cada um dos estados de fabricação relevantes para o seu dispositivo.
A tabela a seguir lista os parâmetros que o script device_ready.py assume:
| Parâmetro | Description |
|---|---|
--expected_mfg_state |
Determina qual estado de fabricação deve ser verificado e controla quais testes são executados. Se esse parâmetro não for especificado, o padrão será "DeviceComplete". Se o estado de fabricação do dispositivo for diferente desse valor, a verificação falhará. |
--images |
Especifica a lista de IDs de imagem (GUIDs) que devem estar presentes no dispositivo para que a verificação seja bem-sucedida. A lista consiste nos GUIDs de imagem separados por espaços. Este parâmetro assume como padrão a lista vazia se não for especificado. Se a lista de IDs de imagem instalados no dispositivo for diferente dessa lista, a verificação falhará. Ao verificar IDs de imagem (em vez de IDs de componentes), essa verificação garante que uma versão específica de um componente esteja presente. |
--os |
Especifica uma lista de versões do sistema operacional Azure Sphere. Este parâmetro assume como padrão a lista vazia se não for fornecido. Se a versão do SO presente no dispositivo não estiver nesta lista, esta verificação falhará. |
--os_components_json_file |
Especifica o caminho para o arquivo JSON que lista os componentes do sistema operacional que definem cada versão do sistema operacional. Para dispositivos baseados em MT3620, este arquivo é chamado mt3620an.json. Use a download_os_list.py ferramenta para baixar a versão mais recente. |
--azsphere_path |
Especifica o caminho para o utilitário azsphere.exe. Se não for especificado, esse parâmetro assume como padrão o local de instalação padrão do SDK do Azure Sphere no Windows. Use esse parâmetro somente se o SDK do Azure Sphere não estiver instalado no local padrão. |
--help |
Mostra a ajuda da linha de comando. |
--verbose |
Fornece detalhes adicionais de saída. |
O exemplo a seguir é um exemplo de execução da device_ready.py ferramenta com os seguintes 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
Definir o estado de fabricação do dispositivo
Operações de fabricação confidenciais, como colocar o rádio no modo de teste e definir fusíveis eletrônicos de configuração Wi-Fi, não devem ser acessíveis aos usuários finais de dispositivos que contêm um chip do Azure Sphere. O estado de fabricação do dispositivo Azure Sphere restringe o acesso a essas operações confidenciais.
Os três estados industriais são os seguintes:
Em branco. O estado em branco não limita as operações de fabricação em um chip. Os chips no estado em branco podem entrar no modo de teste de RF e seus fusíveis eletrônicos podem ser programados. Quando os chips são enviados da fábrica de silício, eles estão no estado de fabricação em branco .
Módulo1Completo. O estado de fabricação do Module1Complete foi projetado para limitar os ajustes que os usuários podem fazer nas definições de configuração de rádio, como níveis máximos de potência de transmissão e frequências permitidas. Os comandos RF podem ser usados até que Module1Complete esteja definido. Pode ser necessário restringir o acesso do utilizador final a estas definições para satisfazer as políticas regulamentares relativas ao hardware de rádio. Essa configuração afeta principalmente os fabricantes que precisam testar e calibrar os parâmetros de operação do rádio.
A Microsoft recomenda que você defina esse estado de fabricação após a conclusão do teste e calibração de rádio; Os comandos RF não podem ser usados depois de definidos. O estado Module1Complete protege o dispositivo contra alterações que possam perturbar o funcionamento adequado do rádio e de outros dispositivos sem fios nas imediações.
DeviceComplete. O estado de fabricação DeviceComplete permite que os fabricantes de produtos acabados protejam os dispositivos implantados no campo contra alterações. Depois que um dispositivo é colocado no estado DeviceComplete, um arquivo de capacidade específico do dispositivo deve ser usado sempre que executar qualquer tarefa de carregamento e configuração de software. O recurso de manutenção de campo permite fazer sideload de imagens assinadas pela produção, mas não excluí-las. O recurso de desenvolvimento de aplicativos permite sideload e exclusão de imagens.
Não defina DeviceComplete para dispositivos ou módulos inacabados (módulos Wi-Fi, placas de desenvolvimento e assim por diante) que possam ser usados como parte de um sistema maior, esse estado limita as atividades de fabricação, como testes de linha de produção, instalação de software e configuração. Muitos comandos da CLI não estão disponíveis depois que DeviceComplete é definido e, portanto, certas verificações prontas para envio devem ser executadas antes que esse estado seja definido. Os comandos restritos podem ser reativados usando um recurso de dispositivo, como o recurso de manutenção de campo, mas apenas para dispositivos que você reivindicou e, portanto, isso não é apropriado para uso em um ambiente de fábrica, pois requer conectividade em nuvem.
A tabela a seguir resume os recursos do dispositivo presentes para cada estado de fabricação.
| Estado de fabricação | Capacidades do dispositivo |
|---|---|
| Em branco | enableRfTestMode, fieldServicing, e aqueles que são sideloaded ou passados com uma operação, conforme descrito em Recursos do dispositivo. |
| Módulo1Completo | fieldServicing e aqueles que são sideloaded ou passados com uma operação, conforme descrito em Recursos do dispositivo. |
| DispositivoCompleto | Somente aqueles que são sideloaded ou passados com uma operação, conforme descrito em Recursos do dispositivo. |
Quando a fabricação estiver concluída, use o comando azsphere device manufacturing-state update para definir o estado DeviceComplete:
azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]
Nota
Se vários dispositivos estiverem conectados ao PC, inclua o --device parâmetro para identificar o dispositivo de destino por endereço IP ou caminho de conexão. Consulte Conectar cada chip do Azure Sphere a um PC de chão de fábrica para obter detalhes.
Importante
Mover um chip para o estado DeviceComplete é uma operação permanente e não pode ser desfeita. Uma vez que um chip está no estado DeviceComplete , ele não pode entrar no modo de teste de RF, suas configurações de fusível eletrônico não podem ser ajustadas e as configurações de Wi-Fi, atualizações do sistema operacional e aplicativos instalados não podem ser alterados sem reivindicar o dispositivo e usar uma capacidade do dispositivo. Se você precisar reativar funções em um chip individual que os recursos do dispositivo não reativam, como em um cenário de análise de falha, entre em contato com a Microsoft.