1 changed files with 3 additions and 139 deletions
Split View
Diff Options
-
+3 -139readme.md
+ 3
- 139
readme.md
View File
| @ -1,142 +1,6 @@ | |||
| SNITS_simulation | |||
| ("SNITS_RealTimeSignals"의 readme 파일을 그대로 복사함) | |||
| "SNITS_RealTimeSignals"라는 repo를 쓰고 있었으나 다음과 같은 이유로 새 repo를 만들었음. | |||
| --- | |||
| **목차** | |||
| - [1. 개요](#1-개요) | |||
| - [1.1. 네트워크 구축](#11-네트워크-구축) | |||
| - [1.2. 데이터 수령](#12-데이터-수령) | |||
| - [1.3. 신호 생성](#13-신호-생성) | |||
| - [1.3.1. 데이터 전처리](#131-데이터-전처리) | |||
| - [1.3.2. 신호생성 (`dict`)](#132-신호생성-dict) | |||
| - [1.3.3. 신호파일 생성 (`SN.tll.xml`)](#133-신호파일-생성-sntllxml) | |||
| - [1.4. 시뮬레이션](#14-시뮬레이션) | |||
| - [2. 파일트리](#2-파일트리) | |||
| --- | |||
| # 1. 개요 | |||
| 단위시간마다 신호정보를 생성하고 이를 통해 SUMO로 시뮬레이션하는 프로젝트입니다. | |||
| 이것은 SNITS(성남 지능형 교통체계, Seong-nam Intelligent Transport System)의 일환입니다. | |||
| 다음은 상세한 내용입니다. | |||
| ## 1.1. 네트워크 구축 | |||
| 모든 것에 앞서서 네트워크 파일이 구축되어 있어야 합니다. | |||
| 네트워크 파일은 `[filename].net.xml`와 같은 형태의 파일명을 가집니다. | |||
| ## 1.2. 데이터 수령 | |||
| tiberoDB로부터 데이터(테이블)들을 수령받습니다. | |||
| - 수령받아야 하는 핵심적인 테이블들은 다음의 세 종류입니다. | |||
| - 하루 단위로 현시구성 테이블을 받습니다. | |||
| - 이 테이블에는 각각의 교차로에 대하여 (현시, 링)이 주어졌을 때 어떤 이동류가 할당되어 있는지, 그 이동류에 대한 녹색시간, 황색시간은 얼마인지 등에 대한 정보가 담겨있습니다. | |||
| - 현재(2023. 11. 3) 기준으로 이 테이블는 `SNITS_INT\S_INT_PHASE_CONFIG`에 담겨있습니다. | |||
| - 하루 단위로 신호계획 테이블를 받습니다. | |||
| - 신호계획 테이블은 TOD(time of day) 방식의 자료로 각 시간대마다 어떤 프로그램을 운영할 것인지, 각 프로그램은 각 교차로마다 어떤 이동류 조합을 어떻게 운용할 지에 대한 전반적인 정보를 포함합니다. | |||
| - 현재 기준으로 이 테이블은 `SNITS_INT\SNITS_INT_TPLAN`에 담겨있습니다. | |||
| 그 외에 그룹 일계획, 그룹주간계획이 이 테이블을 보완할 수 있고, 연동과 관련된 테이블들도 이 테이블를 보완할 수 있습니다. | |||
| - 단순한 현시(non-overlapped phase)에 대해서뿐만 아니라 오버랩현시(overlapped phase)에 대해서도 신호계획이 잘 특정되어 있어야 합니다. 또한, 직진과 좌회전만 고려하는 것이 아니라 유턴 신호 정보와 비보호 좌회전도 함께 고려될 필요가 있습니다. | |||
| - 단위시간마다 신호이력 테이블을 받습니다. | |||
| - 여기에서 단위시간이란 5분이 될 수도 있고, 주기가 될 수도 있고, 현시간격이 될 수도 있습니다. | |||
| 이때 신호이력이란, 실제로 각각의 교차로들이 매시간마다 어떻게 신호를 등화했는지를 나타냅니다. | |||
| - (수정 여지 있음) 한가지 이슈는 신호이력 정보가 정확하지 않을 수 있다는 점입니다. | |||
| 신호를 만들어낼 때에는 기본적으로 신호이력을 기반으로 만들어야 하지만, 신호이력에 문제가 있어보이는 경우에는 신호계획에 기반하여 신호를 생성해야 합니다. | |||
| - 현재 기준으로 이 테이블은 `SNITS_INT\S_TOD_HIS`에 담겨있습니다. | |||
| - 이 세 형식의 테이블를 수령받는 방식은 다음의 두 가지입니다. | |||
| - GUI 툴인 DBeaver를 통해 데이터를 수령받을 수 있습니다. | |||
| 이 방법은 간단히 데이터를 열람하는 데 효과적입니다. | |||
| 하지만, 경·위도의 좌표가 정수로 표출되는 등의 단점이 있습니다. | |||
| - 파이썬 pyodbc 패키지를 활용하여 데이터를 수령받을 수 있습니다. | |||
| - `Scripts\fetch_tables_all.py`를 실행하면 `SNITS`, `SNITS_IF`, `SNITS_INT` 스키마에 속한 모든 테이블을 받아옵니다. | |||
| 이 스크립트가 실행되는 데 걸리는 시간은 약 7분입니다. | |||
| - `Scripts\fetch_tables_nec.py`를 실행하면 꼭 필요한 테이블들만 받아옵니다. | |||
| 이 스크립트가 실행되는 데 걸리는 시간은 약 1.2초입니다. | |||
| ## 1.3. 신호 생성 | |||
| - 이 데이터로부터 신호를 만들어냅니다. | |||
| 만들어내는 신호는 일반신호와 유턴신호, 그리고 비보호 좌회전 신호입니다. | |||
| - 신호생성 스크립트는 `.\Scripts\RealTimeSignals.py`에 담겨있습니다. | |||
| 이 스크립트에 `RealTimeSignals`라는 클래스가 정의되며 다음의 세 단계를 거치게 됩니다. | |||
| - 데이터 전처리 | |||
| - 신호 생성 | |||
| - 신호 파일 생성 | |||
| <!-- 각각의 단계는 세 개의 method로서 정의됩니다. --> | |||
| 다음은 세 단계에 대한 설명입니다. | |||
| ### 1.3.1. 데이터 전처리 | |||
| - 테이블들을 불러와 `pd.DataFrame`형태로 저장합니다. | |||
| 각각의 컬럼들을 어떤 dtype으로 저장할 지에 대한 이슈가 있고, 이를 위해 별도의 함수를 만들 필요도 있습니다. | |||
| - 각각의 테이블들에 대한 무결성 검사를 진행합니다. | |||
| - 데이터들을 적당히 합치고 필요없는 부분을 제거하고 하면서 세 종류의 `pd.DataFrame`을 얻어냅니다. | |||
| - 신호 현시 정보 (`signals`) | |||
| - 신호 계획 (`plans`) | |||
| - 신호 이력 (`history`) | |||
| ### 1.3.2. 신호생성 (`dict`) | |||
| - 세 개의 `pd.DataFrame`을 가지고 `programs`라는 객체를 만들어냅니다. | |||
| - `programs`는 딕셔너리로서, `(node_id, program_id)`가 주어지면 `program`에 대응시킵니다. | |||
| 또 `program`은 그 자체로 딕셔너리인데, `(A_no, B_no, color)`가 주어지면 `signal`에 대응시킵니다. | |||
| 이때, `signal`은 문자 `'g', 'G', 'r', 'y`가 유한 개 나열된 문자열입니다. | |||
| `signal`의 예시는 `gGGgrgrgrr` 같은 것이 될 수 있습니다. | |||
| - 정리하면, `programs`는 딕셔너리의 딕셔너리이며, 이 객체가 잘 생성되기만 하면, 각 프로그램에 대한 모든 신호를 제대로 만들어낸 셈이니다. | |||
| ### 1.3.3. 신호파일 생성 (`SN.tll.xml`) | |||
| - `programs`를 통해 신호파일을 만들어냅니다. | |||
| - 신호정보의 최종 형태는 xml 파일이어야 합니다. | |||
| `[filename].tll.xml`, `[filename].add.xml`의 형태의 파일이 생성됩니다. | |||
| - `[filename].tll.xml`에는 각 교차로별, 각 시간대별 신호프로그램을 기록됩니다. | |||
| 만들어진 두 신호파일들 중 주요 신호파일입니다. | |||
| - `[filename].add.xml`는 소위 '스위치 파일'이라고 불리는 것 같습니다. | |||
| 각각의 신호프로그램을 어떤 offset을 통해 적용할지 특정합니다. | |||
| ## 1.4. 시뮬레이션 | |||
| - 시뮬레이션을 위해서는 `[filename].rou.xml`와 같은 형태의 통행배정 파일이 있어야 합니다. | |||
| - `sumo-gui -n [filename].net.xml -r [filename].rou.xml -a [filename].tll.xml,[filename].add.xml` 와 같은 명령어를 prompt에 입력하여 사용하여 SUMO를 통한 시뮬레이션을 진행합니다. | |||
| # 2. 파일트리 | |||
| SNITS_RealTimeSignals는 다음과 같은 하위폴더들을 가집니다. | |||
| 각각의 하위폴더명은 rts(가상환경 폴더)를 제외하면 첫글자가 대문자가 됨을 원칙으로 합니다. | |||
| - `Analysis` : 데이터의 분석 결과나 중간 결과물, 그래프 등을 저장하는 폴더입니다. | |||
| - `Archives` : 이전 버전의 사용하지 않는 코드, 데이터 등을 보관하기 위한 폴더입니다. | |||
| 프로젝트의 이전 상태를 참조하거나 백업하기 위해 사용될 수 있습니다. | |||
| - `Data` : 사용될 데이터를 보관하는 폴더입니다. | |||
| - `sumo` : 구축해놓은 네트워크들이 담기는 폴더입니다. | |||
| - `tiberoDB` : DB에서 받은 테이블들이 담기는 폴더입니다. | |||
| - `tables_all` : DB에서 가져올 수 있는 데이터 중 `SNITS`, `SNITS_IF`, `SNITS_INT` 스키마에 포함된 모든 테이블이 이곳에 저장됩니다. | |||
| - `tables_nec` : 신호생성에 꼭 필요한 테이블들이 이곳에 저장됩니다. | |||
| - `int2node.json` : 교차로와 노드를 대응시키는 json파일입니다. | |||
| - `link2edge.json` : 링크와 엣지를 대응시키는 json파일입니다. | |||
| - `Draft` : 성남시 DB 데이터를 수령받기 전에 임시 데이터들을 만들고 코드를 만들어놓은 폴더입니다. | |||
| [박산하 과장님의 작업물](http://git.uinetworks.kr/TransportationResearchHeadquarters/SmartTransportationSystem)들을 기반으로 합니다. | |||
| - `Reports` : 분석 결과나 리포트, 만들어낸 문서(document)들을 넣기 위한 폴더입니다. | |||
| - `rts` : 파이썬 가상환경 폴더입니다. | |||
| `virtualenv`로 만든 가상환경입니다. | |||
| - `Scripts` : 실행가능한 스크립트, 코드를 저장합니다. | |||
| 데이터를 가져오는(fetch) 스크립트, 신호를 생성하는 스크립트 등이 담기게 됩니다. | |||
| - `credentials.json` : DB에 테이블 호출시 필요한 접속정보 (id, pw 등)가 담겨있습니다. | |||
| - `fetch_tables_all.py` : DB에서 `SNITS`, `SNITS_IF`, `SNITS_INT` 스키마에 해당하는 모든 테이블들을 `.\Data\tiberoDB\tables_all`에 저장합니다. | |||
| - `fetch_tables_nec.py` : DB에서 신호 생성과 관련된 테이블들을 `.\Data\tiberoDB\tables_nec`에 저장합니다. | |||
| - `RealTimeSignals.py` : 신호파일을 생성하는 스크립트입니다. | |||
| --- | |||
| <!-- <img src="Reports\1102_figure\1102_figure.png" width="600" height="400"> --> | |||
| <!-- <img src="https://i.imgur.com/ufxHLup.png" width="600" height="400"> --> | |||
|  | |||
| - 처음에 불러와지는 table의 형식이 맞지 않을 수 있다. 테이블 정의서를 작성하고 이를 기반으로 코드가 작성되어야 한다. | |||
| - 이전 repo는 너무 복잡했다. 꼭 필요한 것들만 추려서 구성할 필요가 있다. | |||