Tarefas de 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:

• Conectando cada chip do Azure Sphere a um computador de chão de fábrica
• Obtendo detalhes do dispositivo e gravando-os para uso posterior
• Atualizando o sistema operacional do 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 correto funcionamento do produto
• Realização de testes e calibração de radiofrequência (RF)
• Verificando a comunicação Wi-Fi
• Configurando o dispositivo para Ethernet
• Finalizando o dispositivo do Azure Sphere para envio

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

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

Durante a fabricação, você deve conectar cada chip do Azure Sphere a um computador de chão de fábrica. Se você quiser conectar simultaneamente vários dispositivos do Azure Sphere a um único computador, 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ê tem vários dispositivos conectados ao computador, deve 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 estiverem 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 conectados ao computador de chão 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 são necessários para especificar o dispositivo de destino quando há 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 azsphere 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 do silício cria a ID do dispositivo, armazena-a no chip e a registra na Microsoft. Esse registro do dispositivo garante que a Microsoft esteja ciente de todos os chips do Azure Sphere e que apenas chips legítimos sejam usados em dispositivos conectados.

• Endereço IP — O endereço IP é atribuído quando uma interface de dispositivo baseada em FTDI é conectada ao PC; Isso não indica que um dispositivo responsivo está presente. O endereço IP persiste enquanto a interface de dispositivo baseada em FTDI está anexada ao computador, mesmo se há um dispositivo diferente do Azure Sphere conectado à interface. Porém, após uma reinicialização do computador, o endereço IP poderá mudar. A primeira interface de dispositivo baseada em FTDI a ser conectada recebe o endereço 192.168.35.2. Cada dispositivo recebe um endereço IP ( mesmo que não esteja respondendo) para que você possa usar o endereço IP para identificar um dispositivo que precisa de recuperação.

• Caminho de conexão — O caminho de conexão é um ID de local FTDI que identifica a conexão USB. A 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 computador. Assim, ele persiste após a reinicialização. No entanto, qualquer alteração à conexão entre o computador e o dispositivo pode levar a alterações ao caminho de conexão. Como o endereço IP, ele não muda mesmo que um dispositivo do Azure Sphere diferente seja conectado à interface FTDI.

Atualizar o SO do Azure Sphere

Cada chip do Azure Sphere é carregado com o sistema operacional do Azure Sphere quando é enviado do fabricante de silício. Dependendo da versão do sistema operacional do Azure Sphere disponível em seu 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 seu PC. Consulte Preparar-se 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 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>]

Atualizar o repositório de chaves confiável

Como pré-requisito para carregar o software em seu dispositivo, talvez seja necessário atualizar o armazenamento de chaves confiável no dispositivo. Isso será necessário somente se o sistema operacional no dispositivo for mais antigo que o 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 , a causa será um armazenamento de chaves confiável desatualizado.

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 repositório de chaves confiável atualizado antes de carregar o software do aplicativo, substituindo <path-to-trusted-keystore.bin> pelo caminho para o arquivo de repositório de chaves confiável:

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

azsphere device sideload deploy --imagepackage <path-to-trusted-keystore.bin> [--deviceip <IP-address> | --devicelocation <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 por 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 necessárias durante o processo de chão de fábrica devem ser salvas em seu computador 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 Azure Sphere não devem exigir nenhuma funcionalidade de dispositivo especial, como a funcionalidade de desenvolvimento de aplicativos, que permite a depuração. A aquisição de recursos para dispositivos individuais reduz a segurança do dispositivo e exige conectividade com a Internet, o que geralmente é prejudicial no chão de fábrica.

Para carregar software em um dispositivo na 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:

  • Azure Sphere CLI
  • CLI clássica do Azure Sphere

  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> pela ID do componente da imagem a ser excluída:

  • Azure Sphere CLI
  • CLI clássica do Azure Sphere

  azsphere 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 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 os 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 chão de fábrica ou ao equipamento de teste externo por meio 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 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 são descritos em Equipamentos e software para teste e calibração de RF nas tarefas de preparação de fabricação.

O pacote de ferramentas de RF inclui utilitários e uma biblioteca de API C para uso durante o teste. Você pode usar a biblioteca C API 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, para ajustar os dispositivos para um desempenho ideal e para habilitar canais Wi-Fi. O tópico Ferramentas de teste de RF descreve como usar as ferramentas de RF.

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

O sistema operacional do 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 das Diretrizes de Conteúdo do Fusível Eletrônico MT3620.

O código de 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 do 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, caso em que os fusíveis eletrônicos permanecerão definidos como 0x00 0x00, ou se os caracteres "00" forem programados, o sistema operacional usará 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 do 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 geralmente adotam regulamentos semelhantes ou idênticos, o que pode permitir que os códigos de região sejam usados de forma intercambiável.

Exemplo: para instruir o sistema operacional do 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 do 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 (Controle de Acesso à Mídia) Wi-Fi, foram definidas corretamente. A documentação Ferramenta de configuração de RF fornece mais informações sobre como usar essa ferramenta.

Verifique 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 conexão Wi-Fi não tenha acesso à Internet, pois uma atualização over-the-air 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 no Início Rápido (guia CLI). Se vários dispositivos estiverem conectados ao computador, 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 anexados, consulte Conectar cada chip do Azure Sphere a um computador de chão de fábrica.

Após o teste de Wi-Fi, você deve remover todos os pontos de acesso Wi-Fi usados para teste do chip para que não fiquem visíveis para os clientes. A recuperação do dispositivo remove todos os dados de configuração de Wi-Fi do chip.

Configurar o dispositivo para Ethernet

Um dispositivo do Azure Sphere pode se comunicar por Ethernet. O dispositivo requer um adaptador Ethernet externo e uma imagem de configuração de placa para comunicação via Ethernet.

Para configurar um dispositivo do Azure Sphere para Ethernet, conecte um adaptador Ethernet ao dispositivo do Azure Sphere, conforme descrito em Conectando 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 em velocidade half-duplex ou sem um indicador LED em velocidade full-duplex. Os devkits Seeed são conectados para operação half-duplex.
2. Wiznet W5500. Este é um adaptador 100Base-TX (100mpbs). Ele dá suporte a uma pilha TCP/IP integrada e modos de passagem de NIC, mas o Azure Sphere só dá suporte à passagem de NIC ao usar o W5500 para conectividade com a Internet. Devido a limitações de largura de banda de barramento, a velocidade total de 100 mbps pode não ser alcançada pelo dispositivo MT3620.

A interface Ethernet será habilitada 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:

• A 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 que as ferramentas de RF estejam desativadas.

• Definir o estado de fabricação do dispositivo para bloquear a configuração de RF e as ferramentas de calibragem e evitar violações de segurança.

Execute verificações prontas para envio

É importante executar verificações prontas para envio antes de enviar um produto que inclua um dispositivo do Azure Sphere. Diferentes verificações devem ser realizadas para diferentes estados de fabricação. As verificações prontas para envio 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.
• 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 nenhum certificado de capacidade especial. 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 os recursos 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 usa:

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 configurar os fusíveis eletrônicos de configuração Wi-Fi, não devem estar acessíveis aos usuários finais dos 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 de fabricação são os seguintes:

• Blank. 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 .

• Module1Complete. O estado de fabricação do Module1Complete foi projetado para limitar os ajustes que os usuários podem fazer nas configurações 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 seja definido. A restrição do acesso do usuário final a essas configurações pode ser necessária para atender às políticas regulatórias relacionadas a hardware de rádio. Essa configuração afeta principalmente os fabricantes que precisam testar e calibrar parâmetros de operação de rádio.

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

• DeviceComplete. O estado de fabricação do DeviceComplete permite que os fabricantes de produtos acabados protejam os dispositivos implantados em 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 qualquer tarefa de carregamento e configuração de software. O recurso de manutenção de campo permite que você faça sideload de imagens assinadas pela produção, mas não as exclua. O recurso 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 teste 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 chão de fábrica, pois requer conectividade de nuvem.

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

Quando a fabricação for 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>]

azsphere device manufacturing-state update --state <desired-state> [--deviceip <IP-address> | --devicelocation <connection-path>]