차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- traccar-test-01-kr [2019/01/30 07:12]
chajh 만듦
+++ traccar-test-01-kr [2021/04/13 06:54] (현재)
@@ 줄 1: / 줄 1: @@
-===== Traccar Client on Old Smartphones =====
+<title> Traccar 사용 보고서1: 오래된 장비일 때 </title>
 {{:traccar-working.png?nolink&400|}}
@@ 줄 5: / 줄 5: @@
 [[traccar-test-01|English/영문판]]
-==== 들어가기 전에 ====
+===== 들어가기 전에 =====
 이미 우리는 2015년 CRC 과제와 이번 과제 중 장애인과 비장애인 30명 씩 대상으로 위치 정보를 수집했었다. Traccar가 아닌 자체 외주 개발 앱을 사용한 적도 있었지만 문제가 많았고, Traccar를 사용한 뒤 크게 문제가 없는 것으로 보였다.
-==== 문제 발생? ====
+===== Traccar 배경 지식 =====
-GPS는 기본적으로 야외에서만 사용 가능하다.((최근의 스마트폰은 모두 Assisted GPS (AGPS) 를 채택했으므로 네트워크가 잡히면 그 네트워크 라우터(Wifi든 LTE든)의 위치를 참조하여 자신의 위치를 사용한다. 따라서 실내에서 완전히 위치가 안 뜨는 것은 아니긴 하다.)) 또한 대부분의 GPS Tracker는 야외에서 활동하는 객체들을 위해 디자인 되었다. 비행기, 기차, 화물차, 택시 등 법적으로 영업용 운송수단은 이동 기록을 제출하도록 되어있고, 회사들은 GPS Tracker를 자신들의 차량에 부착한다. 이러한 차량들도 GPS 신호 음영 지역에 들어가는 경우가 있지만 대부분 알려진 터널, 차고지 등일 경우가 많다. Traccar도 마찬가지로 많은 기능들이 차량을 기반으로 만들어져 있다. \\
+Traccar는 오픈소스 GPS Tracker 플랫폼이다. 대부분의 GPS Tracker와 마찬가지로 차량의 위치 추적을 위한 기능이 많이 탑재되어 있다.\\
+이는 GPS는 기본적으로 야외에서만 사용 가능하기 때문이다.((최근의 스마트폰은 모두 Assisted GPS (AGPS) 를 채택했으므로 네트워크가 잡히면 그 네트워크 라우터(Wifi든 LTE든)의 위치를 참조하여 자신의 위치를 사용한다. 따라서 실내에서 완전히 위치가 안 뜨는 것은 아니긴 하다.)) 비행기, 기차, 화물차, 택시 등 법적으로 영업용 운송수단은 이동 기록을 제출하도록 되어있고, 회사들은 GPS Tracker를 자신들의 차량에 부착한다. 이러한 차량들도 GPS 신호 음영 지역에 들어가는 경우가 있지만 대부분 알려진 터널, 차고지 등일 경우가 많다. Traccar도 마찬가지로 많은 기능들이 차량을 기반으로 만들어져 있다. \\
-반면에 사람은 대부분의 시간을 안에서 지낸다. 또한 건물 안에서 활동을 한다. 따라서 우리는 GPS를 통해서 사용자들의 '활동'을 파악할 수는 없다.
+반면에 사람은 대부분의 시간을 실내에서 보내기 때문에 Traccar와 같은 GPS Tracker로는 장소와 장소 간의 이동만 파악할 수 있다. 또한 차량에 내장되는 GPS Tracker와 달리 GPS 수신 장치로써 스마트폰은 비교적 다양한 종류가 존재한다. 따라서 몇몇 스마트폰은 정확도나 성능 등에 있어서 문제가 발생할 수 있다. \\
-GPS is only available outdoors.((In fact, today's smartphones with Assisted GPS (AGPS) can get their location from nearby network routers that tell the device where they are. )) Today, GPS tracking system are usually built in vehicles such as airplane, ships, trucks, and taxis. They move most of the time except for a few minutes on a shaded path such as a tunnel. So, it's easy to get the location data from these objects. There are not too many tracking devices that also fit perfectly by types of vehicle. Well then. How about the location of people? Can we still get data from individual person through GPS Tracker like Traccar?\\
-Today's people mostly spend their time inside: home, office, subway, shopping mall and so on. GPS cannot get indoor position so that we can just see where people move from a place to another place. What's more, if people send their location data through small devices like smartphone, we will face numerous smartphones. Unlike the devices for vehicles, there are a lot of things varied such as its OS, the version of OS, manufacturer, hardware conditions, etc. \\
+그럼에도 불구하고, 현재까지 Traccar 는 대부분의 스마트폰에서 정상적인 작동을 보였고 그 배포와 설치가 간편하기 때문에 우리는 계속 실험에 사용했다.
-So, we got some potential issues:
+===== 갭(Gap) 현상 =====
-  * Most of data doesn't show precise position. It is an estimated value of its place.
-  * The tracker device are so varied. It is so hard to comprehend.
-Besides, it is sufficient so that we can get the places our participant visits, although we don't catch actual location where they are in each place.
-==== There is a gap! ====
 {{::traccar-error1-rev1.png?nolink&600|}}
-While we believe we know the testers' stay points, Dr. Jun, our fellow researcher, reported some clients didn't send data for several hours. It could be problems. We need to find answer for some questions:
+지난 12월부터 약 1개월간 진행된 비장애인 대상 실험에서 전주희 박사님은 몇몇 실험자가 몇 시간 정도 위치 데이터 갱신이 없다는 것을 보고했다. 즉, 데이터와 데이터 사이에 1분(우리가 설정한 데이터 송신 주기) 이상의 갭Gap이 존재하는 것이었다. 이는 기존 내부 실험에서는 보이지 않던 현상이었다. 이는 몇 가지 문제를 야기할 수 있으므로 우리는 다음에 대한 문제를 확인해야 했다.
-  * Is there any critical gap? Have we missed a lot of the data?
-  * If not, our data are really safe?
-  * What causes the gaps? Should we prevent the gaps?
-We must look into which was right.
+  * 갭 동안 데이터 손실이 발생하였나?
-==== Test ====
+  * 무엇이 갭을 유발했나?
-Unfortunately, we don't have the specific information of previous participant's devices. So, we should imagine the device which might cause some problems and should be sifted out before experiment begin. First, we picked old phones with some troubles. We want to know whether these legacy devices can run Traccar client properly. Because no small number of our study targets is the disabled and the aged. Some of them use a quite old phone that might have hardware or software issues.((The disabled and the aged are normally not rich, rather than others, at least in Korea. (I think it is global phenomenon) Anyhow, we'd better ready for a participant who has a phone that we're not familiar with. )) \\
+  * 갭이 데이터 손실을 야기한다면 이를 방지할 수 있는 방법은?
+==== 테스트 ====
+우선 앞서 말한 것과 같이 스마트폰은 기종이 너무 다양하다. 안타깝게도 지난 실험 진행자들의 스마트폰 기종과 버전, 환경 등에 대한 정보를 확보하지 못했다. 따라서 나는 몇가지 상황을 가정하고 추가 실험을 진행했다. 우선 노후화로 인해 하드웨어, 소프트웨어적 문제가 발생할 수 있는 구형폰을 가지고 일주일 정도의 추가 실험을 진행했다. 두 기종 모두 출시된지 5년 이상 경과되었고 외부적인 고장은 없지만 오래된 사용으로 인한 이상 증상을 보이는 기종이었다.
 Test starts: 20190121
 ^Name^Phone^OS Ver.^Traccar Ver.^Network^Major problem^
-|DBLAB0102|iPhone 6|12.1.2|5.5 (latest in iOS)|Only Wi-Fi (tethered to other phone's network)|Battery Drain|
+|DBLAB0102|iPhone 6|12.1.2|5.5 (latest in iOS)|Only Wi-Fi (다른 폰의 LTE로 테더링)|배터리 드레인 현상|
-|DBLAB0103|Samsung Galaxy S5|6.0.1|5.17 (latest in Android)|Only Wi-Fi (tethered to other phone's network)|A little Lag to catch GPS signal|
+|DBLAB0103|Samsung Galaxy S5|6.0.1|5.17 (latest in Android)|Only Wi-Fi (다른 폰의 LTE로 테더링)|다른 폰보다 GPS 수신 감도 낮음.|
-Both devices have sent location data for a week.
+해당 실험 중 두 폰은 모두 실제 사용 (웹 서핑 등) 하진 않고, 와이파이를 켠 상태로 사용자의 집, 연구실, 테더링할 와이파이 세 네트워크에만 자동 연결되게 설정했으며, 수동 잠금해제는 되도록 하지 않았다.
-To get more information, go to the GitHub link above.
-==== Result and Analysis ====
+보다 자세한 정보는 상단의 GitHub을 참조하세요.
-We configured the client to send its location every 60 seconds. Theoretically, it should've transmit data within 1-2 minutes even if there is some include calculation delays. Here is count of the gaps in minute.
-^         ^ < 2 min ^   5 ^ 30 ^ 60 ^ 120 ^ 180 ^ 360 ^ > 360 ^ total ^ % of < 2 min ^
+===== 결과와 분석 =====
-^DBLAB0102| 5095    | 49  |   3|  0 |    2|    0|    4|      4|   5157|      98.0370 |
+최초 데이터 생성 시간: 2019-01-21 00:00:50\\
-^DBLAB0103| 8852    | 144 |   7|  14|    5|    1|    3|      0|   9026|      98.0722 |
+마지막 데이터 생성 시간: 2019-01-28 22:45:25\\
-Although the iPhone(0102)'s overall delays are shorter than the other, the count is remarkably low. The reason why it didn't send anything is that iOS blocked Traccar several times. Thus, iOS has got many long gaps. \\
+총 실험 시간 (분): 11,444 분
-=== Case 1: Low battery and shutting down ===
+표 1. 발생한 갭
-Low battery example: DBLAB0102's shutdown (#357) \\
+^         ^ < 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^
-^356| 2019-01-21 14:56:11.084| 2019-01-21 14:56:10 | 37.555125|   127.050063    |      1.0|    00:01:01|
+^284| 2019-01-21 14:56:11.084| 2019-01-21 14:56:10 | 37.555125|   127.050063    |      1.0|    00:01:01|
-^357 (Gap)|2019-01-21 18:11:50.026| 2019-01-21 18:11:43 | 37.555152  |   127.050041  |      100.0|    03:15:33|
+^285 (Gap)|2019-01-21 18:11:50.026| 2019-01-21 18:11:43 | 37.555152  |   127.050041  |      100.0|    03:15:33|
-^358| 2019-01-21 18:12:45.090 | 2019-01-21 18:12:44 | 37.555191  |   127.050067  |      100.0|   00:01:01|
+^286| 2019-01-21 18:12:45.090 | 2019-01-21 18:12:44 | 37.555191  |   127.050067  |      100.0|   00:01:01|
-Traccar client spend the network data and battery, more or less. Old phones usually have smaller battery size than brand-new ones. We have already planned for the battery issue by providing additional battery to participants. Still, we need a tracking system that can save more energy and alert the battery getting low.
+배터리 종료로 인해 3시간 가량 데이터 발신이 종료된 경우.\\
-  * Some data could be missed if the participant would have not recognized the battery level.
+재부팅 시 자동으로 Traccar가 시작되는 것을 볼 수 있다.
-=== Case 2: Low battery and energy saving mode ===
+==== Case 2: 낮은 배터리로 인한 시스템 보호 ====
-Energy saving example: DBLAB0102 (#119) \\
+Energy saving example: DBLAB0102 (#47) \\
 ^index ^ servertime ^ devicetime ^   latitude ^ longitude ^ battery_level ^ delay^
-^118| 2019-01-21 10:40:36.633 |2019-01-21 09:27:28 | 37.555067 | 127.050128    |      37.0|    00:00:00|
+^46(Delayed)| **2019-01-21 10:40:36.633** |**2019-01-21 09:27:28** | 37.555067 | 127.050128    |      37.0|    **00:00:00**|
-^119 (Gap)|2019-01-21 10:40:36.915 | 2019-01-21 10:40:35  | 37.555115 | 127.050077   |      86.0|    01:13:07|
+^47 (Gap)|2019-01-21 10:40:36.915 | 2019-01-21 10:40:35  | 37.555115 | 127.050077   |      86.0|    01:13:07|
-^120| 2019-01-21 10:41:40.577 | 2019-01-21 10:41:40 | 37.555111 |  127.050112 |      87.0|   00:01:05|
+^48| 2019-01-21 10:41:40.577 | 2019-01-21 10:41:40 | 37.555111 |  127.050112 |      87.0|   00:01:05|
-This case occurred twice on DBLAB0102 (iPhone). iOS seems to have got a kind of procedure that halts power-consuming process for a while. It may have a relation to the case 3. We have not founded the case 2 on Android phones yet.
+배터리 수준이 37 정도로 낮아지자 시스템이 프로세스를 정지시킨 현상. 외부의 정지로 추정되는 이 현상은 반복적으로 나타난다.
-  * Some data could be missed if the participant would have not recognized the battery level.
+==== OS의 block으로 추정되는 현상 ====
-=== Case 3: Process killed/blocked by OS ===
+장치에서는 정보 송신을 위한 데이터가 생성되었으나(timestamp: devicetime) Server에는 송신되지 않는다 (Delayed 부분). 그리고 idle 상태가 해제되면 다시 전송을 재개한다 (Gap 부분). Gap 이전의 데이터를 더 살펴보면 전송되는 데이터의 순서(position id)와 데이터의 생성 타임(devicetime)이 서로 섞이는 것도 위치는 수신되었지만 전송이 되지 않음을 의미하는 것으로 보인다.\\
-**Traccar blocked: DBLAB0102 (#1738)**
-^index ^ servertime ^ devicetime ^   latitude ^ longitude ^ battery_level ^ delay^
-^1736 | 2019-01-23 03:05:32.082 | 2019-01-23 03:05:31 |37.415354 | 126.879795    |      100.0|    00:01:00|
-^1737 (Delayed)| **2019-01-24 08:28:23.978** | **2019-01-23 03:05:31** | 37.415354 | 126.879795  |     100.0|    00:00:00|
-^1738 (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**|
-^1739| 2019-01-24 08:28:24.322 | 2019-01-24 08:27:53  | 37.454902 | 126.895622 |      98.0|   00:09:43|
-It is critical issue. You can see #1737 data sent after unblocking Traccar. (#1738) The circumstances like this can also be shown Case 4, but the system unblock automatically in that case. We must prevent this case.\\
+배터리 부족으로 기기의 전원이 종료될 때는 보이지 않는 현상으로 OS 등의 외부 요인으로 인한 프로세스 정지가 발생할 경우 나타나는 현상으로 보인다. 만약 클라이언트가 정상이고 서버의 응답이 없는 경우 데이터가 유실되지 않고 클라이언트는 위치 정보를 계속 생성했다가, 나중에 연결이 회복되면 클라이언트가 저장된 데이터를 보이므로 생성 순서(devicetime)가 꼬인 데이터가 한번에 들어오는 것은(servertime, id) 보내지지 못한 데이터가 한번에 보내져서 생긴 것으로 추정된다.
-iPhone blocks a process that uses power and data continuously. As I know, the only way to unblock Traccar is to wait until iphone shows a pop-up asking whether keep blocking the process. The default option (right side) is block. If the participant are unaware, he will tap "block" and the experiment with iPhones will be doomed. Samsung phones have a similar energy-saving procedure, but we can exclude Traccar beforehand.
-  * iPhone: Some data could be missed if the participant would have clicked pop-up unconsciously.
+==== Case 3: Process killed/blocked by OS ====
-  * Android (Samsung): Some data could be missed if the participant would have turned off energy saving options in advance.
+**Traccar blocked: DBLAB0102 (#1666)**
-=== Case 4: Sleep mode/idle ===
 ^index ^ servertime ^ devicetime ^   latitude ^ longitude ^ battery_level ^ delay^
-^118 (Delayed) | **2019-01-21 10:40:36.633** | **2019-01-21 09:27:28** | 37.555067 | 127.050128    |      37.0|    00:00:00|
+^1664 | 2019-01-23 03:05:32.082 | 2019-01-23 03:05:31 |37.415354 | 126.879795    |      100.0|    00:01:00|
-^119 (Gap)|2019-01-21 10:40:36.915 | 2019-01-21 10:40:35  | 37.555115 | 127.050077   |      86.0|    01:13:07|
+^1665 (Delayed)| **2019-01-24 08:28:23.978** | **2019-01-23 03:05:31** | 37.415354 | 126.879795  |     100.0|    **00:00:00**|
-^120| 2019-01-21 10:41:40.577 | 2019-01-21 10:41:40 | 37.555111 |  127.050112 |      87.0|   00:01:05|
+^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은 이 케이스에서 발생하였다. 실험자가 집 또는 연구실 등 미리 알려진 공간에서 핸드폰을 충전 등 핸드폰을 사용하지 않은 상태로 두고 있으면 자동적으로 변환되는 것으로 보인다. 실제 이 케이스가 일어난 시각에서 실험자의 이동이나 특별한 행동은 보고되지 않았다. 오히려 이동을 개시했을 때 위치가 갱신되기 때문에 이동 시작의 지표로써 활용 가능성이 보인다.
-We can see server got two locations #118 and #119 at once because OS blocks sending position #118 so that Traccar client update the local location like #118 but it'd not sent. Unlike Case 3, however, the device resend the data spontaneously in this case. We've spotted a lot of idle mode delays. All of this case, the devices have no movement when they connected known Wi-Fi at home or in the office. Usually, the owner was sleeping or working inside.
+===== 결론 =====
-  * Safe. But, there could be a lag for recalibrating GPS signal.
+Traccar 가 신호를 보내지 않는 텀(gap)이 발생하는 원인과 데이터 유실 확인
-  * If the user didn't go outside for a long time, we could be misunderstood this case as Case 3.
+  - 기기(OS)의 Sleep/idle mode: 데이터 유실 없는 것으로 보임.
+  - 기기(OS)의 낮은 배터리 보호: 데이터 유실 가능성 있음.
+  - 기기(OS)의 수상한 프로세스 블록: 데이터 유실 가능성 높음.
-==== Summary ====
+번 경우는 매우 많이 발생하나 데이터 유실은 없는 것으로 보인다. 새벽 시간과 실내에서 일하는 시간에 많이 목격되는 현상. \\
-  * Most gaps caused by sleep/idle mode of the operating system. There is no data loss unless the user forgot carrying his phone.
+번 경우는 자주 발생하진 않지만 실험자가 배터리를 충전해주는 것이 아니면 방법이 없다. 모니터링 시스템이 피실험자에게 낮은 배터리 경고를 보내야 할 것 같다.\\
-  * The user must experience the device blocks Traccar because of its power consumption. It is usually three days after. We need to make sure the participant's client unblocked.
+번은 가장 심각한 문제로, 안드로이드 폰에서는 절전 앱 리스트에서 제외하는 것이 가능한 것으로 보이지만(삼성, LG 확인), 아이폰은 3일쯤 뒤에 먼저 프로세스를 막고 사용자에게 Traccar를 계속 허용할 것인지 물어보는 팝업을 띄운다. 만약 이 팝업을 제대로 읽지 않고 차단했을 경우 다시 해제하는 방법이 있는지는 아직 알 수 없다. \\
-  * Battery issue is not trivial.
-==== Future works ====
+따라서 이러한 문제를 예방하기 위해서는
-  * This is data about locations. We need to make some visualization tools with Korean maps. Traccar supports google and openstreetmap but they have some deficiencies because of legislations.
+  * 배터리 부족을 예방하기 위한 배터리 지급 이외에도 배터리 부족을 실험참가자에게 알리는 방안을 검토.
-  * We also need monitoring system for notifying users to prevent any data loss.
+  * 사전 테스트 기간 (3-4일) 정도를 통해 해당 스마트폰이 Traccar를 막는지 확인.
-  * All participant have to take a pre-test period at least three days. We could assure Traccar working on the device fine.

Database Lab

사용자 도구

사이트 도구

차이

문서 도구