psXML Technical Description for Consumer Portal

제 1 장 연구개발과제의 개요

1.1 연구개발의 목적

본 연구는 ESP 사업자들이 대수용가 및 빌딩의 전력설비들을 관리하는 Device

Portal 로부터 필요한 정보를 수신하여 새로운 부가가치 서비스를 창출하는 SOA(Service-

Oriented Architecture) 플랫폼을 개발하고자 하는 것이다.

1.2 연구개발의 필요성

Device Portal 은 빌딩 및 대수용가 자체의 전력 설비들을 통합관리하는 시스템이다.

그러나 이 Device Portal 은 해당 수용가 내부의 정보만을 가지고 동작하는 모니터링이

주목적이다. Demand Response, 새로운 전력 요금, 새로운 부가가치 서비스, 수용가

전체적인 전력 수요 관리 등을 위해서는 ESP 가 대수용가의 전력설비들을 통합 관리할

수 있어야 하며, 이를 위해서 Consumer Portal이 필요하다.

Consumer Portal 은 Device Portal 로부터 주기적 혹은 필요에 의해서 히스토리 데이터를

수집하며, 이를 이용하여 새로운 부가가치 서비스를 창출하는 BM(Business Model)

어플리케이션이 이를 이용할 수 있는 표준화된 인터페이스를 제공한다.

Consumer Portal 이 제공하는 표준화된 인터페이스는 SOAP, WSDL 등을 이용하기 때문에

이를 이용하는 BM 은 오류없이 정확한 클라이언트 어플리케이션을 개발할 수 있는

기능을 제공한다.

1.3 연구개발의 범위

본 연구는 다음과 같은 연구개발 범위를 갖는다.

- Consumer Portal 의 Data Layer 를 개발한다.

- Device Profile XML 관리를 위한 Device Repository Service 개발

- Device Portal 관리를 위한 Controller 개발

- Device Portal / BM간의 안전한 통신을 위한 Security Layer 개발

- psXML 테스트를 위한 시험 플랫폼 구축

- Device Portal 과의 시험 연동 체계 구축

제 2 장 국내외 기술개발 현황

에너지 수급 단가가 높아지는 세계적인 추세에 의해서 전력설비에 대한 효율적인 관리를

위해서 IT 기술을 접목하는 시도가 전 세계적으로 시도되고 있다. 이와 더불어

전력시스템의 연동을 위한 표준의 양대 축인 미국과 유럽의 표준이 IEC61850, IEC61968,

IEC61970 등으로 표준화되었고, 이를 구현한 전력 설비들이 출시되고 있다.

이러한 표준은 변전 자동화(Substation Automation), 배전 자동화 (Distribution Automation),

발전관리 (Energy Management System) 등의 구성요소별로도 진행되고 있으며 이러한

구성요소를 플러그 앤 플레이 방식으로 결합하고 계층별 지오메트리가 아닌 그래프

형태의 지오매트리로 전력 공급체계를 구축하는 스마트그리드가 제안되고 있다.

이러한 추세에서 본 연구과제에서 개발되는 Consumer Portal 은 전력 IT 2 세부과제에서

연구되는 Device Portal 과의 연동을 통해서 대수용가 및 빌딩에 고부가가치 전력 부가

서비스를 제공하고, ESP 사업자로 하여금 발전설비의 관리 및 증설에 대한 탄력성을

제공하는 등의 역할을 한다.

제 3 장 연구개발수행 내용 및 결과

제 1 절 연구개발 수행 내용

1. Consumer Portal 개요

Consumer Portal 은 ESP(Energy Service Provider)를 위한 시스템으로서 전력 IT 서비스를

이용하는 수용가가 갖추고 있는 Device Portal 과의 연동을 통해서 새로운 전력

부가가치를 창출하는 시스템이다.

Consumer Portal 은 Device 의 Profile 관리를 담당하는 Repository Service 와 Device

Portal 과의 연동 및 Device 들의 속성을 저장하고 이를 BM 에 제공하는 Consumer Portal

Engine, 데이터를 저장하는 Database Server, 기타 Interface 시스템 및 OAM 의 집합체로서

일종의 Enterprise System이라고 볼 수 있는 방대한 시스템이다.

Engine Server

Database Server

Presentation Server

Interface Server

SMSIF

BillingIF

WEB Service

WEB Admin

WAP Service

HTTP Server

Servlet E

ngine

Oracle

Cache

Manager

BM Modules

Repository Server

Repository

Registrar

BM Server

BM ModulesBM Modules

Device Portal

Device Portal

Device Portal

Event

Listener

Event

Processor

XML

Provider

Internal

BM Modules

SOAP

Framework

Firebird

Chart Engine

Repository

Service

DPIF

Consumer Portal Block Diagram

2. Data Layer 개발

가. Data Layer 의 정의

Data Layer 는 1 차년도에 정의하였던 Consumer Portal 의 관계형 데이터베이스 스키마를

기반으로 이를 Consumer Portal 엔진에서 쉽게 사용할 수 있는 ORM(Object Relational

Mapping)을 제공하는 Layer 이다.

나. Data Layer 기반기술

ORM 은 기존의 관계형 데이터베이스와 Java 와 같은 객체지향언어의 Class 가 구조가

다름으로 인해 발생하는 많은 반복작업을 줄여주기 위해 생겨난 개념이다. 기존에는

관계형 테이블을 Class 로 변환하기 위해 DAO(Data Access Object) Class 를 별도로

만들어야 했고, 여기에 Relation 과 Object 의 맵핑을 기술해야 했다. ORM 을 이용하면

이러한 작업은 자동으로 이루어진다.

ORM 은 현재 가장 주목받고 있는 Java 진영의 기술이며 많은 제품이 출시되어 있다.

가장 많이 사용되는 것은 iBatis SQLMap, Hibernate 등이 될 것이다. 그러나 Java 진영은

ORM 에 대한 표준을 최근에 정립했고, 이는 JDO(Java Data Object)와 JPA(Java Persistence

API)로 대표되며, 최근에 발표된 EJB 3.0 규격에 포함되었다.

JDK 5.0

Eclipse SWT 3.3

OAM

JDK 5.0

Jboss AS 4.0

Apache Axis2

XML Service Provider

Apache ActiveMQ 4.2

JDK 5.0

JPOX 2.1

Device Repository Service

JDK 5.0

Apache Tomcat 5.5

DP Controller Gathering Engine

JMS 1.1

Flex2 Engine

MessageQueue

Oracle 10g

Firebird 2.0

Consumer Portal Software Configuration

CVS 1.10

Consumer Portal 에서는 이 중에서 JDO 를 사용한다. JDO 는 JPA 에 비해서 더 많은

데이터 타입을 지원하며, 다양한 Cursor 모델 등의 장점이 있다. JDO 의 구현체는 여러

가지가 있는데, 그 중에서 오픈소스 진영의 JPOX 1.2 를 선택하여 구현하였다. JPOX 는

JDO/JPA를 모두 지원하기 때문에 쉽게 두 기술을 갈아탈 수 있는 장점이 있다.

다. JDO 구현 방법

JDO 는 Class 와 Relation 의 Mapping 이기 때문에 Class 만을 정의해도 JPOX 의 Schema

Tool 을 이용하여 자동으로 Relation 을 만들 수 있다. 간단한 예를 통해 사용방법을

정리해본다.

다음과 같이 Device를 정의하는 Class 가 있다고 하자.

package com.voce.pit.jdo;

public class Device {

String qid = null;

String name = null;

String maker = null;

protected Device() {}

public Device(String qid, String name, String maker) {

this.qid = qid;

this.name = name;

this.maker = maker;

}

}

위 클래스의 소스파일 디렉토리에 package.jdo 라는 파일을 만든다. 이 파일이 실제로

Class와 Relation을 맵핑한 XML파일이다.

<?xml version="1.0"?>

<jdo>

<package name="com.voce.pit.jdo">

<class name="Device" identity-type="datastore">

<inheritance strategy="new-table"/>

<field name="qid" persistence-modifier="persistent">

<column length="64" jdbc-type="VARCHAR"/>

</field>

<field name="name" persistence-modifier="persistent">

<column length="128" jdbc-type="VARCHAR"/>

</field>

<field name="maker" persistence-modifier="persistent">

<column length="32" jdbc-type="VARCHAR"/>

</field>

</class>

</package>

</jdo>

JDO 의 domain Class 는 PersistenceCapable 이라는 인터페이스를 반드시 implement 해야

한다. 그러나 이 인터페이스는 매우 복잡하고 구현하기 어렵다. 그래서 JPOX 는 Byte

Code Enhancer 라는 모듈을 통해 PersistenceCapable 인터페이스를 jdo XML 을 해석하여

자동으로 구현해준다.

이러한 부가과정은 Ant Script 를 통해서 간단히 해결할 수 있는데 다음 부분을 build.xml

에 추가하면 된다.

<target name="enhance" description="JPOX enhancement">

<taskdef name="jpoxenhancer" classpathref="enhancer.classpath"

classname="org.jpox.enhancer.tools.EnhancerTask" />

<jpoxenhancer classpathref="enhancer.classpath"

dir="${jdo.file.dir}" failonerror="true" verbose="true">

<jvmarg line="-Dlog4j.configuration=${log4j.config.file}"/>

</jpoxenhancer>

</target>

이러한 부가과정은 Ant Script 를 통해서 간단히 해결할 수 있는데 다음 부분을 build.xml

에 추가하면 된다.

라. Data Layer 의 개발

Data Layer 는 위에서 언급한 JDO 를 이용한 ORM 집합체이다. com.voce.pit.cp.jdo.domain

패키지에 Persistence 에 대한 클래스들을 정의하였는데 그것들은 Device, DeviceProperties,

User, ControlHistory, DevicePortal 등이다.

이들 클래스들은 jdo XML 을 통하여 Relation 과 맵핑시켰으며, Schema Tool 에 의해

Relation 들을 생성하였다. 생성된 Relation 들은 수작업으로 검증하여 효율에 문제없는지

점검하고 튜닝하였다. 그리고 관련된 Index도 생성되었는지 확인하였다.

이렇게 만들어진 ORM 들을 다루는 Named Query 를 생성하였다. 이들은

com.voce.pit.cp.jdo.query 패키지에 정의되어 있다. Named Query 는 JDOQL 로 정의되는

데이터베이스 쿼리를 비즈니스 로직으로 해석하여 이름을 붙인 것으로 이를 이용하는

사용자들이 쉽게 추상화된 이름으로 Query 를 선택할 수 있게 하고, 또한 Back-end 에서

Query가 변경되더라도 사용측에서는 변함이 없도록 하였다.

Data Layer 는 다른 Consumer Portal 에서도 사용하는 공통적인 Package 이다. 따라서 이

Data Layer Package 들은 jar 로 묶여져서 다른 모듈들에 사용될 수 있다.

e) Cache Manager의 개발

Cache Manager 는 Consumer Portal 이 Device Portal 로부터 Device 들의 속성값을 가져오는

것을 효율적으로 하기 위한 모듈이다.

이는 Device 로부터 가져오는 속성값은 히스토리 데이터이며 변하지 않는다는 속성을

이용한 것이다. 이미 Consumer Portal 에 있는 데이터의 경우 굳이 Device Portal 로부터

가져올 필요가 없는 것이다.

Cache Manager는 다음 그림과 같은 방식으로 구현되어 있다.

3. Device Repository 개발

가. Device Repository의 역할

Device Repository 는 Device Maker 들이 자신들이 생산한 Device 에 대한 정보(Profile)을

등록하는 중앙 데이터베이스 서비스이다. Device Repository 서비스는 다음과 같은 기능을

한다.

- Device Maker 에 대한 계정을 생성/변경/삭제할 수 있다.

- 신규 Device 를 등록하거나, 기존 Device를 변경/삭제할 수 있다.

- psXML Device Profile 규칙에 의거한 Device 메타 정보를 입력하는 기능을 제공한다.

- psXML의 속성 이름에 대한 권고를 제공한다.

- Consumer Portal / Device Portal 등에 Device Profile 에 대한 정보를 제공한다.

- Device Profile 변경에 대한 버전 관리를 한다.

� Consumer Portal Engine은 Device Portal의 데이타들을 효율적으로 관리하는 목표를 가지고 있음.� 많이 사용되는 데이타 영역은 보존하고, 많이 사용되지 않는 영역은 제거하여 효율적인 데이타 관리

� Time Range 조회에 대해 빈 영역을 추출, 해당 영역만 DP에 요청

2007.5.16, 01:00….2007.5.15, 16:10

2007.5.16, 01:00….2007.5.15, 16:20

2007.5.16, 01:00….2007.5.15, 16:30

2007.5.16, 00:00….2007.5.15,15:30

2007.5.16, 00:00….2007.5.15,15:20

2007.5.16, 00:00….2007.5.15,15:10

Recently UsedData수집시간

2007.5.18, 01:00….2007.5.15, 16:10

2007.5.18, 01:00….2007.5.15, 16:20

2007.5.16, 01:00….2007.5.15, 16:30

2007.5.18, 01:00….2007.5.15,16:00

2007.5.18, 01:00….2007.5.15,15:50

2007.5.18, 01:00….2007.5.15,15:40

2007.5.18, 01:00….2007.5.15,15:30

2007.5.18, 01:00….2007.5.15,15:20

2007.5.16, 00:00….2007.5.15,15:10

Recently UsedData수집시간

2007.5.18, 01:00 에 해당 Device에 대해 2007.5.15,15:20 ~ 16:20 까지의 데이타 요청

Cache 확인후

2007.5.15,15:30 < time <

2007.5.15, 16:10

인 것만 요청

Cache Manager의 기능

나. Device Repository에 적용된 기술

Device Repository는 자체로 완결적인 서비스로서 User Interface / Database / Business Logic

을 갖추고 있다.

먼저 User Interface 의 경우에는 Adobe 의 Flex2 엔진을 사용하였다. Flex 엔진은 Flash

Player 에서 동작하는 swf 를 생성하는 엔진으로서 MXML 과 ActionScript 로 Flash 파일을

저작할 수 있는 도구이다.

Device Repository 는 다루는 데이터가 구조적인 데이터여서 일반적인 WEB 기술로는

구현하기가 매우 어려운데, Flex 를 이용함으로서 일반 어플리케이션을 이용하는 듯한

User Experience 를 제공할 수 있다. 또한 WEB Application 처럼 항상 자동 업데이트되는

어플리케이션이기 때문에 배포 문제 또한 자유롭다. 무엇보다도 어떤 OS 에서도

동작한다는 장점이 있기 때문에 Flex 엔진을 선택하였다.

Business Logic 의 경우에는 일반적인 Servlet 으로 개발되었다. Flex User Interface 는

HTTP 와 XML 로서 통신하는 것이 일반적이기 때문에 Business Logic Servlet 은 일반적인

HTTP 요청을 받으면 XML을 리턴하는 POX(Plain Old XML) 형식의 API를 제공한다.

Database Layer의 경우에는 앞에서 언급한 JDO를 이용하여 개발되었다.

버전관리를 위해서는 CVS(Concurrent Version Control System)을 이용하였다. 버전관리는

일반적으로 CVS 와 Subversion 을 많이 사용하는데, CVS 는 파일별 커밋인데 비해서

Subversion 은 Atomic 커밋을 지원한다. 일반적인 소스관리는 Subversion 이 더 유리하지만,

개별 Profile XML 을 버전관리하는데에는 파일별 커밋을 지원하는 CVS 가 더 자연스럽다

하겠다.

이를 위해서 CVS 서버를 설치하였고, CVS 의 Java Binding 을 이용하여 Java 로 CVS 를

직접 관리한다. CVS 를 이용함으로서 Device Profile 의 변경마다 버전번호를 자동으로

붙일 수 있으며, Annotation 에 변경자와 변경내용을 넣어 관리하도록 하였다. 이 같은

기능을 이용하여 사용자는 잘못 수정된 것에 대해서 Revert 도 할 수 있으며, 이전

버전과의 차이점을 비교해볼 수도 있다.

4. Device Portal Controller 개발

가. DP Controller 의 역할

Device Portal Controller 는 크게 두가지의 기능을 가지고 있고 다음과 같이 그 모듈이

구분된다.

(1) DPIF : Device Portal Interface Module

DPIF 는 Device Portal 과 psXML 을 통해 통신을 하는 모듈로서 주로 Device Portal 이

관리하는 Device 의 상태값을 읽어오는 기능을 한다. DPIF 는 Message Queue 를 이용하여

안전한 통신을 하며, Diffie Hellman 규격에 의거하여 안전한 키교환 통신을 한다.

(2) XML Provider:

XML Provider는 SOA(Service Oriented Architecture) 개념의 Web Service Provider로서 주로

다양한 BM 모듈들이 Consumer Portal 과 Device Portal 의 자원을 활용하여 부가가치

서비스를 창출할 수 있도록 지원하는 모듈이다.

XML Provider 는 SOAP 기반의 통신 프로토콜을 지원하여 어떤 플랫폼에서도 접근할 수

있는 장점이 있으며 Device Portal 로부터 얻어온 psXML 정보를 SOAP으로 Wrapping하여

전달하는 기능을 가지고 있다.

나. DPIF의 구현

DPIF는 다음 그림과 같은 형태로 구현이 되어있다.

DPIF는 Java Messaging Service를 구현한 ActiveMQ로부터 메시지 요청을 수신하며, 이는

Device Repository 의 Device Profile 을 참조하여 psXML 로 생성이 된다. 생성된 psXML 은

Security Layer 를 통해 Device Portal 로 전달된다.

Device Portal 은 요청을 받아 상태값을 정리하여 psXML 의 형태로 DPIF 에 전송한다.

DPIF 는 이를 psXML Parser 로 넘겨 Class 형태로 변환하며 이는 다시 Message Queue 에

쌓게 된다.

DPIF 는 위와 같이 데몬의 형태로 동작하기 때문에 J2EE Servlet Container 의 Context

Listener 로 개발이 되었으며, 각각의 메시지는 EJB 의 Message Driven Bean 에 의해

동작하게 되며, Multi-threaded 방식이다.

다. XML Provider의 구현

� Java 표준 Messaging Framework에 기반한 안전하고 효율적인 통신

Security

Layer

psXML Generator

psXML Parse

r

JMS Consumer

JMS Producer

Device

Profile

/ Reposito

ry Handler

Java

Messaging

Service

Axis 2

.0 Framework

JMS Producer

JMS Consumer

Web Service

Object (S

OAP)

Request O

bject

Response O

bject

Serialized

Java Object

Serialized

Java Object

DPIF XML Provider

Device

Porta

ls

BM M

odules

Cache Manager

DP Controller Architecture

XML Provider 는 SOAP Service Provider 의 일종이다. BM 으로부터 서비스 요청을 받게

되면 Cache Manager 를 통해 Consumer Portal 내부에 있는 데이터인지를 먼저 점검한다.

만일 있는 데이터일 경우 바로 리턴을 하게 되며, 없을 경우에는 요청 객체를 만들어

Message Queue 에 넣게 된다.

Message Queue 에 있는 요청객체는 DPIF 에 의해 Device Portal 로부터 속성값을 가져오게

되며, 이는 다시 Message Queue 로 저장된다. 이 값은 SOAP 으로 다시 envelope 되어

BM 으로 전달된다.

(1) Device Addressing

BM 은 특정 Device Portal 의 특정 Device 를 정확하게 타겟팅할 수 있어야 한다. 이를

위해서 psXML 은 Qualified Device ID 라는 개념을 사용하고 있으며 그 개요는 다음과

같다.

위 그림은 아파트 단지의 예를 든 것이다. Qualified Device ID (이후 QID)는 “device-

id@device-portal-id"의 형태를 가진다. @를 구분자로 하여 왼쪽은 Device Portal 내의 ID,

오른쪽은 Device Portal의 ID를 가리킨다.

물탱크

HSCP HSCP

HSCPHSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

D/G

E/L

BSCP

RS485물탱크

HSCP HSCP

HSCPHSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

HSCP

D/G BSCP

RS485

E/L

D/G SSCP

Device Portal

Ethernet

InternetConsumer Portal

Device Addressing

• hscp.1309.305@대우1차.금호.성동.서울

• bscp.305@대우1차.금호.성동.서울

• sscp@대우1차.금호.성동.서울

DP Configuration Example

각 파트는 "." 기호를 통해 세분화될 수 있다. 예를 들어 서울시 성동구 금호동 대우 1 차

아파트에 있는 305 동 1309 호의 HSCP 를 Addressing 하고 싶다면

“hscp.1309.305@대우 1차.금호.성동.서울” 과 같은 QID를 가지게 된다.

(2) XML Provider Protocol

XML Provider 는 다음과 같은 프로토콜을 구현하고 있다.

(가) getDevicePortalEquipments

getDevicePortalEquipments 메쏘드는 Device Portal 이 관리하는 모든 Device 들에 대한

Tree정보를 요청한다.

요청과 음답은 다음과 같은 형식이다.

<soap:Envelope …>

<soap:Body>

<getDevicePortalEquipments …>

<qid>@대우 1 차.금호.성동.서울</qid>

</getDevicePortalEquipments>

</soap:Body>

</soap:Envelope>

<soap:Envelope …>

<soap:Body>

<getDevicePortalEquipmentsResponse …>

<device>

<qid>sscp@대우 1 차.금호.성동.서울</qid>

<class>http://repo.cosumerportal.co.kr/sscp</class>

</device>

<device>

<qid>bscp.305</qid>

<class>http://repo.cosumerportal.co.kr/bscp</class>

</device>

<device>

<qid>hscp.1309.305</qid>

<class>http://repo.cosumerportal.co.kr/hscp</class>

</device>

<device>

….

</device>

</getDevicePortalEquipmentsResponse>

</soap:Body>

</soap:Envelope>

(나) getDeviceProperties

getDeviceProperties 메쏘드는 특정 디바이스의 기간별 속성을 얻어오는 기능을 제공한다.

옵션에 따라서 Cache를 사용할지 말지를 결정할 수 있다.

요청과 응답은 다음과 같다.

<soap:Envelope …>

<soap:Body>

<getDeviceProperties …>

<qid>sscp@대우 1 차.금호.성동.서울</qid>

<properties>

<property>*</property>

</properties>

<timeRange>

<from>2007.5.15,15:10:10</from>

<to>2007.5.15,16:00:00</to>

</timeRange>

<useCache>true</useCache>

</getDeviceProperties>

</soap:Body>

</soap:Envelope>

<soap:Envelope …>

<soap:Body>

< getDevicePropertiesResponse …>

<properties time="2007.5.15,15:10:30">

<property name="voltage">220</property>

<property name="current">10</property>

….

</ properties >

<properties time="2007.5.15,15:20:30">

<property name="voltage">220</property>

<property name="current">11</property>

….

</ properties >

</ getDevicePropertiesResponse>

</soap:Body>

</soap:Envelope>

(다) setDeviceProperties

setDeviceProperties 메쏘드는 특정 디바이스의 속성을 설정하는 기능을 제공한다.

요청과 응답은 다음과 같다.

<soap:Envelope …>

<soap:Body>

<setDeviceProperties …>

<qid>sscp@대우 1 차.금호.성동.서울</qid>

<properties>

<property name="upperBound">200</property>

</properties>

</ setDeviceProperties >

</soap:Body>

</soap:Envelope>

<soap:Envelope …>

<soap:Body>

< setDevicePropertiesResponse …>

<properties time="2007.5.15,15:10:30">

<property name="upperBound">200</property>

</ setDevicePropertiesResponse>

</soap:Body>

</soap:Envelope>

(라) 기타 메쏘드들

이외에도 다음과 같은 메쏘드들이 제공된다.

- getDeviceProfile

- getCriticalEvents

- addDevicePortal / deleteDevicePortal / modifyDevicePortal

- makeDevicePortalCredential

- 기타 등등

5. Security Layer 개발

Security Layer 는 별도의 프로그램은 아니고 DPIF 와 XML Provider 에 플러그인 형태로

제공되는 라이브러리이다. Security Layer 는 기본적으로 psXML 통신이나 SOAP 통신을

암호화하여 악의적인 해킹을 원천적으로 차단하는 매우 중요한 역할이다.

Consumer Portal 은 Device Portal 과의 연동, BM 과의 연동 이 두가지만 존재하므로 보안

모델도 두가지로 제공된다.

가. Device Portal 과의 Security Layer

Device Portal 과의 통신은 psXML over HTTP이다. psXML Transport 규격에 의하면 Device

Portal 과의 통신의 효율성을 위하여 SSL(Secure Socket Layer)와 같은 공개키방식이 아니라

대칭키 방식의 암호화를 사용하는 것을 원칙으로 하고 있다.

그러나 대칭키 방식의 암호화는 메시지 송수신자가 하나의 키를 공유해야 하는데,

이것이 네트웍상으로 전송될 경우 해킹당할 우려가 있다. 따라서 키를 전송하는 것은

공개키방식으로 하고, 키가 전송된 이후에는 대칭키 방식으로 암호화를 하는 것이

적절하다.

이를 위해서 가장 적절한 키교환 방식은 Diffie Hellman 키교환 방식이다. Diffie Hellman

키교환 방식은 공개된 키를 서로 주고 받지만, 이를 해킹해서는 공유되는 비밀키를 알

수 없는 방식이다. 공개된 키를 서로 주고 받은 송수신측은 별도의 알고리즘으로

공유되는 비밀키를 생성할 수 있게 된다.

이후의 대칭키 통신은 SEED 혹은 Blowfish 알고리즘으로 통신을 하게 되며 이는 공개키

방식의 RSA에 비해 훨씬 계산량이 적어서 매우 효율적이라 할 수 있다.

나. BM 과의 Security Layer

BM 과 Consumer Portal과의 통신은 SOAP over HTTP 통신이다. BM과 Consumer Portal 과의

통신은 Device Portal 과의 통신보다는 빈도가 적기 때문에 보안과 관련하여서는 표준을

채택하였다.

일반적으로 SOAP Service 의 보안은 SOAP over SSL 로 구현을 한다. SSL 은 RSA

알고리즘을 이용하며, RSA 는 대표적인 공개키 알고리즘으로 복잡도는 높지만 매우

안전한 알고리즘으로 알려져 있다.

Consumer Portal 은 Axis2 를 기반으로 개발되었기 때문에 Axis2 에 맞는 SSL 관련 설정은

다음과 같다.

먼저 Java 의 SSL 관련 표준 라이브러리인 JSSE(Java Secure Socket Extension)을 설치해야

한다. JSSE 는 http://java.sun.com/products/jsse 에서 다운받을 수 있다. 다운받은 후 jsse.jar,

jcert.jar, jnet.jar 를 JAVA_HOME/jre/lib/ext 로 복사를 해야 한다. 다음으로

JAVA_HOME/jre/lib/security/java.security 파일에 다음 항목을 넣는다.

security.provider.3 = com.sun.net.s 니.internal.ssl.Provider

다음으로는 Certificate 와 KeyStore 를 생성해야 한다. 이는 Java SDK 에서 제공되는

keytool 로서 생성할 수 있는데 순서는 다음과 같다.

- server.keystore에 Server KeyStore 를 생성한다.

- keystore 로부터 certificate 를 추출하여 server.cer를 생성한다.

- Client KeyStore를 생성하여 client.keystore 파일을 생성한다.

- keystore 로부터 certificate 를 추출하여 client.cer를 생성한다.

- client 의 certificate를 server 의 keystore 로 import 한다.

- server 의 certificate 를 client 의 keystore 로 import 한다.

위와 같이 공개키/비밀키 생성이 완료되면 Servlet Container 를 설정한다. Consumer

Portal 에서 사용한 Tomcat 의 경우 server.xml 에 Factory설정이 다음과 같이 되어야 한다.

<!-- Define an SSL HTTP/1.1 Connector on port 8443 -->

<Connector className = "org.apache.catalina.connector.http.HttpConnector"

port="8443" minProcessors="5" maxProcessors="75"

enableLookups="true"

acceptCount="10" debug="0" scheme="https" secure="true"<

<Factory className = "org.apache.catalina.net.SSLServerSocketFactory"

keystoreFile="c:\progs\java\WSOverSSL\hpwsp\server.keystore"

keystorePass="changeit"

clientAuth="false" protocol="TLS"/<

</Connector>

이상과 같이 하면 SSL위에서 SOAP을 서비스할 수 있다.

6. psXML 테스트베드 구축

Device Portal 과의 psXML 통신을 테스트하기 위해서는 테스트베드로서의 Device Portal과

Consumer Portal이 준비되어야 한다.

아래 그림은 완성된 테스트베드인데, 현재는 Device Portal 1 대와 Consumer Portal 1 대로

구축되어 있다.

KVM

LCD

Switching Hub (Public)

Switching Hub (Private)

IBM System x3650

IBM System x3650

IBM System x3650

Repository Service

Consumer Portal Engine

Database

IBM System x3650Device Portal #1

Device Portal #2 IBM System x3650

psXML Testbed 완성 모습

위 그림은 실제 구축된 Consumer Portal과 Device Portal의 Configuration에 대한 그림이다.

7. Device Portal 연동 테스트

Device Portal 과의 연동테스트는 다음과 같은 범주와 절차에 의해서 이루어졌으며

성공적으로 결과를 산출하였다.

- Device Portal 에서 Device Repository로의 연동을 통해 Device Profile을 추출해 감.

- Consumert Portal에서 Device Portal 이 관리하는 디바이스의 계층적 목록을 얻어옴.

- Consumer Portal 에서 기간별 조회를 통해 Device Portal 로부터 Device 의 속성값을

조회하여 Database 에 저장함.

- Device Portal 로부터의 응급메시지를 수신하여 Database 에 저장함.

- Consumer Portal 로부터 Device 설정변경 메시지를 Device Portal 로 전달하여 Device 의

설정값을 변경함.

위 그림은 SOAP 툴을 이용하여 실제 Device Portal 과 연동하여 전력설비의 정보를

읽어오는 예제이다. 이러한 표준적인 SOAP 프로토콜을 이용하여 BM을 개발할 수 있다.

제 2 절 연구개발 수행 결과

1. 개발 결과 (제품, 시스템 등)

본 연구를 통해서 다음과 같은 프로그램과 시스템이 개발되었다.

- Consumer Portal / Device Portal 연동 엔진

- Consumer Portal SOAP Interface

- Sanion DC 연동을 위한 Device Driver

- Device Portal 로부터 전송 받은 데이터를 저장하는 캐쉬 데이터베이스 시스템

- 이중화 및 Fail-over 구성된 Consumer Portal 테스트베드 시스템

제 5 장 연구개발결과의 활용계획

본 연구를 통해서 개발된 Consumer Portal 은 상용화를 고려하여 개발되었으므로 바로

상용으로 적용이 가능하다. 주 수요 대상은 ESP 사업자로서 대상 고객 사이트의

전력설비의 수요치를 모니터링하고, 이를 바탕으로 DR, 탄력 가격제 등을 적용하기 위한

기반 플랫폼으로 활용할 수 있다.

또한 SOAP 기반의 표준 SOA 아키텍쳐로 개발되어 ESP 사업자가 쉽게 부가 서비스를

붙여 구현할 수 있어 확장성도 매우 뛰어나다.

하지만 전력 IT 관련 국제표준인 IEC61850/IEC61968/IEC61970 등과는 아직 연동이 되지

않으므로 수출형 제품이 되기에는 무리가 있다. 앞으로 이런 부분을 보강하여 해외

수출도 가능한 형태로 개발할 필요가 있다.