[카테고리:] 미분류

IEC 61850은 변전소의 모니터링, 제어 등을 위한 표준화된 통신기술로써, 변전소에 대한 재원을 기술하는 언어인 SCL(Substation Configuration description Language)을 정의하고 있습니다. XML 기반이므로 쉽게 읽을 수 있고 쓸 수 있습니다.

아래는 SCL에 대한 코드 예인데요.

위의 SCL에 대해 기술된 변전소의 재원은 E1-Q1이라는 이름의 Bay에서 차단기 QA1과 단로기 QB1은 모두 L1이라는 노드에 연결되어 있다는 내용입니다. QA1이 차단기라는 것은 CBR Type 속성을 갖기 때문이고, QB1이 단로기라는 것은 DIS Type 속성을 갖기 때문입니다.

이 글은 차세대전력기술연구센터의 김태완님이 작성한 IEC 61850에 대한 소개에서 가져왔습니다.

좌표를 주소로 변환해 주는 툴인 Geocoder-Xr은 다음, 네이버, 구글의 좌표변환 API를 사용합니다. 간혹 Geocoder-Xr에서 변환이 않된다는 분들이 계셨고, 대부분의 이유는 OpenAPI Key 문제입니다. 기본적으로 Geocoder-Xr에 등록된 Key에 대한 사용량 초과로 인해 발생하는 것으로, 이 문제를 해결하기 위해서는 직접 사용자 개인의 OpenAPI Key를 발급받아 등록을 하시면 됩니다. Geocoder-Xr에서 이 OpenAPI 키를 등록하는 방법은 아래 화면을 참고하시기 바랍니다.

보시는 것처럼 먼저 화면 좌하단의 OpenAPI Key 관리 버튼을 클릭해 표시되는 대화상자에서 자신의 OpenAPI Key를 입력하시면 됩니다. 그럼 이 대화상에서 입력할 수 있는 OpenAPI Key를 발급받기 위해서 다음과 네이버에 대해 간단히 설명을 드리겠습니다.

먼저 기본적으로 다음과 네이버 모두 자신의 ID로 로그인이 되어 있다는 가정 하에 설명합니다. 먼저 다음(Daum)의 경우는 다음 화면을 통해 OpenAPI Key를 발급받을 수 있습니다. 화면을 클릭하면 전체 이미지를 볼 수 있으므로 정확한 URL을 볼 수 있습니다.

그리고 네이버에서 OpenAPI Key를 발급받기 위해서는 아래의 화면을 참고하시기 바랍니다. 화면을 클릭하면 큰 화면으로 표시되어 정확한 URL을 볼 수 있습니다.

작년에 모바일 GIS 엔진인 블랙포인트의 저작권 침해와 관련하여 법정다툼이 있었습니다. 이와 관련하여 다음과 같은 글을 게시한 적이 있습니다.

이에 대한 법정 다툼에 대한 판결이 2014년 1월 23일에 다음과 같이 있었습니다.

2014년부터는 관공서에서 의무적으로 도로명 주소를 사용해야 합니다. 기존의 익숙한 주소체계가 아닌 도로명 주소가 처음에는 어색하고 불편할 수 밖에 없습니다. 하지만 이 도로명 주소에는 분명 좋은 장점이 있습니다. 특히 도로명을 알고 있으면 보다 쉽게 내가 가고자 하는 목적지에 찾아갈 수 있다는 장점이 있습니다. 이러한 도로명의 장점을 십분 활용하기 위해 도로명 주소 나침반 앱을 릴리즈하였습니다. 가고자 하는 목적지의 ‘도로명 주소’만 알면 쉽고 빠르게 찾아갈 수 있는 앱입니다.

구글의 플레이스토어에서 ‘도로명 주소 나침반’이라고 검색해 사용해 보시기 바랍니다. 도로명 주소 나침반의 기능은 다음과 같습니다.

• 현재 내 위치에서 가장 가까운 도로명 주소와 함께 나침반을 표시해 줌
• 도로명 주소로 지정된 목적지까지의 선을 참조하여 걷다보면 빠르고 정확하게 목적지에 도착
• 내가 이동한 경로를 kml로 저장할 수 있는 GPS Logger 기능

도로명 데이터는 안전행정부에서 제공하는 새주소 데이터를 사용하였습니다. GIS 분야에서 일을 함에도 길치인지라 늘 어디갈때 해매고는 하는 제가 직접 이 앱을 이용해 재밌고 정확하게 목적지를 찾아갈 수 있었습니다.

보안에 대한 이슈로 인해 특정 서버에 어떤 요청을 해도 응답을 하지 않는 다음 그림과 같은 상황이 있습니다. 이런 경우는 방확벽에 막혀 있거나.. 서버에서 특정 IP에 대해서 응답을 하지 않는 경우입니다.

이러한 상황이 발생하는 이유는 서버단에서 클라이언트인 사용자를 차단하기 때문입니다. 이럴 경우 서버가 차단하지 않는 별도의 서버로 우회하여 사용자가 요청에 대한 원하는 결과를 받을 수 있는데요. 이러한 구성은 다음과 같습니다.

즉, 사용자(User)가 직접적으로 Server에 요청을 날리지 않고 Server가 안전하다고 판단되는 Proxy Server를 통해 간접적으로 요청을 날리면 Proxy Server는 User 대신 실제 Server에게 요청을 날리고 그 결과를 대신 받아 다시 User에게 날려주는 것 입니다.

이게 상당히 쓸모가 있습니다. 저 같은 경우 어떤 프로젝트를 진행하면서 실제 서버가 특정한 장소 안에서만 접근할 수 있음으로 해서.. 결국 작업을 하려면 지정된 장소에 가서 작업을 해야할 상황이였는데요. 이에 대해서 Proxy Server를 두고 실제 서버에서 Proxy Server에 대해서 방화벽 차단을 해제해줄 것을 요청한뒤 어떠한 장소에서든 이 Proxy Server를 통해 실제 서버에 접근하여 작업을 할 수 있었습니다.

그 당시 제가 사용했던 Proxy Server는 GeoService-Xr이라는 공간서버였습니다. GeroService-Xr은 기본적으로 Proxy Server 기능을 가지고 있습니다.

아래의 코드는 실제 서버의 IP가 44.44.44.44이고 Proxy Server의 IP는 77.77.77.77일때를 예로 든 경우입니다. 즉, 저와 같은 경우 GeoService-Xr이 77.77.77.77에 설치되어 있는 것입니다.

var svc:XrRequestURLProxy = new XrRequestURLProxy("77.77.77.77", 
    onRequestComplete, onRequestError);
var url:String = "http://44.44.44.44/doAction.jsp";
var queryString:String = "param=100";
svc.run({url:url, queryString:queryString});

호출이 성공적으로 완료되면 onRequestComplete 함수가 호출되고 실패하면 onRequestError 함수가 호출됩니다. onRequestComplete 함수는 다음과 같은 형태입니다.

private function onRequestComplete(result:String):void
{
    var obj:Object = JSON.parse(result);
    //..
}

위의 코드는 요청 결과가 JSON 형태일 경우에 대한 예입니다. 그리고 onRequestError 함수는 다음과 같은 형태입니다.

private function onRequestError():void
{
    //..
}

이상으로 프록시 서버에 대한 간단한 설명과 저와 같은 상황에서 어떤식으로 프록시 서버를 활용했지에 대한 예 였습니다.