다음을 통해 공유

무선 업데이트 정보

  • 아티클

업데이트 재생 가능 보안의 속성을 구현하기 때문에 Azure Sphere 보안 모델의 중요한 부분입니다. 업데이트가 정기적으로 수행되도록 하면 디바이스 7 속성을 준수하는 데 도움이 됩니다. Azure Sphere 디바이스는 전원을 켜거나 다시 설정 단추를 누른 후 인터넷에 처음 연결할 때 업데이트를 검사. 그 후 검사는 정기적으로 발생합니다(현재 20시간).

업데이트에는 필수 업데이트, OS 업데이트 및 배포 업데이트의 세 가지 유형 이 있습니다. 필수 구성 요소 업데이트는 업데이트 프로세스 자체가 사용하는 구성 요소(현재 TKS(신뢰할 수 있는 키 저장소) 및 인증서 저장소)가 최신 상태인지 확인하는 데 사용됩니다. TKS는 다운로드 및 설치할 이미지를 인증하는 데 사용되며 인증서 저장소는 인터넷 연결의 유효성을 검사합니다. OS 업데이트는 애플리케이션이 실행되는 일반 세계 운영 체제뿐만 아니라 Pluton 하위 시스템 및 보안 모니터와 같은 하위 수준 펌웨어를 포함하여 디바이스에서 Microsoft에서 제공하는 소프트웨어를 대상으로 합니다. 배포 업데이트는 사용자 고유의 소프트웨어(고급 및 실시간 지원 애플리케이션 및 보드 구성 이미지(있는 경우)를 대상으로 합니다. 필수 구성 요소 및 OS 업데이트는 Azure Sphere에서 관리됩니다. 애플리케이션 업데이트는 organization 만든 배포에 따라 Azure Sphere에서 조정됩니다.

모든 디바이스가 필수 구성 요소 또는 OS 업데이트를 수신하려면 다음을 수행합니다.

모든 디바이스가 애플리케이션 및 보드 구성 이미지를 업데이트하려면 다음을 수행합니다.

  • 애플리케이션 개발 기능이없어야 합니다.
  • 카탈로그에서 클레임해야 합니다.
  • 디바이스 그룹에 속해야 합니다.
  • 속한 디바이스 그룹은 배포의 대상이 되어야 합니다.
  • 배포에는 organization 또는 를 대신하여 만든 애플리케이션 이미지(및 선택적으로 보드 구성 이미지)가 포함되어야 합니다.
  • 디바이스 그룹에 UpdateAll 업데이트 정책이 있어야 합니다. az sphere device-group update 명령을 사용하여 특정 디바이스 그룹에 대한 애플리케이션 업데이트를 사용하지 않도록 설정할 수 있습니다.

지정된 디바이스 그룹의 모든 디바이스에서 해당 디바이스 그룹을 대상으로 하는 배포는 해당 디바이스를 이미징하기 위한 진리 소스로 간주됩니다. 배포에 없는 디바이스의 이미지는 디바이스에서 제거됩니다. Azure Sphere OS 21.04의 한 가지 예외는 보드 구성 이미지가 새 보드 구성 이미지로 대체되지 않는 한 제거되지 않는다는 것입니다.

디바이스 업데이트 검사 세 가지 유형의 업데이트에 해당하는 세 단계로 수행됩니다.

  • 첫 번째 단계에서 Azure Sphere는 TKS 및 인증서 저장소의 현재 버전을 나열하는 매니페스트를 가져옵니다. 디바이스의 TKS 및 인증서 저장소가 최신 상태인 경우 업데이트는 두 번째 단계로 계속됩니다. 그렇지 않은 경우 현재 이미지가 다운로드되어 설치됩니다.
  • 두 번째 단계에서 Azure Sphere는 다양한 OS 구성 요소 이미지의 현재 버전을 나열하는 매니페스트를 가져옵니다. 디바이스의 이미지가 최신 상태가 아니면 업데이트 프로세스가 실패할 경우 디바이스를 알려진 양호한 상태로 롤백하는 데 사용할 수 있는 롤백 이미지 와 함께 현재 이미지가 다운로드됩니다. OS 및 롤백 이미지는 다운로드되어 디바이스의 스테이징 영역에 저장되고 OS 이미지가 설치되고 디바이스가 다시 부팅됩니다.
  • 세 번째 단계에서 Azure Sphere는 디바이스 그룹이 이를 수락하는 경우 배포 업데이트를 확인합니다. OS 업데이트와 마찬가지로 애플리케이션에 대한 롤백 이미지도 필요에 따라 준비됩니다. 애플리케이션 및 롤백 이미지가 다운로드되어 스테이징 영역에 저장되고 애플리케이션 이미지가 설치됩니다.

업데이트 롤백

업데이트 프로세스의 각 부분에는 롤백 옵션이 포함됩니다. 필수 구성 요소 업데이트에서 롤백 이미지는 단순히 사전 업데이트 상태의 백업입니다. 업데이트가 실패하면 업데이트 전 상태가 복원됩니다.

모든 수준의 롤백은 모든 상위 수준에서 롤백을 강제합니다. 펌웨어 이미지가 부팅되지 않으면 펌웨어 및 애플리케이션 파티션이 모두 롤백됩니다.

OS 업데이트의 경우 서명 확인 실패 또는 런타임 문제가 롤백을 트리거할 수 있습니다. 서명 확인 실패의 경우 이미지를 수정하려고 시도합니다. 이 작업이 실패하면 전체 롤백이 트리거됩니다. 전체 롤백에서 스테이징된 롤백 이미지는 OS 및 애플리케이션 모두에 대해 설치됩니다.

OS 업데이트 및 배포에는 독립적인 릴리스 주기가 있으므로 OS 업데이트 간에 여러 배포가 발생할 수 있습니다. 이 경우 배포에 대한 롤백 대상은 최신 배포가 아니라 마지막 OS 업데이트 당시의 배포라는 점에 유의해야 합니다. 이렇게 하면 OS와 애플리케이션이 롤백 상태에서 함께 작동합니다.

중단된 업데이트

예를 들어 정전 또는 연결 끊기 등 업데이트가 중단되는 경우 각 업데이트 유형에 대해 다음과 같은 네 가지 시나리오가 있습니다.

  • 전체 이미지 집합이 성공적으로 다운로드되고 스테이징되었지만 아직 설치되지 않은 경우 전원이 복원되면 설치가 완료됩니다.
  • 일부 이미지가 다운로드되고 스테이징되지 않은 경우 업데이트는 누락된 이미지를 계속 다운로드한 다음 설치를 진행합니다.
  • 다운로드가 완료된 후 설치 중에 업데이트가 중단되면 부팅 시 설치가 다시 시작됩니다.
  • 이미지가 완전히 다운로드되지 않은 경우 설치할 준비가 되지 않은 상태로 전원이 복원되면 업데이트 프로세스가 새로 시작됩니다.

전원 다운 시나리오의 업데이트

Azure Sphere는 배터리 수명을 절약하기 위해 디바이스의 전원을 장기간 낮추 도록 하는 저전력 시나리오를 지원합니다. 이러한 시나리오에서는 디바이스가 주기적으로 업데이트를 검사 수 있어야 합니다. Power Down 샘플 애플리케이션은 디바이스가 OS 및 앱 업데이트를 위해 검사 주기적으로 절전 모드에서 유지되도록 하면서 전력 소비를 적절하게 줄이는 방법을 보여 줍니다.

지연된 업데이트

업데이트로 인해 중요한 작업이 중단되지 않도록 상위 수준 애플리케이션은 지연된 업데이트를 통합할 수 있습니다. 이 기능을 사용하면 애플리케이션이 중요한 작업을 완료한 다음 업데이트를 진행할 수 있도록 종료를 준비할 수 있습니다. DeferredUpdate 샘플은 이러한 지연된 업데이트를 구현하는 방법을 보여 줍니다.