2.1 마이크로그리드 통신 요구사항

마이크로그리드는 내부적으로 IED (Intelligent Electronic Device) 간 혹은 IED 와 MGMS 간에 데이터 송수신이 가능해야 한다. 이는 내부 사설네트워크로 구축되어 운영되므로 외부에서 마이크로그리드 내부에 있는 IED로 직접적인 접속이 불가하다.

마이크로그리드가 공용 인터넷망을 통해 DMS와 통신 시에 마이크로그리드 내에선 오직 MGMS만이 공용 인터넷망에 연결되어 통신을 할 수 있다. MGMS는 DMS입장에서 게이트웨이 역할을 수행하며, 유일하게 마이크로그리드에 대한 정보를 얻을 수 있는 노드로 구분한다. 이러한 MGMS노드들은 여러 지역으로 분포된 마이크로그리드 내에 위치해 있으며, 공용 인터넷망을 통해 데이터를 송수신한다.

2.2 IoT프로토콜 기반의 광대역 네트워크

마이크로그리드는 DMS와 통신 시에 IoT 프로토콜을 사용하여 통신을 수행할 수 있다. HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol)와 같이 연결지향형 client-server 기반의 통신프로토콜은 일반적으로 TCP에 기반한 전송계층의 사용으로 연결점이 많아지는 경우 데이터를 처리하는데 많은 시간이 소요되며, 이는 서버의 큰 부담이 된다. 반면, publish/subscribe 방식의 통신방식은 강한 연결성을 가지지 않지만, 메시지를 전송하는 송신 측이 수신하는 측에 대한 정보를 알지 못하더라도 송수신이 가능한 메시지 기반의 통신방식이다. publish/subscribe 방식의 통신은 송신 측과 수신 측을 분리함으로써 언제든 노드가 참여하는 즉시 통신이 가능해지며, 높은 확장성과 동적인 네트워크를 구성할 수 있게 된다. 이러한 이유로 분산된 환경에서의 마이크로그리드의 통신은 기존의 연결지향형 server-client 방식이 아닌 publish/subscribe 방식의 비동기적 통신방법이 적합할 것으로 여겨진다.

IoT프로토콜은 센서네트워크에 특화된 프로토콜답게 일 대 다, 다 대 다 통신방식을 지원하며, publish/subscribe 방식을 지원한다. 이러한 기능들을 지원하는 IoT 프로토콜들로 MQTT, XMPP, DDS 등이 있다⁽⁸⁾. 본 논문은 그중에서도 다수의 QoS와 Non-broker방식의 통신구조로 인해 single-point failure의 위험이 없는 DDS를 사용하여 마이크로그리드 운영을 위한 네트워크 구성을 제안한다.

MGMS는 내부적으로 IED들의 상태정보 및 제어를 위해 IEC 61850 프로토콜을 사용하고, 외부적으로는 DMS와 통신하기 위해 DDS를 사용하여 통신을 수행한다. 내, 외부적으로 서로 다른 프로토콜을 사용하여 통신하기 때문에 그림 2와 같은 듀얼 프로토콜스택을 필요로 한다.

MGMS는 마이크로그리드 내 필드 장비 및 IED들의 데이터를 MMS 프로토콜의 request/response, report 메시지를 통해 송·수신하며, client-server 방식을 따른다. 이 경우 IED들은 서버가 되고, MGMS는 클라이언트가 된다. IED들은 각 장비가 가지고 있는 데이터 모델에 해당 장비의 상태 혹은 제어데이터를 포함하고, IEC 61850 표준을 따라 정의된 service control block을 통해 클라이언트로 데이터를 제공한다.

그림. 2. MGMS 멀티플랫폼 프로토콜 스택

Fig. 2. MGMS multi-platform protocol stack

DMS가 MGMS로부터 마이크로그리드의 혹은 특정 IED의 상태정보 및 제어를 원하는 경우 MGMS는 MMS 프로토콜을 통해 수신한 데이터를 DMS가 디코딩할 수 있는 형태로 변환하는 과정을 거치게 되는데, IEC 61850-8-2 표준을 따라 정의된 메시지포맷으로 바꾸어 전송한다. 메시지포맷 변환에 대한 설명은 3장에서 자세히 설명한다. DMS로부터 요청받은 데이터를 MGMS에서 메시지포맷 변환한 후에 DDS를 사용하여 공용 인터넷망으로 응답할 데이터를 전송한다. DMS는 MGMS로부터 수신한 데이터를 디코딩 과정을 거쳐 응용프로그램으로 전달하고, 응용프로그램은 데이터를 사용자에게 제공한다.

2.3 DMS의 기능적 요구사항

DMS는 MGMS를 관리, 감독하는 상위시스템으로써 언제든 MGMS로의 접속이 가능해야 한다. MGMS를 통해 마이크로그리드의 상태정보뿐만 아니라 특정 IED의 제어가 가능해야 하므로 MGMS는 IED와 DMS 간의 연결점으로서 상시운영이 가능하다. DMS는 마이크로그리드내의 IED들을 직접 제어할 수 없지만, MGMS를 통해 간접적으로 제어명령을 전달할 수 있다. DMS가 마이크로그리드내의 특정 IED를 제어하기 위해 MGMS가 마이크로그리드내의 IED들의 리스트와 데이터모델을 DMS로 제공한다. MGMS가 관리하는 IED들의 목록을 수신한 DMS는 제어를 원하는 IED의 참조(Reference) 혹은 IED 식별자를 사용하여 제어를 원하는 데이터와 해당하는 제어 값을 MGMS로 송신한다. 제어 값을 수신한 MGMS는 사설네트워크를 통해 IED를 제어한다.

3.1 IEC 61850 서버

본 논문에서 제시하는 테스트베드에서는 IEC 61850 서버는 분산에너지자원 중 태양광발전장치기능을 수행하며, MGMS의 요청에서 따라 response 혹은 report 기능을 수행한다. 실제 태양광발전장치의 계측데이터를 제공하는 IED 서버와 유사한 환경에서 성능분석을 진행하기 위해 태양광 패널과 라즈베리파이로 IED 서버를 개발하였다. IED 서버는 센서로부터 데이터를 취득하면서 MGMS로부터 이벤트가 요청되는 경우 이를 처리해야 하므로 멀티스레드를 사용하여 병렬적으로 동작하도록 개발되었고, MGMS와의 MMS 통신을 위한 API로 SISCO사의 MMS-Lite를 사용하였다. 라즈베리파이에서 MMS-Lite는 IEC 61850 서버기능을 위해 사용되며, MGMS에선 IEC 61850 클라이언트기능을 위해 사용된다. MMS로 통신하기 위해선 논리노드(Logical Node)에 데이터 맵핑을 필요로 한다. 태양광발전장치 구성을 위한 논리노드는 IEC 61850-7-420 표준을 따라 STMP, MMET, MMDC로 구성하였다.

STMP는 발전장비 온도를 관리하는 데에 사용되고 적정수준 이상으로 온도가 높아질 시에 경고 기능을 수행할 때 사용된다. MMET는 센서 주변의 기상정보를 나타내는 데 사용되는 논리노드로 온도, 습도, 풍속 등의 데이터를 선택적으로 구성하여 사용할 수 있고, MMDC는 DC로 변환된 계측데이터 (전압, 전류, 전력)를 나타내기 위해 사용된다.

3.2 MGMS 멀티플랫폼

MGMS 멀티플랫폼이 다중 프로토콜스택을 가지기 위한 구현방법에 관하여 설명한다. 멀티플랫폼은 DDS와 IEC 61850 적용을 위한 MMS 프로토콜이 하나의 애플리케이션에 통합되어 동작한다.

3.2.1 DDS

OMG (Object Management Group)에서 제안하는 DDS는 publish/subscribe 모델의 실시간 데이터 분배가 가능한 서비스이다⁽⁹⁾. 다수의 송신자와 수신자가 참여하는 분산형 네트워크 환경에 적합하며, 함정전투체계, 병원, 전기통신분야 등에서 사용되고 있다. publish/subscribe 방식을 지원하므로 낮은 연결성을 가지고 있으며 다 대 다 통신방식에서 비용과 복잡도 줄일 수 있고, 이종 네트워크 환경에서도 적합하다는 특징이 있다^(10,11). DDS는 통신미들웨어로 분류되며, 응용프로그램과 운영체제 사이에 서비스를 제공하는 API로 개발에 사용되는 언어와 하드웨어에 독립적이다.

DDS는 DataWriter와 DataReader와 같이 통신에 관여된 7개의 개체가 존재하며, 개념적인 측면에서 publish/subscribe 구조는 다음 그림 3과 같다. Publisher 또는 Subscriber는 각각 다수의 DataWriter 혹은 DataReader를 포함한다. 같은 도메인 내에 Publisher 와 Subscriber는 혼재할 수 있으며 송신 및 수신 기능만을 담당하여 다양한 종류의 Topic 데이터를 송수신한다. 송수신자의 ip주소, 포트번호 등의 정보를 모르더라도 Domain ID와 Topic만 일치하면 언제든 통신할 수 있다. 그림 3에서 3개의 Topic과 2개의 도메인이 존재하여 각각 다른 도메인에 속한 Subscriber가 자신이 속한 도메인과 일치하는 Publisher의 데이터만을 수신하고 있음을 알 수 있다.

그림. 3. DDS 통신 구조

Fig. 3. DDS communication architecture

네트워크 환경과 사용자 요구조건을 충족시키기 위해 DDS 개체별로 QoS를 적용할 수 있다. QoS는 높은 신뢰성과 통신품질을 보장하며 1.4버전 기준 총 22가지를 보유하고 있다. 다양한 기능을 제공한다.

3.2.2 메시지형식

DDS는 IDL (Interface Definition Language)을 통해 메시지형식을 정의한다. IDL을 사용하여 메시지를 정의하면 어떠한 프로그래밍 언어에 종속적이지 않으며, 플랫폼과 독립적이므로 이식성이 높고, 서로 다른 플랫폼과 통신을 할 수 있다.

전력시스템에서 통신 상호운용성을 위해 IEC 61850은 공용 인터넷망 환경에서 비실시간 데이터교환방법에 관한 내용과 데이터를 IoT 프로토콜인 XMPP에 맵핑시켜 통신하는 방법에 관한 내용을 IEC 61850-8-2에서 다루고 있다⁽¹²⁾. XMPP는 스트림(Stream)기반의 통신방식을 가지며, 스트림이 사용하는 메시지 형식의 따라 message, iq(Info/Query), presence 스탠자를 스트림에 포함한다. message 스탠자는 메시지를 전달하는데 사용되며, 이메일과 유사한 형식을 가지고, iq 스탠자는 HTTP와 같이 요청/응답 메커니즘으로 동작하며, get, set, result, error의 4가지타입의 형식을 포함한다. presence 스탠자는 상대방의 접속유무, 부재중, 수신가능 등의 상태를 알리기 위해 사용된다.

그림. 4. IEC 61850-8-2 메시지형식⁽¹²⁾

Fig. 4. IEC 61850-8-2 message format⁽¹²⁾

XMPP가 XML을 기반으로 하는 IoT 프로토콜인 만큼 표준에서 정의하고 있는 메시지의 형태는 그림 4와 같이 XML 형태를 따르고 있다. 그림 4는 IEC 61850-8-2 메시지형식의 Application-Profile로 Application, Presentation, Session 계층들의 묶음을 의미한다. <userData> 엘리먼트 상위 부분은 보안과 세션연결에 대한 내용을 다루고 있으며 application 계층의 MMS 데이터는 <userData> 하위 부분에 포함이 된다⁽¹³⁾.

통신에서 사용되는 요청 타입에 따라 iq 스탠자를 사용할지, message 스탠자를 사용할지 결정되며, iq 스탠자의 경우 request/ response와 같이 비주기적 서비스인 solicited 메시지에 사용되고, message 스탠자의 경우 report와 같이 클라이언트의 요청이 없어도 주기적으로 메시지를 전송하는 unsolicited 메시지에 사용된다. 실제 메시지의 의미 있는 데이터는 <userData> 엘리먼트의 하위 부분부터 정의되므로 멀티플랫폼에서 메시지본문에 포함되는 내용 또한 그림 5와 같이 <userData> 엘리먼트의 하위 부분만을 포함한다.

그림 5의 예는 IEC 61850-8-2 표준에 따라 본문에 삽입된 내용이며, SOLAR01이라는 논리장치로부터 분산전원의 DC 데이터와 주변 온도를 요청한 내용에 대한 메시지이다. <DOMAIN-SPECIFIC> 엘리먼트 내의 <DOMAINID> 엘리먼트는 이러한 요청을 위한 논리장치의 이름과 논리노드의 레퍼런스 데이터를 표현하기 위해 사용된다.

그림. 5. 요청 메시지 페이로드

Fig. 5. Request message payload

3.2.3 MGMS 다중 플랫폼

공용망 통신을 위한 DDS 미들웨어로 OCI (Object Computing Inc.)에서 배포한 OpenDDS를 사용했으며 지원하는 언어는 JAVA와 C++을 지원하며, 본 연구에서는 MMS-Lite와의 호환성을 위해 C++를 사용하여 개발하였다.

그림. 6. 멀티플랫폼 시퀀스다이어그램

Fig. 6. Multi-platform sequence diagram

그림 6은 MGMS 멀티플랫폼이 DMS의 요청을 수행하는 데 있어 처리되는 시퀀스다이어그램을 나타낸다. MGMS가 DMS로부터 요청을 받으면 IEC 61850-8-2 표준을 따라 XML 형태의 메시지를 수신한다. 이후 MGMS는 의미 분석을 통해 DMS가 요청한 데이터를 XML 파서 (Parser)를 이용해 추출하고 IEC 61850 서버로 추출한 데이터를 레퍼런스 형태로 조합하여 재요청한다. 이후 요청한 데이터가 정당한 요청이면 IED 서버는 요청한 데이터에 대한 값 (Value)을 응답하고, 서버가 동작 중이지 않거나 정당한 요청이 아니라면 에러코드를 응답한다. MGMS가 IED 서버로부터 데이터를 성공적으로 취득했다면, XML 형태로 재조합하여 DMS의 응답을 수행한다. MGMS의 IEC 61850 클라이언트가 동작 중이지 않거나 IED 서버로부터 에러코드가 응답된 경우 DMS로 성공하지 못한 원인에 대한 에러코드를 응답한다.

공용 인터넷망에서의 통신은 스니핑(Sniffing) 이나 스푸핑 (Spoofing)과 같은 공격에 취약하므로 멀티 플랫폼에서 사용될 DDS미들웨어는 보안이 반드시 적용되어야 한다. OMG에서는 DDS가 사용할 수 있는 보안에 관한 표준문서를 정의하고 있다⁽¹³⁾. DDS는 참여자 탐색 시에 공개키 방식을 사용하며, 탐색이 완료된 이후엔 탐색에 사용한 공개키를 사용하여 Endpoints간에 비밀키를 교환하고, 교환한 비밀키를 사용하여 메시지를 암호화한다. DDS SPI는 DDS가 보안통신을 수행하는데 있어 사용되는 Authentication, Access Control, Crypto- graphic, Logging, Data Tagging 플러그인이 있으며, 이를 사용하여 DDS 미들웨어 레벨에서 암호방식 전달 시에 RSA (Rivest, Shamir, Adleman) 또는 DSA (Digital Signature Algorithm)를 사용할지, 메시지전송 시에 AES (Advanced Encryption Standard) 알고리즘 중 128bit 또는 256bit를 사용할지 사용자가 보안규칙을 정의하여 통신할 수 있다.

4.1 성능분석 환경

멀티플랫폼이 실제 공용 인터넷망 환경에서 타당성을 분석하기 위하여 개발된 테스트베드를 이용하여 검증을 진행하였다. 성능분석 시나리오는 DMS가 DDS를 사용해 MGMS에게로 태양광발전기의 전압, 전류의 계측데이터를 요청한 후 MGMS가 태양광 IED 서버로부터 얻은 계측데이터를 DMS에게로 응답하는 것을 100ms 간격으로 50만 번 시도하며, MGMS 1대와 DMS 1대가 1:1통신하는 것으로 가정한다. 성능분석을 진행하는 데 있어 필요한 장비와 네트워크를 다음 그림 7과 같이 구성하였다. MGMS역할을 하는 노트북은 KT회선에 연결되어 있으며, DMS역할을 하는 PC는 세종대학교 내 서버 실에 위치해 있다. 서로 다른 네트워크에 위치한 두 호스트 간의 네트워크 계층 hop수는 13 hop이다.

그림. 7. 네트워크 구성도

Fig. 7. Network configuration

태양광 패널과 라즈베리 파이를 태양광 IED 서버로 구성하고, IED 서버의 제어, 모니터링을 위한 MGMS와 DMS기능을 각각 다른 PC에 적재하여 네트워크 성능분석 환경을 구성하였다. 다음 표 1은 성능분석을 진행하는데 있어 사용된 장비사양을 나타낸다.

네트워크의 구성은 외부에서도 노트북PC와 통신을 할 수 있어야 하므로 KT 회선에 ipTIME 공유기를 연결하고 TwinIP를 사용하여 노트북PC의 MAC 주소에 공인 IP의 주소를 직접 부여하였다. 노트북PC와 라즈베리 간의 통신을 위해 라즈베리파이를 노트북PC가 연결된 공유기와 연결한 후 사설 IP를 부여하여 공유기 내에서만 통신할 수 있도록 구성하였다. 그림 8은 성능분석에 사용된 메시지의 패킷을 MGMS측에서 캡처한 화면이다. 성능분석에 사용된 메시지는 요청 시에 738 bytes, 응답 시에 458 bytes이다.

4.2 일반적인 트래픽 환경에서의 성능분석

DDS가 보유하고 있는 QoS 중 Reliability는 메시지전달의 신뢰성 여부를 지정할 때의 사용 된다. DDS는 기본적으로 전송계층에서 UDP를 사용하여 통신하므로 패킷손실이 발생하는 경우 재전송을 보장하지 않는다. Reliability가 RELIABLE로 설정된 경우 UDP 계층에서도 패킷손실이 발생하면 유실된 패킷을 재전송하여 신뢰성을 보장한다. 이와 반대로 BEST_ EFFORT로 설정된 경우 RELIABLE처럼 패킷손실 시에 재전송을 보장하지 않지만, CPU 및 네트워크의 자원을 효율적으로 사용하여 통신할 수 있다는 장점이 있다⁽¹⁴⁾.

이 절은 부하 트래픽이 없는 일반적인 트래픽 통신환경에서의 Reliability QoS 설정별, 보안모듈설정별 비교결과를 다룬다. Reliability QoS를 각각 BEST_EFFORT, RELIABLE로 설정하고, Deadline QoS를 1000ms 로 설정하여 DMS나 MGMS 양 측의 메시지가 허용범위 내에 도착하는가를 알아보았다. Deadline QoS 1000ms 설정 근거는 비실시간 계통운영을 위한 통신속도 요구조건을 1초 이내로 정의하고 있는 IEC 61850-5 표준의 요구조건을 준수하였다⁽¹⁵⁾. 또한, DDS보안을 적용한 경우와의 통신성능을 비교하기 위해 위와 동일한 네트워크 환경에서 Reliability QoS를 바꿔가며 성능분석을 진행하였고, 암호화방식은 RSA-2048로 생성된 인증서를 사용하여 AES-256방식으로 생성한 키를 전달한 후, 메시지 송수신시에 전달된 암호키를 사용하여 암호화/복호화를 수행하였다.

그림. 8. DDS를 사용한 DMS와 MGMS 간의 패킷

Fig. 8. Packet captured between DMS and MGMS

비교항목은 DMS가 MGMS로부터 계측데이터를 얻기까지의 RTT (Round Trip Time)의 평균, 최댓값, 분산, 표준편차, 손실률, 1초 이상의 응답률, DeadLine QoS 위반율 등을 비교한다. 매 성능분석은 DMS가 MGMS로부터 주기적인 요청을 보낸 뒤 응답을 받는 request/response의 메시지를 송수신한 결과를 보인다. 표 2는 Reliability QoS 설정과 보안모듈 설정별 지연시간에 대한 관측값을 나타내었다.

성능분석 결과, DDS는 일반적인 환경에서 Reliability QoS를 RELIABLE로 설정한 경우 최대 1,700ms의 RTT와 0%의 손실률, 0.004%의 1초 이상 응답률을 보인 반면, BEST_EFFORT로 설정한 경우의 최대 61ms의 RTT와 0.001%의 손실률을 보였다. Reliability QoS를 RELIABLE로 설정함에 따라 패킷손실이 발생한 경우 재전송을 수행하여 지연시간도 늘어났음을 확인할 수 있었으며, Reliability QoS가 RELIABLE로 설정되었을 때 지연시간이 늘어남에 따라 응답시간이 1초 이상 지연되는 경우가 발생하였지만, 보안이 적용되지 않은 경우와 적용된 경우 모두 RELIABLE로 설정되었을 때 패킷손실이 발생하지 않았음을 확인할 수 있었다. 또한, DDS 보안모듈설정은 공용 인터넷망 환경에서 통신의 성능에 큰 영향을 주지 않는 것으로 보인다.

4.3 트래픽이 발생하는 환경에서의 성능분석

네트워크에 부하가 발생하는 상황에서의 성능을 측정하기 위해 의도적으로 트래픽을 발생시킨 후, 위 4.2절과 동일한 QoS 설정으로 성능분석을 진행하였다. DMS가 MGMS와 통신하는 동안 FTP를 통해 파일을 전송받으면서, request/response의 메시지를 송수신한 결과를 보인다. FTP 전송속도는 512KB/s로 Reliability QoS를 RELIABLE로 설정했을 때와 BEST_EFFORT로 설정했을 때, 보안모듈을 적용하지 않았을 때와 적용했을 때 모두 동일한 환경에서 진행되었다. FTP 전송속도 512KB/s의 설정근거는 위와 같은 성능분석 환경에서 DMS가 최대 마이크로그리드 40기 이상의 데이터를 끊임없이 송수신할 수 있는 환경이며 이는 분산된 환경에서 마이크로그리드를 관리하는 데 충분할 것으로 여겨진다.

다음 표 3은 Reliability QoS, 보안모듈 설정별 지연시간에 대한 관측값과 분석에 사용된 그래프이다. 트래픽이 발생한 환경에서 RELIABLE의 경우 일반적인 환경에 비해 QoS 설정별 편차가 더 큰 것으로 나타났다. RELIABLE RTT는 매 성능분석시나리오마다 최대 지연시간의 차이가 적은 BEST_ EFFORT RTT에 비해 많은 편차가 있는 것으로 확인되었으며, 일반적인 환경에서보다 약 15배 더 높은 평균치를 보였다. 일반적인 환경에서의 성능분석과 마찬가지로 보안모듈을 적용한 경우와 적용하지 않았을 때의 편차는 크지 않은 것으로 보인다.

네트워크의 부하가 주어진 환경에서 RELIABLE은 최대 4.2초의 RTT와 0%의 손실, 6.6%의 1초 이상 응답률을 보였고, BEST_EFFORT는 최대 704ms 지연시간과 2.2%의 손실률을 보였다. 이는 Reliability QoS의 재전송 메커니즘으로 인한 결과이며 BEST_EFFORT로 설정하였을 때 수신 측이 메시지를 올바르게 수신하였는가를 확인하지 않기 때문에 빠른 전송이 가능하다. BEST_EFFORT의 1초 이상 응답률과 패킷손실률을 비교하였을 때 BEST_EFFORT를 사용하여 지연시간을 줄이고, 일정 시간 내에 수신되지 않으면 응용계층에 제한시간을 초과하였음을 알려주도록 설계하여야한다. 손실이 발생했을때는 수신측에서 인지 할 수 없으나 1.2%의 손실률은 전체 데이터에 비하여 작은 부분을 차지하기 때문에 실제 통신환경에서는 무시할 수 있는 정도의 값으로 고려할 수 있다. 때문에 BEST_EFFORT의 메시지 지연시간은 마이크로그리드의 비실시간 제어와 모니터링 기능을 수행하기에 충분할 것으로 여겨진다.