KR20180008820A - 태양광 발전의 모니터링 시스템 및 그 방법 - Google Patents

Abstract

본 발명은 메타모델을 기반으로 서로 다른 종류의 프로토콜을 사용하는 모니터링 시스템 사이의 데이터 통합을 가능하게 함으로 인하여 기존 레가시 시스템과의 호환성을 향상시키며, 데이터를 처리할 수 있는 코드를 자동으로 생성하여 생성된 코드를 통해서 프로토콜을 처리할 수 있는 프로그램 또한 자동으로 생성하므로 프로토콜을 잘 모르는 사용자도 쉽게 장치들을 연결할 수 있는 태양광 발전의 모니터링 시스템 및 그 방법으로써, 지역별로 분산 설치된 복수개의 태양광 발전 설비와 상기 태양광 발전 설비를 통합 관리하는 통합서버를 이용하는 태양광 발전의 모니터링 방법에 있어서, 상기 복수개의 태양광 발전 설비와 상기 통합서버 모두에 적용하는 통합 통신 프로토콜을 생성하는 단계는, 수집된 데이터를 통합서버로 제공하기 위해 상기 각각의 태양광 발전 설비에서 개별적으로 사용하는 통신 프로토콜에 대하여 메타모델을 기반으로 개별적으로 모델링하는 단계; 상기 메타모델을 기반으로 개별적으로 모델링 된 통신 프로토콜을 코드로 생성하는 단계; 및 상기 생성된 코드를 상기 통합서버에 설계된 통합 메타모델에 매핑하는 단계를 포함하는 것을 특징으로 한다.

Description

태양광 발전의 모니터링 시스템 및 그 방법{The Monitoring System for Photovoltaic Power Generation and the Method Thereof}

본 발명은 태양광 발전의 모니터링 시스템 및 그 방법에 관한 것으로써, 특히 서로 다른 종류의 통신 프로토콜을 사용하는 서버 사이의 호환이 가능하도록 메타모델을 기반으로 데이터를 통합하는 태양광 발전의 모니터링 시스템 및 그 방법에 관한 것이다.

최근 국제사회는 세계 인구의 지속적인 증가와 유가 불안, 한정된 자원으로 에너지 고갈의 문제에 직면해 있어 신재생에너지에 대한 관심이 높아지고 있다.

신재생에너지는 연료전지, 수소, 석탄액화, 가스와 같은 신에너지와 태양광, 태양열, 바이오, 풍력, 수력, 해양, 지열과 같은 재생에너지를 통틀어 말하는 것으로써 기존의 화석연료를 변환시켜 이용하거나 햇빛, 물, 지열, 강수, 생물유기체 등을 포함하여 재생 가능한 에너지를 변환시켜 이용하는 에너지를 말한다.

특히, 태양광의 모듈 가격이 하락하고 태양광 에너지 기술의 발전으로 효율이 높아져 경제성이 확보되었기 때문에 신재생에너지 중 태양광 발전이 주목 받고 있다.

하지만, 태양광 발전은 에너지를 전기로 저장하기 때문에 화재의 위험이 있고, 구조물의 크기가 크기 때문에 자연재해로 인한 구조물 파손시 인명피해가 발생할 수 있다. 또한, 태양광 발전은 햇빛 등의 기후변화에 따라 전력생산량이 급변하기 때문에 효율적인 발전율을 위해서는 지속적인 관리가 필요하다. 한국에서는 의무적으로 태양광 발전 설비의 에너지 생산량 및 가동현황과 이용률 향상 등을 위한 통합모니터링시스템을 서비스하고 있으나, 읍/면/동 단위의 발전 설비들은 관리되지 않는 경우가 많다. 또한, 태양광 에너지 관련 설비들은 유지보수 기간이 끝나면 운용할 수 없어 방치되거나, 개발사 및 시공사가 도산하거나 국내 지사를 철수한 경우, 더 이상의 기술적 지원과 유지보수 등을 수행할 수 없게 된다.

이와 같이 태양광 발전 시스템의 유지, 보수 및 관리를 위한 개발이 최근에 활발하게 이루어지고 있는데, 예를 들어 한국 등록특허 제 10-1415163 호(이하, "특허문헌 1"이라함.)는 태양광 발전 모니터링 시스템을 개시하고 있다.

상기 특허문헌 1은 각 지역에 설치된 태양광 발전시스템의 발전 형황을 네트워크를 통해 전달받아 실시간으로 모니터링하여 유지 관리를 원활하게 하도록 한 태양광 발전 모니터링 시스템에 관한 것으로서, 태양 에너지를 전기 에너지로 변환하여 출력하는 태양전지모듈을 포함하여 이루어진 복수개의 태양광 발전부와, 상기 각 태양광 발전부에 설치되는 태양광 발전 측정부와, 상기 태양광 발전 측정부에서 측정된 각종 정보를 네트워크를 통해 전달받아 모니터링하는 태양광 발전 모니터링부를 포함하여 구성되는 것을 특징으로 한다.

하지만, 상기 특허문헌 1은 네트워크를 통한 모니터링으로써, 상기 태양광 발전부와 발전 측정부 사이에서 사용되는 프로토콜의 종류가 상이할 수 있다. 이러한 경우, 이종의 프로토콜을 호환하거나 통합하는 방법에 관한 기재는 상기 특허문헌 1에 기재되어 있지 않다.

특허문헌 1 : 한국등록특허 제 10-1415163 호

없음

본 발명은 상기와 같은 종래기술의 문제점을 감안한 것으로, 메타모델을 기반으로 서로 다른 종류의 프로토콜을 사용하는 모니터링 시스템 사이의 데이터 통합을 가능하게 하여 기존 레가시 시스템과의 호환성을 향상시킬 수 있다.

또한, 본 발명은 데이터를 처리할 수 있는 코드를 자동으로 생성하여, 생성된 코드를 통해서 프로토콜을 처리할 수 있는 프로그램 또한 자동으로 생성되어 프로토콜을 잘 모르는 사용자도 쉽게 장치들을 연결할 수 있다.

본 발명에 의한 태양광 발전의 모니터링 방법은 지역별로 분산 설치된 복수개의 태양광 발전 설비와 상기 태양광 발전 설비를 통합 관리하는 통합서버를 이용하는 태양광 발전의 모니터링 방법에 있어서, 상기 복수개의 태양광 발전 설비와 상기 통합서버 모두에 적용하는 통합 통신 프로토콜을 생성하는 단계는, 각각의 태양광 발전설비에서 수집된 모니터링 데이터를 통합서버로 제공하기 위해, 상기 각각의 태양광 발전 설비에서 개별적으로 사용하는 이종 통신 프로토콜에 대해 메타모델을 기반으로 개별적으로 모델링하는 프로토콜 모델링 단계; 상기 메타모델을 기반으로 개별적으로 모델링된 통신 프로토콜을 상기 각각의 태양광 발전 설비의 이종 프로토콜의 해석이 가능한 프로그램 코드로 자동 생성하는 코드 생성 단계; 및 상기 생성된 프로그램 코드를 이용하여 상기 수집된 모니터링 데이터를 상기 통합서버에 설계된 통합 메타모델의 엘리먼트와 연결하여 매핑하는 통합 메타모델 매핑 단계;를 포함하며, 상기 프로토콜 모델링 단계는, 모델의 이름 정보를 입력받는 최상위 노드에 전송 패킷(SendPacket)과 수신 패킷(RecvPacket)을 연결하고, 상기 패킷들(SendPacket, RecvPacket)에는 패킷 내의 Type 종류(Start, Header, Command, Data, ParityBit, End)에 따라 분류되는 두 Type(SendType, RecvType)을 각각 연결한 트리 형태의 메타모델을 기반으로 하여 패킷 단위로 모델링하되, 사용자 인터페이스를 통해 블록 엘리먼트에 데이터의 종류와 크기를 사용자가 기입하되, 상기 이종 통신 프로토콜의 데이터 순서에 맞추어 블록 엘리먼트를 트리 형태로 기입하고, 사용자 기입 후, 모델링 프로그램이 트리 형태의 배치 순서에 따라 자동 처리하여 XML 형태로 저장하는 것을 특징으로 한다.

또한, 상기 전송 패킷(SendPacket)은 패킷 내의 Type 종류 중 코어 패킷(CoreType)에 해당하는 Start, ParityBit, End 뿐만 아니라 Command를 가지고, 상기 수신 패킷(RecvPacket)은 패킷 내의 Type 종류 중 코어 패킷(CoreType)에 해당하는 Start, ParityBit, End 뿐만 아니라 Header, Data를 가지며, 상기 Header, Data 각각에 대해 사용자 인터페이스를 통해 NameElement 정보로서 이름과 데이터타입을 입력하고, 상기 Command, Start, End 각각에 대해 사용자 인터페이스를 통해 TokenElement 정보로서 고유문자를 입력하는 것을 특징으로 한다.

본 발명에 의한 태양광 발전의 모니터링 시스템 및 그 방법은 메타모델을 기반으로 서로 다른 종류의 프로토콜을 사용하는 모니터링 시스템 사이의 데이터 통합을 가능하게 하여 이미 사용하고 있던 기존 모니터링 시스템을 변경하거나 새로 구축하지 않아도 되므로 방치되었던 모니터링 시스템의 이용률 향상을 도모하고 예산을 절약할 수 있다.

또한, 본 발명에 의한 태양광 발전의 모니터링 시스템 및 그 방법은 발전설비를 원거리에서도 통합적으로 관리할 수 있게 되어 문제가 발생했을 경우 빠르게 대처가 가능하며, 설비의 생산량 및 가동현황등을 실시간으로 모니터링이 가능하므로 설비에 의해 발생되는 신재생에너지의 전력 생산량 관리에 유용하다.

도 1은 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템의 구성을 나타낸 도면.
도 2는 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템 중 제 N 발전부와 통합서버의 구성을 구체적으로 나타낸 도면.
도 3는 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템 방법에 관한 소프트웨어 플랫폼의 구조를 나타낸 도면.
도 4은 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템 방법에 관한 흐름도.
도 5는 본 발명의 실시예에 따른 메타모델 기반 프로토콜 모델의 메타모델을 나타낸 도면.
도 6은 본 발명의 실시예에 따른 메타모델 기반 프로토콜 모델을 통해 생성된 코드의 구조를 도시한 도면
도 7은 본 발명의 실시예에 따른 통합 모델의 메타모델을 나타낸 도면.
도 8은 본 발명의 실시예에 따른 메타모델 기반의 프로토콜 처리 구조를 나타낸 도면.

본 발명의 실시예에 따른 태양광 발전 모니터링 시스템은 태양광 셀로부터 수집된 전력의 양과 온도, 기울기 센서의 정보 등을 모니터링하고 관리할 수 있다. 태양광으로부터 수집된 에너지가 전기적인 특성을 가지고 있기 때문에 화재의 위험이 있고 구조물이 파손될 경우 인명피해의 우려가 있어, 항시 모니터링 시스템에 의한 관리가 필요하다.

이하에서는 도 1 내지 도 2를 참고로 하여, 본 발명에 따른 태양광 발전 모니터링 시스템에 관하여 설명한다. 도 1은 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템의 구성을 나타낸 도면이고, 도 2는 본 발명의 실시예에 따른 태양광 발전의 모니터링 시스템 중 제 N 발전부와 통합서버의 구성을 구체적으로 나타낸 도면이다.

먼저, 도 1을 참조하여 보면, 태양광 발전 모니터링 시스템(1)은 발전부(110-1,...,110-N)와 로컬서버(120-1,...,120-N)를 각각 구비하는 태양광 발전 설비(100-1,...,100-N)와, 상기 태양광 발전 설비(100-1,...,100-N)에서 수집된 데이터를 토대로 태양광 발전 상황을 관리하는 통합서버(220)로 구성되어 있다.

상기 태양광 발전 설비(100-1,...,100-N)는 지역적으로 분산 설치되어 있다. 따라서, 분산 설치된 상기 태양광 발전 설비(100-1,...,100-N)에서 측정되거나 수집되는 데이터를 한 곳에서 통합 관리할 필요성이 있다.

지역적으로 분산 배치되어 있는 복수개의 태양광 발전 설비(100-1,...,100-N)를 각각 살펴보면, 발전부(110-1,...,110-N)와 로컬 서버(120-1,...,120-N)로 구성되어 있으며, 상기 각 발전부(110-1,...,110-N)에서 수집된 모니터링 데이터를 상기 각 로컬 서버(120-1,...,120-N)의 데이터베이스에 구축한다. 이 때, 상기 발전부(110-1,...,110-N)와 상기 로컬 서버(120-1,...,120-N)는 비교적 근거리에 위치하고 있으므로, 근거리에서 이용가능한 RS232 또는 RS422/485 통신을 이용한다.

각 지역에서 수집되어 구축된 상기 로컬 서버(120-1,...,120-N)의 데이터베이스는 상기 통합 서버(200)에 전송되어 분산된 지역에서 수집된 상기 각 태양광 발전 설비(100-1,...,100-N)의 데이터를 한 곳에서 통합하며, 상기 각 태양광 발전설비(100-1,...,100-N)와 상기 통합 서버(200)는 상대적으로 원거리에 위치하고 있으므로 TCP/IP 통신을 이용하는 것이 바람직하다.

다음으로는, 각각의 태양광 발전설비(100-1,...,100-N)는 기본적으로 동일한 구성을 구비한다. 이하에서는 도 2에 도시된 제 N 태양광 발전설비(100-N)와 통합서버(200)를 참고로 하여 구체적으로 설명한다.

먼저, 제 N 태양광 발전설비(100-N)는 제 N 발전부(110-N)와 제 N 로컬서버(120-N)로 구성되어 있다.

상기 제 N 발전부(110-N)는 구체적으로 직접 태양빛을 받는 제 N 태양전지 모듈(111-N)과, 상기 제 N 태양전지에서 발생된 에너지와 측정된 데이터를 수집하고 변환하는 제 N 부대설비(112-N)로 구성된다.

또한, 상기 제 N 부대설비(112-N)는 상기 제 N 발전부(110-N)의 어레이를 접속하는 제 N 접속함(113-N)과, 상기 제 N 접속함(113-N)으로부터 데이터를 수신하여 상기 제 N 로컬서버(120-N)로 전송하는 제 N 인버터(114-N)로 구성된다.

구체적으로, 상기 제 N 인버터(114-N)는 상기 제 N 접속함(113-N)으로부터 상기 제 N 태양전지모듈(111-N)의 아날로그 데이터를 수집하여 수신하고, 이를 상기 제 N 로컬서버(120-N)로 전송하며 상기 제 N 태양전지모듈(111-N)에 의해 생성된 직류 전기 에너지를 교류 전기 에너지로 변환한다.

상기 제 N 태양광 발전 설비(100-N)는 상기 제 N 인버터(114-N)를 통해서 전력의 양과 온도, 기울기 센서의 정보 등을 상기 제 N 로컬 서버(120-N)에 설치될 수 있는 모니터에 표시해 주거나, 상기 제 N 태양전지모듈(111-N)에 설치된 다양한 종류의 센서들에 의해 측정된 값을 상기 제 N 로컬 서버(120-N)에 전송할 수 있다.

다음으로, 상기 통합서버(200)의 구성요소에 관하여 설명한다. 상기 통합서버(200)는 상기 제 N 로컬 서버(120-N)로부터 전송된 데이터를 받는 데이터 수집기(210), 수집된 데이터를 저장하는 데이터저장기(220), 필요에 따라 상기 데이터저장기(220)의 데이터 분석을 수행하는 데이터 분석기(230), 그리고 외부에서 상기 데이터저장기(220)에 접속이 가능한 웹 어플리케이션(240)으로 구성된다.

상기 통합서버(200)의 구성요소를 더욱 구체적으로 살펴보면, 상기 데이터 수집기(210)는 상기 제 N 로컬 서버(120-N)로부터 전송된 데이터를 모아서 상기 데이터저장기(220)로 전송하는 역할을 한다. 또한, 상기 통합서버(200)는 분산되어 있는 각 지역에 설치된 상기 태양광 발전설비(110-1,...,110-N)를 모니터링하기 위하여 설치되며, 상기 각 로컬 서버(120-1,...120-N)로부터 전송된 모든 데이터를 상기 데이터 수집기(210)가 수집할 수 있다.

또한, 상기 데이터저장기(220)는 상기 데이터 수집기(210)로부터 전송된 데이터를 모아서 저장하며, 상기 데이터 분석기(230)에서 분석한다. 상기 데이터 분석기(230)는 필요한 경우에 상기 데이터 수집기(210)에 저장되어 있는 데이터를 이용하여 분석을 수행하며, 이때 빅데이터 시스템을 이용하여 분석하기 위하여 하둡(Hadoop)을 사용한다.

상기 데이터 분석기(230)에서는 목표부하 수요 예측 서비스, 실시간 태양광 에너지 예측 서비스, 통합 제어 서비스, 최적 제어 상태 및 운영 서비스, 통합 모니터링 서비스 중 어느 하나를 수행할 수 있으며, 필요할 경우 상기 데이터 분석기(230)에서 수행할 수 있는 서비스의 종류를 추가하거나 삭제할 수 있다.

또한, 상기 데이터저장기(220)에 저장된 데이터를 이용하여 여러가지 정보를 분석하고, 판단하기 위하여 외부에서 사용자가 직접 상기 데이터저장기(220)에 접속하여 조회가 가능하도록 하기 위하여 상기 웹 어플리케이션(240)이 구비된다. 상기 웹 어플리케이션(240)은 인터넷 상에서 사용자가 조회하고자 하는 데이터를 서비스하며, 필요에 따라 조회된 데이터를 저장하거나 프린트할 수 있다.

상기와 같은 태양광 발전 모니터링 시스템(1)은 서로 다른 지역에 설치된 서로 다른 종류의 상기 로컬 서버(120-1,...,120-N)로부터 데이터를 하나의 통합 서버(200)로 전송받아야 한다. 그러나 다른 종류의 서버는 다른 종류의 프로토콜을 사용하기 때문에 데이터 송수신이 매끄럽지 않거나 불가능하다. 따라서, 서로 다른 종류의 프로토콜의 호환이 가능하도록 하는 방법이 필요하다.

상기 서로 다른 종류의 프로토콜이 호환 가능하도록 하는 방법은 두 가지가 있다. 첫 번째 방법은 상기 발전부(110-1,...,110-N)와 상기 로컬 서버(120-1,...,120-N)를 연결하는 자체 통신 프로토콜을 모두 같은 종류로 통합하는 것이며, 두 번째 방법은 상기 태양광 발전설비(100-1,...,100-N)는 기존의 것을 사용하고, 상기 통합 서버(200)와의 통신 프로토콜을 통합화하는 방법이다.

상기 첫 번째 방법은 기존에 사용하던 장치 및 설비를 모두 같은 통신 프로토콜을 사용하는 것으로 교체해야 하는 번거로움이 따르므로, 본 발명의 실시예에서는 기존의 상기 태양광 발전설비(100-1,...,100-N)를 그대로 사용하고, 상기 발전부(110-1,...,110-N)와 상기 로컬 서버(120-1,...,120-N)를 연결하는 자체 통신 프로토콜의 종류에 관계없이, 상기 로컬 서버(120-1,...,120-N)와 상기 통합 서버(200) 사이의 통신을 통합하는 방법의 실시예를 개시하고자 한다.

상기 로컬 서버(120-1,...,120-N)와 상기 통합 서버(200)의 통신을 통합하기 위해서는 도 3에 도시된 바와 같은 소프트웨어 플랫폼(300)이 구축되어야 한다. 상기 소프트웨어 플랫폼(300)은 메타모델 프레임워크(320), 시리얼통신 미들웨어(330), TCP/IP 통신 미들웨어(340), 하둡(350), 및 가시화 미들웨어(390)로 구성한다.

상기 메타모델 프레임워크(320)는 이종의 데이터 프로토콜(310-1,...,310-N)을 메타모델을 기반으로 통합하기 위해 구축된다. 상기와 같이 구성된 프로토콜은 메타모델을 기반으로 상기 시리얼 통신 미들웨어(330)를 통합한다. 이렇게 수집된 프로토콜 데이터들은 데이터베이스(360)에 저장되며, 필요할 경우에 분석을 하기 위해서는 상기 하둡(350) 기반의 빅데이터 분석을 시도한다. 또한, 웹 모니터링을 위해서는 PC(370)와 웹(380)을 이용하여 상기 가시화 미들웨어(390)를 통해서 수행하는 구조로 구성된다.

상기와 같이 서로 다른 종류의 프로토콜이 서로 호환이 가능하도록 하기 위해서는 표준을 사용하는 방법, 어댑터를 만드는 방법, 모델변환을 사용하는 방법이 있다. 상기 표준을 사용하는 방법은 하나의 통일된 버전을 사용하기 때문에 쉽게 연계가 가능하지만, 기존에 만들어진 시스템에 적용하기는 어렵다. 또한, 상기 어댑터를 이용하는 방법은 각 변환 프로토콜이 생성될 때마다 어댑터를 만들어서 이를 처리할 수 있는 시스템을 계속적으로 추가하는 방법으로 연결하고자 하는 시스템이 많아질수록 어댑터의 수가 기하급수적으로 늘어날 수 있다.

상기 모델변환은 메타모델을 기반으로 하나의 모델을 만들고 그 모델을 통해서 이종의 모델을 생성하는 방법으로써, 본 발명의 실시예에서는 상기 모델변환 방법을 이용하여 기존에 만들어진 이종의 시스템들과 성공적으로 연동 될 수 있도록 한다.

따라서, 본 발명에서는 상기 모델변환을 사용하여 메타모델을 기반으로 이종 프로토콜의 데이터를 통합하는 방법에 관한 실시예를 구체적으로 설명한다.

일반적으로 프로토콜의 데이터는 전송할 때와 수신할 때를 구분할 수 있다. 보통 전송할 때는 데이터를 해석하지 않고 명령어를 그대로 입력하게 된다. 하지만, 수신할 때는 데이터를 읽어서 처리해야 하므로 데이터를 읽고 파싱해야 한다. 상기 각 전송할 때와 수신할 때의 데이터 프로토콜은 다음과 같다.

예) 전송: #1NQ110000$

응답: #1NR1100010004000A00290000000000000384000000000000$

상기와 같은 작업을 프로그램 코드로 작성할 때에 각각 다른 종류의 프로토콜을 이해하여 프로그램 코드를 개별적으로 작성해야 하는 어려움이 있다. 따라서, 본 발명에서는 메타모델을 기반으로 이종의 프로토콜을 모델링하는 과정을 선행하여 별도의 개별적 코드 작성 없이 상기 모델링된 프로토콜의 데이터를 처리할 수 있는 코드를 자동으로 생성함으로써 빠른 개발을 도모한다.

특히, 메타모델을 기반으로 하여 프로토콜을 모델링하게 되면 복잡한 이종의 프로토콜을 이해하지 않고도 원하는 정보만 입력하여 모델링을 수행할 수 있어 효과적이다.

이에 따라, 도 4를 참고로 하면 본 발명에서는, 메타모델을 기반으로 하여 각 상기 태양광 발전설비(100-1,...,100-N)와 상기 통합 서버(200)와의 통신 프로토콜을 모델링하고(S1), 상기 모델링된 각 프로토콜의 데이터를 처리 가능한 프로그램 코드를 자동으로 생성하여(S2), 상기 생성된 프로그램 코드를 상기 통합 서버(200)의 통합 메타모델에 매핑하여(S3) 이종 시스템의 연동을 자유롭도록 한다.

이와 같은 메타모델기반 이종 통신 프로토콜 통합 방법의 각 단계를 도 4 내지 도 8을 참고로 하여 이하에서 자세하게 설명한다.

(1) 메타모델 기반 프로토콜 모델링(S1)

메타모델 기반 프로토콜 모델링 과정(S1)은 상기 기술한 바와 같이, 후술하는 코드 생성을 자동으로 수행할 수 있도록 하기 위하여 선행되는 과정으로써, 특히 상기 태양광 발전설비에 설계된 메타모델을 기반으로 모델링하며, 그 구체적인 과정은 아래와 같다.

이하에서는, 도 5를 참고로 하여 상기 메타모델 기반 프로토콜 모델링(S1) 단계를 자세하게 설명한다. 실시예에서 메타모델 기반 프로토콜 모델링은 사용자 인터페이스를 통해 사용자가 직접 입력하는 모델링 프로그램을 이용하여 수행한다. 도 5는 메타모델 기반 프로토콜 모델의 메타모델(400)을 도시한 도면이다.

ProtocolModel(410)은 최상위 노드로 사용자 인터페이스를 통해 사용자가 직접 모델의 이름 정보를 입력받을 수 있다. Packet은 프로토콜에서 정의한 하나의 묶음 단위로 한 번에 전송할 수 있는 데이터의 단위이다. 그러므로 모델에는 하나의 Packet이 존재해야 한다.

상기 Packet에는 여러 개의 Type들이 올 수 있다. 상기 Type은 Start, Header, Command, Data, ParityBit, End로 구성되어 있고 각각의 Type은 크기 정보를 가진다. 상기 크기 정보는 데이터의 크기로 단위는 byte이다. 예를 들어, 4byte의 크기는 4라고 입력한다.

상기 메타모델기반 프로토콜 모델의 메타모델(400)은 전송을 위한 SendPacket(420)과 수신을 위한 RecvPacket(430)으로 구분한다. 상기 두 종류의 Packet은 Type을 가지게 되는데 상기 SendPacket(420)은 SendType(421), 상기RecvPacket(430)은 RecvType(431)으로 각각 구분되어 포함한다.

상기 두 종류의 Type은 CoreType(440)을 포함하는데, 상기 CoreType(440)은 상기 SendPacket(420)과 RecvPacket(430)Type이 공동적으로 사용하는 Start(441), End(442), ParityBit(443)를 가진다.

상기 ParityBit(443)는 전송된 데이터 값이 중간에 오류 없이 전송되었는지 확인하는 용도로 사용하며, 확인을 위해서 전송하고자 하는 값을 모두 더한 값을 보내고 받는 측에서도 이를 더해서 같은 값이 나오면 전송한 데이터는 무결하다고 판단하는 것이다.

상기 SendType(421)에는 상기 CoreType(440)과 더불어 Command(422)를 가진다. 상기 RecvType(431)은 상기 CoreType(440)과 더불어 Header(432)와 Data(433)를 포함한다.

상기 Header(432), 상기 Data(433)는 NameElement(460)의 정보를 가지고 있다. 여기서 사용자 인터페이스를 통해 NameElement(460)의 정보를 사용자가 직접 입력한다. 상기 NameElement(460)는 이름과 데이터타입을 가진다. 상기 데이터타입은 실제 데이터의 종류로 데이터를 파싱할 때 문자열인지 숫자인지를 구분하기 위해서 사용한다.

상기 Command(422), 상기 Start(441), 및 상기 End(442)는 TokenElement(450)의 정보를 가지고 있다. 여기서 사용자 인터페이스를 통해 TokenElement(450)의 정보를 사용자가 직접 입력한다. 상기 TokenElement(450)는 고유의 문자를 가질 수 있다. 예를 들어, $로 시작하여 #으로 끝나는 프로토콜의 토큰은 Start는 $, End는 #이 된다. 토큰타입은 토큰이 어떤 타입으로 데이터가 표현되어야 하는지를 나타내는 값으로 상기 데이터타입과 같이 문자열인지 숫자인지 구분하기 위해서 사용한다.

상기 메타모델기반 프로토콜 모델을 만들기 위하여 사용되는 표기법은 표 1과 같다. 이러한 표기법은 모델링 프로그램에서 제공되고, 사용자 인터페이스를 통해 사용자가 직접 표기법을 이용하여 블록 엘리먼트를 배치할 수 있다. 상기 이종 프로토콜의 데이터 순서에 맞추어 배치된 블록 형태의 엘리먼트로 모델링하고, 이후 모델링 프로그램이 사용자에 의해 모델링 된 블록 형태의 엘리먼트를 기반으로 저장데이터를 형성한다.

즉, 상기 블록형태의 엘리먼트에 데이터의 종류를 기입하게 되어 어떤 데이터 타입인지 확인할 수 있다. 이름 옆에 "{1}"은 데이터의 크기를 나타낸 것으로 1 byte를 나타낸다.

[표 1] 메타모델기반 프로토콜 모델의 표기법

상기 메타모델기반 프로토콜 모델의 메타모델(400)을 이용하여 아래의 데이터 프로토콜 예시 1의 모델링을 표 2에 도시하였다.

예시 1) 전송: #1NQ110000$

응답: #1NR1100010004000A00290000000000000384000000000000

[표 2] 메타모델기반 프로토콜 모델링의 예시 1

상기 표 2에 도시된 메타모델 기반 프로토콜 모델링의 저장데이터 형식을 표 3에 도시하였다. 상기 표 3는 상기 예시 1의 프로토콜이 저장되는 파일의 구조를 보여주는 것으로, 사용자 기입 후 모델링 프로그램이 트리 형태의 배치 순서에 따라 자동 처리하여 XML 형태로 저장하게 된다.

[표 3] 메타모델기반 프로토콜 모델링의 예시 1의 저장데이터 형식

상기 표 2의 메타모델 기반 프로토콜 모델링은 ProtocolModel과 상기 Packet을 제외한 모든 구성요소는 순서를 가지게 된다. 따라서, 모델링 시에 순서를 반드시 지켜주어야 한다.

즉, 상기 메타모델 기반 프로토콜 모델링은 블록형태의 엘리먼트가 트리형태로 배치되는 것이며, 일정한 순서를 갖는다.

상기 순서는 좌에서 우를 기본으로 하며 하위에 블록이 있을 경우, 하위의 블록을 모두 수행한 다음에 우측의 첫번째 블록으로 이동하는 순서를 가지고 있다. 이는 상기 모델링을 순차적으로 옆으로 나열했을 경우에 너무 길어지는 것을 방지할 수 있다.

(2) 프로토콜 처리 코드 생성(S2)

이하에서는, 도 6을 참조하여 상기 S1과정에서 형성된 메타모델 기반 프로토콜 모델의 데이터를 처리하는 프로그램 코드를 자동으로 생성하는 방법(S2)에 관하여 구체적으로 설명한다. 도 6은 메타모델 기반 프로토콜 모델을 통해 생성된 코드의 구조를 도시한 도면이다.

상기 프로그램 코드는 코드 발생수단에 상기 모델링된 프로토콜을 입력하여 자동으로 생성한다. 이와 같이 자동으로 생성된 프로그램 코드는 후술하는 상기 통합서버(200)의 통합 메타모델에 매핑하는 과정을 위한 것이며, 상기 코드 발생수단이 모든 프로토콜을 해석하는데 사용된다.

도 6을 살펴보면, 생성된 코드(500)는 3개의 클래스로 구분되어 생성된다. 첫 번째는 프로토콜을 보내고 받을 때 처리할 수 있도록 제공하는 송수신 클래스(510)이고, 두 번째는 프로토콜에서 생성된 데이터가 저장되는 Data 클래스(520)이고, 세 번째는 모든 프로토콜 해석에 사용되는 API가 저장된 Util 클래스(530)이다.

상기 송수신 클래스(510)는 데이터를 읽고 처리하기 위해서 내부에 상기 Data 클래스(520)를 포함하고 있고, 상기 송수신 클래스(510)가 코드 생성시 생성될 때 상기 Data 클래스(520)를 받을 수 있도록 한다.

또한, 상기 송수신 클래스(510)는 send API(511)와 recv API(512)의 두 가지 API를 가지고 있다. 상기 send API(511)는 데이터를 보낼 경우 시리얼 포트에 쓰일 byte 데이터를 얻어올 수 있고, 상기 recv API(512)는 수신된 byte 데이터를 읽어서 상기 Data 클래스(520)에 데이터를 입력한다.

이러한 구성에 따라, 상기 생성된 코드에 형성된 3개의 클래스의 동작 메커니즘을 각각 예시와 함께 이하에서 자세히 설명한다.

먼저, send API(511)는 메타모델기반 프로토콜 모델(410)에서 형성된 트리형태의 블록 엘리먼트의 요소 및 속성에 따라 처리된다. 예를 들어, 아래 표 4에 도시된 메타모델기반 프로토콜 모델의 전송 예시가 있다면 표 5와 같이 자동적으로 생성된다.

[표 4] 메타모델기반 프로토콜 모델의 전송 예

[표 5] send API 코드 생성 예

상기 send API(511)의 내용을 자세히 살펴보면, 먼저 byte 데이터 형태로 출력해야하기 때문에 ArrayList를 이용하여 데이터를 수집하고 최종적으로 상기 ArrayList를 byte 배열로 변환하여 리턴한다. 상기와 같은 변환 처리는 모두 상기 Util 클래스(530)에서 처리한다.

상기 표 5에서 상기 send API(511)의 코드는 앞에 SEND 키워드가 붙게 되는데, 이것은 상기 recv API(512)의 데이터와의 충돌을 방지하기 위해서 추가된 키워드이다.

상기 send API(511)에서 데이터를 전송하기 위해서, 상기 표 4의 메타모델기반 프로토콜 모델의 전송 예에서 처음에 START가 사용되었다. 상기 START는 상기 Data 클래스(520)에서 가져와 ArrayList로 입력한다. 이때 입력은 문자열 값이 될 수도 있고 byte 값이 될 수도 있는데 이것은 상기 Util 클래스(530)에서 두 가지 타입에 대해서 모두 처리가 가능하기 때문에 타입에 관계없이 표 4에 도시된 바와 같이 모델의 순서대로 코드가 자동 생성되게 된다. 더불어 표 4의 마지막에 기재된 PARITY BIT 또한 상기 Util 클래스(530)의 API를 통해서 처리가 가능하다.

다음으로, 상기 recv API(512)는 수신된 데이터를 순차적으로 읽어서 각각 데이터에 입력한다. 예를 들어, 아래 표 6와 같은 모델이 정의되어 있을 때 상기 recv API(512) 코드 생성은 표 7과 같이 생성된다.

[표 6] 메타모델기반 프로토콜 모델의 수신 예

[표 7] recv API의 코드 생성 예

상기 표 6에서 상기 recv API(512)는 순차적으로 데이터를 읽어야 하기 때문에 _index 변수를 가지게 된다. 상기 표 6와 표 7에서 START와 END와 같이 토큰 값을 가지는 데이터는, 데이터를 읽는데 사용되는 것이 아니라 입력된 데이터의 오류를 체크하는데 사용된다. 따라서, 상기 START와 상기 END는 데이터 값을 가져와 현재 입력된 데이터 값과 다른 경우 false를 리턴하게 되어 전송된 데이터 값이 잘못된 것을 확인할 수 있다.

상기 recv API(512)의 데이터 입력은 상기 Data 클래스(520)의 getter 함수를 이용하여 순차적으로 처리하게 되며 상기 데이터의 처리는 상기 Util 클래스(530)에서 처리해주므로 상기 recv API(512)에서는 별도의 처리 없이 데이터를 입력만 하면 된다.

상기 recv API(512) 코드는 순차적으로 실행되기 때문에 상기 메타모델기반 프로토콜 모델(400)의 사이즈 값(470)에 따라 _index 값의 증감 값이 달라진다. 또한, 어떤 데이터들은 1 byte가 아닌 2 byte 씩 읽어서 처리해줘야 하는데 이 또한 상기 Util 클래스(530)에 미리 만들어진 API를 활용해 처리한다.

다음으로, 상기 Data 클래스(520)는 상기 메타모델기반 프로토콜 모델(400)에 입력된 순서대로 데이터를 만들어낸다. 이때 데이터 타입이 STRING인 경우에는 문자열 데이터로 만들어주고, 데이터 타입이 토큰일 경우에는 변경 불가능하며 읽기만 가능한 데이터로 만들어 준다. 또한, 그 외의 경우에는 int로 데이터를 선언한다.

예를 들어, 상기 도시된 표 6의 메타모델기반 프로토콜 모델의 수신 예는 아래에 도시된 표 8과 같은 Data 클래스(520)를 만든다.

[표 8] Data 클래스의 예

상기 모델링된 프로토콜에 입력된 데이터의 타입에 따라서 상기 Util API가 결정되는데, 그 경우는 아래 기재된 표 9와 같이 변환되며, 이때 상기 Util 클래스에서 사용되는 API 리스트는 표 10과 같다.

[표 9] 입력된 데이터 타입에 따른 Util API

[표 10] Util 클래스의 API

(3) 통합 메타모델에 매핑(S3)

상기 프로토콜 처리 코드 생성 과정(S2)을 통하여, 상기 메타모델기반 프로토콜 모델(400)을 통해 생성된 코드(500)를 이용하면 데이터를 상기 Data 클래스(520)에 수집할 수 있다. 따라서 이종의 프로토콜에서 생성된 데이터를 통합 모델에 간단하게 수집이 가능하다.

이에 따라 수집된 데이터를 도 7에 도시된 통합 모델의 메타모델에 매핑(S3)하여 각 지역에 분산된 복수개의 상기 로컬서버(120-1,...,120-N)에서 서로 다른 종류의 프로토콜에 의해 생성된 데이터를 통합함으로 인하여 기존 레가시 시스템의 변경이 없이도 상기 통합서버(200)를 통한 원거리 모니터링이 가능하게 된다.

도 7을 참고로 하여, 상기 통합 모델의 메타모델이 포함하고 있는 엘리먼트를 살펴보면, SolarEnergyModel(610) 엘리먼트는 최상위 모델로 발전소의 아이디와 전송 시간을 속성으로 가진다. 상기 SolarEnergyModel(610) 엘리먼트는 하위 엘리먼트로 PlatDisplay(620), Invertes(630), Sensors(640), JunctionBoxes(650)를 포함한다.

상기 PlatDisplay(620) 엘리먼트는 전체 모니터링 결과를 볼 수 있는 현재 출력량, 당일, 전일, 당월, 전월, 전체 발전량 정보를 보낸다. 또한, 상기 Inverters(630) 엘리먼트는 Inverter(631)에서 얻을 수 있는 정보들을 보낸다. 상기 Inverter(631)는 현재, 당일, 전일, 전체 발전량과 출력 전류, 전압, 입력 전력, 전류, 전압, 주파수, 인버터의 경고 정보를 알 수 있다.

또한, 상기 Sersors(640) 엘리먼트는 센서들의 정보로 수평 일사량, 경사 일사량, 모듈 온도, 외부 온도, co2의 농도, 기울기를 보낸다. 또한, 상기 JunctionBoxes(650) 엘리먼트는 JunctionBox(651)에 연결되는 태양광 모듈의 전압과 전류 들을 얻을 수 있다.

상기 살펴본 바와 같이, 도 4에 도시된 세 단계의 과정을 거쳐 메타모델로 구현된 통합 모델은, 서로 송수신할 수 있는 방법이 필요하다. 즉, 상기 로컬서버(120-1,...,120-N)와 상기 통합 서버(200)는 모두 통신 프로토콜의 메타모델 규칙에 맞게 작성하고 보낼 수 있으며 이는 도 8에 도시되어 있다. 즉, 메타모델의 모델 데이터는 XMI를 사용하고, 이는 근본적으로 문자열 데이터이기 때문에 상기 메타모델 데이터를 TCP/IP를 통해 주고받을 수 있다.

1 태양광 발전 모니터링 시스템
100-1,...,100-N 태양광 발전설비 110-1,...,110-N 발전부
111-1,...,111-N 태양전지모듈 112-1,...,112-N 부대설비
113-1,...,113-N 접속함 114-1,...,114-N 인버터
120-1,...,120-N 로컬서버 200 통합서버
210 데이터수집기 220 데이터저장기
230 데이터분석기 240 웹 어플리케이션
300 태양광 발전 모니터링 시스템 소프트웨어 플랫폼 구조
400 메타모델기반 프로토콜 모델의 메타모델
500 메타모델 기반 프로토콜 모델을 통해 생성된 코드의 구조
600 통합 모델의 메타모델

Claims (2)

1. 지역별로 분산 설치된 복수개의 태양광 발전 설비와 상기 태양광 발전 설비를 통합 관리하는 통합서버를 이용하는 태양광 발전의 모니터링 방법에 있어서,
   상기 복수개의 태양광 발전 설비와 상기 통합서버 모두에 적용하는 통합 통신 프로토콜을 생성하는 단계는,
   각각의 태양광 발전설비에서 수집된 모니터링 데이터를 통합서버로 제공하기 위해, 상기 각각의 태양광 발전 설비에서 개별적으로 사용하는 이종 통신 프로토콜에 대해 메타모델을 기반으로 개별적으로 모델링하는 프로토콜 모델링 단계;
   상기 메타모델을 기반으로 개별적으로 모델링된 통신 프로토콜을 상기 각각의 태양광 발전 설비의 이종 프로토콜의 해석이 가능한 프로그램 코드로 자동 생성하는 코드 생성 단계; 및
   상기 생성된 프로그램 코드를 이용하여 상기 수집된 모니터링 데이터를 상기 통합서버에 설계된 통합 메타모델의 엘리먼트와 연결하여 매핑하는 통합 메타모델 매핑 단계;를 포함하며,
   상기 프로토콜 모델링 단계는,
   모델의 이름 정보를 입력받는 최상위 노드에 전송 패킷(SendPacket)과 수신 패킷(RecvPacket)을 연결하고, 상기 패킷들(SendPacket, RecvPacket)에는 패킷 내의 Type 종류(Start, Header, Command, Data, ParityBit, End)에 따라 분류되는 두 Type(SendType, RecvType)을 각각 연결한 트리 형태의 메타모델을 기반으로 하여 패킷 단위로 모델링하되,
   사용자 인터페이스를 통해 블록 엘리먼트에 데이터의 종류와 크기를 사용자가 기입하되, 상기 이종 통신 프로토콜의 데이터 순서에 맞추어 블록 엘리먼트를 트리 형태로 기입하고, 사용자 기입 후, 모델링 프로그램이 트리 형태의 배치 순서에 따라 자동 처리하여 XML 형태로 저장하는 것을 특징으로 하는 태양광 발전의 모니터링 방법.
   
2. 제1항에 있어서,
   상기 전송 패킷(SendPacket)은 패킷 내의 Type 종류 중 코어 패킷(CoreType)에 해당하는 Start, ParityBit, End 뿐만 아니라 Command를 가지고,
   상기 수신 패킷(RecvPacket)은 패킷 내의 Type 종류 중 코어 패킷(CoreType)에 해당하는 Start, ParityBit, End 뿐만 아니라 Header, Data를 가지며,
   상기 Header, Data 각각에 대해 사용자 인터페이스를 통해 NameElement 정보로서 이름과 데이터타입을 입력하고,
   상기 Command, Start, End 각각에 대해 사용자 인터페이스를 통해 TokenElement 정보로서 고유문자를 입력하는 것을 특징으로 하는 태양광 발전의 모니터링 방법.

Images