Zephyr 기반 IoT 애플리케이션 디버깅을 위한 모범 사례

Linux Foundation Zephyr 오픈 소스 프로젝트는 많은 IoT 프로젝트의 중추로 성장했습니다. Zephyr는 여러 아키텍처에서 리소스가 제한된 장치에 최적화된 동급 최고의 소형, 확장 가능한 실시간 운영 체제(RTOS)를 제공합니다. 이 프로젝트에는 현재 1,000명의 기여자와 50,000명의 커밋이 있으며 ARC, Arm, Intel, Nios, RISC-V, SPARC 및 Tensilica와 250개 이상의 보드를 포함한 여러 아키텍처에 대한 고급 지원을 구축하고 있습니다.

Zephyr로 작업할 때 연결 상태를 유지하고 안정적으로 작동하기 위해 몇 가지 중요한 고려 사항이 있습니다. 개발자는 책상에서 모든 종류의 문제를 해결할 수 없으며 일부는 장치 집합이 증가할 때만 분명해집니다. 네트워크와 네트워크 스택이 발전함에 따라 업그레이드로 인해 불필요한 문제가 발생하지 않도록 해야 합니다.

예를 들어 농장 동물을 추적하기 위해 배치된 GPS 추적기가 직면한 상황을 생각해 보십시오. 이 장치는 발자국이 적은 센서 기반 칼라였습니다. 주어진 날에 동물은 모바일 네트워크에서 모바일 네트워크로 로밍했습니다. 국가에서 국가로; 위치에서 위치로. 이러한 움직임으로 인해 잘못된 구성과 예기치 않은 동작이 빠르게 노출되어 전력 손실로 이어질 수 있어 막대한 경제적 손실을 초래할 수 있습니다. 우리는 문제에 대해 알 필요가 없었습니다. 문제가 발생한 이유와 해결 방법을 알아야 했습니다. 연결된 장치로 작업할 때 원격 모니터링 및 디버깅은 무엇이 잘못되었는지, 상황을 해결하기 위한 최선의 단계, 궁극적으로 정상 작동을 설정하고 유지하는 방법에 대한 즉각적인 통찰력을 얻는 데 매우 중요합니다.

Zephyr와 클라우드 기반 장치 관찰 플랫폼 Memfault의 조합을 사용하여 장치 모니터링 및 업데이트를 지원합니다. 경험에 따르면 두 가지를 모두 활용하여 재부팅, 감시 장치, 오류/어설션 및 연결 메트릭을 사용하여 원격 모니터링을 위한 모범 사례를 설정할 수 있습니다.

관측 가능성 플랫폼 설정

Memfault를 통해 개발자는 펌웨어를 원격으로 모니터링, 디버그 및 업데이트할 수 있으므로 다음을 수행할 수 있습니다.

<울>

최소 실행 가능한 제품 및 Day-0 업데이트를 위해 생산 중단 방지

전체 기기 상태를 지속적으로 모니터링

최종 사용자가 문제를 인지하기 전에 업데이트 및 패치를 푸시합니다.

Memfault의 SDK는 클라우드 분석 및 문제 중복 제거를 위한 데이터 패킷을 수집하기 위해 쉽게 통합됩니다. 매니페스트 파일에 추가하는 일반적인 Zephyr 모듈처럼 작동합니다.

# west.yml [ ... ]  - 이름:memfault-firmware-sdk  URL:https://github.com/memfault/memfault-firmware-sdk  경로:모듈/memfault-firmware-sdk  개정:마스터     # prj.conf CONFIG_MEMFAULT=y CONFIG_MEMFAULT_HTTP_ENABLE=y   

첫 번째 초점 영역:재부팅

장치에서 재설정이 상당히 급증했다고 가정합니다. 이는 종종 토폴로지의 무언가가 변경되었거나 하드웨어 결함으로 인해 장치에 문제가 발생하기 시작했음을 나타내는 초기 지표입니다. 기기 상태에 대한 통찰력을 얻기 위해 수집할 수 있는 가장 작은 정보이며 하드웨어 재설정과 소프트웨어 재설정의 두 부분으로 생각하는 데 도움이 됩니다.

하드웨어 재설정은 종종 하드웨어 감시 및 절전으로 인해 발생합니다. 소프트웨어 재설정은 펌웨어 업데이트, 어설션 또는 사용자 시작으로 인해 발생할 수 있습니다.

어떤 유형의 재설정이 발생하는지 식별한 후 전체 제품군에 영향을 미치는 문제가 있는지 또는 소수의 장치에만 국한된 문제인지 이해할 수 있습니다.

재부팅 이유 기록

무효  fw_update_finish(무효) {  // ...   memfault_reboot_tracking_mark_reset_imminent(kMfltRebootReason_FirmwareUpdate, ...);  sys_reboot(0); } 

Zephyr에는 Memfault가 연결되는 재설정을 통해 보존될 영역을 등록하는 메커니즘이 있습니다. 플랫폼을 재부팅하려는 경우 시작하기 직전에 저장하는 것이 좋습니다. 플랫폼을 재부팅할 때 재부팅 이유(이 경우 펌웨어 업데이트)를 기록한 다음 Zephyr sys_reboot라고 합니다.

Zephyr에서 기기 재설정 캡처

부팅 정보를 읽는 초기화 핸들러 등록

정적  int record_reboot_reason() {   // 1. 하드웨어 리셋 이유 레지스터를 읽는다.   (MCU 데이터 시트에서 레지스터 이름 확인)   // 2. noinit RAM에서 소프트웨어 재설정 이유 캡처   // 3. 집계를 위해 서버로 데이터 보내기  }   SYS_INIT(record_reboot_reason, APPLICATION,  CONFIG_KERNEL_INIT_PRIORITY_DEFAULT); 

MCU 리셋 이유 레지스터를 통해 리셋하기 전에 시스템 정보를 캡처하는 매크로를 설정할 수 있습니다. 기기가 다시 시작되면 Zephyr는 system_int 매크로를 사용하여 핸들러를 등록합니다. MCU 리셋 이유 레지스터는 모두 약간 다른 이름을 가지고 있으며 하드웨어 문제나 결함이 있는지 확인할 수 있으므로 모두 유용합니다.

예:전원 공급 문제

원격 모니터링이 재부팅 및 전원 공급 장치를 살펴봄으로써 차량 상태에 대한 중요한 통찰력을 제공할 수 있는 방법의 예를 살펴보겠습니다. 여기서 우리는 12,000회 이상의 재부팅을 차지하는 소수의 기기를 볼 수 있습니다(그림 1).

전체 크기 이미지를 보려면 클릭하세요.

그림 1:전원 공급 문제의 예, 15일 동안의 재부팅 차트. (출처:저자)

<울>

12,000번의 기기 재부팅 – 너무 많음

재부팅의 99%는 10개의 기기에서 발생합니다.

기기의 지속적인 재부팅을 유발하는 잘못된 기계 부품

이 경우 기계적 문제(부품 불량, 배터리 접촉 불량 또는 다양한 고질적인 속도 문제)로 인해 일부 장치가 하루에 1,000번 재부팅됩니다.

장치가 생산되면 펌웨어 업데이트를 통해 이러한 여러 문제를 처리할 수 있습니다. 업데이트를 출시하면 하드웨어 결함을 해결하고 기기를 복구 및 교체해야 하는 필요성을 피할 수 있습니다.

두 번째 초점 영역:감시 장치

연결된 스택으로 작업할 때 감시 장치는 장치를 수동으로 재설정하지 않고도 시스템을 깨끗한 상태로 되돌릴 수 있는 마지막 방어선입니다. 정지는 다음과 같은 여러 가지 이유로 발생할 수 있습니다.

<울>

send()의 연결 스택 블록

무한 재시도 루프

작업 간 교착 상태

부패

하드웨어 감시 장치는 장치를 재설정하지 못하도록 주기적으로 "공급"해야 하는 MCU의 전용 주변 장치입니다. 소프트웨어 워치독은 펌웨어에서 구현되고 하드웨어 워치독보다 먼저 실행되어 하드웨어 워치독으로 이어지는 시스템 상태 캡처가 가능합니다.

Zephyr에는 모든 MCU가 일반 API를 통해 플랫폼에서 감시 장치를 설정 및 구성할 수 있는 하드웨어 감시 장치 API가 있습니다. (자세한 내용은 Zephyr API 참조:zephyr/include/drivers/watchdog.h)

// ... 무효  start_watchdog(무효) {  // 사용 가능한 하드웨어 감시 장치에 대한 장치 트리 참조   s_wdt =device_get_binding(DT_LABEL(DT_INST(0, nordic_nrf_watchdog)));    구조 wdt_timeout_cfg wdt_config ={  /* 감시 타이머가 만료되면 SoC를 재설정합니다.   */   .flags =WDT_FLAG_RESET_SOC,     /* 최대 기간 후 워치독 만료 */   .window.min =0U,  .window.max =WDT_MAX_WINDOW,  };    s_wdt_channel_id =wdt_install_timeout(s_wdt, &wdt_config);    const uint8_t 옵션 =WDT_OPT_PAUSE_HALTED_BY_DBG;  wdt_setup(s_wdt, 옵션);  // TODO:소프트웨어 감시 시작   }   무효  feed_watchdog(무효) {  wdt_feed(s_wdt, s_wdt_channel_id);  // TODO:피드 소프트웨어 감시자  } 

Nordic nRF9160의 이 예를 사용하여 몇 가지 단계를 살펴보겠습니다.

<올>

기기 트리로 이동하여 Nordic nRF watchtime 폴더를 설정합니다.

노출된 API를 통해 watchdog에 대한 구성 옵션을 설정합니다.

감시 장치를 설치합니다.

동작이 예상대로 실행될 때 주기적으로 감시 장치를 제공합니다. 때때로 이것은 가장 낮은 우선 순위 작업에서 수행됩니다. 시스템이 멈추면 재부팅됩니다.

Zephyr에서 Memfault를 사용하면 타이머 주변 장치로 구동되는 커널 타이머를 사용할 수 있습니다. 소프트웨어 워치독 시간 초과를 하드웨어 워치독보다 먼저 설정할 수 있습니다(예:하드웨어 워치독을 60초로 설정하고 소프트웨어 워치독을 50초로 설정). 콜백이 호출되면 어설션이 트리거되어 Zephyr 오류 처리기를 통해 시스템이 중단된 해당 시점에 무슨 일이 일어났는지에 대한 정보를 얻습니다.

예:SPI 드라이버 멈춤

다시 개발에 얽매이지 않고 현장에서 발생하는 문제의 예를 살펴보겠습니다. 그림 2에서 SPI 드라이버 칩의 타이밍, 사실 및 성능 저하를 볼 수 있습니다.

전체 크기 이미지를 보려면 클릭하세요.

그림 2:SPI 드라이버 멈춤 예. (출처:저자)

<울>

시간 경과에 따른 SPI 플래시 저하, 잘못된 통신 타이밍

16개월 간의 현장 배포 후 1%의 기기에서 이를 추적했습니다.

드라이버 수정 및 다음 릴리스 출시

Flash의 경우 현장에서 1년이 지나면 SPI 트랜잭션이나 다양한 코드 조각에 끼어 갑자기 오류가 시작되는 것을 볼 수 있습니다. 전체 추적이 있으면 근본 원인을 찾고 솔루션을 개발하는 데 도움이 됩니다.

아래의 감시 장치(그림 3)가 Zephyr 오류 처리기를 시작합니다.

그림 3:오류 처리기 예, 레지스터 덤프. (출처:저자)

세 번째 영역 초점:결함/주장:

추적할 세 번째 구성 요소는 결함 및 주장입니다. 로컬 디버그를 수행했거나 자체 기능을 구축한 적이 있다면 플랫폼에서 오류가 발생했을 때 등록 상태에 대한 유사한 화면을 본 적이 있을 것입니다. 그 이유는 다음과 같습니다.

<울>

주장 또는

불량 메모리 액세스

0으로 나누기

주변기기를 잘못된 방식으로 사용

다음은 Zephyr의 Cortex M 마이크로컨트롤러에서 취한 오류 처리 흐름의 예입니다.

무효  network_send(무효) {  const size_t packet_size =1500;  무효 * 버퍼 =z_malloc(packet_size);  // NULL 검사가 누락되었습니다!   memcpy(버퍼, 0x0, 패킷 크기);  // ...  } ↓무효  network_send(무효) {  const size_t packet_size =1500;  무효 * 버퍼 =z_malloc(packet_size);  // NULL 검사가 누락되었습니다!   memcpy(버퍼, 0x0, 패킷 크기);  // ...  } ↓부울  memfault_coredump_save(const   sMemfaultCoredumpSaveInfo *save_info) {  // 등록 상태 저장   // _커널 및 작업 컨텍스트 저장   // 선택한 .bss 및 .data 영역 저장  } ↓무효  sys_arch_reboot(int 유형) {  // ...  } 

주장 또는 결함이 시작되면 인터럽트가 발생하고 충돌 시 레지스터 상태를 제공하는 Zephyr에서 결함 처리기가 호출됩니다.

Memfault SDK는 오류 처리 흐름에 자동으로 연결되어 등록 상태, 커널 상태 및 충돌 시점에 시스템에서 실행 중인 모든 작업의 ​​일부를 포함한 중요한 정보를 클라우드에 저장합니다.

로컬 또는 원격으로 디버깅할 때 찾아야 할 세 가지 사항이 있습니다.

<올>

Cortex M 오류 상태 레지스터는 플랫폼이 어설션되거나 오류가 발생한 이유를 알려줍니다.

Memfault는 시스템이 충돌 전에 실행되었던 정확한 코드 줄과 다른 모든 작업의 ​​상태를 복구합니다.

_커널 수집 Zephyr RTOS의 구조를 통해 스케줄러를 확인하고, 연결된 애플리케이션인 경우 Bluetooth 또는 LTE 매개변수의 상태를 확인합니다.

네 번째 초점 영역:기기 관찰 가능성을 위한 추적 측정항목

추적 지표를 사용하면 시스템에서 발생하는 일의 패턴을 구축하기 시작할 수 있으며, 이를 통해 기기와 제품군 전체를 비교하여 어떤 변경 사항이 영향을 미치는지 이해할 수 있습니다.

추적에 유용한 몇 가지 측정항목은 다음과 같습니다.

<울>

CPU 사용률

연결 매개변수

열 사용량

Memfault SDK를 사용하면 다음 두 줄의 코드로 Zephyr에서 메트릭 정의를 추가하고 시작할 수 있습니다.

<올>

측정항목 정의

MEMFAULT_METRICS_KEY_DEFINE(  LTE 연결 해제, kMemfaultMetricType_Unsigned) 

1. 코드에서 측정항목 업데이트

무효  lte_disconnect(무효) {  memfault_metrics_heartbeat_add(  MEMFAULT_METRICS_KEY(LteDisconnect), 1),  //...  } 

Memfault SDK + 클라우드

<울>

전송을 위한 메트릭 직렬화 및 압축

기기 및 펌웨어 버전별 지표 색인

기기별 및 플릿 전체에서 측정항목을 검색하기 위한 웹 인터페이스를 표시합니다.

수십 개의 메트릭을 장치 및 펌웨어 버전별로 수집하고 인덱싱할 수 있습니다. 몇 가지 예:

<울>

NB-IoT/LTE-M 기본 연결: 모뎀이 연결되거나 연결되어 배터리 수명에 어떤 영향을 미치는지 알아보세요.

NB-IoT/LTE-M에서 기지국 및 PSM 추적: 모바일 신호 품질은 관리되지 않으면 고통스러울 수 있으며 배터리 수명을 소모할 수 있습니다. 네트워크 상태, 이벤트, 기지국 정보, 설정, 타이머 등에 대한 메트릭을 만듭니다. 변경 사항을 모니터링하고 알림을 사용하세요.

대규모 테스트: 예상치 못한 대용량 데이터는 기기 연결 비용을 증가시키고 이상점을 식별하는 데 도움이 될 수 있습니다.

예:NB-IoT/LTE-M 데이터 크기

전체 크기 이미지를 보려면 클릭하세요.

그림 4:장치 관찰 가능성에 대한 추적 메트릭 – NB-IoT 예, LTE-M 데이터 크기. (출처:저자)

<울>

UDP 데이터 크기:전송 간격당 추적 바이트(그림 4)

재부팅 후 더 많은 데이터가 전송됨

추가 정보 또는 추적으로 인해 일부 패킷이 더 큽니다.

데이터 소비 문제 추적

결론

개발자는 Zephyr 및 Memfault를 활용하여 원격 모니터링을 구현하여 연결된 장치 기능을 더 잘 관찰할 수 있습니다. 재부팅, 워치독, 오류/어설션 및 연결 메트릭에 중점을 두어 개발자는 IoT 시스템의 비용과 성능을 최적화할 수 있습니다.

2021 Zephyr 개발자 회의에서 녹화된 프레젠테이션을 보고 자세히 알아보세요.