Tarefas de base de fábrica

O fabrico de dispositivos ligados que incorporam hardware do Azure Sphere envolve as seguintes tarefas de fábrica para preparar dispositivos para envio:

• Ligar cada chip do Azure Sphere a um PC de fábrica
• Obter detalhes do dispositivo e gravá-los para utilização posterior
• Atualizar o SO do Azure Sphere, se necessário
• Atualize o keystore fidedigno, se necessário
• A carregar software para o dispositivo
• Executar testes funcionais para verificar a operação correta do produto
• Realizar testes e calibragem de radiofrequência (RF)
• Verificar a comunicação Wi-Fi
• Configurar o dispositivo para o Ethernet
• Finalizar o dispositivo do Azure Sphere para envio

Primeiro, tem de ligar o chip ao PC, obter os detalhes do dispositivo em segundo lugar e finalizar o dispositivo em último lugar, mas pode efetuar as outras tarefas por qualquer ordem que se adeque ao seu ambiente de fabrico.

Ligar cada chip do Azure Sphere a um PC de fábrica

Durante o fabrico, tem de ligar cada chip do Azure Sphere a um PC de fábrica. Se quiser ligar simultaneamente vários dispositivos do Azure Sphere a um único PC, veja Equipamento para tarefas de base de fábrica nas tarefas de preparação de fabrico.

A maioria das tarefas de base de fábrica envolvem o comando do dispositivo az sphere . Quando tem vários dispositivos ligados ao PC, tem de especificar o dispositivo no qual pretende aplicar o comando do dispositivo az sphere , incluindo o --device parâmetro definido para o endereço IP do dispositivo ou o caminho de ligação do dispositivo. O comando falhará se o --device parâmetro for omitido e vários dispositivos estiverem ligados. Para obter o endereço IP ou o caminho de ligação, veja Obter detalhes do dispositivo.

Obter detalhes do dispositivo

Tem de registar o ID do dispositivo de cada chip do Azure Sphere que a sua empresa incorpora em produtos fabricados. Precisará do ID do dispositivo para tarefas de configuração da cloud.

Se tiver vários dispositivos ligados ao PC do piso de fábrica, também tem de registar o endereço IP ou o caminho de ligação dos dispositivos anexados para utilização posterior em tarefas de piso de fábrica. Conforme explicado em Ligar cada chip do Azure Sphere, o endereço IP ou o caminho de ligação são necessários para especificar o dispositivo de destino quando existem vários dispositivos ligados.

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

• ID do Dispositivo – o fabricante do silício cria o ID do dispositivo, armazena-o no chip e regista-o na Microsoft. Este registo de dispositivos garante que a Microsoft tem conhecimento de todos os chips do Azure Sphere e que apenas os chips legítimos podem ser utilizados em dispositivos ligados.

• Endereço IP – o endereço IP é atribuído quando uma interface de dispositivo baseada em FTDI é anexada ao PC; não indica que um dispositivo reativo está presente. O endereço IP persiste enquanto a interface de dispositivo baseada em FTDI está ligada ao PC, mesmo que um dispositivo do Azure Sphere diferente esteja ligado à interface. No entanto, após um reinício do PC, o endereço IP pode ser alterado. É atribuída ao endereço 192.168.35.2 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 ligação – o caminho de ligação é um ID de localização FTDI que identifica a ligação USB. O ID de localização persiste enquanto a interface de dispositivo baseada em FTDI está ligada à mesma porta USB no mesmo concentrador USB e, por sua vez, à mesma porta no PC. Assim, persiste durante o reinício. No entanto, quaisquer alterações na cablagem entre o PC e o dispositivo podem resultar em alterações ao caminho de ligação. Tal como o endereço IP, não muda mesmo que um dispositivo do Azure Sphere diferente esteja ligado à interface FTDI.

Atualizar o SO do Azure Sphere

Cada chip do Azure Sphere é carregado com o SO do Azure Sphere quando é enviado do fabricante do silício. Consoante a versão do SO do Azure Sphere em chips disponíveis no seu fornecedor e consoante os requisitos de versão do SO da sua aplicação, poderá ter de atualizar o SO do Azure Sphere durante o fabrico do dispositivo ligado. Pode atualizar o SO ao instalar imagens de recuperação específicas, que já devem estar presentes no PC. Veja Preparar uma atualização do SO nas tarefas de preparação de fabrico. Os Exemplos de Fabrico incluem um script de exemplo que executa a recuperação paralela de vários dispositivos.

Pode atualizar o SO no dispositivo do Azure Sphere ao emitir o comando az sphere device recover . Utilize 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 keystore fidedigno

Como pré-requisito para carregar software para o seu dispositivo, poderá ter de atualizar o keystore fidedigno no dispositivo. Isto só é necessário se o SO no dispositivo for mais antigo do que o software e apenas se a chave de assinatura de imagem do Azure Sphere utilizada pelo AS3 tiver sido atualizada entre o SO que está a ser publicado e o software assinado em produção. Para evitar este passo e reduzir o tempo de fabrico, considere atualizar a versão do SO que está a utilizar durante o fabrico.

Pode determinar facilmente se a atualização do keystore fidedigno é necessária ao tentar carregar o software de acordo com as instruções na secção seguinte. Se o carregamento for bem-sucedido, não precisa de atualizar o keystore fidedigno. Se o carregamento falhar com a mensagem que começa com Internal device error: Image not trusted by device , é a causa de um keystore fidedigno desatualizado.

Para atualizar o keystore fidedigno, tem de ter adquirido o ficheiro de keystore fidedigno atualizado. Em seguida, como parte dos scripts de fabrico, utilize o comando az sphere device sideload deploy para carregar o keystore fidedigno atualizado antes de carregar o software da aplicação, substituindo <path-to-trusted-keystore.bin> pelo caminho para o ficheiro keystore fidedigno:

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

Carregar software de dispositivo

Todo o software que carregar, independentemente de ser uma imagem de configuração do quadro, uma aplicação de teste ou uma aplicação de produção, tem de estar assinado em produção. Se carregar uma aplicação temporária para testes, tem de eliminá-la após a conclusão do teste.

Todas as imagens assinadas em produção de que precisa durante o processo de fábrica devem ser guardadas no PC de fábrica antes de iniciar o processo, conforme descrito em Obter imagens assinadas pela produção nas tarefas de preparação de fabrico.

Durante o fabrico, os dispositivos do Azure Sphere não podem exigir capacidades especiais de dispositivos, como a capacidade de desenvolvimento de aplicações, que permite a depuração. A aquisição de capacidades para dispositivos individuais reduz a segurança do dispositivo e requer conectividade à Internet, o que é normalmente indesejável no piso de fábrica.

Para carregar software para um dispositivo na fábrica ou para eliminar software temporário de um dispositivo após a conclusão do teste, utilize o comando de sideload do dispositivo az sphere da seguinte forma:

• Utilize az sphere device sideload deploy para carregar uma imagem, substituindo <file-path> pelo nome e caminho para o ficheiro de imagem assinado em produção:

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

• Utilize az sphere device sideload delete para eliminar uma imagem temporária, substituindo <component-id> pelo ID do componente da imagem a eliminar:

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

Executar testes funcionais

Os testes funcionais são necessários para verificar se o produto funciona corretamente. Execute as aplicações que desenvolveu para testes funcionais como parte das tarefas de preparação de fabrico. Veja Desenvolver aplicações para testes funcionais.

Se os testes funcionais exigirem comunicação com o chip que está a ser testado, ligue os UARTs periféricos MT3620 (ISU0, ISU1, ISU2 ou ISU3) ao PC de fábrica ou ao equipamento de teste externo através de circuitos adequados da sua própria estrutura.

Executar testes e calibragem de radiofrequência (RF)

Os chips do Azure Sphere podem utilizar Wi-Fi para receber atualizações de software e comunicar com a Internet. Se o seu produto utilizar Wi-Fi e incorporar uma estrutura de chip-down ou um módulo que não tenha certificação RF, tem de efetuar testes de RF e calibragem para cada dispositivo. Os equipamentos e ferramentas necessários para esta tarefa estão descritos em Equipamento e software para testes de RF e calibragem nas tarefas de preparação de fabrico.

O pacote ferramentas RF inclui utilitários e uma biblioteca de API C para utilização durante os testes. Pode utilizar a biblioteca da API C para programar definições de RF específicas do produto em fusíveis eletrónicos. Por exemplo, os e-fuses são programados para configurar a antena e a frequência, para otimizar os dispositivos para um desempenho ideal e para ativar Wi-Fi canais. O tópico Ferramentas de teste de RF descreve como utilizar as ferramentas de RF.

Fusíveis eletrónicos de programas para ativar canais Wi-Fi

O SO do Azure Sphere seleciona Wi-Fi canais com base no código de região que é programado para os fusíveis eletrónicos MT3620 em endereços de deslocamento 0x36 e 0x37. Para obter detalhes sobre os fusíveis eletrónicos no MT3620, consulte o documento Mediatek Diretrizes de Conteúdo de E-fuse MT3620 .

O código de região é um código ASCII de duas letras. O SO do Azure Sphere utiliza a definição de código de região nos fusíveis eletrónicos para procurar a região na base de dados reguladora sem fios do Linux e, em seguida, seleciona os canais permitidos para essa região. Se nenhum código de região for programado para os fusíveis eletrónicos, nesse caso, os fusíveis eletrónicos permanecem definidos como 0x00 0x00 ou, se os carateres "00" forem programados, o SO predefine um conjunto conservador de canais geralmente permitidos em todas as regiões. Os canais permitidos para a região "00" são especificados na base de dados reguladora sem fios do Linux.

A definição de código de região nos fusíveis eletrónicos não tem de corresponder ao país onde o dispositivo será utilizado. Os fabricantes podem escolher qualquer código de região que mapeie para um conjunto permitido de canais para a região de funcionamento. Regiões e países diferentes adotam frequentemente regulamentos semelhantes ou idênticos, que podem permitir que os códigos de região sejam utilizados alternadamente.

Exemplo: Para instruir o SO do Azure Sphere a selecionar Wi-Fi canais para a região "DE" (Alemanha), programa 0x44=D e 0x45=E nos fusíveis eletrónicos nos endereços 0x36 e 0x37. Os canais permitidos para a Alemanha, extraídos da base de dados reguladora sem fios 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

Utilize o RfSettingsTool para verificar se as opções de configuração de rádio, como a potência de transmissão de destino, o código de região e o endereço Wi-Fi Controlo de Acesso de Multimédia (MAC) foram definidas corretamente. A documentação da ferramenta de definições rf fornece mais informações sobre a utilização desta ferramenta.

Verificar Wi-Fi comunicação

Considere ligar a um ponto de acesso Wi-Fi para verificar se a sua aplicação de produto consegue comunicar através de Wi-Fi. Certifique-se de que a ligação Wi-Fi não tem acesso à Internet, uma vez que poderá ocorrer uma atualização via ar se o chip se ligar a um ponto de acesso ativado pela Internet.

Para ligar um dispositivo a um ponto de acesso Wi-Fi, siga as instruções no Início Rápido (separador CLI). Se vários dispositivos estiverem ligados ao PC, tem de incluir o --device parâmetro no comando az sphere device wifi show-status e no comando az sphere device wifi add . Para obter detalhes sobre como utilizar o comando do dispositivo az sphere com vários dispositivos ligados, veja Ligar cada chip do Azure Sphere a um PC de fábrica.

Após Wi-Fi teste, deve remover qualquer Wi-Fi pontos de acesso utilizados para testes do chip para que estes não estejam visíveis para os clientes. A recuperação de dispositivos remove todos os dados de configuração Wi-Fi do chip.

Configurar o dispositivo para o Ethernet

Um dispositivo do Azure Sphere pode comunicar através de Ethernet. O dispositivo requer um adaptador Ethernet externo e uma imagem de configuração de quadro para comunicação através de Ethernet.

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

Dois dispositivos Ethernet são suportados pelo Sistema Operativo do Azure Sphere.

1. Microchip ENC28J60. Este é um adaptador de 10Base-T (10 mbps). Pode ser ligado com um indicador LED a uma velocidade de meio duplex ou sem um indicador LED a uma velocidade de duplex completa. Os devkits visualizados estão ligados para a operação half-duplex.
2. Wiznet W5500. Este é um adaptador de 100Base-TX (100mpbs). Suporta uma pilha TCP/IP integrada e modos pass-through NIC, mas o Azure Sphere só suporta pass-through NIC ao utilizar o W5500 para conectividade à Internet. Devido às limitações de largura de banda do barramento, a velocidade total de 100 mbps pode não ser alcançável pelo dispositivo MT3620.

A interface Ethernet será ativada automaticamente assim que a configuração do quadro for carregada, conforme descrito em Carregar software do dispositivo e o dispositivo for reiniciado. Por predefinição, todas as interfaces utilizam endereços IP dinâmicos.

Finalizar o dispositivo do Azure Sphere

A finalização garante que o dispositivo do Azure Sphere está num estado seguro e está pronto para ser enviado aos clientes. Tem de finalizar o dispositivo antes de o enviar. A finalização envolve:

• Executar verificações prontas a enviar para garantir que o software de sistema e a aplicação de produção corretos estão instalados e que as ferramentas de RF estão desativadas.

• Definir o estado de fabrico do dispositivo para bloquear as ferramentas de configuração e calibragem de RF e evitar falhas de segurança.

Executar verificações prontas a enviar

É importante executar verificações prontas a enviar antes de enviar um produto que inclua um dispositivo do Azure Sphere. Têm de ser efetuadas verificações diferentes para diferentes estados de fabrico. As verificações prontas a enviar garantem o seguinte:

• O estado de fabrico do dispositivo está definido corretamente para essa fase de fabrico.
• O SO do Azure Sphere no dispositivo é válido e a versão esperada. Só é possível verificar se existem dispositivos que ainda não se encontram no estado DeviceComplete.
• As imagens fornecidas pelo utilizador no dispositivo correspondem à lista de imagens esperadas. Só é possível verificar se existem dispositivos que ainda não se encontram no estado DeviceComplete.
• Não existem redes Wi-Fi inesperadas configuradas no dispositivo. Só é possível verificar se existem dispositivos que ainda não se encontram no estado DeviceComplete.
• O dispositivo não contém certificados de capacidade especiais. Para dispositivos baseados em MT3620, esta opção só pode ser verificada 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 executar também irão depender da conceção de um módulo ou de um dispositivo ligado. Por exemplo, como fabricante de módulos, pode optar por deixar o chip no estado de fabrico em branco para que o cliente do módulo possa realizar testes de rádio e configuração adicionais.

Utilizar device_ready.py para efetuar verificações

O pacote Exemplos de Fabrico inclui uma ferramenta denominada device_ready.py, que efetua as verificações acima, conforme adequado para cada estado de fabrico. Deve ser executado para cada um dos estados de fabrico relevantes para o seu dispositivo.

A tabela seguinte lista os parâmetros que o script device_ready.py utiliza:

Segue-se 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 fabrico do dispositivo

As operações de fabrico confidenciais, como colocar o rádio no modo de teste e definir Wi-Fi fusíveis de configuração não devem estar acessíveis aos utilizadores finais de dispositivos que contêm um chip do Azure Sphere. O estado de fabrico do dispositivo do Azure Sphere restringe o acesso a estas operações confidenciais.

Os três estados de fabrico são os seguintes:

• Em branco. O estado Em Branco não limita as operações de fabrico num chip. Os chips no estado Em branco podem entrar no modo de teste RF e os respetivos fusíveis eletrónicos podem ser programados. Quando os chips são enviados da fábrica de silício, estão no estado de fabrico em branco .

• Module1Complete. O estado de fabrico module1Complete foi concebido para limitar os ajustes que os utilizadores podem fazer às definições de configuração de rádio, tais como níveis máximos de energia de transmissão e frequências permitidas. Os comandos RF podem ser utilizados até que Module1Complete esteja definido. A restrição do acesso do utilizador final a estas definições pode ser necessária para satisfazer as políticas regulamentares em torno do hardware de rádio. Esta definição afeta principalmente os fabricantes que precisam de testar e calibrar os parâmetros de operação de rádio.

  A Microsoft recomenda que defina este estado de fabrico após a conclusão dos testes de rádio e da calibragem; Os comandos RF não podem ser utilizados depois de ser definido. O estado Module1Complete protege o dispositivo contra alterações que possam interromper o funcionamento adequado do rádio e de outros dispositivos sem fios nas proximidades.

• DeviceComplete. O estado de fabrico DeviceComplete permite que os fabricantes de produtos concluídos protejam os dispositivos implementados no campo contra alterações. Depois de um dispositivo ser colocado no estado DeviceComplete , tem de ser utilizado um ficheiro de capacidade específico do dispositivo sempre que efetuar tarefas de carregamento e configuração de software. A capacidade de manutenção de campos permite-lhe fazer sideload de imagens assinadas com produção, mas não eliminá-las. A capacidade de desenvolvimento de aplicações permite o sideload e a eliminação de imagens.

  Não defina DeviceComplete para dispositivos ou módulos inacabados (módulos Wi-Fi, quadros de desenvolvimento, etc.) que possam ser utilizados como parte de um sistema maior; este estado limita as atividades de fabrico, tais 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 de DeviceComplete ser definido e, por isso, determinadas verificações prontas a enviar têm de ser executadas antes de este estado ser definido. Os comandos restritos podem ser reativados através de uma capacidade de dispositivo , como a capacidade de manutenção de campos , mas apenas para dispositivos que tenha afirmado, pelo que não é adequado para utilização num ambiente de fábrica, uma vez que requer conectividade à cloud.

A tabela seguinte resume as capacidades do dispositivo que estão presentes para cada estado de fabrico.

Quando o fabrico estiver concluído, utilize 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>]