Задачи фабрики

  • Статья

Производство подключенных устройств, включающих оборудование Azure Sphere, включает следующие задачи на заводе для подготовки устройств к доставке:

  • Подключение каждой микросхемы Azure Sphere к компьютеру на заводе
  • Получение сведений об устройстве и их запись для последующего использования
  • При необходимости обновление ОС Azure Sphere
  • При необходимости обновите доверенное хранилище ключей
  • Загрузка программного обеспечения на устройство
  • Выполнение функциональных тестов для проверки правильности работы продукта
  • Выполнение радиочастотного тестирования и калибровки
  • Проверка Wi-Fi связи
  • Настройка устройства для Ethernet
  • Завершение доставки устройства Azure Sphere

Сначала необходимо подключить микросхему к компьютеру, получить сведения об устройстве второй и завершить устройство последним, но другие задачи можно выполнять в любом порядке, который подходит для вашей производственной среды.

Важно

Необходимо подготовиться к выполнению задач, выполняемых на заводе, без задержек. Подготовка включает в себя настройку компьютера на заводе и любого другого необходимого оборудования, а также установку необходимых программных средств пк. Все задачи, которые необходимо выполнить для подготовки к гладкому производственному процессу, описаны в разделе Подготовка производственного процесса.

Подключение каждой микросхемы Azure Sphere к компьютеру на заводе

Во время производства необходимо подключить каждую микросхему Azure Sphere к компьютеру на заводе. Если вы хотите одновременно подключить несколько устройств Azure Sphere к одному компьютеру, см. статью Оборудование для задач производственной подготовки.

Большинство задач фабрики включают команду az sphere device . Если к компьютеру подключено несколько устройств, необходимо указать устройство, на котором будет применяться команда az sphere device , включив --device параметр, заданный для IP-адреса устройства или пути подключения устройства. Команда завершится ошибкой, --device если параметр опущен и подключено несколько устройств. Чтобы получить IP-адрес или путь подключения, см. статью Получение сведений об устройстве.

Важно

Пакет SDK для Azure Sphere поддерживает обмен данными только с несколькими подключенными устройствами с Windows. Если вы используете Linux, поддерживается взаимодействие только с одним подключенным устройством. Однако вы можете использовать несколько виртуальных машин Linux, каждая из которых имеет один USB-порт, чтобы иметь один компьютер с несколькими экземплярами Linux, которые взаимодействуют с несколькими устройствами Azure Sphere одновременно.

Получение сведений об устройстве

Необходимо записать идентификатор устройства каждой микросхемы Azure Sphere, которую ваша компания включает в готовые продукты. Вам потребуется идентификатор устройства для задач облачной конфигурации.

Если к компьютеру фабрики подключено несколько устройств, необходимо также записать IP-адрес или путь подключения подключенных устройств для последующего использования в задачах заводского этажа. Как описано в разделе Подключение каждой микросхемы Azure Sphere, IP-адрес или путь подключения требуется для указания целевого устройства при наличии нескольких подключенных устройств.

Чтобы получить идентификатор устройства, IP-адрес и путь подключения подключенных устройств, используйте команду az sphere device list-attached . В следующих описаниях содержатся важные сведения об идентификаторе устройства, IP-адресе и пути подключения.

  • Идентификатор устройства— производитель кремния создает идентификатор устройства, сохраняет его на микросхеме и регистрирует его в корпорации Майкрософт. Эта регистрация устройства гарантирует, что корпорация Майкрософт будет знать обо всех чипах Azure Sphere и что на подключенных устройствах можно использовать только допустимые чипы.

  • IP-адрес — IP-адрес назначается при подключении интерфейса устройства на основе FTDI к компьютеру; он не указывает, что присутствует адаптивное устройство. IP-адрес сохраняется, пока интерфейс устройства на основе FTDI подключен к компьютеру, даже если к интерфейсу подключено другое устройство Azure Sphere. Однако после перезагрузки компьютера IP-адрес может измениться. Первому подключенному интерфейсу устройства на основе FTDI назначается адрес 192.168.35.2. Каждому устройству назначается IP-адрес, даже если оно не отвечает, поэтому вы можете использовать ЕГО для идентификации устройства, требующего восстановления.

  • Путь подключения — это идентификатор расположения FTDI , который идентифицирует USB-подключение. Идентификатор расположения сохраняется, пока интерфейс устройства на основе FTDI подключен к тому же USB-порту на том же USB-концентраторе и, в свою очередь, к тому же порту на компьютере. Таким образом, он сохраняется при перезагрузке. Однако любые изменения в подключении между компьютером и устройством могут привести к изменению пути подключения. Как и IP-адрес, он не меняется, даже если другое устройство Azure Sphere подключено к интерфейсу FTDI.

Обновление ОС Azure Sphere

Каждая микросхема Azure Sphere загружается с ОС Azure Sphere, когда она поставляется от производителя кремния. В зависимости от версии ОС Azure Sphere на микросхемах, доступных у вашего поставщика, и в зависимости от требований к версии ОС вашего приложения может потребоваться обновить ОС Azure Sphere во время производства подключенного устройства. Вы можете обновить ОС, установив определенные образы восстановления, которые уже должны присутствовать на компьютере. См . статью Подготовка к обновлению ОС в задачах подготовки к производству. Производственные примеры содержат пример скрипта, который выполняет параллельное восстановление нескольких устройств.

Вы можете обновить ОС на устройстве Azure Sphere, выполнив команду az sphere device recover . --images Используйте параметр для установки определенных образов восстановления:

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

Примечание

Если к компьютеру подключено несколько устройств, включите --device параметр для идентификации целевого устройства по IP-адресу или пути подключения. Дополнительные сведения см. в статье Подключение каждой микросхемы Azure Sphere к компьютеру на заводе .

Обновление доверенного хранилища ключей

В качестве необходимого условия для загрузки программного обеспечения на устройство может потребоваться обновить доверенное хранилище ключей на устройстве. Это необходимо, только если ОС на устройстве старше вашего программного обеспечения, и только в том случае, если ключ подписывания образа Azure Sphere, используемый AS3, был обновлен между публикацией ОС и рабочей подписью программного обеспечения. Чтобы избежать этого шага и сократить время производства, рассмотрите возможность обновления версии ОС, используемой во время производства.

Вы можете легко определить, требуется ли обновление доверенного хранилища ключей, попытаясь загрузить программное обеспечение в соответствии с инструкциями в следующем разделе. Если загрузка завершается успешно, обновление доверенного хранилища ключей не требуется. Если загрузка завершается сбоем с сообщением, начинающемся с Internal device error: Image not trusted by device , причиной является устаревшее доверенное хранилище ключей.

Чтобы обновить доверенное хранилище ключей, необходимо получить актуальный файл доверенного хранилища ключей. Затем в рамках производственных сценариев используйте команду az sphere device sideload deploy , чтобы загрузить обновленное доверенное хранилище ключей перед загрузкой программного обеспечения приложения, заменив <path-to-trusted-keystore.bin> путь к файлу доверенного хранилища ключей:

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

Загрузка программного обеспечения устройства

Все загружаемые программы, независимо от того, является ли это образ конфигурации платы, тестовое приложение или рабочее приложение, должны быть подписаны в рабочей среде. Если вы загружаете временное приложение для тестирования, его необходимо удалить после завершения тестирования.

Все изображения, подписанные в рабочей среде, которые необходимы во время производственного процесса, должны быть сохранены на компьютере с заводским цехом перед началом процесса, как описано в разделе Получение изображений, подписанных в рабочей среде, в задачах подготовки к производству.

Интерфейс компьютера с инструментами

Во время производства устройствам Azure Sphere не должны требоваться какие-либо специальные возможности устройств, такие как возможность appdevelopment, которая обеспечивает отладку. Приобретение возможностей для отдельных устройств снижает безопасность устройств и требует подключения к Интернету, что обычно нежелательно на заводе.

Чтобы загрузить программное обеспечение на устройство в фабрике или удалить временное программное обеспечение с устройства после завершения тестирования, используйте команду az sphere device sideload следующим образом:

  • Используйте команду az sphere device sideload deploy для загрузки образа, заменив <file-path> именем и путем к рабочему подписанному файлу образа:

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

  • Используйте команду az sphere device sideload delete , чтобы удалить временное изображение, заменив <component-id> идентификатором компонента удаляемого образа:

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

Примечание

Если к компьютеру подключено несколько устройств, включите --device параметр для идентификации целевого устройства по IP-адресу или пути подключения. Дополнительные сведения см. в статье Подключение каждой микросхемы Azure Sphere к компьютеру на заводе .

Выполнение функциональных тестов

Чтобы убедиться, что продукт работает правильно, необходимы функциональные тесты. Запустите приложения, разработанные для функционального тестирования, в рамках задач подготовки производства. См. раздел Разработка приложений для функционального тестирования.

Если для функциональных тестов требуется взаимодействие с тестируемым чипом, подключите периферийные UART MT3620 (ISU0, ISU1, ISU2 или ISU3) к вашему заводским пк или внешнему тестового оборудования через подходящую схему собственной конструкции.

Поток функционального тестирования

Тестирование и калибровка радиочастот (RF)

Чипы Azure Sphere могут использовать Wi-Fi для получения обновлений программного обеспечения и связи с Интернетом. Если в вашем продукте используется Wi-Fi и он включает в себя либо конструкцию снизу микросхемы, либо модуль, который не сертифицирован по стандарту RF, необходимо выполнить радиочастотное тестирование и калибровку для каждого устройства. Оборудование и инструменты, необходимые для этой задачи, описаны в разделе Оборудование и программное обеспечение для тестирования и калибровки rf в задачах подготовки производства.

Пакет средств RF включает служебные программы и библиотеку API C для использования во время тестирования. Вы можете использовать библиотеку API C для программирования параметров RF для конкретного продукта в электронных предохранителях. Например, электронные предохранители запрограммируются для настройки антенны и частоты, настройки устройств для оптимальной производительности и включения Wi-Fi каналов. В разделе Средства rf testing описывается использование средств RF.

Программирование электронных предохранителей для включения Wi-Fi каналов

ОС Azure Sphere выбирает Wi-Fi каналы на основе кода региона, который запрограммирован в электронные предохранители MT3620 по адресам смещения 0x36 и 0x37. Дополнительные сведения о электронных предохранителях на MT3620 см. в документе Mt3620 E-fuse Content Guidelines Mediatek.

Код региона представляет собой двухбуквенный код ASCII. ОС Azure Sphere использует параметр кода региона в электронных предохранителях для поиска региона в базе данных linux для беспроводной нормативной базы данных , а затем выбирает каналы, разрешенные для этого региона. Если код региона не запрограммирован в электронные предохранители, в этом случае для электронных предохранителей остается 0x00 0x00 или если запрограммированные символы "00", ос по умолчанию использует консервативный набор каналов, которые обычно разрешены во всех регионах. Каналы, разрешенные для региона "00", указываются в базе данных по беспроводной сети Linux.

Параметр кода региона в электронных предохранителях не должен соответствовать стране, в которой будет использоваться устройство. Производители могут выбрать любой код региона, который сопоставляется с допустимым набором каналов для региона операции. Различные регионы и страны часто принимают аналогичные или идентичные правила, которые позволяют использовать коды регионов взаимозаменяемо.

Примере: Чтобы указать ОС Azure Sphere выбрать каналы Wi-Fi для региона "DE" (Германия), запрограммируйте 0x44=D и 0x45=E в электронные предохранители по адресам 0x36 и 0x37. Ниже показаны разрешенные каналы для Германии, выдержки из базы данных по беспроводной сети Linux. Большинство стран Европейского союза (ЕС) разрешают один и тот же набор каналов.

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)

Проверка конфигурации RF

Используйте RfSettingsTool, чтобы убедиться, что параметры конфигурации радиосвязи, такие как целевая мощность передачи данных, код региона и Wi-Fi адрес контроль доступа мультимедиа (MAC), заданы правильно. Дополнительные сведения об использовании этого средства см. в документации по средству параметров RF .

Проверка Wi-Fi связи

Попробуйте подключиться к точке доступа Wi-Fi, чтобы убедиться, что приложение продукта может обмениваться данными по Wi-Fi. Убедитесь, что подключение Wi-Fi не имеет доступа к Интернету, так как при подключении микросхемы к точке доступа с поддержкой Интернета может произойти обновление по воздуху.

Чтобы подключить устройство к точке доступа Wi-Fi, следуйте инструкциям в разделе Краткое руководство (вкладка CLI). Если к компьютеру подключено несколько устройств, необходимо включить --device параметр в команду az sphere device wifi show-status и команду az sphere device wifi add . Дополнительные сведения об использовании команды az sphere device с несколькими подключенными устройствами см. в статье Подключение каждой микросхемы Azure Sphere к компьютеру на заводе.

После Wi-Fi тестирования следует удалить все Wi-Fi точки доступа, используемые для тестирования, из микросхемы, чтобы они не были видны клиентам. При восстановлении устройства из микросхемы удаляются все Wi-Fi данные конфигурации.

Настройка устройства для Ethernet

Устройство Azure Sphere может обмениваться данными через Ethernet. Для связи через Ethernet устройству требуется внешний адаптер Ethernet и образ конфигурации платы.

Чтобы настроить устройство Azure Sphere для Ethernet, подключите адаптер Ethernet к устройству Azure Sphere, как описано в разделе Подключение адаптеров Ethernet.

Операционная система Azure Sphere поддерживает два устройства Ethernet.

  1. Микрочип ENC28J60. Это адаптер 10Base-T (10 Мбит/с). Он может быть подключен со светодиодным индикатором на полудуплексной скорости или без светодиодного индикатора на полнодуплексной скорости. Видимые девкиты подключены для полудуплексной операции.
  2. Wiznet W5500. Это адаптер 100Base-TX (100mpbs). Он поддерживает интегрированный стек TCP/IP и режимы сквозной передачи сетевого адаптера, но Azure Sphere поддерживает сквозной сетевой адаптер только при использовании W5500 для подключения к Интернету. Из-за ограничений пропускной способности шины, полная скорость 100 Мбит/с может быть недостижима для устройства MT3620.

Интерфейс Ethernet будет включен автоматически после загрузки конфигурации платы, как описано в разделе Загрузка программного обеспечения устройства, и устройство перезагрузится. Все интерфейсы по умолчанию используют динамические IP-адреса.

Завершение работы устройства Azure Sphere

Завершение гарантирует, что устройство Azure Sphere находится в защищенном состоянии и готово к отправке клиентам. Перед отправкой устройства необходимо завершить работу. Завершение включает в себя:

  • Выполните проверки готовности к отправке, чтобы убедиться, что установлено правильное системное программное обеспечение и рабочее приложение, а средства RF отключены.

  • Настройка состояния производства устройства для блокировки средств настройки и калибровки RF и предотвращения нарушений безопасности.

Выполнение проверок готовности к отправке

Перед отправкой продукта, содержащего устройство Azure Sphere, важно выполнить проверки готовности к отправке. Для разных состояний производства должны выполняться различные проверки. Проверки готовности к отправке обеспечивают следующее:

  • Состояние производства устройства правильно задано для этого этапа производства.
  • Операционная система Azure Sphere на устройстве является допустимой и ожидаемой версией. Это можно проверить только для устройств, которые еще не находятся в состоянии DeviceComplete.
  • Предоставленные пользователем изображения на устройстве соответствуют списку ожидаемых образов. Это можно проверить только для устройств, которые еще не находятся в состоянии DeviceComplete.
  • На устройстве не настроены непредвиденное Wi-Fi сети. Это можно проверить только для устройств, которые еще не находятся в состоянии DeviceComplete.
  • Устройство не содержит никаких специальных сертификатов возможностей. Для устройств на основе MT3620 это можно проверить только на устройствах, не в состоянии "Пусто".

Различные проверки необходимы на разных этапах производства, так как состояние производства устройства определяет возможности устройства.

Выполняемые проверки также зависят от того, разрабатываете ли вы модуль или подключенное устройство. Например, как производитель модуля вы можете оставить микросхему в состоянии "Пустое производство", чтобы клиент модуля мог выполнить дополнительное радиотестирование и настройку.

Использование device_ready.py для выполнения проверок

Пакет производственных примеров содержит средство с именем device_ready.py, которое выполняет указанные выше проверки в соответствии с каждым производственным состоянием. Он должен выполняться для каждого из состояний производства, относящихся к вашему устройству.

В следующей таблице перечислены параметры, которые принимает скрипт device_ready.py:

Параметр Описание
--expected_mfg_state Определяет, для какого состояния производства следует проверка, а также определяет, какие тесты выполняются. Если этот параметр не указан, по умолчанию используется значение DeviceComplete. Если состояние производства устройства отличается от этого значения, проверка сбой.
--images Указывает список идентификаторов изображений (GUID), которые должны присутствовать на устройстве для успешного выполнения проверка. Список состоит из идентификаторов GUID изображений, разделенных пробелами. Этот параметр по умолчанию использует пустой список, если он не указан. Если список установленных идентификаторов образов на устройстве отличается от этого списка, проверка сбоем. Проверяя идентификаторы изображений (а не идентификаторы компонентов), это проверка гарантирует наличие определенной версии компонента.
--os Указывает список версий ОС Azure Sphere. Этот параметр по умолчанию использует пустой список, если он не указан. Если версия ОС, представленная на устройстве, отсутствует в этом списке, это проверка сбоем.
--os_components_json_file Указывает путь к JSON-файлу, в котором перечислены компоненты ОС, определяющие каждую версию ОС. Для устройств на основе MT3620 этот файл называется mt3620an.json. download_os_list.py Используйте средство для скачивания последней версии.
--azsphere_path Указывает путь к служебной программе azsphere.exe. Если этот параметр не указан, по умолчанию используется расположение установки по умолчанию для пакета SDK Azure Sphere в Windows. Используйте этот параметр, только если пакет SDK для Azure Sphere не установлен в расположении по умолчанию.
--help Отображает справку из командной строки.
--verbose Предоставляет дополнительные сведения о выходных данных.

Ниже приведен пример запуска device_ready.py средства со следующими аргументами:

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

Настройка состояния производства устройства

Конфиденциальные производственные операции, такие как размещение радио в тестовом режиме и настройка Wi-Fi конфигурации электронных предохранителей, не должны быть доступны конечным пользователям устройств, содержащих микросхему Azure Sphere. Состояние производства устройства Azure Sphere ограничивает доступ к этим конфиденциальным операциям.

Три состояния производства:

  • Пустая. Состояние Пустое не ограничивает производственные операции на микросхеме. Чипы в пустом состоянии могут переходить в режим тестирования RF, и их электронные предохранители могут быть запрограммированы. Когда чипы поставляются с кремниевого завода, они находятся в состоянии пустого производства.

  • Module1Complete. Состояние производства Module1Complete предназначено для ограничения параметров конфигурации радиосвязи, таких как максимальные уровни мощности передачи и разрешенные частоты. Команды RF можно использовать, пока не будет задано значение Module1Complete . Ограничение доступа конечных пользователей к этим параметрам может потребоваться для соответствия нормативным политикам в отношении оборудования радиосвязи. Этот параметр в первую очередь влияет на производителей, которым необходимо протестировать и откалибровать рабочие параметры радиосвязи.

    Корпорация Майкрософт рекомендует установить это состояние производства после завершения радио-тестирования и калибровки. Команды RF нельзя использовать после установки. Состояние Module1Complete защищает устройство от изменений, которые могут нарушить правильную работу радио и других беспроводных устройств в непосредственной близости.

  • DeviceComplete. Состояние производства DeviceComplete позволяет производителям готовых продуктов защищать устройства, развернутые в этом поле, от изменений. После того как устройство перейдет в состояние DeviceComplete , при выполнении любых задач загрузки и настройки программного обеспечения необходимо использовать файл возможностей для конкретного устройства. Возможность fieldservicing позволяет загружать неопубликованные образы, подписанные рабочей средой, но не удалять их. Возможность appdevelopment позволяет загружать и удалять неопубликованные изображения.

    Не устанавливайте DeviceComplete для незавершенных устройств или модулей (модулей Wi-Fi, плат разработки и т. д.), которые могут использоваться в составе более крупной системы; это состояние ограничивает производственные действия, такие как тестирование производственной линии, установка программного обеспечения и настройка. Многие команды CLI недоступны после установки DeviceComplete , поэтому перед настройкой этого состояния необходимо выполнить определенные проверки готовности к отправке. Ограниченные команды можно повторно включить с помощью возможности устройства , такой как возможность fieldservicing , но только для запрошенных устройств, поэтому это не подходит для использования в среде фабрики, так как требуется подключение к облаку.

В следующей таблице перечислены возможности устройств, которые присутствуют для каждого производственного состояния.

Состояние производства Возможности устройства
Пустой enableRfTestMode, fieldServicing и те, которые загружаются или передаются с помощью операции, как описано в разделе Возможности устройства.
Module1Complete fieldServicing и те, которые загружаются неопубликованным или передаются вместе с операцией, как описано в разделе Возможности устройства.
DeviceComplete Только те, которые загружаются неопубликованным или передаются вместе с операцией, как описано в разделе Возможности устройства.

После завершения производства используйте команду az sphere device manufacturing-state update , чтобы задать состояние DeviceComplete :

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

Примечание

Если к компьютеру подключено несколько устройств, включите --device параметр для идентификации целевого устройства по IP-адресу или пути подключения. Дополнительные сведения см. в статье Подключение каждой микросхемы Azure Sphere к компьютеру на заводе .

Важно

Перемещение микросхемы в состояние DeviceComplete является постоянной операцией, и ее невозможно отменить. После того как микросхема находится в состоянии DeviceComplete , она не может перейти в режим тестирования RF; его параметры e-fuse не могут быть изменены; и Wi-Fi параметры, обновления операционной системы и установленные приложения не могут быть изменены без утверждения устройства и использования возможности устройства. Если вам нужно повторно включить функции на отдельной микросхеме, которая не включает возможности устройства повторно, например в сценарии анализа сбоев, обратитесь в корпорацию Майкрософт.