Поделиться через

Задачи заводского уровня

  • Статья

Внимание

Это документация по Azure Sphere (устаревшая версия). Служба Azure Sphere (устаревшая версия) выходит на пенсию 27 сентября 2027 г., и к этому времени пользователи должны перейти в Azure Sphere (интегрированная). Используйте селектор версий, расположенный над toC, чтобы просмотреть документацию по Azure Sphere (интегрированная).

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

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

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

Внимание

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

Подключение каждого чипа Azure Sphere к компьютеру на этаже фабрики

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

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

Внимание

Выпуск пакета SDK для Azure Sphere 23.05 и более поздних выпусков поддерживает взаимодействие с несколькими подключенными устройствами в Windows и Linux.

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

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

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

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

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

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

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

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

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

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

azsphere 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 того, что устаревшее надежное хранилище ключей является причиной.

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

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

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

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

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

Интерфейс для подключения компьютера и средств

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Программа e-fuses для включения каналов Wi-Fi

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

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

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

Пример. Чтобы указать ОС 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)

Проверка радиочастотной конфигурации

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

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

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

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

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

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

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

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

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

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

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

Завершение подготовки устройства Azure Sphere

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

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

  • Назначение состояния изготовления устройства для блокировки радиочастотной конфигурации и средств калибровки для устранения брешей в системе безопасности.

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

Перед отправкой продукта, включающего устройство 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), которые должны присутствовать на устройстве для успешной проверки. Список состоит из графических идентификаторов изображений, разделенных пробелами. Этот параметр по умолчанию использует пустой список, если он не указан. Если список установленных идентификаторов образов на устройстве отличается от этого списка, проверка завершается ошибкой. Проверив идентификаторы изображений (а не идентификаторы компонентов), эта проверка гарантирует наличие определенной версии компонента.
--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 ограничивает доступ к таким операциям.

Три производственных состояния:

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

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

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

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

    Не устанавливайте DeviceComplete для незавершенных устройств или модулей (модули Wi-Fi, доски разработки и т. д.), которые могут использоваться в рамках более крупной системы. Это состояние ограничивает производственные действия, такие как тестирование производственных линий, установка программного обеспечения и конфигурация. Многие команды ИНТЕРФЕЙСА командной строки недоступны после установки DeviceComplete , поэтому перед заданием этого состояния необходимо выполнить определенные проверки готовности к отправке. Ограниченные команды можно повторно включить с помощью таких возможностей устройств, как возможность поля , но только для устройств, которые вы утверждали, и поэтому это не подходит для использования в среде на заводских этажах, так как требуется облачное подключение.

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

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

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

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

Примечание.

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

Внимание

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