관리형 통합 허브 오프보드 - 에 대한 관리형 통합 AWS IoT Device Management

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

관리형 통합 허브 오프보드

Hub SDK 오프보드 프로세스 개요

허브 오프보딩 프로세스는 AWS 클라우드 관리 시스템에서 허브를 제거합니다. 클라우드가 DeleteManagedThing 요청을 보내면 프로세스는 두 가지 기본 목표를 달성합니다.

디바이스 측 작업:

  • 허브의 내부 상태 재설정

  • 로컬로 저장된 모든 데이터 삭제

  • 향후 재온보딩 가능성을 위해 디바이스 준비

클라우드 측 작업:

  • 허브와 연결된 모든 클라우드 리소스 제거

  • 이전 계정과의 연결 해제 완료

고객은 일반적으로 다음과 같은 경우 허브 오프보딩을 시작합니다.

  • 허브의 연결된 계정 변경

  • 기존 허브를 새 디바이스로 교체

이 프로세스는 허브 구성 간에 깔끔하고 안전한 전환을 보장하여 원활한 디바이스 관리와 계정 유연성을 제공합니다.

허브 오프보딩 다이어그램

사전 조건

  • 온보딩된 허브가 있어야 합니다. 지침은 허브 온보딩 설정을 참조하세요.

  • /data/aws/iotmi/config/에 있는 iotmi_config.json 파일에서가 iot_provisioning_state를 표시하는지 확인합니다PROVISIONED.

  • 에서 참조되는 영구 인증서와 키가 지정된 경로에 iotmi_config.json 있는지 확인합니다.

  • HubOnboarding, Agent, Provisioner 및 MQTT 프록시가 올바르게 구성되고 실행 중인지 확인합니다.

  • 허브에 하위 디바이스가 없는지 확인합니다. 계속하기 전에 DeleteManagedThing API를 사용하여 모든 하위 디바이스를 제거합니다.

Hub SDK 오프보드 프로세스

다음 단계에 따라 허브를 오프보드합니다.

hub_managed_thing ID 검색

iotmi_config.json 파일은 관리형 통합 허브의 관리형 사물 ID를 저장하는 데 사용됩니다. 이 식별자는 허브가 AWS IoT 관리형 통합 서비스와 통신할 수 있도록 하는 중요한 정보입니다. 관리형 사물 ID는 JSON 파일의 rw(읽기-쓰기) 섹션 내 managed_thing_id 필드 아래에 저장됩니다. 이는 다음 샘플 구성에서 볼 수 있습니다.

{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "UPC", "sh_endpoint_url": "ENDPOINT_URL", "SN": "SN", "fp_template_name": "TEMPLATENAME" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "ID", "managed_thing_id": "ID", "iot_permanent_cert_path": "CERT_PATH", "iot_permanent_pk_path": "KEY", "metadata": { "last_updated_epoch_time": 1747766125 } } }

오프보드 허브로 명령 전송

계정 자격 증명을 사용하고 이전 섹션에서 managed_thing_id 검색된 로 명령을 실행합니다.

aws iot-managed-integrations delete-managed-thing \ --identifier HUB_MANAGED_THING_ID

허브가 오프보딩되었는지 확인

계정 자격 증명을 사용하고 이전 섹션에서 managed_thing_id 검색된 로 명령을 실행합니다.

aws iot-managed-integrations get-managed-thing \ --identifier HUB_MANAGED_THING_ID

성공 및 실패 시나리오

성공 시나리오

허브 오프보드 명령이 성공하면 다음 샘플 응답이 예상됩니다.

{ "Message" : "Managed Thing resource not found." }

또한 허브 오프보딩 명령이 성공하면 다음 샘플이 관찰iotmi_config.json됩니다. rw 섹션에 iot_provisioning_state 및 선택적으로 메타데이터만 포함되어 있는지 확인합니다. 메타데이터의 부재는 허용됩니다.는 NOT_PROVISIONED여야 iot_provisioning_state 합니다.

{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "1234567890101", "sh_endpoint_url": "ENDPOINT_URL", "SN": "1234567890101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "NOT_PROVISIONED", "metadata": { "last_updated_epoch_time": 1747766125 } } }

실패 시나리오

허브 오프보드 명령이 실패한 경우 다음 샘플 응답이 예상됩니다.

{ "Arn" : "ARN", "CreatedAt" : 1.748968266655E9, "Id" : "ID", "ProvisioningStatus" : "DELETE_IN_PROGRESS", "Role" : "CONTROLLER", "SerialNumber" : "SERIAL_NO", "Tags" : { }, "UniversalProductCode" : "UPC", "UpdatedAt" : 1.748968272107E9 }
  • ProvisioningStatus가 인 경우 Hub 복구의 지침을 DELETE_IN_PROGRESS따릅니다.

  • ProvisioningStatus가가 아닌 경우 허브 오프보드 DELETE_IN_PROGRESS명령이 관리형 통합 클라우드에서 실패했거나 관리형 통합 클라우드에서 수신되지 않았습니다. Hub 복구의 지침을 따릅니다.

  • 오프보딩에 실패한 경우 iotmi_config.json 파일은 아래 샘플 파일과 같습니다.

{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "123456789101", "sh_endpoint_url": "ENDPOINT_URL", "SN": "123456789101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "ID", "managed_thing_id": "ID", "iot_permanent_cert_path": "PATH", "iot_permanent_pk_path": "PATH", "metadata": { "last_updated_epoch_time": 1747766125 } } }

(선택 사항) 오프보딩 후 Hub SDK

중요

다음 시나리오에서는 오프보딩 Hub SDK가 실패한 후 또는 오프보딩 후 허브를 다시 온보딩하려는 경우 수행할 선택적 작업을 나열합니다.

재온보딩

오프보딩에 성공한 경우 3단계: 관리형 사물 생성(플릿 프로비저닝) 및 나머지 온보딩 프로세스에 따라 Hub SDK를 온보딩합니다.

허브 복구
디바이스 허브 오프보딩 성공 및 클라우드 오프보딩 실패

GetManagedThing API 호출iotmi_config.jsonManaged Thing resource not found 메시지를 반환하지 않지만 파일이 오프보딩된 경우. 샘플 json 파일은 성공 시나리오를 참조하세요.

이 시나리오에서 복구하려면 강제 삭제를 참조하세요.

디바이스 허브 오프보딩 실패

이 시나리오는 파일이 올바르게 오프보드되지 않는 경우iotmi_config.json입니다. 샘플 json 파일의 실패 시나리오를 참조하세요.

이 시나리오에서 복구하려면 강제 삭제를 참조하세요. iotmi_config.json가 아직 오프보딩되지 않은 경우 허브를 공장 초기화해야 합니다.

디바이스 허브 오프보딩 및 클라우드 오프보딩 실패

이 시나리오에서 iotmi_config.json는 여전히 오프보딩되지 않으며 허브 상태는 ACTIVATED또는 입니다DISCOVERED.

이 시나리오에서 복구하려면 강제 삭제를 참조하세요. 강제 삭제iotmi_config.json에 실패하거나 오프보딩되지 않은 경우 허브를 초기 기본값으로 재설정해야 합니다.

허브가 오프라인 상태이고 허브 상태가 DELETE_IN_PROGRESS임

이 시나리오에서는 허브가 오프라인 상태이고 클라우드가 오프보딩 명령을 수신합니다.

이 시나리오에서 복구하려면 강제 삭제를 참조하세요.

강제 삭제

성공적인 디바이스 허브 오프보딩 없이 클라우드 리소스를 삭제하려면 다음 단계를 따르세요. 이 작업을 수행하면 클라우드와 디바이스 상태 간에 불일치가 발생하여 향후 운영에 문제가 발생할 수 있습니다.

허브의 managed_thing_idforce 파라미터를 사용하여 DeleteManagedThing API를 호출합니다.

aws iot-managed-integrations delete-managed-thing \ --identifier HUB_MANAGED_THING_ID \ --force

그런 다음 GetManagedThing API를 호출하고를 반환하는지 확인합니다Managed Thing resource not found. 이렇게 하면 클라우드 리소스가 삭제됩니다.

참고

클라우드 상태와 디바이스 상태 간에 불일치가 발생할 수 있으므로이 접근 방식은 권장되지 않습니다. 일반적으로 클라우드 리소스를 삭제하기 전에 성공적인 디바이스 허브 오프보딩을 보장하는 것이 좋습니다.