KR20130090953A

KR20130090953A - 차량 간 교통상황정보 공유 방법

Info

Publication number: KR20130090953A
Application number: KR1020120012095A
Authority: KR
Inventors: 최광주
Original assignee: 최광주
Priority date: 2012-02-07
Filing date: 2012-02-07
Publication date: 2013-08-16
Also published as: KR101377153B1

Abstract

본 발명은 차량통신장치를 탑재한 차량이 도로 주행중 정체등의 현상으로 인해 도로교통상황을 확인하고자 할 때 스마트폰을 사용하여 주변 차량의 위치를 확인하여 상대방 스마트폰의 카메라를 작동시켜 그 곳의 교통상황을 실시간 동영상으로 모니터 할 수 있는 기술에 관한 것으로, GPS(Global Positioning System) , WAVE(Wireless Access in Vehicular Environment) OBU(On Board Unit), WIFI(와이파이) 및 스마트폰을 사용한 서비스 제공을 위한 알고리즘 기술에 관한 것으로, 도로상 교통사고발생시 사고발생차량이 돌발정보와 동영상정보를 긴급으로 방송하는 방법, 주행중 정체 발생시 전방의 위치한 차량의 상황정보를 선택적으로 요청하여 동영상과 차량상태정보를 수신하는 방법, 그리고 주행중 전방 상황정보를 자동요청 모드로 설정해 놓았을 때 정해진 속도 이하로 진행하는 차량에 대하여 스마트폰으로 자동으로 실시간동영상 및 음성을 제공하는데 필요한 알고리듬 개발 기술에 관한 것이다.

이를 위하여 차량의 위치를 측위하기 위한 GPS, 고속 주행중에도 안전하게 정보를 전송할 수 있는 차량통신단말기인 WAVE OBU, WAVE OBU와 스마트폰을 무선으로 접속해 주는 와이파이공유기 및 차량의 위치정보, 주행속도, ID를 아이콘 형태로 표출하거나 동영상을 표출할 수 있는 스마트폰으로 구성된다.

이는 WAVE OBU가 1초 마다 GPS정보, 타 OBU에서 방송되는 정보를 수신하여 메모리에 저장하는 단계, 수시로 GPS를 읽어 돌발상황이 감지되면 차량상태정보 (ID,위치,방향,속도 등)를 WAVE OBU의 메모리에 저장하는 단계, 와이파이공유기에 접속되어 있는 스마트폰과 연동하는 단계, 스마트폰에 탑재된 카메라를 제어하여 동영상을 촬영하여 와이파이공유기를 경유 WAVE OBU로 전송하는 단계, WAVE표준에 의해 V2V통신방식으로 상대방 차량통신장치(WAVE OBU)로 전송하는 단계, 수신된 멀티미디어정보를 와이파이공유기를 경유하여 상대방 스마트폰에 전송하는 단계 및 이를 스마트폰 화면에 표출하는 단계로 구분할 수 있다. 특히, 주행중 필요에 의해 실시간 교통정보를 제공하는 과정에는 차량통신장치(OBU)가 사고 감지 시, 차량통신장치가 설치되어 있는 주변 차량에 탑승하고 있는 스마트폰을 통하여 영상을 방송하고 수신하여 스마트폰으로 재생하는 기술, 어느 한 스마트폰 사용자가 스마트폰 화면에 나타나 있는 타 차량아이콘을 호출하게 되면 피호출된 차량통신장치와 접속된 스마트폰 카메라가 작동하여 영상을 촬영하여 차량통신장치(OBU)를 통해 호출한 차량통신장치로 전송하고 이를 수신한 스마트폰의 화면에 동영상을 표출하는 기술 및 스마트폰이 차량통신장치와 접속하게 되면 수시로 주변에 있는 차량통신장치와 통신하면서 수집된 정보를 스마트폰 화면에 나타내는 기술을 구현함으로써 안전주행에 필요한 교통정보를 편리하게 수집 및 제공할 수 있도록 개발된 특징이 있다.

WAVE, 와이파이공유기 , 스마트폰, 스마트패드, 차량통신장치, V2I(Vehicle to Infrastructure), V2V(Vehicle to Vehicle)

Description

주행중 차량간통신환경에서 스마트폰(또는 스마트기기)를 이용하여 실시간 교통동영상을 자동으로 교환하기위한 스마트폰 프로그램 구성 및 알고리듬{Smart phone program architecture and algorithm to automatically transmit for real time traffic video using smart phone or smart devices in Vehicle to Vehicle communication on driving.}

본 발명은 차량에 설치되어 있는 차량통신장치를 이용하여 도로 주행 중 차량통신장치간에 상호 위치정보, 속도정보 등 차량상태정보를 공유하고 차량통신장치가 와이파이 접속 기능을 갖게 되면, 도로상에 주행 중인 차량들에 대한 정보를 운전자나 동승자가 소유하고 있는 스마트폰 또는 스마트기기(스마트패드, PDA, UMPC, NTPC등)를 통해 도로 교통정보를 LCD표시기에 나타낼 수 있는 기술이다. 예를 들면 스마트폰에 차량통신용 모바일 SNS APP 프로그램을 탑재한 상태에서 차량통신장치가 설치되어 있는 차량에 승차하여 스마트폰 거치대에 거치하게 되면 스마트폰은 차량통신장치와 자동으로 접속하게 된다. 차량이 출발하게 되면 차량통신장치는 주변에 있는 차량통신장치들과 통신하면서 아이디, 위치정보, 속도정보, 방향정보, 차량상태정보 등을 교환하게 되며 이러한 동작을 통해 수집된 정보를 스마트폰 표시기에 표출하게 된다. 스마트폰 표시기에는 도로상에 주행중인 차량 중에서 동일한 목적으로 가입한 Family 차량의 정보를 수집 가공하여 스마트폰 표시기에 나타내는데 이때 표시기에는 동일 방향으로 주행하는 차량에 대한 정보를 가공하여 내 차량 위치를 중심으로 앞.뒤 차량에 대한 차량을 아이콘으로 원근기법으로 표시기상에 아이디, GPS위치, 내 차량과의 이격 거리, 주행속도정보 등을 나타낸다. 정상속도로 주행하게 되면 스마트폰 표시기는 녹색으로 표시되나 규정속도를 초과하게 되면 황색으로 표시되고 위험상태가 되면 적색으로 표시된다. 내 차량을 기준으로 전방에 주행 중인 동일 소셜네트워크서비스(SNS) 가입자 중에 차량고장이나 돌발사고로 인해 차량이 갑자기 속도를 감속하게 되면 그 차량에 설치되어 있는 차량통신단말기는 돌발사고 정보를 주변 차량들을 위해 방송하게 된다. 이때 거치대에 놓여 있는 스마트폰은 카메라를 작동시켜 전방의 교통 동영상을 촬영하여 차량통신단말기를 경유하여 주변 차량들을 위해 실시간 동영상을 방송한다. 후방에서 주행하고 있는 차량들이 이 방송정보를 수신하게 되면 스마트폰 표시기에 나타나 있는 전방 차량의 아이콘이 적색으로 변화하면서 전방 차량에서 송신하는 교통영상정보를 수신하여 스마트폰 표시기에 자동적으로 실시간 교통정보 동영상이 나타낸다. 다른 방법으로 앞차를 뒤따르는 차량 운전자가 스마트폰 표시기에 나타나는 차량의 아이콘을 누르면 그 차량의 스마트폰의 카메라를 동작시켜 실시간 동영상을 보내 주기 위한 기술을 구현하기 위하여 스마트폰에 탑재되는 프로그램을 개발에 필요한 알고리듬 개발에 관한 것이다.

본 기술을 발명하기 이전에는 주행상태에서 안전운전에 필요한 정보를 제공 받기 어렵고, 정보 내용도 실시간 정보가 아닌 신뢰도가 낮은 정보이어서 운전자가 목적지까지의 주행경로를 선택하는데 판단의 어려움이 있었으며, 일방적으로 내려 받는 정보이기 때문에 정보가 고객 지향적이지 않은 내용이었고, 또한 운전자가 보다 신뢰도 있는 정보를 얻기 위해서는 이동통신사업자(TELCO)가 운영하는 통신인프라를 거쳐야 했기 때문에 부득이 유료로 교통정보를 이용할 수 밖에 없었다. 다음은 운전자 입장에서 안전주행에 필요한 교통정보를 얻는데 불편한 사항들을 정리하였다.

1.도로 주행 중 교통정체 발생시 발생 원인을 실시간으로 알 수 없어 불편함.

2.동일 방향으로 주행하는 차량에 대한 위치 및 속도정보를 알 수 없어 불편함.

3.도로상에 과속주행 차량에 대한 정보를 알 수 없어 방어운전이 어려움.

4.도로상에 Facebook 과 같은 소셜네트워크 가입자와 통신이 불가하여 불편함.

5.스마트폰 또는 스마트패드와 같은 와이파이 기반의 스마트기기를 통해 운전자에게 편리한 서비스를 제공할 수 없어 불편함.

6.차량통신장치와 유선으로만 Display장치와 접속되어 있고 무선으로 스마트폰과 접속이 안되어 불편함.

7.각 차량에 보유하고 있는 스마트폰 가입자간에 무료로 동영상 및 음성을 전달할 수 없음.

8.현재 차량간통신을 위해서는 TELCO사업자망을 통해서만 가능하며 교통상황에 대한 동영상정보를 전송하려면 채널사용료를 지불해야 하기 때문에 보급화 하는데 어려움.

본 발명은 메쉬와이파이, 이동통신망, 와이맥스, 와이브로, LTE, DSRC 및 TRS기술을 이용할 때의 문제점인 Latency Time, Channel Access Time, 데이터전송속도 및 고속주행시의 통신성공율 등의 문제를 성능개선을 통해 해결하는 것을 목적으로 하였다. 이를 위해 주행 중 응급상황 발생 시 , 사고예방 및 안전운전을 위한 수단으로 차량통신장치의 차량탑재 필요성을 제시하고, 스마트폰과 차량통신장치를 연동하게 함으로써 차량통신장치(WAVE OBU)의 활용성을 높이기 위한 응용서비스를 제시하였으며, 단순 데이터가 아닌 동영상, 음성, 데이터가 융합된 멀티미디어 데이터를 전송하게 함으로써 적용분야를 확대하고자 하였으며, 차량간통신을 하는데 IP기반 및 WSM(WAVE Short Message) 패킷 적용을 제시하였다.

본 발명은 상기 문제점 해결하기 위한 기술개발 방법은 아래와 같다.

1.도로 주행 중 교통정체 발생시 발생 원인을 실시간으로 알 수 없어 목적지까지 가기 위한 경로를 우회해야 하는 판단을 못하고 도로상에서 시간낭비를 할 수 밖에 없었으나, 전 차량에 설치되어 있는 차량통신장치들 간에 차량간통신에 의한 위치,속도,방향,거리 정보를 공유하고 이 정보를 스마트폰에 탑재된 APP프로그램에 의해 뒤 차량에 있는 스마트폰 사용자가 앞에주행하고 있는 차량의 스마트폰 카메라를 작동시켜 동영상을 수신하여 볼 수 있게 함으로써 불편 문제를 개선할 수 있게 된다.

2.동일 방향으로 주행하는 차량에 대한 위치 및 속도정보를 알 수 없어 불편하였으나 본 발명기술을 이용하게 되면 스마트폰 표시기에 상대 차량에 대한 GPS위치, 속도, 나와의 거리정보를 알 수 있도록 개선할 수 있다.

3.도로상에 과속주행 차량에 대한 정보를 알 수 없어 경계운전 하기 어려웠으나, 본 발명기술을 이용하게 되면 스마트폰 표시기에 나타나 있는 차량들에 대한 ID, 속도정보 및 과속차량이 표시되기 때문에 경계운전을 할 수 있다.

4.도로상에 Facebook 과 같은 소셜네트워크 가입자와 통신이 불가하여 도로 주행중에 교통정보를 공유하기 어려웠으나 본 발명기술을 통해 도로상에서도 Facebook 과 같은 소셜네트워크 기반의 서비스를 할 수 있다.

5.스마트폰 또는 스마트패드와 같은 와이파이 기반의 스마트기기를 통해 운전자에게 편리한 서비스를 제공할 수 없었으나, 본 발명 기술에서 제시하는 차량통신장치와 차내망 와이파이 및 스마트폰용 APP프로그램을 사용함으로써 차내에서도 V2I(Vehicle to Infrastructure) 및 V2V(Vehicle to Vehicle)통신을 하면서 사용 가능한 서비스를 와이파이 환경에서 스마트폰으로 편리한 서비스를 즐길 수 있다.

6.차량통신장치와 유선으로만 Display장치와 접속되어 있고 무선으로 스마트폰과 접속이 안되어 불편하였으나, 본 발명기술에서 차량통신장치와 와이파이공유기가 융합되어 있어 와이파이 기능이 탑재된 주변기기와 편리하게 접속 사용할 수 있다.

7.각 차량에 보유하고 있는 스마트폰 가입자간에 무료로 동영상 및 음성을 전달할 수 없으나 본 발명기술을 이용하게 되면 차량간통신에 사용되는 주파수는 누구나 무료로 사용할 수 있는 ISM밴드를 사용하고 있기 때문에 차량통신장치와 와이파이로 접속되어 있는 스마트폰 사용자는 도로상에 위치한 타 차량통신장치와 와이파이로 접속된 스마트폰 사용자와 무료로 멀티미디어 통신을 할 수 있다.

8.현재 차량간통신을 위해서는 TELCO사업자망을 통해서만 가능하며 교통상황에 대한 동영상정보를 전송하려면 채널사용료를 지불해야 하기 때문에 보급화 하는데 어려움이 있었으나 본 발명기술을 이용하게 되면 차량간통신에 사용되는 주파수를 무료로 사용할 수 있기 때문에 보급화 하는데 큰 기여를 하게 될 것이다.

본 발명은 차량통신장치와 와이파이공유기를 차량에 탑재하고 스마트폰에 차량간통신기반의 앱(APP) 프로그램을 설치하게 되면 다음과 같은 편리한 서비스를 무료로 사용할 수 있는 새로운 기술이다.

1.도로 주행 중 교통정체 발생시 발생 원인을 실시간으로 동영상 수신을 통해 알 수 있다.

2.동일 방향으로 주행하는 차량에 대한 위치 및 속도정보를 스마트폰 표시기로 알 수 있다.

3.도로상에 과속주행 차량에 대한 정보를 알 수 있어 경계운전이 가능하게 되어 교통사고를 크게 줄일 수 있다.

4.도로상에 주행중에도 Facebook 과 같은 소셜네트워크 가입자와 통신이 가능하게 된다.

5.스마트폰 또는 스마트패드와 같은 와이파이 기반의 스마트기기를 통해 운전자에게 편리한 서비스를 제공할 수 있게 된다.

6.차량통신장치와 Display장치간에 유선으로만 접속 사용하였으나 본 발명에는 차량통신장치와 와이파이공유기가 융합되어 있어 무선환경에서 스마트폰과 접속이 편리하다.

7.각 차량에 보유하고 있는 스마트폰 가입자간에 무료로 동영상 및 음성을 전달할 수 있다.

8.현재 교통상황에 대한 정보를 TELCO사업자망을 통해서만 이용 가능하였으나 , 본 발명기술을 적용하게 되면 차량간통신기술을 사용하여 교통상황정보를 실시간 동영상으로 무료로 받아 볼 수 있다.

본 발명을 첨부된 도면을 참조하여 상세히 설명하면 다음과 같다.

그림1은 주행중 교통정보 공유를 위한 차량간통신시스템 구성도이다.

Vehicle1에 탑재되는 장치로는 차량통신장치(OBU＃1), 와이파이공유기(AP1), 스마트폰(1)로 구성되며, Vehicle2에 탑재되는 장치는 Vehicle1과 동일하게 차량통신장치(OBU＃2), 와이파이공유기(AP2), 스마트폰(2)로 구성되어 있다. Vehicle1에서 차량통신장치(OBU＃1)은 차량간통신기술인 WAVE(Wireless Access In Vehicular Environment) 표준을 사용하고 있으며, 와이파이공유기(AP1)는 차량통신장치(OBU＃ 1)과 이더넷으로 접속되어 TCP/IP프로토콜을 사용하여 스마트폰(1)과 와이파이(무선랜) 통신할 수 있도록 하기 위한 장치이며, 스마트폰(1)은 스마트폰용 앱(APP)프로그램을 탑재하여 본 발명기술인 "주행중 차량간통신환경에서 스마트폰(또는 스마트기기)를 이용하여 실시간 교통동영상을 자동으로 교환하기위한 스마트폰 프로그램 구성 및 알고리듬"을 구현하기 위하여 구성된다. 한편 Vehicle2에 탑재되는 장치로는 차량통신장치(OBD＃2), 와이파이공유기(AP2), 스마트폰(2)로 구성되어 있으며 장치별 역할은 OBD＃1, AP1, 스마트폰(1)과 동일하다.

그림2는 Whole System Activity Diagram (Smart Phone) 이다.

이 Diagram의 각 lane은 Android에서 각각의 UI나 위치를 가지고 역할을 수행하는 Activity 혹은 Service의 단위로 분류되어있으며, WAVE-Mobile SNS의 smart-phone application에 대한 전체적인 흐름과 기능을 설명한다. 둥근 사각형은 정의나 실행의 액션을 뜻하며, 직사각형은 application 내에서 동작하는 object를 뜻한다.

-이 mobile Application은 두 곳의 entry point를 갖는다. 이유는, 시스템의 main이 되는 background service가 실행되기 위한 조건/방법이 두 가지이기 때문이다. 이 것들은 1과 3에 설명되어 있다.

-이후로 언급하는 Activity는 Android 내에서 하나의 UI thread로 동작하는, Application의 구성 클래스를 말한다. 이는 한 Application 내부에서 동작하지만 별도의 UI 화면 window를 갖는다.

전체적인 설명은 " 그림 2) " 을 기준으로 되어있고, 세부적인 설명은 나머지 그림으로 보충하는 형식으로 되어있다. 각 항목의 번호는 그림에 있는 각 번호의 node에 관한 설명이다.

그림2를 설명하면 다음과 같다.

-Android 부팅 시에 시스템 broadcast가 발생되는데, Application 설치 시점에서 이를 수신하는 receiver를 등록해두면, 차후 매 부팅 시마다 해당 broadcast를 인식하여 자동적으로 어떤 routine을 수행하게 된다(0).

-Android 부팅 완료 broadcast를 수신한 경우, 자동적으로 background service를 실행한 후 리시버의 call back method는 종료된다(1).

-Application의 실행/단축 아이콘을 터치하여 실행 시(2),

-background service를 재실행 시킨다(3).

-사용자를 위한 버튼 두 개와 직접 연결을 위한 IP 입력 창 하나를 표시해준다. 버튼 하나는 직접 연결 요청(Direct Demand) 버튼이고, 나머지 하나는 주위 차량 리스트를 보여주는 다른 Activity를 호출하는 버튼이다(4).

-주위 차량 리스트를 보여주는 버튼이 눌렸을 경우 호출되는 method로 차량 리스트 화면을 실행시킨다. 41번 node로 연결된다(5). (그림 16. Capture 1)

-직접 연결 요청 버튼이 눌렸을 경우 호출되는 method로 입력되어있는 IP로 연결하기 위해 background service의 handler에 IP 주소를 포함한 message를 보낸다(6). (그림 16. Capture 1)

-Android의 hardware button으로 Home Key나 Back키가 눌린 경우, Activity는 종료되며 별도 처리나 리턴 값을 따로 남기지 않는다(7).

-background service를 초기화 시키는 작업으로, 서비스에서 사용하게 될 각 변수와 상수 값을 설정하고, 리스트 자료구조를 사용하기 위한 객체 등을 미리 선언한다. Vehicle Information List를 새로 생성한다(8).

-background service와 다른 Activity나 thread와의 상호작용을 위한 message를 받아 처리하는 Handler를 생성한다(9).

-UDP broadcast로 발생되는 datagram packet을 받아 처리하기 위한 broadcast thread를 생성한다(10).

-자신의 정보를 담아 주기적으로 UDP broadcast를 하는 thread를 생성한다. 이 thread 역시 daemon으로 동작한다(11).

-TCP 관련 socket 연결을 accept 하기 위한 thread를 생성한다(12).

-다른 Activity나 thread로부터 message를 받아 이를 처리하는 handler로서 전체 프로그램내부로부터의 흐름을 진행시키는 역할을 한다(13).

-이 thread는 daemon으로서 looping을 하며, packet을 수신하기 전까지는 pending된다. 수신되는 모든 packet의 처리를 위해 처리 thread를 바로 실행 후 바로 다음 packet을 받기 위한 준비를 한다(14).

-14번과 16번 thread에서 수신한 network message의 분석과 처리를 위해 존재하는 thread로 이 thread는 daemon이 아닌, message 수신 발생시마다 생성되어 동작하는 thread이다. 이렇게 구성한 이유는 network message의 처리를 asynchronous하게 동작시켜 processing throughput을 최대화 하고자 하는 목적 때문이다. 물론, 완전한 asynchronous thread는 아니며, background service 자체에 갖도록 설정한 서비스 상태 값에 따라 같은 network message를 받더라도 다르게 처리하도록 구현하였다(15).

이 thread에서 처리하는 network message는 다음과 같다.

A. _OGA : 그림 3)

* OBU에서 _OGA network message를 받으면, background service는 다음의 작업을 실행하며 두 작업은 parallel하게 진행된다. 또한 background service의 상태 mode가 MODE_NORMAL인 경우에만 수행되며, 이를 MODE_REC로 변경한다.

1)자신의 차량이 위급상황임을 알리는 broadcast를 주기적으로 보내는 daemon을 실행시킨다. 이 경우 17번 node로 진행되며 주기적으로 _OSA network message를 발생시킨다. 또한 주기는 3 sec이며, datagram packet에 자신의 IP address를 포함한다.

2)영상을 녹화, 전송하기 위한 Activity를 실행시킨다. 30번 node로 진행된다.

B. _OSA : 그림 4)

* _OSA network message를 수신한 경우, 주위에 위급상황이 발생했음을 인지하여 영상을 받아 재생하는 작업을 진행한다. 이 경우 20번 node로 진행된다. background service의 상태 mode가 MODE_NORMAL인 경우에만 수행되며, 이를 MODE_PLAY로 변경한다.

C. _IXX : 그림 5)

* _I로 시작되는 모든 network message를 처리한다. OBU의 ID에 해당하는 XX 를 화면에 보여주는 Activity를 실행한다. 47번 node로 진행된다. background service의 상태 mode가 MODE_NORMAL인 경우에만 수행되며, 이를 MODE_PLAY로 변경하지 않는다.

D. _PRR : 그림7)

* server가 되는 smart-phone이 다른 client phone으로부터 녹화 요청을 받은 경우 이를 처리하는 routine이다. _PRR이 수신되면 먼저 현재 mode를 확인하여 MODE_NORMAL인 경우에만 녹화 준비 화면 Activity를 실행시키고, 이 과정이 완료되고 난 이후에 해당 network message를 송신한 client에게 녹화 준비가 되었다는 것을 알리기 위해 _PPV를 전달한다. background service의 상태 mode가 MODE_NORMAL이거나 MODE_RQST_SERVER인 경우에만 수행되며, 자신의 mode를 MODE_RQST_SERVER로 변경한다. 30번 node로 진행된다.

E. _PSI : 그림8)

* OBU와 연결된 각 smart-phone이 주기적으로 broadcast하는 정보를 수신한 경우 진입하는 routine으로 background service의 상태 mode와는 무관하게 진입한다. 전달받은 위도, 경도, 속도, IP address, 방향 값 등의 정보들을 Nearby Vehicle List에 추가하는 작업을 한다. 이 때, list 내에 자신과 동일한 IP를 가진 item은 삭제한다.

F. _PPV : 그림9)

* server에서 녹화중임을 알리는 network message로, 이를 수신한 client는 재생 준비 화면 Activity를 실행 한다. 20번 node로 진행된다.

-이 thread는 14번과 마찬가지로 daemon으로 동작하며, accept 직후 해당 socket을 pool에 추가한 뒤 UDP broadcast thread와 마찬가지로 바로 처리 thread를 실행시키고 data를 전달한 후 다음 packet을 받기 위한 준비를 한다(16).

-이 thread는 주기적, 반복적으로 UDP broadcast를 발신하기 위한 용도로 만들어 졌으며, 이 system상에서는 현재 두 가지의 역할을 수행한다. 단지 주기적으로 broadcast를 반복 할 뿐이며, 보낼 message의 내용과 반복 주기는 Constructor에서 인자로 받아 포함된다.

하나는 위도, 경도, 속도, IP, 방위각 등이 포함되어있는 자신의 정보를 주기적으로 broadcast하는 thread로 daemon으로 동작한다. 이러한 정보를 얻어오기 위해 이 thread는 지속적으로 OBU와 통신을 해야 한다. 둘째로, 자신이 위급상황임을 주위에 알리고 영상을 전송하고 있는 상태임을 알리는 용도로 사용된다(17).

-앞에서 background service가 초기화되는 시점에 생성되고 clear되는 리스트 형을 갖는 object container이다. item이 되는 object는 주위의 OBU와 연결된 Smart-phone에서 위의 18번 thread를 통해 발생된 정보들이다. 이 리스트는 item이 갖는 IP address 값을 고유하게 유지함으로써 list내에 같은 차량이 겹치지 않도록 한다(18).

-TCP server에서 생성시 입력된 client에게 요청 받은 message를 보내는 thread이다(19).

-15번 thread에서 재생 준비 화면 Activity가 생성된다. 이 Activity가 실행되면 내부적으로 처리해야 하는 message들에 관한 handler가 먼저 생성된다. 이 과 정은 재생 준비 화면 Activity 실행 시 처음 한번만 실행된다(20).

-재생 도중 server에서 발생되는 Exception message를 받아 처리하기 위한 server를 생성한다(21).

-영상을 녹화하여 전송하게 될 server에 연결하는 일을 담당하는 thread를 생성한다(22).

-재생 준비 Activity에 관련된 Message를 처리한다. 처리되는 message는 다음과 같다.

A. MSG_START_CLIENT

* 재생 관련 전체 process를 진행하는 thread를 실행시킨다. 26번 node로 진행.

B. MSG_START_PLAY

* 재생 Activity를 실행시킨다. 28번 node로 진행된다.

C. MSG_RECONNECT_TO_SERVER

* socket error나 server socket에 연결이 몰린 경우 server로 연결을 재시도 한다. 이 때, 랜덤으로 1∼5초를 대기한 후 다시 접속 한다. 22번 node로 진행된다.

D. MSG_RESTART_TCPSERVER

* server의 exception packet을 수신하는 socket에서 exception이 발생한 경우 이 수신 socket을 재 시작한다. 24번 node로 진행된다.

-server에서 exception이 발생할 경우, 자신 Activity를 종료하고 이를 23번 의 handler에 전달하는 thread로 server socket을 listen상태로 대기시켜두다가 accept 되는 경우 message를 분석하여 handler로 MSG_RESTART_TCPSERVER를 전달한다. 이 때 수신되는 network message는 _END이다(24). 그림 5)

-file을 server로부터 전송 받는 것을 담당하는 thread이다. 전송이 완료되면, 재생 화면 Activity를 실행시킨다(25).

-server로부터 _END network message를 수신하거나 사용자가 Activity를 종료시킬 때까지 내부에서 반복되어 실행되는 thread이다. 진행 순서는 다음과 같다.

A. TCP socket을 이용해 server에 연결한다.

B. server에서 녹화중인 file의 index number를 수신한다.

C. 전송 받을 file의 크기를 수신한다.

D. file을 수신한다.

E. MSG_START_PLAY message를 자신의 handler에 보내 재생을 시작한다. 23번 node로 진행된다(26).

-MSG_RESET_SERVICE_MODE를 13번의 handler에게 전달 후 Activity를 종료한다. 이 때, 이 Activity에서 생성된 thread와 socket은 모두 제거된다. 또한 MSG_RESET_SERVICE_MODE를 background service의 handler에게 전달하여 서비스 역시 초기화 시킨다(27).

-intent를 통해 전달받은 경로의 file을 재생하는 역할을 한다(28).

-정상 종료일경우 RESULT_OK를 남기고, 이 경우 재생 준비 화면 Activity는 Android의 Garbage Collector를 사용하여 memory를 정리한다(29).

-file의 녹화와 전송을 위한 thread를 생성 후 실행시키기 위해 MSG_START_SERVER message를 handler에 보낸다(30).

-녹화 상태를 monitoring 하는 thread 관련 변수를 설정한다(31).

-자체 message를 처리할 handler를 생성한다(32).

-server socket을 만들어 대기하다가 연결이 이루어지면 만들어진 socket을 ListArray에 추가시킨다. monitoring thread가 생성되어있지 않은 경우에만 MSG_RECORDING_MONITOR message를 handler에 보내어 monitoring thread를 생성, 실행한다(33).

-녹화 준비 화면 Activity의 중심이 되는 thread로서, exception이 발생되거나 사용자로부터 종료될 때까지 반복적으로 실행된다. 주요 작업 순서는 다음과 같으며 각 단계는 synchronous 하게 진행된다(34).

A.녹화 중이 아니라면 MSG_START_RECORD message를 handler에 보내어 녹화 Activity를 실행시킨다. 39번 node로 진행된다.

B.socket list에 저장되어있는 모든 socket을 통해 file을 전송한다. 이 때 file transfer thread가 실행되고, 이 thread는 동시에 병렬적으로 file을 전송한다. 그리고 monitor thread는 모든 전송이 종료 될 때까지 join 상태로 대기한다. 35-36번 path에 해당.

C.방금 녹화한 file의 full path를 저장한 후 다시 MSG_RECORDING_MONITOR를 실행시키도록 handler에 요청 후 자신은 종료된다. 36-34번 path에 해당한다.

-녹화 준비 Activity 내부의 message들을 처리한다. 처리하는 message는 다 음과 같다(35).

A. MSG_START_SERVER

* 연결을 받아 socket을 등록하는 server thread를 실행시킨다.

B. MSG_START_RECORD

* 녹화 Activity를 호출한다. 이 때 녹화할 file의 full path를 함께 전달한다.

C. MSG_RECORDING_MONITOR

* recording monitor thread를 실행시킨다.

D. MSG_END_CONNECTION

* 연결되어있는 모든 client에 대하여 _END를 보내는 thread를 실행한다. 37번 node로 연결된다.

-녹화된 file의 전송을 담당하는 thread로서 녹화된 file의 index number와 file size를 전송한 뒤 file을 전송하고 완료되면 thread도 종료된다(36).

-전달 받은 IP address에 _END network message를 전송한 뒤 종료한다(37).

-녹화 Activity의 실행을 제외한 다른 이유로 녹화 준비 Activity가 stop 상태에 들어가면 비정상 종료, 혹은 사용자에 의한 종료로 판단할 수 있으므로, MSG_END_CONNECTION message를 handler에 전달하고 list에 등록되어 있거나 열려있는 모든 socket을 닫는다. 또한 MSG_RESET_SERVICE_MODE를 background service의 handler에게 전달하여 서비스 역시 초기화 시킨다(38).

-전달받은 file path에 영상을 녹화하여 저장한다(39).

-정상적으로 녹화가 종료되는 경우 RESULT_OK를 반환하며 종료된다(40).

-background service에서 관리하고 저장하고 있는 Nearby Vehicle List를 받아온다(41).

-받아온 list를 보여주기 위한 ListView와 좌측 Graphical View를 준비한다(42).

-list의 각 item은 touch를 통해 click되는 경우, 저장되어 있는 IP address를 이용해 server가 될 smart-phone에 연결을 시도한다. 6번 node로 진행된다(43). (그림 16.Capture 2)

-list의 각 item이 표시되는 곳으로 45번 node의 Item Adapter를 이용해 item을 생성하고 얻어온다(44).

-Nearby Vehicle List의 내용이 변경되는 경우, 이에 대한 알림을 받아서 Item Adapter는 ListView를 update 시킨다(45).

-종료는 사용자가 back key나 home key를 누른 경우 발생하며, 특별한 처리는 없다(46).

-전달받은 OBU ID를 포함한 문구를 전체 화면으로 표시하고 TimerTask를 이용하여 1.5초간 표시 후 자동 종료시킨다(47). (그림16.Capture 6)

-또한 다음과 같은 동작을 수행한다(48).

1. Capture Recieve Thread는 TCP Daemon과 같이 동작하며, Recording Phone에서 전달되는 Capture Image를 수신하기 위해 대기한다.

2. Capture Image를 수신하는 서버 소켓에 연결이 된 경우, 이를 처리하기 위해 실행되는 Thread이다. File download와 Prepare Playing Activity의 배경 이미지로의 설정이 이루어 진다.

3. Capture Receive Thread를 생성한다.

4. Message Handler에 의해 생성되며, 매 동영상 촬영 이전에 생성되어 화면 Capture와 전송을 진행한다.

5. 실질적으로 Client에 연결하여 Capture Image를 전송하는 Thread이다.

6. 주위 차량의 정보를 담고 있는 Array List이며, 이 List의 변경 내용은 List Adaptor를 통해 List View 객체와 동기화된다.

7. Service쪽에서 수신하여 전달한 새로운 차량 정보를 Message로 받아 처리하는 이 Handler에 의해 Array List가 update 된다.

8. Prepare Playing Activity의 재생 전 두 가지 상태를 나타내는 화면이다. (그림16. Capture3, Capture4)

9.Prepare Recording Activity의 촬영 전 대기화면이다. (그림16. Capture5)

그림3은 _OGA Activity Diagram(Smart Phone) 이다.

_OGA message의 경우, 차량에서 사고나 위급상황을 OBU가 감지 하였을 때, 자신과 AP를 통해 WiFi로 연결된 smart-phone에게 이 _OSA message를 전달하여 영상을 촬영하도록 하며, 주위의 다른 OBU들에게 이를 알려 영상 재생을 준비시키고, 이를 전송하여 현 사고 감지차량의 상황을 알리는 역할을 수행한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

-OBU에서 장착 차량의 사고나 위급상황을 감지하는 경우 주위로의 전파를 목 적으로 smart phone에 전달하는 network message이며, socket 연결을 통해 전달된다(50).

-message 도착(51)

-message의 도착을 기다리다가 message 처리 thread를 생성하고 인자로 받은 message를 전달 후 바로 다음 message를 받기 위해 대기한다. 빠른 message 수집을 위해 이와 같이 동작한다(52).

-전달받은 message를 분석하여 해당하는 routine으로 분기시킨다. 필요한 경우 Activity를 호출하거나 thread를 생성, 실행한다(53).

-위의 52, 53번 node는 background service에서 공통적으로 사용되는 message 처리 thread이며, 51-54번 node flow는 그림 1)에서의 14-15번, 16-15번 node의 flow와 동일하다(54).

-이 thread는 주기적, 반복적으로 UDP broadcast를 발신하기 위한 용도로 만들어 졌으며, 이 system상에서는 현재 두 가지의 역할을 수행한다. 단지 주기적으로 broadcast를 반복 할 뿐이며, 보낼 message의 내용과 반복 주기는 Constructor에서 인자로 받아 포함된다(55).

-_OSA를 주기적으로 broadcast한다(56).

-_OSA를 받은 client로부터 TCP 연결을 받기 위한 socket을 가지고 대기하는 thread이다(57).

-연결이 accept되면, 해당 socket을 client socket list에 추가한다. TCP server thread는 곧바로 다시 listen 상태로 돌아간다.

- 현재 smart phone의 recording monitor의 동작 여부를 확인한다. recording monitor thread의 역할은 그림2) 의 34번 node 설명에 나와있다(58).

-녹화된 영상은 recording monitor에서 한 주기(10초)가 완료 될 때마다 client socket list에 등록된 모든 socket을 통해 client들에게 전파되므로, 이미 녹화 상태인 경우에는 그대로 thread를 종료한다(59).

-녹화 준비 화면 Activity를 실행시킨다. 이 과정은 그림2) 의 30-34번 node까지의 flow와 동일하다(60).

-녹화를 시작한다. 이 과정은 그림2) 의39번 node에 해당한다(61).

-녹화된 영상을 연결되어있는 모든 client에게 전송한 다음, 다음 번 녹화를 준비한다. 그림2) 의35-36-34번 순서의 node flow와 동일하다(62).

-동영상 처리과정은 다음과 같다.

1)Capture, Recording, Transfer 등을 순차적으로 수행하게 만드는 Thread로 전체적인 진행 흐름을 수행한다(63.1).

2)Capture에 관련된 진행을 하며 Capture Activity를 실행시켜 순간적인 화면을 Image로 저장한 후, Capture Transfer Thread를 실행시킨다(63.2).

3)촬영 된 Capture Image를 Client 측에 전달하는 역할을 한다(63.3).

그림4는 _OSA Activity Diagram (Smart Phone)이다.

그림4에서 _OSA message의 경우, 다른 차량에서 사고나 위급상황을 OBU가 감지 하였을 때, 주위의 다른 OBU들에게 이를 알려 영상 재생을 준비시키는 message이다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

좀 더 세부적으로 설명하면 다음과 같다.

-사고 발생이나 위급 상황을 감지한 smart phone에서 주위에 이를 알리기 위해 발생시키는 broadcast에 사용되는 network message이다(65).

-message 도착(51)

-message의 도착을 기다리다가 message 처리 thread를 생성하고 인자로 받은 message를 전달 후 바로 다음 message를 받기 위해 대기한다. 빠른 message 수집을 위해 이와 같이 동작한다(53).

-Activity 생성시 전달받은 IP address를 이용하여 녹화 file을 받아 올 server에 접속하는 thread를 생성하여 실행한다. 그림2) 의 20-21-26번 node flow에 해당한다(66).

-file을 server로부터 download 하는 thread가 생성, 실행된다. download가 완료되면, 재생 화면 Activity를 실행시킨다. 그림2) 의26-23-25-28번 node flow에 해당한다(67).

-전달받은 file path의 영상을 재생한다. 정상 종료일경우 RESULT_OK를 남기고, 이 경우 재생 준비 화면 Activity는 Android의 Garbage Collector를 사용하여 memory를 정리한다. 다시 재생 준비 화면 Activity로 복귀하여 file을 download 받을 준비를 한다. 그림2) 의 28-29-23번 node flow에 해당한다(68).

-동영상 처리과정은 다음과 같다.

1)Capture Image를 수신하기 위한 서버소켓을 가지고 대기하는 Thread이다(69.1).

2)Capture Image file 전송을 진행하는 Thread이다(69.2).

그림5는_IXX Activity Diagram (Smart Phone) 이다.

그림5에서 _IXX message의 경우, 자신의 통신 반경 내에 있는 다른 OBU와 그에 연결된 smart-phone에게 자신의 ID를 알리는 역할을 수행한다. ID는 XX로 표시 된 부분에 작성되어지며 길이는 가변적으로 사용할 수 있다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명하였다.

-OBU에서 자신의 ID를 XX 부분에 넣어 주기적으로 broadcast하는 network message이다(70).

-message 도착(51)

-위의 52, 53번 node는 background service에서 공통적으로 사용되는 message 처리 thread이며, 51-54번 node flow는 그림2)에서의 14-15번, 16-15번 node의 flow와 동일하다(54).

-화면상에 OBU ID를 포함한 문구를 전체 화면으로 표시하고 TimerTask를 이용하여 1.5초간 표시 후 자동 종료시킨다. 그림2)의 47번 node에 해당한다(71).

그림6은 _END Activity Diagram (Smart Phone) 이다.

그림6에서 _END message의 경우, 영상을 촬영하는 smart-phone에서 촬영이 종료됨을 다른 client smart-phone들에게 알리는 역할을 수행한다. client의 종료는 server 역할을 하는 촬영 smart-phone에게 알려줄 필요가 없으며, 이 message를 받은 client smart-phone은 다음 파일을 재생하는 loop에 Activity를 종료하고 이전에 실행하던 화면으로 복귀한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 다음과 같이 설명하고 있다.

-server에서 녹화나 data 전송 중 발생된 exception이나 사용자의 종료 명령이 발생한 경우, _END network message를 Broadcast 하게 된다(73).

-message 도착(51)

-server의 handler에 해당 조건이 일치함을 message를 보내어 알린다. 해당 message는 그림2) 의35번 node로 보내진다(74).

-_END network message를 Broadcast 한다. 그림2) 의 35-37번 node에 해당한다(75).

-자신이 사용하던 모든 socket과 resource와 IO stream을 닫고 반환한 후, background service의 handler에 message를 보낸다. 그림2) 37-38-13번 node flow에 해당한다.

-_END network message는 UDP socket을 통해 전달된다(76).

-message 도착(51)

-위의 52, 53번 node는 background service에서 공통적으로 사용되는 message 처리 thread이며, 51-54번 node flow는 그림2) 에서의 14-15번, 16-15번 node의 flow와 동일하다(54).

-자신이 사용하던 모든 socket과 resource와 IO stream을 닫고 반환한 후, background service의 handler에 message를 보낸다.. 그림2) 의 37-38-13번 node flow에 해당한다(78).

그림7은 _PRR Activity Diagram (Smart Phone) 이다.

이 그림은 스마트폰에서 Recording 요청하기 위한 동작을 나타낸다. 즉, PRR message의 경우, 한 차량의 OBU와 연결된 smart-phone에서 다른 차량의 OBU와 연결 된 smart-phone에게 촬영과 전송을 요청하는 역할을 수행한다. 재생 준비를 마친 후 _PRR message를 보내고, _PPV message를 수신하여 서로간에 촬영과 재생의 준비가 완료됨을 확인하기 전까지는 대기하고 있는다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

- _PRR network message는 다른 OBU와 연결되어있는 smart phone에서 특정 OBU에 연결된 smart phone의 영상을 보기 위한 목적으로 보낸다. TCP를 이용하여 통신한다(80).

-message 도착(51)

-위의 52, 53번 node는 background service에서 공통적으로 사용되는 message 처리 thread이며, 51-54번 node flow는 그림 2) 에서의 14-15번, 16-15번 node의 flow와 동일하다(54).

- _OSA를 받은 client로부터 TCP 연결을 받기 위한 socket을 가지고 대기하는 thread이다(57).

-연결이 accept되면, 해당 socket을 client socket list에 추가한다. TCP server thread는 곧바로 다시 listen 상태로 돌아간다(58).

A.현재 smart phone의 recording monitor의 동작 여부를 확인한다. recording monitor thread의 역할은 그림 2) 의 34번 node 설명에 나와 있다.

B.연결이 accept 된 client socket을 통해 _PPV network message를 전송한 다.

-녹화 준비 화면 Activity를 실행시킨다. 이 과정은 그림 2) 의 30-34번 node까지의 flow와 동일하다(60).

-녹화를 시작한다. 이 과정은 그림 2) 의 39번 node에 해당한다(61).

-녹화된 영상을 연결되어있는 모든 client에게 전송한 다음, 다음 번 녹화를 준비한다. 그림 2) 의 35-36-34번 순서의 node flow와 동일하다(62).

- _PRR을 받아 녹화한 file을 전송할 client가 등록되면, server는 해당 client에게 녹화 준비가 완료되었음을 알리기 위해 _PPV network message를 전송한다(81).

-동영상전송을 위한 다음의 동작이 수행된다(63.1, 63.2, 63.3)

그림8은 _PSI Activity Diagram (Smart Phone)으로, 스마트폰이 정보를 보내는 동작을 나타낸다. _PSI message의 경우, 본인 차량의 OBU에서 주기적으로 보내 진 위도, 경도, 속도, 방위각, ip 등의 정보를 smart-phone이 받아, 주위 다른 차량에게 전달하는 message인데, 이를 관리, 전달하는 역할을 수행한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

- _PSI network message는 자신의 위도, 경도, 속도, IP address, 방위각 등을 한 datagram packet에 담에 주위에 주기적으로 broadcast되는 message이다. OBU에 연결된 모든 smart phone은 이 packet을 항상 발생시킨다(83).

-message 도착(51)

-이것을 수신한 모든 smart phone은 자신이 갖고 있는 Nearby Vehicle List에 해당 정보를 item으로 만들어 추가한다(84).

- List를 확인하여, 동일한 IP address를 갖는 item이 있는지 확인하여, item을 삭제 후 새로 추가한다.

- 얻어온 Data를 계산하여 Carlist Activity에서 필요로 하는 정보로 변환한 다.

- 이전 Data와 비교하여 값을 보정하는 Algorithm을 수행 한 뒤 Carlist Activity의 Message Handler로 전달한다.

그림 1)의 15-18번 node flow가 이에 해당한다.

-주위 차량에서 발생되는 _PSI message에 포함된 각종 정보(위도, 경도, 속도, IP address, 방위각 등)를 하나의 item으로 하여, 각각의 주변 차량의 정보를 list로 구성해 둔 것이다. list 내에 동일한 IP를 갖는 item은 존재하지 않도록 구현되어 있다(85).

그림9는 _PPV Activity Diagram (Smart Phone) 으로, 스마트폰에서 동영상을 표출하기 위한 동작을 나타낸다. 즉, _PPV message의 경우, 다른 차량의 smart-phone에서 특정 차량의 smart-phone에게 영상의 촬영과 전송을 요청한 경우, 이를 수신한 smart-phone 측에서 촬영과 전송 준비를 마쳤을 때 이를 알려주는 message로, 이것을 전달하는 역할을 수행한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

-_PPV는 _PRR을 받은 server가 client에게 보내는 network message로, file 녹화와 전송을 위한 연결을 수락할 준비가 되었음을 알려준다. 이를 수신한 client는 server의 TCP socket에 연결을 시도한다(88).

-message 도착(51)

-file을 server로부터 download 하는 thread가 생성, 실행된다. download가 완료되면, 재생 화면 Activity를 실행시킨다. 그림2) 의 26-23-25-28번 node flow에 해당한다(67).

-동영상전송을 위한 다음 동작을 수행한다(69)

2)Capture Image file 전송을 진행하는 Thread이다(69.2).

그림10은 List and Direct connection Activity Diagram(Smart Phone) 으로, 스마트폰 사용자가 통신상대를 선택하기 위한 동작을 나타낸다. Direct Connection의 경우, IP address의 입력을 통해 수행되는데, 이 기능을 수행하는 전반적인 work flow 기반 diagram이다. User의 touch screen을 통한 입력에서 시작되며, 입력된 ip address를 통해 직접적으로 _PRR을 전송하는 시퀀스로 진행이 되거나, List에서 item을 선택하는 형식으로 해당 item에서 ip address를 얻어와서 _PRR message를 전송하는 방식의 두 가지 시퀀스를 취하고 있다.

-Show Vehicle List Button은 main UI Activity에서 사용자가 선택할 수 있는 두 개의 버튼 중 하나이며, 그림2) 의 5번 node를 통해 발생하며 41-46번 node flow와도 관련이 있다(90).

-Direct Demand Button은 main UI Activity에서 사용자가 선택할 수 있는 두 개의 버튼 중 하나이며, 그림2) 의 6번 node를 통해 발생한다(91).

-차량 리스트 화면(Show Vehicle List) Activity가 실행된다. 그림2) 의 5-41번 node flow에 해당한다(92).

-이 Activity는 자체의 UI를 가지고, background service에서 가지고 있는 Nearby Vehicle List를 화면에 보여주고 사용자와 상호작용 하는 역할을 한다(93).

-다른 Activity를 거치지 않고 곧바로 background service의 handler에게 _PRR의 전송을 요청하는 message를 보낸다(94).

-background service로부터 Nearby Vehicle List를 받아오는 부분이다(95).

-거리와 방향 등을 계산한다(96).

-계산된 결과를 이용하며 GUI 상에 적절하게 배치한다. 95-97번 node flow는 그림2) 의 41번 node에서 하는 일에 해당한다(97).

-해당 smart phone에게 _PRR을 전송한다. 그림2) 의 13-19번 node flow에 해당한다(98).

그림11은 On demand Direct case Sequence Diagram (Smart Phone) 으로 스마트폰이 직접 녹화한 동영상을 주변 스마트폰 사용자에게 전송하기 위한 동작을 나타낸다. 직접적으로 ip address를 입력하여 _PRR을 보내는 경우에 대한 sequence diagram이다. 각 device 별로 수행하는 작업과 순서를 보여준다. _PRR과 _PPV를 주고받으며, 서로의 재생과 촬영, 전송, 수신 상태를 확인 한 뒤 촬영을 하고, 이를 보내고 전송 완료 이후 재생하는 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart-phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속된다.

-Smart-phone1에서 user가 특정 차량으로 표시되는 OBU에 연결된 다른 smart-phone2에게 영상 촬영 및 전송을 요청한다. 이 때, 사전에 _PSI message를 통해 알고 있는 ip address를 사용하여 요청한다(1).

-요청을 받은 smart-phone2의 service는 영상을 촬영할 준비를 마친 뒤 이를 _PPV message를 통해 이를 요청한 smart-phone1에게 알려준다(2).

-Smart-phone1의 service는 smart-phone2의 _PPV를 수신한 다음, 실제 재생을 위해 Activity(Prepare Playing Activity)를 실행시킨다(3).

-Smart-phone1의 Prepare Playing Activity에서 smart-phone2의 service 측 과 실제 data 전송을 위한 TCP connection을 맺는다(4).

-TCP connection이 정상적으로 맺어지면, smart-phone2의 service는 영상 촬영을 위한 Activity(Prepare Recording Activity)를 실행시키고 촬영에 들어간다(5).

-영상을 촬영하여 file로 저장한다(6).

-저장 된 file을 smart-phone1으로 전송한다. 이 때, smart-phone1의 Prepare Playing Activity는 Playing Activity를 실행시켜 전송 받은 영상을 화면에 보여준다(8).

-위의 8, 9, 10항을 반복한다(11).

-특정 상황(user의 종료 명령)에 의해 _END message가 발생되면, smart-phone2는 smart-phone1에게 이 message를 전달한다. 이 때, _END message는 UDP datagram packet을 통해 broadcast 된다(13).

-_END message를 받은 smart-phone1은 재생을 멈추고 main 화면으로 복귀한다(14).

-_END message를 전송 후, smart-phone2는 촬영을 멈추고 main 화면으로 복귀하거나 user가 입력한 명령을 수행하는 화면으로 이동한다(15).

그림12는 On demand List case Sequence Diagram (Smart Phone) 으로, 스마트폰 사용자가 자신의 스마트폰 표시창에 표출되어 있는 리스트를 확인하여 희망하는 스마트폰 사용자와 통신하여 실시간 교통동영상을 수신하기 위한 동작을 나타낸다. 즉, 스마트폰 표시창에 나타난 List에서 상대방을 선택하면 ip address를 얻어 와서 _PRR을 보내는 경우에 대한 sequence diagram이다. 각 device 별로 수행하는 작업과 순서를 보여준다. _PRR과 _PPV를 주고받으며, 서로의 재생과 촬영, 전송, 수신 상태를 확인한 뒤 촬영을 하고, 이를 보내고 전송 완료 이후 재생하는 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart-phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속된다.

-smart-phone1은 Car List Activity에서 list의 형태로 주위 차량과의 거리와 위치, 속도 등을 보여주고 있다(1).

-이 중 user가 특정 차량의 주행화면을 보기 위해 list의 item중 하나를 touch한다(2).

-Smart-phone1에서 user가 특정 차량으로 표시되는 OBU에 연결된 다른 smart-phone2에게 영상 촬영 및 전송을 요청한다. 이 때, 사전에 _PSI message를 통해 알고 있는 ip address를 사용하여 요청한다(3).

-요청을 받은 smart-phone2의 service는 영상을 촬영할 준비를 마친 뒤 이를 _PPV message를 통해 이를 요청한 smart-phone1에게 알려준다(4).

-Smart-phone1의 service는 smart-phone2의 _PPV를 수신한 다음, 실제 재생을 위해 Activity(Prepare Playing Activity)를 실행시킨다(5).

-Smart-phone1의 Prepare Playing Activity에서 smart-phone2의 service 측과 실제 data 전송을 위한 TCP connection을 맺는다(6).

-TCP connection이 정상적으로 맺어지면, smart-phone2의 service는 영상 촬영을 위한 Activity(Prepare Recording Activity)를 실행시키고 촬영에 들어간다 (7).

-영상을 촬영하여 file로 저장한다(8).

-저장 된 file을 smart-phone1으로 전송한다. 이 때, smart-phone1의 Prepare Playing Activity는 Playing Activity를 실행시켜 전송 받은 영상을 화면에 보여준다(10).

-위의 8, 9, 10항을 반복한다(13).

-특정 상황(user의 종료 명령)에 의해 _END message가 발생되면, smart-phone2는 smart-phone1에게 이 message를 전달한다. 이 때, _END message는 UDP datagram packet을 통해 broadcast 된다(15).

-_END message를 받은 smart-phone1은 재생을 멈추고 main 화면으로 복귀한다(16).

-_END message를 전송 후, smart-phone2는 촬영을 멈추고 main 화면으로 복귀하거나 user가 입력한 명령을 수행하는 화면으로 이동한다(17).

그림13은 On occur case Sequence Diagram (Smart Phone) 으로, 차량통신환경에 있는 스마트폰 사용자가 자신의 차에 돌발상황이 발생되었을 경우 OBU에서 사고나 위급상황을 감지하여 _OGA를 수신한 뒤, 주위 차량의 OBU로 _OSA을 보내는 경우에 대한 sequence diagram이다. 촬영과 전송 준비를 마친 뒤, _OGA를 전송하며, _OSA를 받은 OBU와 smart-phone은 재생준비 이후, 바로 연결을 시도한다. 촬영, 전송, 재생의 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart-phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속되는 동작을 나타낸다

-OBU2에서 급 감속, 또는 사고 발생으로 추정되는 사건을 감지하는 경우, 이를 OBU2와 연결된 smart-phone2에게 _OGA message를 보내어 알린다(1).

-_OGA를 수신한 smart-phone2의 service에서는 바로 촬영을 위한 Activity(Prepare Recording Activity)를 실행시키게 된다(2).

-Prepare Recording Activity가 실행된 이 후, 촬영에 들어가기 전에 주위의 차량에 있는 OBU1과 연결된 smart-phone1에게 _OSA message를 UDP broadcast로 알린다(3).

-_OSA message를 수신한 smart-phone1의 service는 이를 재생하기 위한 Activity(Prepare Playing Activity)를 실행시킨 뒤, smart-phone2에게 TCP 연결을 시도한다(5).

-영상을 촬영하여 file로 저장한다(6).

-위의 6, 7, 8항을 반복한다(11).

-_END message를 받은 smart-phone1은 재생을 멈추고 main 화면으로 복귀한 다(14).

그림14는 On _IXX case Sequence Diagram (Smart Phone) 으로, 주위의 OBU로부터 _IXX message를 수신한 경우, 이를 smart-phone의 화면에 표시하여 주는 간단한 Activity의 sequence diagram이다. OBU측에서 WSM broadcast를 수신한 후 TCP/IP protocol로 smart-phone에 전달해주는 과정을 볼 수 있고, smart-phone에서는 이를 개별 Activity로 실행하여 화면에 잠시 표시해 준 뒤 종료되는 과정을 나타낸다.

-OBU2에서 자신의 ID값을 _IXX message에 포함시켜 주기적으로 WSM broadcast한다(1).

-_IXX WSM을 수신한 OBU1은 이를 자신과 연결된 smart-phone1에게 전달한다(2).

-_IXX message를 통해 ID(XX부분)를 전달받은 smart-phone1의 service는 이를 표시하기 위한 Activity(Show OBU ID Activity)를 실행시킨다(3).

-Show OBU ID Activity는 전달받은 OBU2의 ID를 1.5초간 화면에 보여준 뒤 종료한다(4).

그림15는 On_PSI case Sequence Diagram (Smart Phone) 으로, 주기적으로 발생되는 _PSI message에 대한 저장, 전송과 처리, 그리고 활용에 대한 sequence diagram이다. 크게 두 가지의 작업으로 구분 할 수 있는데, 하나는 _PSI에 포함시 킬 data를 OBU에서 주기적으로 발생시키고, 이를 자신의 정보로 저장하고, 다시 그 data를 WSMP를 통해 전달하는 과정과 그렇게 여러 OBU 로부터 수신되어 smart-phone이 저장하고 있는 data를 list에 반영하여 활용하는 과정을 나타낸다.

-OBU2는 주기적으로 자신과 연결된 smart-phone2에게 현재 상태정보를 전달한다. 이 때, 전달되는 정보에는 위도, 경도, 속도, 방향 값(Degree), ID(IP address) 등이 있다(1).

-전달받은 정보를 smart-phone2가 자신의 정보로 설정한다(2).

-설정 된 자신의 정보를 WSMP를 이용하여 주기적으로 broadcast한다. 이 때, OBU1은 이 정보를 그대로 자신과 연결된 smart-phone2에게 전달한다(3).

-Smart-phone2에서는 전달받은 정보를 이용하여 보정한 뒤, 자신의 Nearby Vehicle Information List에 반영한다(4).

-1∼4항의 과정은 정보의 발생부터 저장까지의 단계로 일련의 주기적인 looping 과정이다.

-Car List Activity에서 list에 주위 차량의 정보를 보여주는 중이다(5).

-주기적으로 list를 update하기 전에, 불필요한 item의 제거를 service측에 요청한다. 일정 시간 동안 각 차량의 정보 update상태를 보기 위해 indicator가 표시되며, 5초간 update가 되지 않으면 주황색, 10초를 넘어서면 빨간색, 20초를 넘어가면 회색으로 표시된다. 30초를 넘어가면 list에서 삭제되며, 정상 연결 상태에서는 녹색으로 표시한다(6).

-List를 update하기 위해, service측에 list를 주기적으로 요청한다(7).

-현재 시점의 Nearby Vehicle Information List를 Car List Activity에게 전달한다(8).

-한편, 5∼8항의 과정은 정보의 발생부터 저장까지의 단계로 일련의 주기적인 looping 과정이다.

-1∼4항과 5∼8항은 비동기적으로 운용된다. 이는 6항의 동작과 관련이 있으며, 각 item별 timer를 통해 정보의 전달 상태를 확인 하는 부분과 밀접하게 연관이 있다.

그림1은 주행중 교통정보 공유를 위한 차량간통신시스템구성도이며, 스마트폰을 이용하여 차량통신을 하기 위해 구성되는 요소들을 나타낸 도면이다.

그림2는 Whole System Activity Diagram으로, 차량간통신 환경에서 스마트폰을 사용하여 차량통신에 필요한 세부 기능을 하나의 그림으로 통합하여 나타낸 그림이다. 즉, 이 Diagram의 각 lane은 Android에서 각각의 UI나 위치를 가지고 역할을 수행하는 Activity 혹은 Service의 단위로 분류되어있으며, WAVE-Mobile SNS의 smart-phone application에 대한 전체적인 흐름과 기능을 설명한다. 둥근 사각형은 정의나 실행의 액션을 뜻하며, 직사각형은 application 내에서 동작하는 object를 뜻한다.

그림3은 _OGA Activity Diagram으로, _OGA message의 경우, 차량에서 사고나 위급상황을 OBU가 감지 하였을 때, 자신과 AP를 통해 WiFi로 연결된 smart-phone에게 이 _OSA message를 전달하여 영상을 촬영하도록 하며, 주위의 다른 OBU들에게 이를 알려 영상 재생을 준비시키고, 이를 전송하여 현 사고 감지차량의 상황을 알리는 역할을 수행한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림4는 _OSA Activity Diagram으로, _OSA message의 경우, 다른 차량에서 사고나 위급상황을 OBU가 감지 하였을 때, 주위의 다른 OBU들에게 이를 알려 영상 재생을 준비시키는 message이다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림5는_IXX Activity Diagram으로, _IXX message의 경우, 자신의 통신 반경 내에 있는 다른 OBU와 그에 연결된 smart-phone에게 자신의 ID를 알리는 역할을 수행한다. ID는 XX로 표시 된 부분에 작성되어지며 길이는 가변적으로 사용할 수 있다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림6은 _END Activity Diagram으로, _END message의 경우, 영상을 촬영하는 smart-phone에서 촬영이 종료됨을 다른 client smart-phone들에게 알리는 역할을 수행한다. client의 종료는 server 역할을 하는 촬영 smart-phone에게 알려줄 필요가 없으며, 이 message를 받은 client smart-phone은 다음 파일을 재생하는 loop에 Activity를 종료하고 이전에 실행하던 화면으로 복귀한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림7은 _PRR Activity Diagram으로, 스마트폰에서 Recording 요청하기 위한 동작을 나타낸다. 즉, PRR message의 경우, 한 차량의 OBU와 연결된 smart-phone에서 다른 차량의 OBU와 연결 된 smart-phone에게 촬영과 전송을 요청하는 역할을 수행한다. 재생 준비를 마친 후 _PRR message를 보내고, _PPV message를 수신하여 서로간에 촬영과 재생의 준비가 완료됨을 확인하기 전까지는 대기하고 있는다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림8은 _PSI Activity Diagram으로, 스마트폰이 정보를 보내는 동작을 나타낸다. _PSI message의 경우, 본인 차량의 OBU에서 주기적으로 보내진 위도, 경도, 속도, 방위각, ip 등의 정보를 smart-phone이 받아, 주위 다른 차량에게 전달하는 message인데, 이를 관리, 전달하는 역할을 수행한다. 이 Diagram은 이와 같은 처리 를 주요 work flow 기반으로 설명해 준다.

그림9는 _PPV Activity Diagram으로, 스마트폰에서 동영상을 표출하기 위한 동작을 나타낸다. 즉, _PPV message의 경우, 다른 차량의 smart-phone에서 특정 차량의 smart-phone에게 영상의 촬영과 전송을 요청한 경우, 이를 수신한 smart-phone 측에서 촬영과 전송 준비를 마쳤을 때 이를 알려주는 message로, 이것을 전달하는 역할을 수행한다. 이 Diagram은 이와 같은 처리를 주요 work flow 기반으로 설명해 준다.

그림10은 List and Direct connection Activity Diagram으로, 스마트폰 사용자가 통신상대를 선택하기 위한 동작을 나타낸다. Direct Connection의 경우, IP address의 입력을 통해 수행되는데, 이 기능을 수행하는 전반적인 work flow 기반 diagram이다. User의 touch screen을 통한 입력에서 시작되며, 입력된 ip address를 통해 직접적으로 _PRR을 전송하는 시퀀스로 진행이 되거나, List에서 item을 선택하는 형식으로 해당 item에서 ip address를 얻어와서 _PRR message를 전송하는 방식의 두 가지 시퀀스를 취하고 있다.

그림11은 On demand Direct case Sequence Diagram으로, 스마트폰이 직접 녹화한 동영상을 주변 스마트폰 사용자에게 전송하기 위한 동작을 나타낸다. 직접적으로 ip address를 입력하여 _PRR을 보내는 경우에 대한 sequence diagram이다. 각 device 별로 수행하는 작업과 순서를 보여준다. _PRR과 _PPV를 주고받으며, 서로의 재생과 촬영, 전송, 수신 상태를 확인 한 뒤 촬영을 하고, 이를 보내고 전송 완료 이후 재생하는 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart- phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속된다.

그림12는 On demand List case Sequence Diagram으로, 스마트폰 사용자가 자신의 스마트폰 표시창에 표출되어 있는 리스트를 확인하여 희망하는 스마트폰 사용자와 통신하여 실시간 교통동영상을 수신하기 위한 동작을 나타낸다. 즉, 스마트폰 표시창에 나타난 List에서 상대방을 선택하면 ip address를 얻어와서 _PRR을 보내는 경우에 대한 sequence diagram이다. 각 device 별로 수행하는 작업과 순서를 보여준다. _PRR과 _PPV를 주고받으며, 서로의 재생과 촬영, 전송, 수신 상태를 확인 한 뒤 촬영을 하고, 이를 보내고 전송 완료 이후 재생하는 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart-phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속된다.

그림13은 On occur case Sequence Diagram 으로, 차량통신환경에 있는 스마트폰 사용자가 자신의 차에 돌발상황이 발생되었을 경우 OBU에서 사고나 위급상황을 감지하여 _OGA를 수신한 뒤, 주위 차량의 OBU로 _OSA을 보내는 경우에 대한 sequence diagram이다. 촬영과 전송 준비를 마친 뒤, _OGA를 전송하며, _OSA를 받은 OBU와 smart-phone은 재생준비 이후, 바로 연결을 시도한다. 촬영, 전송, 재생의 과정을 반복적으로 수행한다. 이는 _END message가 촬영하는 smart-phone 측에서 발생하거나, client smart-phone이 재생을 중단하여 socket이 닫힐 때까지 계속되는 동작을 나타낸다.

그림14는 On _IXX case Sequence Diagram 으로, 주위의 OBU로부터 _IXX message를 수신한 경우, 이를 smart-phone의 화면에 표시하여 주는 간단한 Activity의 sequence diagram이다. OBU측에서 WSM broadcast를 수신한 후 TCP/IP protocol로 smart-phone에 전달해주는 과정을 볼 수 있고, smart-phone에서는 이를 개별 Activity로 실행하여 화면에 잠시 표시해 준 뒤 종료되는 과정을 나타낸다.

그림15는 On_PSI case Sequence Diagram으로, 주기적으로 발생되는 _PSI message에 대한 저장, 전송과 처리, 그리고 활용에 대한 sequence diagram이다. 크게 두 가지의 작업으로 구분 할 수 있는데, 하나는 _PSI에 포함시킬 data를 OBU에서 주기적으로 발생시키고, 이를 자신의 정보로 저장하고, 다시 그 data를 WSMP를 통해 전달하는 과정과 그렇게 여러 OBU 로부터 수신되어 smart-phone이 저장하고 있는 data를 list에 반영하여 활용하는 과정을 나타낸다.

그림16은 스마트폰에 나타나는 화면을 나타낸 것으로 Capture1)은 메인화면, Capture2)는 차량리스트 화면, Capture3,4)는 재생준비 화면, Capture5는 녹화준비화면이고 Capture6)는 ID를 보여 주는 화면을 나타낸다.

Claims

차량통신장치인 OBU와 와이파이공유기가 접속되어 와이파이로 스마트폰과 무선랜 사용가능환경에서 스마트폰(또는 스마트패드, UMPC 등 스마트기기)을 사용하여 차량간통신(V2V)을 통해 실시간 교통상황정보를 동영상 및 멀티미디어데이터를 전송하거나 수신하여 교통정보를 확인하기 위한 방법
차량통신장치를 탑재한 차량이 도로 주행중 정체등의 현상으로 인해 도로교통상황을 확인하고자 할 때 스마트폰을 사용하여 주변 차량의 위치를 확인하여 상대방 스마트폰의 카메라를 작동시켜 그 곳의 교통상황을 실시간 동영상으로 모니터 할 수 있는 기술에 관한 것으로, GPS(Global Positioning System) , WAVE(Wireless Access in Vehicular Environment) OBU(On Board Unit), WIFI(와이파이) 및 스마트폰을 사용한 서비스 제공을 위한 알고리즘
스마트폰이 주행상태가 되면 주변의 차량통신장치와 통신하여 수신된 상대방 차량통신장치들을 수집 정리하여 스마트폰 화면상에 상대방의 ID, 위치, 주행속도, 방향, 내 차와의 이격거리 등을 화면에 표출하는 방법 및 차량의 주행속도에 따라 차량을 나타내는 아이콘의 색상을 식별하기 용이하게 차별화 하여 표출하는 방법
주행중 정체 발생시 전방의 위치한 차량의 상황정보를 선택적으로 요청하면 선택된 차량통신장치와 와이파이로 연결된 스마트폰과 통신하면서 스마트폰 카메라를 동작시켜 촬영한 동영상을 요청한 스마트폰사용자에게 전송하여 요청한 사용자의 스마트폰으로 실시간 동영상을 재생하는 방법
주행 중 교통상황정보를 자동으로 전송하거나 수신하는 모드로 설정해 놓았을 때 정해 놓은 속도 이하로 주행하는 차량은 차량통신장치와 스마트폰이 연동하여 스마트폰이 자동적으로 실시간 교통정보 동영상을 촬영하여 주변 주행차량을 위한 실시간 교통동영상을 방송하는 방법