Tarefas do chão de fábrica

A fabricação de dispositivos conectados que incorporam o hardware do Azure Sphere envolve as seguintes tarefas de chão de fábrica para preparar dispositivos para envio:

• Conectar cada chip do Azure Sphere a um computador de fábrica
• Obter detalhes do dispositivo e gravá-los para uso posterior
• Atualizando o sistema operacional do Azure Sphere, se necessário
• Atualizar o repositório de chaves confiável, se necessário
• Carregar software no dispositivo
• Executando testes funcionais para verificar a operação correta do produto
• Executar testes e calibragem de RF (radiofrequência)
• Verificando Wi-Fi comunicação
• Configurando o dispositivo para ethernet
• Finalizando o dispositivo do Azure Sphere para envio

Você deve conectar o chip primeiro ao computador, obter detalhes do dispositivo em segundo lugar e finalizar o dispositivo por último, mas você pode executar as outras tarefas em qualquer ordem que atenda ao seu ambiente de fabricação.

Conectar cada chip do Azure Sphere a um computador de fábrica

Durante a fabricação, você deve conectar cada chip do Azure Sphere a um computador de fábrica. Se você quiser conectar simultaneamente vários dispositivos do Azure Sphere a um único computador, consulte Equipamentos para tarefas de chão de fábrica nas tarefas de preparação de fabricação.

A maioria das tarefas do chão de fábrica envolve o comando do dispositivo az sphere . Quando você tem vários dispositivos anexados ao computador, você deve especificar o dispositivo no qual aplicar o comando do dispositivo az sphere , 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 da conexão, consulte Obter detalhes do dispositivo.

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á da ID do dispositivo para tarefas de configuração de nuvem.

Se você tiver vários dispositivos anexados ao computador de chão de fábrica, também deverá registrar o endereço IP ou o caminho de conexão de dispositivos anexados 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 são necessários para especificar o dispositivo de destino quando houver vários dispositivos anexados.

Para obter a ID do dispositivo, o endereço IP e o caminho de conexão dos dispositivos anexados, use o comando az sphere device list-attached . As descrições a seguir fornecem detalhes essenciais sobre a ID do dispositivo, o endereço IP e o caminho da conexão.

• ID do dispositivo — O fabricante de silício cria a ID do dispositivo, armazena-o no chip e registra-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 podem ser usados em dispositivos conectados.

• Endereço IP – o endereço IP é atribuído quando uma interface de dispositivo baseada em FTDI é anexada ao computador; ele não indica que um dispositivo responsivo esteja presente. O endereço IP persiste enquanto a interface do dispositivo baseada em FTDI é anexada ao computador, mesmo que um dispositivo Azure Sphere diferente esteja conectado à interface. No entanto, após uma reinicialização do computador, o endereço IP pode ser alterado. A primeira interface de dispositivo baseada em FTDI a ser anexada recebe o endereço 192.168.35.2. Cada dispositivo recebe um endereço IP, mesmo que não responda, para que você possa usar o endereço IP para identificar um dispositivo que requer recuperação.

• Caminho da conexão – o caminho de conexão é uma ID de localização FTDI que identifica a conexão USB. A ID de localização persiste enquanto a interface do dispositivo baseada em FTDI é anexada à mesma porta USB no mesmo hub USB e, por sua vez, à mesma porta no computador. Assim, ele persiste sobre a reinicialização. No entanto, qualquer alteração na fiação entre o computador e o dispositivo pode resultar em alterações no caminho da conexão. Assim como o endereço IP, ele não será alterado mesmo se um dispositivo Azure Sphere diferente estiver conectado à interface FTDI.

Atualizar o sistema operacional do Azure Sphere

Cada chip do Azure Sphere é carregado com o sistema operacional do Azure Sphere quando ele é enviado do fabricante de silício. Dependendo da versão do sistema operacional do Azure Sphere em chips disponíveis do fornecedor e dependendo dos requisitos de versão do sistema operacional do aplicativo, talvez seja necessário atualizar o sistema operacional do 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 computador. 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 do Azure Sphere emitindo o comando az sphere device recover . Use o --images parâmetro para instalar imagens de recuperação específicas:

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

Atualizar o repositório de chaves confiável

Como pré-requisito para carregar software em seu dispositivo, talvez seja necessário atualizar o repositório de chaves confiável no dispositivo. Isso só será necessário se o sistema operacional no dispositivo for mais antigo que seu software e somente se a chave de assinatura de imagem do Azure Sphere usada pelo AS3 for atualizada entre o sistema operacional que está sendo publicado e o software que está sendo assinado pela 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 repositório de chaves confiável é necessária ao tentar 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 , um repositório de chaves confiável desatualizado será 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 az sphere device sideload deploy para carregar o armazenamento de chaves confiável atualizado antes de carregar o software do aplicativo, substituindo <path-to-trusted-keystore.bin> pelo caminho para o arquivo de armazenamento de chaves confiável:

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

Carregar software de dispositivo

Todos os softwares carregados, independentemente de ser uma imagem de configuração de placa, um aplicativo de teste ou um aplicativo de produção, devem ser assinados pela 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 pela produção que você precisa durante o processo de chão de fábrica devem ser salvas no computador do chão de fábrica antes de iniciar o processo, conforme descrito em Obter imagens assinadas pela produção nas tarefas de preparação de fabricação.

Durante a fabricação, os dispositivos do Azure Sphere não devem exigir recursos especiais do dispositivo, 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, que normalmente é indesejável no piso de fábrica.

Para carregar o software em um dispositivo na fábrica ou excluir o software temporário de um dispositivo após a conclusão do teste, use o comando de sideload do dispositivo az sphere da seguinte maneira:

• Use az sphere device sideload deploy to load an image, replacing <file-path> with the name and path to your production-signed image file:

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

• Use az sphere device sideload delete para excluir uma imagem temporária, substituindo <component-id> pela ID do componente da imagem a ser excluída:

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

Executar testes funcionais

Testes funcionais são necessários para verificar se o produto opera 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 os UARTs periféricos MT3620 (ISU0, ISU1, ISU2 ou ISU3) ao computador de fábrica ou ao equipamento de teste externo por meio de circuitos adequados de seu próprio design.

Executar teste 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 produto usa Wi-Fi e incorpora um design de chip-down ou um módulo que não é certificado por RF, você deve executar testes de RF e calibragem para cada dispositivo. Os equipamentos e ferramentas necessários para essa tarefa são descritos em Equipamentos e software para testes de RF e calibração nas tarefas de preparação de fabricação.

O pacote ferramentas rf inclui utilitários e uma biblioteca de API C para uso durante o teste. Você pode usar a biblioteca de API C para programar configurações de RF específicas do produto em fusíveis eletrônicos. Por exemplo, os fusíveis eletrônicos são programados para configurar a antena e a frequência, ajustar dispositivos para um desempenho ideal e habilitar Wi-Fi canais. O tópico ferramentas de teste de RF descreve como usar as ferramentas de RF.

Programar fusíveis eletrônicos para habilitar canais de Wi-Fi

O sistema operacional do Azure Sphere seleciona Wi-Fi canais com base no código de região programado para o e-fuses MT3620 em endereços de deslocamento 0x36 e 0x37. Para obter detalhes sobre fusíveis eletrônicos no MT3620, consulte o documento Mt3620 E-fuse Content Guidelines Mediatek.

O código da região é um código ASCII de duas letras. O sistema operacional do 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 linux e, em seguida, seleciona os canais permitidos para essa região. Se nenhum código de região for programado nos fusíveis eletrônicos, nesse caso, os fusíveis eletrônicos permanecerão definidos como 0x00 0x00 ou se os caracteres "00" forem programados, o sistema operacional será padrão para um conjunto conservador de canais geralmente 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 em que o dispositivo será usado. Os fabricantes podem escolher qualquer código de região que mapeia para um conjunto permitido de canais para a região de operação. Regiões e países diferentes geralmente adotam regulamentos semelhantes ou idênticos, o que pode permitir que códigos de região sejam usados de forma intercambiável.

Exemplo: Para instruir o sistema operacional do Azure Sphere a selecionar Wi-Fi canais 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 energia de transmissão de destino, código de região e endereço MAC (Wi-Fi Media Controle de Acesso) foram definidas corretamente. A documentação da ferramenta de configurações de RF fornece mais informações sobre como usar essa ferramenta.

Verificar Wi-Fi comunicação

Considere conectar-se a um ponto de acesso Wi-Fi para verificar se seu aplicativo de produto é capaz de se comunicar por Wi-Fi. Verifique se a conexão Wi-Fi não tem acesso à Internet, pois uma atualização no ar pode ocorrer se o chip se conectar a um ponto de acesso habilitado para Internet.

Para conectar um dispositivo a um ponto de acesso Wi-Fi, siga as instruções na guia Início Rápido (CLI). Se vários dispositivos estiverem conectados ao computador, você deverá incluir o --device parâmetro no comando az sphere device wi-status e no comando az sphere device wifi add command. Para obter detalhes sobre como usar o comando do dispositivo az sphere com vários dispositivos anexados, confira Conectar cada chip do Azure Sphere a um computador de fábrica.

Após Wi-Fi teste, você deve remover qualquer Wi-Fi pontos de acesso 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 do Azure Sphere pode se comunicar pela Ethernet. O dispositivo requer um adaptador Ethernet externo e uma imagem de configuração de placa para comunicação por meio da Ethernet.

Para configurar um dispositivo do Azure Sphere para Ethernet, conecte um adaptador Ethernet ao dispositivo Azure Sphere, conforme descrito em Conectar adaptadores Ethernet.

Dois dispositivos Ethernet são compatíveis com o Sistema Operacional do Azure Sphere.

1. Microchip ENC28J60. Este é um adaptador 10Base-T (10mbps). Ele pode ser conectado com um indicador LED a uma velocidade de meio duplex ou sem um indicador LED em velocidade total duplex. Os devkits verificados são conectados para a operação de meio duplex.
2. 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 à passagem nic ao usar o W5500 para conectividade com a Internet. Devido às limitações de largura de banda do barramento, a velocidade total de 100mbps pode não ser alcançável pelo dispositivo MT3620.

A interface Ethernet será habilitada automaticamente depois que a configuração do board for carregada, conforme descrito no software de dispositivo de carga, e o dispositivo for reiniciado. Todas as interfaces usam endereços IP dinâmicos por padrão.

Finalizar o dispositivo do Azure Sphere

A finalização garante que o dispositivo do Azure Sphere esteja em um estado protegido e esteja pronto para ser enviado aos clientes. Você deve finalizar o dispositivo antes de envia-lo. A finalização envolve:

• Executando verificações prontas para enviar para garantir que o software e o aplicativo de produção do sistema corretos estejam instalados e as ferramentas RF estejam desabilitadas.

• 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 o navio

É importante executar verificações prontas para o envio antes de enviar um produto que inclua um dispositivo do Azure Sphere. Verificações diferentes devem ser executadas para diferentes estados de fabricação. Verificações prontas para o navio garantem o seguinte:

• O estado de fabricação do dispositivo é definido corretamente para esse estágio de fabricação.
• O sistema operacional do 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.
• Não há redes de Wi-Fi inesperadas configuradas no dispositivo. Isso só pode ser verificado para dispositivos que ainda não estão no estado DeviceComplete.
• O dispositivo não contém certificados de funcionalidade especiais. Para dispositivos baseados em MT3620, isso só pode ser verificado em dispositivos que não estão no estado em branco.

Verificações diferentes são necessárias em diferentes estágios de fabricação porque o estado de fabricação do dispositivo determina as funcionalidades do dispositivo.

Quais verificações você executar também dependerão se você está projetando um módulo ou um dispositivo conectado. Por exemplo, como fabricante de módulo, você pode optar por deixar o chip no estado de fabricação em branco para que o cliente do módulo possa executar testes de rádio e configuração adicionais.

Use device_ready.py para executar verificações

O pacote Exemplos de Fabricação 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 seu dispositivo.

A tabela a seguir lista os parâmetros que o script device_ready.py usa:

O exemplo a seguir é uma execução de exemplo 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 Wi-Fi configuração de fusíveis eletrônicos não devem estar acessíveis aos usuários finais de dispositivos que contêm um chip do Azure Sphere. O estado de fabricação do dispositivo do Azure Sphere restringe o acesso a essas operações confidenciais.

Os três estados de fabricação são os seguintes:

• Em branco. O estado Blank não limita as operações de fabricação em um chip. Os chips no estado Em branco podem entrar no modo de teste 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 .

• Module1Complete. O estado de fabricação Module1Complete foi projetado para limitar os ajustes que os usuários podem fazer em configurações de configuração de rádio, como níveis máximos de transmissão e frequências permitidas. Os comandos RF podem ser usados até que Module1Complete seja definido. Restringir o acesso do usuário final a essas configurações pode ser necessário para atender às políticas regulatórias em torno do hardware de rádio. Essa configuração afeta principalmente os fabricantes que precisam testar e calibrar parâmetros operacionais de rádio.

  A Microsoft recomenda que você defina esse estado de fabricação após a conclusão do teste de rádio e da calibragem; Os comandos RF não podem ser usados depois de definidos. O estado Module1Complete protege o dispositivo contra alterações que podem interromper o funcionamento adequado do rádio e de outros dispositivos sem fio nas proximidades.

• DeviceComplete. O estado de fabricação DeviceComplete permite que os fabricantes de produtos acabados protejam dispositivos implantados no campo contra alterações. Depois que um dispositivo é colocado no estado DeviceComplete , um arquivo de funcionalidade específico do dispositivo deve ser usado sempre que executar tarefas de carregamento e configuração de software. O recurso de manutenção de campos permite que você apague imagens assinadas pela produção, mas não as exclua. A funcionalidade de desenvolvimento de aplicativos permite o sideload e a 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, determinadas verificações prontas para o envio devem ser executadas antes que esse estado seja definido. Comandos restritos podem ser habilitados novamente usando uma funcionalidade de dispositivo , como a capacidade de manutenção de campos , mas apenas para dispositivos que você alegou e, portanto, isso não é apropriado para uso em um ambiente de fábrica, pois requer conectividade de nuvem.

A tabela a seguir resume os recursos do dispositivo presentes para cada estado de fabricação.

Quando a fabricação for concluída, use o comando az sphere device manufacturing-state update para definir o estado DeviceComplete :

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