현장 배포 장치의 소프트웨어 추적

소프트웨어 추적은 특히 고급 시각화와 결합될 때 모든 임베디드 개발자 도구 상자에서 중요한 도구입니다. 대부분의 임베디드 시스템에는 동일한 시퀀스가 ​​계속 반복되는 많은 순환 패턴이 있습니다. 디버깅할 때 일반적이지 않은 일이 발생한 정상적인 순환 동작에서 벗어나는 예외를 찾고자 하는 경우가 많습니다.

그러나 소프트웨어 추적 자체는 데이터 수집의 한 형태일 뿐입니다. 텍스트 또는 숫자 로그 데이터에서 문제를 찾는 것은 건초 더미에서 바늘을 찾는 것과 유사하지만 적절한 시각화를 통해 검색은 시각적 패턴 인식의 문제로 변환됩니다. . 실행 시간, 응답 시간, 작업 전환, 작업 간 메시지 전달을 보여주는 대화형 그래프 - 이 모든 것을 통해 개발자는 펌웨어 실행의 이상을 빠르게 찾아내고 더 깊이 파고들 수 있습니다.

시각적 추적 진단을 위한 도구는 적어도 10년 동안 주변에 있었고 연구실에서 개발 및 디버깅에 유용한 것으로 입증되었습니다. 점점 더 많은 임베디드 소프트웨어 개발자가 안전한 '사물 인터넷' 클라우드 연결을 추가함에 따라 테스트 중에 놓쳤던 실제 문제를 포착하기 위해 현장에 배포된 장치에서 추적 사용을 고려하는 것이 매우 자연스럽습니다. 결국 소프트웨어 기반 추적은 추가 하드웨어가 필요하지 않으며 연결된 IoT 장치는 분명히 일반 애플리케이션 데이터와 동일한 방식으로 진단 추적 데이터를 업로드할 수 있습니다. 이러한 방식으로 개발자는 실제 작동 중에 문제를 일으키는 남아 있는 소프트웨어 문제를 신속하게 파악하고 원인을 이해하기 위한 상세한 진단을 받을 수 있습니다.

이 시나리오에서 소프트웨어 추적은 사고 발생 시 여객기에서 사용되는 것과 같은 가상 "비행 기록기"와 비슷합니다. 항상 기록하는 제품의 통합 부품으로, 문제 발생 시 중요한 정보를 제공합니다. 그러나 실제 비행 녹음기 상자와 달리 소프트웨어 솔루션이며 소프트웨어 문제를 위한 것입니다.

이러한 종류의 IoT 장치 모니터링을 위한 한 가지 솔루션은 Percepio의 DevAlert(그림 1)로, 세 부분으로 구성됩니다. 펌웨어 모니터, 경고 추적 및 업로드를 활성화하기 위해 펌웨어에 추가하는 작은 라이브러리, 시각적 추적 진단을 위한 Tracealyzer 도구; 경고 분류 및 저장, 개발자에게 알리기, 중복 경고 필터링 등을 담당하는 클라우드 서비스입니다.

그림 1. Percepio DevAlert는 IoT 개발자에게 클라우드 연결 기기의 오류에 대한 즉각적인 피드백을 제공하여 기기 소프트웨어를 지속적으로 빠르게 개선할 수 있도록 합니다.
(확대하려면 이미지를 클릭하십시오)

초기 버전은 AWS에서 실행되며 AWS IoT 코어를 사용하는 RTOS 애플리케이션을 위한 것이지만 솔루션은 다른 클라우드 플랫폼에 맞게 조정할 수 있습니다.

소프트웨어 추적 및 클라우드 연결
개발 랩에서의 추적과 배포된 장치 추적은 서로 다른 것입니다. 현재 실험실에서 시각적 추적 진단을 사용하고 있으며 이를 현장으로 확장하려는 경우 몇 가지 생각해 봐야 할 사항이 있습니다.

USB 또는 이더넷과 같은 직접적인 물리적 연결과 비교할 때 클라우드 연결은 제한된 대역폭과 훨씬 더 긴 응답 시간을 제공합니다. 무선 인터페이스를 통해 5KB의 데이터를 업로드하는 데 수십 또는 수백 밀리초가 필요할 수 있습니다. 그러나 이 접근 방식에서는 추적이 지속적으로 전송되지 않고 경고가 생성된 경우에만 가장 최근 이벤트의 작은 추적만 전송됩니다. 경고는 예를 들어 온전성 검사 실패, 하드 폴트 또는 워치독 재설정과 같은 오류가 애플리케이션 코드에서 감지된 경우와 같이 비정상적이지만 중요한 경우에만 사용됩니다.

인터넷에 연결된 모든 장치는 안전해야 합니다. 따라서 새로운 공격 벡터를 도입하지 않는 것이 중요합니다. 새로운 연결을 도입하는 대신 기존 클라우드 연결에 의존하여 DevAlert에서 이 문제를 해결합니다. 이는 X.509 인증서를 사용한 장치 인증 및 TLS를 사용한 암호화된 통신과 같은 모범 사례에 따라 보호되는 클라우드 연결을 위한 검증된 SDK를 제공하는 AWS 및 기타 주요 IoT/클라우드 공급자의 보안을 활용합니다. 그러면 DevAlert 업로드가 일반 IoT 애플리케이션 데이터만큼 안전해지며 보안 강화를 위해 단방향 통신만 필요합니다. 들어오는 메시지를 수신하지 않습니다.

이 접근 방식에서 경고는 장치에서 일반적으로 사용하는 것과 동일한 보안 수준과 동일한 클라우드 계정에 업로드됩니다. 일단 클라우드에 들어가면 데이터의 작은 부분이 클라우드 서비스에 제공됩니다. 여기에는 민감한 정보로 간주되어 장치의 클라우드 계정에 남아 있을 수 있는 실제 추적 데이터는 포함되지 않습니다. 그림 2a와 2b는 데이터 흐름과 보안 장벽을 보다 자세히 보여줍니다.

그림 2a. 데이터 흐름은 개발자가 소스 코드에 경고를 추가하는 장치 소프트웨어에서 시작됩니다. 장치 클라우드 계정에 업로드되는 모든 경고에는 경고 이전에 가장 최근 이벤트가 있는 짧은 추적이 포함됩니다. 마지막으로 메타데이터 서명이 DevAlert 클라우드 서비스로 전달됩니다. (이미지를 클릭하면 확대됩니다)

그림 2b. 클라우드 서비스는 수신되는 알림을 고객의 전체 장치 제품군에서 이전 알림과 비교하고 새로운 문제에 대해 개발자에게 알립니다. 중복된 경고는 계산되어 저장되지만 알림은 전송되지 않습니다. 이렇게 하면 여러 장치에서 동일한 경고가 트리거되는 경우 개발자의 받은 편지함이 넘치지 않습니다. (이미지를 클릭하면 확대됩니다)

클라우드 계정에 대한 알림을 수신하기 위한 운영 비용은 일반적으로 낮지만 일반적으로 볼륨에 따라 다릅니다. 우선 문제가 감지되지 않는 한 경고가 전송되지 않습니다. 일반적으로 클라우드 제공업체는 간헐적인 경고 메시지를 보내고 저장하는 데 비용을 거의 청구하지 않습니다. 대부분의 IoT 애플리케이션은 훨씬 더 많은 데이터를 생성하며 이는 IoT/클라우드 서비스의 가격 책정에 반영됩니다. 예를 들어, 100만 개의 MQTT 메시지를 AWS IoT 코어로 보내는 데 비용은 미화 1달러입니다.

대부분의 경고 처리는 Percepio에서 호스팅하는 완전 관리형 서비스인 클라우드 서비스에서 수행됩니다. 초기 처리만 기기 개발자 클라우드 계정에서 이루어지므로 클라우드 비용을 낮추고 통합을 간소화합니다.

보고된 오류를 수정하기 위해 무선 업데이트를 보내는 것은 더 많은 데이터와 모든 장치를 전송해야 하기 때문에 잠재적으로 약간 더 많은 비용이 들 수 있습니다. AWS는 600,000개 디바이스 플릿을 업데이트하는 비용이 미화 1,275달러인 요금 예시를 ​​제공합니다. 그러나 버그가 수정되지 않은 상태로 유지되는 비용과 관련하여 그리 비싸지 않습니다. 고객 경험 손상, 제품 리뷰 평점 저하, 판매 감소, 사고 및 법적 조치까지 포함됩니다.

임베디드 개발을 위한 DevOps
소프트웨어 문제가 발생한 경우 IoT 장치를 "전화 집"으로 활성화하면 상당한 이점이 있습니다. 오류에 대한 직접적인 인식과 상세한 진단은 개발자와 배포된 코드 사이에 피드백 루프를 만들어 개발자가 더 빠르게 버그를 수정하고 업데이트된 펌웨어를 더 빨리 푸시할 수 있도록 합니다(그림 3 참조). 이른바 DevOps 철학은 오랫동안 모바일 개발의 표준이었습니다. 및 클라우드 애플리케이션, 보안 클라우드 기반 IoT 플랫폼의 도입으로 임베디드 개발도 이러한 방식으로 작동하는 것이 가능해졌습니다.

그림 3. Tracealyzer의 DevAlert 대시보드에는 가장 최근에 보고된 경고 및 추적이 나열됩니다.
(확대하려면 이미지를 클릭하십시오)

비즈니스 관점에서 이 DevOps 스타일 모니터링은 프로덕션 코드의 버그에 영향을 받는 최종 사용자가 줄어들기 때문에 불만족한 고객이 줄어듭니다. 대부분의 임베디드 소프트웨어에는 모든 검증 노력에도 불구하고 릴리스 시 누락된 버그가 있지만 일반적으로 모든 사람에게 직접 표시되지는 않습니다. 많은 고객이 영향을 받기 전에 문제를 조기에 알면 문제를 해결할 시간이 있는 경우가 많습니다. 이상적으로는 첫 번째 경고가 발생한 후 몇 초 이내에 개발자에게 알려야 하며 제공된 추적 진단을 통해 신속한 분석 및 수정이 가능합니다. 그런 다음 개발자는 문제를 해결하기 위해 자동 무선 업데이트를 보낼 수 있습니다. 즉각적인 인식 및 추적 진단은 수리 시간을 크게 단축하고 영향을 받는 고객의 수를 최소화할 수 있습니다.

향상된 장치 안정성은 책임 위험을 줄이고 고객 지원, 반품 및 디버깅 비용을 줄입니다. 제공된 진단 기능을 통해 개발자는 고객 문제를 훨씬 쉽게 재현할 수 있습니다. 개발자는 장치에서 직접 정보를 얻고 상황을 설명하기 위해 사용자에게 의존할 필요가 없기 때문입니다. 자동 피드백이 없으면 문제를 보고하고 충분히 상세한 정보를 제공하기 위해 최종 사용자에게 의존합니다. "시스템이 응답하지 않음"과 같은 모호한 오류 보고서는 그다지 도움이 되지 않으며 가능한 원인을 찾는 데 몇 주가 걸릴 수 있습니다. 그렇다 하더라도 그것은 최선의 추측일 뿐입니다. 올바른 문제를 해결했는지 알 수 없습니다.

버그 뿐만 아니라
한 가지 주의할 점은 경고가 누락된 버그와 결과 오류에 대한 것일 필요는 없다는 것입니다. 개발자는 알림을 생성해야 하는 위치와 이유를 자유롭게 결정할 수 있으므로 애플리케이션의 주요 성능 메트릭을 모니터링하고 가끔 성능 문제가 발생하는 이유를 확인하는 데 사용할 수도 있습니다.

사용자 인터페이스를 모니터링하면 흥미로운 정보를 얻을 수도 있습니다. 사용자가 터치 스크린에서 메뉴를 여는 상황이 있다고 가정해 보겠습니다. 차의 인포테인먼트 시스템에서 어디로 가야할지 망설이게 됩니다. 이러한 문제를 포착하기 위해 애플리케이션 개발자는 각 입력 이벤트 후에 타이머를 시작하고 5초 이내에 입력이 수신되지 않으면 경고를 생성할 수 있습니다. 그런 다음 사용자 인터페이스의 동일한 부분에 대해 많은 알림을 받으면 조직에서 더 나은 제품을 만드는 데 도움이 될 수 있는 중요한 피드백이 될 수 있습니다.

대체로 배포된 장치에서 소프트웨어 추적 및 클라우드 기반 경고를 활용하면 큰 이점이 있으며 복잡하지 않습니다. 그러나 DevOps 스타일의 워크플로를 완전히 수용하려면 무선 업데이트 기능과 소프트웨어 테스트의 한계와 릴리스 후에도 지속적인 개선의 중요성을 이해하는 반응형 개발 조직이 필요합니다.