목차

Traccar 사용 보고서1: 오래된 장비일 때

Code (Finding ghosts): GitHub
English/영문판

들어가기 전에

이미 우리는 2015년 CRC 과제와 이번 과제 중 장애인과 비장애인 30명 씩 대상으로 위치 정보를 수집했었다. Traccar가 아닌 자체 외주 개발 앱을 사용한 적도 있었지만 문제가 많았고, Traccar를 사용한 뒤 크게 문제가 없는 것으로 보였다.

Traccar 배경 지식

Traccar는 오픈소스 GPS Tracker 플랫폼이다. 대부분의 GPS Tracker와 마찬가지로 차량의 위치 추적을 위한 기능이 많이 탑재되어 있다.
이는 GPS는 기본적으로 야외에서만 사용 가능하기 때문이다.1) 비행기, 기차, 화물차, 택시 등 법적으로 영업용 운송수단은 이동 기록을 제출하도록 되어있고, 회사들은 GPS Tracker를 자신들의 차량에 부착한다. 이러한 차량들도 GPS 신호 음영 지역에 들어가는 경우가 있지만 대부분 알려진 터널, 차고지 등일 경우가 많다. Traccar도 마찬가지로 많은 기능들이 차량을 기반으로 만들어져 있다.

반면에 사람은 대부분의 시간을 실내에서 보내기 때문에 Traccar와 같은 GPS Tracker로는 장소와 장소 간의 이동만 파악할 수 있다. 또한 차량에 내장되는 GPS Tracker와 달리 GPS 수신 장치로써 스마트폰은 비교적 다양한 종류가 존재한다. 따라서 몇몇 스마트폰은 정확도나 성능 등에 있어서 문제가 발생할 수 있다.

그럼에도 불구하고, 현재까지 Traccar 는 대부분의 스마트폰에서 정상적인 작동을 보였고 그 배포와 설치가 간편하기 때문에 우리는 계속 실험에 사용했다.

갭(Gap) 현상

지난 12월부터 약 1개월간 진행된 비장애인 대상 실험에서 전주희 박사님은 몇몇 실험자가 몇 시간 정도 위치 데이터 갱신이 없다는 것을 보고했다. 즉, 데이터와 데이터 사이에 1분(우리가 설정한 데이터 송신 주기) 이상의 갭Gap이 존재하는 것이었다. 이는 기존 내부 실험에서는 보이지 않던 현상이었다. 이는 몇 가지 문제를 야기할 수 있으므로 우리는 다음에 대한 문제를 확인해야 했다.

테스트

우선 앞서 말한 것과 같이 스마트폰은 기종이 너무 다양하다. 안타깝게도 지난 실험 진행자들의 스마트폰 기종과 버전, 환경 등에 대한 정보를 확보하지 못했다. 따라서 나는 몇가지 상황을 가정하고 추가 실험을 진행했다. 우선 노후화로 인해 하드웨어, 소프트웨어적 문제가 발생할 수 있는 구형폰을 가지고 일주일 정도의 추가 실험을 진행했다. 두 기종 모두 출시된지 5년 이상 경과되었고 외부적인 고장은 없지만 오래된 사용으로 인한 이상 증상을 보이는 기종이었다.

Test starts: 20190121

NamePhoneOS Ver.Traccar Ver.NetworkMajor problem
DBLAB0102iPhone 612.1.25.5 (latest in iOS)Only Wi-Fi (다른 폰의 LTE로 테더링)배터리 드레인 현상
DBLAB0103Samsung Galaxy S56.0.15.17 (latest in Android)Only Wi-Fi (다른 폰의 LTE로 테더링)다른 폰보다 GPS 수신 감도 낮음.

해당 실험 중 두 폰은 모두 실제 사용 (웹 서핑 등) 하진 않고, 와이파이를 켠 상태로 사용자의 집, 연구실, 테더링할 와이파이 세 네트워크에만 자동 연결되게 설정했으며, 수동 잠금해제는 되도록 하지 않았다.

보다 자세한 정보는 상단의 GitHub을 참조하세요.

결과와 분석

최초 데이터 생성 시간: 2019-01-21 00:00:50
마지막 데이터 생성 시간: 2019-01-28 22:45:25
총 실험 시간 (분): 11,444 분 표 1. 발생한 갭

< 2 min 5 30 60 120 180 360 > 360 Total < 2 min / Total (%) Total/11444 (%)
DBLAB0102 5625 49 2 0 2 0 4 3 5685 98.9445 49.67
DBLAB0103 8832 141 7 14 5 1 3 0 9003 98.1006 78.67

표 1에 따르면 수신된 데이터의 98%는 정상적인 딜레이로 수신이 되었다. 그러나 실제 수신 되어야 하는 최대 데이터 수인 11444에는 미치지 못했는데 특히 아이폰에서는 하단에 서술할 '입력 허가' 차단과 배터리 부족으로 인해 6시간 이상의 데이터 수신이 3번이나 발생하였다.

Case 1: 배터리 부족으로 인한 시스템 종료

Low battery example: DBLAB0102's shutdown (#285)

index servertime devicetime latitude longitude battery_level delay
284 2019-01-21 14:56:11.084 2019-01-21 14:56:10 37.555125 127.050063 1.0 00:01:01
285 (Gap)2019-01-21 18:11:50.026 2019-01-21 18:11:43 37.555152 127.050041 100.0 03:15:33
286 2019-01-21 18:12:45.090 2019-01-21 18:12:44 37.555191 127.050067 100.0 00:01:01

배터리 종료로 인해 3시간 가량 데이터 발신이 종료된 경우.
재부팅 시 자동으로 Traccar가 시작되는 것을 볼 수 있다.

Case 2: 낮은 배터리로 인한 시스템 보호

Energy saving example: DBLAB0102 (#47)

index servertime devicetime latitude longitude battery_level delay
46(Delayed) 2019-01-21 10:40:36.633 2019-01-21 09:27:28 37.555067 127.050128 37.0 00:00:00
47 (Gap)2019-01-21 10:40:36.915 2019-01-21 10:40:35 37.555115 127.050077 86.0 01:13:07
48 2019-01-21 10:41:40.577 2019-01-21 10:41:40 37.555111 127.050112 87.0 00:01:05

배터리 수준이 37 정도로 낮아지자 시스템이 프로세스를 정지시킨 현상. 외부의 정지로 추정되는 이 현상은 반복적으로 나타난다.

OS의 block으로 추정되는 현상

장치에서는 정보 송신을 위한 데이터가 생성되었으나(timestamp: devicetime) Server에는 송신되지 않는다 (Delayed 부분). 그리고 idle 상태가 해제되면 다시 전송을 재개한다 (Gap 부분). Gap 이전의 데이터를 더 살펴보면 전송되는 데이터의 순서(position id)와 데이터의 생성 타임(devicetime)이 서로 섞이는 것도 위치는 수신되었지만 전송이 되지 않음을 의미하는 것으로 보인다.

배터리 부족으로 기기의 전원이 종료될 때는 보이지 않는 현상으로 OS 등의 외부 요인으로 인한 프로세스 정지가 발생할 경우 나타나는 현상으로 보인다. 만약 클라이언트가 정상이고 서버의 응답이 없는 경우 데이터가 유실되지 않고 클라이언트는 위치 정보를 계속 생성했다가, 나중에 연결이 회복되면 클라이언트가 저장된 데이터를 보이므로 생성 순서(devicetime)가 꼬인 데이터가 한번에 들어오는 것은(servertime, id) 보내지지 못한 데이터가 한번에 보내져서 생긴 것으로 추정된다.

Case 3: Process killed/blocked by OS

Traccar blocked: DBLAB0102 (#1666)

index servertime devicetime latitude longitude battery_level delay
1664 2019-01-23 03:05:32.082 2019-01-23 03:05:31 37.415354 126.879795 100.0 00:01:00
1665 (Delayed) 2019-01-24 08:28:23.978 2019-01-23 03:05:31 37.415354 126.879795 100.0 00:00:00
1666 (Gap)2019-01-24 08:28:24.149 2019-01-24 08:18:10 37.415651 126.881761 98.0 1 days 05:12:39
1667 2019-01-24 08:28:24.322 2019-01-24 08:27:53 37.454902 126.895622 98.0 00:09:43

블록되는 현상은 Case 2와 동일하나 그 텀이 매우 길다. #1666 당시 사용자는 아이폰은 '입력 허가' 팝업을 띄우고 사용자의 응답을 대기하는 중이었다. 이는 실사용되는 휴대폰이 아니었기 때문에 실험자는 이 알림을 늦게 확인할 수밖에 없었다. 해당 알림창에서 허용을 선택하자 Traccar 프로세스가 재개되었다. 안드로이드의 '앱 절전'과 유사하나 설정에서 미리 끌 수가 없었다.

Case 4: Sleep mode/idle

index servertime devicetime latitude longitude battery_level delay
718 (Delayed) 2019-01-22 08:57:05.475 2019-01-22 03:08:24 37.415295 126.879858 100.0 00:00:00
719 (Gap)2019-01-22 08:57:07.915 2019-01-22 08:24:02 37.416994 126.884924 100.0 05:15:38
720 2019-01-22 08:57:11.347 2019-01-22 08:25:06 37.417065 126.884946 100.0 00:01:04

대부분의 Gap은 이 케이스에서 발생하였다. 실험자가 집 또는 연구실 등 미리 알려진 공간에서 핸드폰을 충전 등 핸드폰을 사용하지 않은 상태로 두고 있으면 자동적으로 변환되는 것으로 보인다. 실제 이 케이스가 일어난 시각에서 실험자의 이동이나 특별한 행동은 보고되지 않았다. 오히려 이동을 개시했을 때 위치가 갱신되기 때문에 이동 시작의 지표로써 활용 가능성이 보인다.

결론

Traccar 가 신호를 보내지 않는 텀(gap)이 발생하는 원인과 데이터 유실 확인

  1. 기기(OS)의 Sleep/idle mode: 데이터 유실 없는 것으로 보임.
  2. 기기(OS)의 낮은 배터리 보호: 데이터 유실 가능성 있음.
  3. 기기(OS)의 수상한 프로세스 블록: 데이터 유실 가능성 높음.

1번 경우는 매우 많이 발생하나 데이터 유실은 없는 것으로 보인다. 새벽 시간과 실내에서 일하는 시간에 많이 목격되는 현상.
2번 경우는 자주 발생하진 않지만 실험자가 배터리를 충전해주는 것이 아니면 방법이 없다. 모니터링 시스템이 피실험자에게 낮은 배터리 경고를 보내야 할 것 같다.
3번은 가장 심각한 문제로, 안드로이드 폰에서는 절전 앱 리스트에서 제외하는 것이 가능한 것으로 보이지만(삼성, LG 확인), 아이폰은 3일쯤 뒤에 먼저 프로세스를 막고 사용자에게 Traccar를 계속 허용할 것인지 물어보는 팝업을 띄운다. 만약 이 팝업을 제대로 읽지 않고 차단했을 경우 다시 해제하는 방법이 있는지는 아직 알 수 없다.

따라서 이러한 문제를 예방하기 위해서는

1)
최근의 스마트폰은 모두 Assisted GPS (AGPS) 를 채택했으므로 네트워크가 잡히면 그 네트워크 라우터(Wifi든 LTE든)의 위치를 참조하여 자신의 위치를 사용한다. 따라서 실내에서 완전히 위치가 안 뜨는 것은 아니긴 하다.