KR20090090047A

KR20090090047A - Ｒｆｉｄ 비즈니스 인식 프레임워크

Info

Publication number: KR20090090047A
Application number: KR1020080015287A
Authority: KR
Inventors: 염근혁; 김성진; 남태우; 김한준
Original assignee: 부산대학교 산학협력단
Priority date: 2008-02-20
Filing date: 2008-02-20
Publication date: 2009-08-25
Also published as: KR100974621B1; US20090210887A1

Abstract

RFID 비즈니스 인식 프레임워크를 제공한다. RFID 비즈니스 인식 프레임워크는 애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가, 애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 정보를 수집하는 Event 매니저 모듈과, RFID 비즈니스 인식 프레임워크와 RFID 비즈니스 인식 프레임워크 사용자와의 상호작용을 담당하는 User 인터페이스 모듈과, ONS, 및 EPCIS DS와의 통신을 담당하는 External 액세서 모듈과, EPCIS와의 통신을 담당하는 EPCIS 액세서 모듈과, RFID 비즈니스 이벤트 또는 EPCIS 이벤트를 생성하는 Biz 이벤트 코어 모듈과, RFID 비즈니스 인식 프레임워크의 서비스, 참조 명세, 설정 정보를 관리하는 BizAF 매니저 모듈 및 Biz 이벤트 코어 모듈에 의해서 생성된 RFID 비즈니스 이벤트를 응용시스템에 전달하는 Biz 이벤트 디스패처 모듈을 포함하고, 비즈니스 이벤트 명세(BESpec)에 의해 RFID 미들웨어 계층을 통하여 전달받는 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 RFID 비즈니스 이벤트를 정의하는 것을 특징으로 한다.

BiaAF(Business-Aware Framework), RFID 미들웨어, EPC 네트워크

Description

ＲＦＩＤ 비즈니스 인식 프레임워크{Radio frequency identification business-aware framework}

　본 발명은 RFID 비즈니스 인식 프레임워크에 관한 것으로, 실시간 RFID 응용 애플리케이션을 개발하는데 있어서 요구되는 통신 기술이나 통신 모듈과 같은 기반 환경을 제공함으로써, RFID 시스템의 빠른 개발 및 관리를 지원하는 RFID BizAF(RFID 비즈니스 인식 프레임워크)를 제공하는 RFID 비즈니스 인식 프레임워크에 관한 것이다.

본 발명은 무선주파수 인식기술(Radio Frequency Identification: 이하 RFID) 기반의 소프트웨어 개발을 지원하기 위한 비즈니스 인식 미들웨어 플랫폼 기술이다.

RFID 기술은 객체에 부착된 일련의 코드를 리더기를 이용하여 객체를 인식하고 처리한다는 관점에서 바코드와 유사성을 가진다. 그러나 RFID는 객체에 직접 접촉하지 않아도 인식할 수 있고, 장애물을 투과해서 감지한다는 점에서 기존 바코드와 차이점을 가진다. 또한, 한 번에 여러 개의 태그를 인식할 수 있으며, 대용량 메모리를 가지고 있어서 많은 정보를 저장할 수 있다. 이와 같은 장점을 바탕으로 물류관리, 유통관리, 상황인식 등의 많은 분야에서 RFID 기술을 도입하려 하고 있다.

RFID 관련 기술의 공개 표준화를 담당하고 있는 비영리 단체인 EPC 글로벌은, 현재　EPC 글로벌 네트워크(즉, EPC 네트워크)라는 국제 표준을 제시하고 있다. EPC 네트워크는 객체의 고유한 정보를 나타낼 수 있는 EPC(Electronic Product Code) 정보를 사용함으로써, RFID 기술을 인터넷과 연결하여 유통 물류망에서 객체의 자동식별, 아이템의 정보를 공유할 수 있게 한다. 인터넷의 개념과 같이 각각의 로컬 EPC 네트워크가 모여서 글로벌 EPC 네트워크가 구축됨으로써 EPC 태그가 부착된 어떠한 아이템이라도 언제, 어디에서, 어떤 비즈니스와 연관되어 있었는지가 파악될 수 있다. EPC 네트워크는 고유한 객체 정보인 EPC의 중복성을 제거하여 수집하고, 관련 정보를 얻을 수 있는 아키텍처인 EPC 네트워크 아키텍처를 제시한다.

도 1에 도시된 바와 같이, 종래 EPC 네트워크 아키텍처는 EPC 태그, RFID 리더(102), RFID 미들웨어(104), EPCIS 캡쳐 어플리케이션(Capturing Application)(106), 로컬 EPCIS(108), ONS(Object Naming Service)(110), EPCIS DS(EPCIS Discovery Service)(112) 등으로 구성될 수 있다.

여기서, EPC 네트워크 아키텍처를 기반으로 하는 응용시스템을 개발할 경우, 개발자는 RFID 미들웨어, ONS, EPCIS(EPC Information Service) 등과 같은 다양한 서비스를 사용하기 위해서 ALE 인터페이스, EPCIS 인터페이스와 같은 다양한 인터페이스를 준수해야 하고 통신 프로토콜을 습득해야 한다. 이는 개발자가 응용시스템을 개발하는 것을 어렵게 한다. 또한, 응용시스템을 개발 하는데 있어서 EPC 네 트워크 아키텍처의 구성요소와의 상호작용을 담당하는 부분과 RFID 기술과는 관계없는 순수한 비즈니스 로직이 섞여 있다면, 급변하는 비즈니스 환경에서 응용시스템이 처리해야 할 비즈니스 로직이 수정되어야 할 때, RFID의 기술적인 처리 부분까지도 깊숙이 연관해서 고려되어야 하는 복잡성을 유발 시키므로 유지보수를 어렵게 한다. 추가적으로 응용시스템의 동작 시에도 RFID 기술의 처리를 위해서 리소스를 투자해야 하므로 응용시스템이 처리해야 할 고유의 업무에 부하를 발생 시킬 수 있는 문제도 발생시킬 수 있다.

따라서, RFID 시스템의 빠른 개발 및 관리를 지원할 필요성이 제기된다.

본 발명은 RFID 비즈니스 인식 프레임워크를 제공하여, 실시간 RFID 응용 애플리케이션을 개발하는데 있어서 요구되는 통신 기술이나 통신 모듈과 같은 기반 환경을 제공함으로써, RFID 시스템의 빠른 개발 및 관리를 지원하는 데에 그 목적이 있다.　

또한, 실시간 RFID 이벤트 기반의 응용시스템의 개발, 운영, 유지보수를 지원하기 위해 비즈니스 이벤트 명세(BESpec)을 정의 및 관리함으로써, 개발자와 RFID 시스템 사이에 변화에 민첩하게 대처할 수 있는 중간 단계의 프레임워크를 제공하고, 이를 통해 실제 비즈니스에서 발생하는 비용을 줄이고 편이성을 제공하는데 그 목적이 있다.

상기 목적을 달성하기 위하여, 본 발명의 실시예에 따른 RFID 비즈니스 인식 프레임워크는 애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가, 애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 정보를 수집하는 Event 매니저 모듈과, RFID 비즈니스 인식 프레임워크와 RFID 비즈니스 인식 프레임워크 사용자와의 상호작용을 담당하는 User 인터페이스 모듈과, ONS, 및 EPCIS DS와의 통신을 담당하는 External 액세서 모듈과, EPCIS와의 통신을 담당하는 EPCIS 액세서 모듈과, RFID 비즈니스 이벤트 또는 EPCIS 이벤트를 생성하는 Biz 이벤트 코어 모듈과, RFID 비즈니스 인식 프레임워크의 서비스, 참조 명세, 설정 정보를 관리하는 BizAF 매니저 모듈 및 Biz 이벤트 코어 모듈에 의해서 생성된 RFID 비즈니스 이벤트를 응용시스템에 전달하는 Biz 이벤트 디스패처 모듈을 포함하고, 비즈니스 이벤트 명세(BESpec)에 의해 RFID 미들웨어 계층을 통하여 전달받는 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 RFID 비즈니스 이벤트를 정의하는 것을 특징으로 한다.

본 발명의 실시예에 따른 RFID 비즈니스 인식 프레임워크는 애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가, 애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 RFID 이벤트를 실시간으로 수집하는 Event 매니저 모듈을 포함하고, 비즈니스 이벤트 명세(BESpec)에 의해 RFID 미들웨어 계층을 통하여 전달받는 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 실시간 RFID 비즈니스 이벤트를 정의하는 것을 특징으로 한다.

본 발명의 RFID 비즈니스 인식 프레임워크에 따르면 다음과 같은 장점이 있다.

　첫째, 종래에는 EPC 글로벌에서 제시한 EPC 네트워크 아키텍처와 글로벌 벤더들이 제시하는 RFID 솔루션만으로는 RFID 응용시스템의 개발을 위해서 개발자가 여러 EPC 네트워크의 구성요소에 대한 인터페이스와 프로토콜을 습득하고, 통신모듈을 개발해야 하므로, 개발의 시간적 비용적인 측면에서 비효율적이다. 또한, 이러한 방법으로 개발된 응용시스템은 비즈니스 로직과 EPC 네트워크 아키텍처의 구성요소와 통신하는 부분이 코드 상에서 섞이게 되므로 복잡성을 증가시켜 유지보수를 어렵게 한다. 추가적으로 응용시스템이 고유의 업무에 집중하지 못한다는 문제도 발생한다.

그러나,　본 발명에서 제시한 BizAF의 RFID 비즈니스 서비스, 비즈니스 이벤트를 정의할 수 있는 BESpec을 사용함으로써 이와 같은 문제를 해결할 수 있고, BizAF를 사용하는 경우에 사용하지 않는 경우보다 개발시간, 개발모듈이 감소하므로 RFID 비즈니스 응용시스템을 개발하는데 효용성을 얻을 수 있다.

둘째, 종래의 EPCIS만을 이용하여 개발하는 응용 애플리케이션과는 달리 실시간 RFID 이벤트에 따라 정보를 가공하기 때문에, RFID 태그가 인식되는 순간 실시간으로 수행되어야 하는 모니터링 및 동작 제어 관련 응용 애플리케이션에서 유용하게 사용되어질 수 있다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

본 발명은 실시간 RFID 이벤트 기반의 애플리케이션 개발을 지원하기 위해 이벤트의 획득 및 가공 과정을 정의한 비즈니스 이벤트 명세(BESpec)과 BESpec의 실제 적용을 위한 (RFID) 비즈니스 인식 프레임워크(BizAF)를 포함하는 것을 특징으로 한다.

BESpec은 BizAF 사용자에 의해서 기술되며 BizAF가 어떻게, 어떤 순서를 가지고 EPC 네트워크 아키텍처의 여러 구성요소와 통신하여 정보를 획득하고, 이 정보에 비즈니스 룰을 적용하여 비즈니스 이벤트를 생성할지에 대한 정의를 담당한다. BESpec은 편리한 작성과 확장성을 위해 바람직하게는 XML 형태로 정의될 수 있 으나 이에 한정되지 않음은 물론이다.

도 2와 도시된 바와 같이, BESpec은 크게 세 부분으로 구성될 수 있으며, 변수 선언 부분(210)과 여러 종류의 처리과정을 정의하는 액티비티 부분(220), 액티비티에서 처리를 하기 위해 참조하는 참조 명세(230)가 있다. 변수 선언 부분(210)에서는 액티비티의 처리 중간에 처리 값들을 저장하는데 사용된다. 변수를 통해서 한 액티비티에서 처리된 결과를 다른 액티비티에서 사용할 수 있다. 그리고, 액티비티 부분(220)에서는 RFID 비즈니스 이벤트를 생성하기 위해서 조합될 수 있는 여러 역할의 액티비티가 정의되어 각 액티비티마다 내부적으로 기술해야 할 속성 값을 다르게 가질 수 있다. 참조 명세(230)는 RFID 미들웨어와의 상호작용을 처리하는 프로바이더 명세(이하, ProviderSpec)(230a), EPCIS와의 상호작용을 처리하는 EPCIS 질의 명세(이하, QuerySpec)(230c), EPCIS 캡쳐 명세(이하, CaptureSpec)(230b)가 존재한다. 각 참조 명세는 EPC 네트워크 아키텍처의 표준 인터페이스를 준수할 수 있도록 정의되었으며, BESpec과는 독립성을 유지함으로써 추후에 EPC 네트워크 아키텍처의 특정 구성요소의 인터페이스가 변동된다고 하더라도 BESpec 자체의 수정 없이, 특정 참조 명세만을 수정함으로써 처리가 가능하게 된다.

보다 구체적으로, 참조 명세, 변수, 액티비티 그리고 전체 내용을 포함하는 BESpec의 순으로 후술하기로 한다.

참조 명세(230)는 ProviderSpec(230a), CaptureSpec(230b), QuerySpec(230c)으로 구성될 수 있다.

ProviderSpec(230a)은 실시간 이벤트를 제공하는 이벤트 제공자와의 상호작용을 정의하는 명세이다. 여기서, 실시간 이벤트 제공자를 RFID 미들웨어로 한정하여 명세가 구성되거나, RTLS(Real-Time Locating Systems) 또는 여러 센서로부터 실시간 이벤트 수집에 관하여 정의의 확장이 가능하도록 명세가 구성될 수 있다. EPC 글로벌에서는 RFID 미들웨어의 인터페이스인 ALE(Application Level Event) 인터페이스를 ALE 스펙 1.1 에서 정의하고 있다. ALE 스펙에 따르면 RFID 미들웨어에 ECSpec을 정의하면 RFID 리더로 부터 수집된 EPC 정보가 ECReport라는 형태로 전달 받게 된다. ProviderSpec(230a)은 ALE 스펙에서 정의한 ECSpec을 포함하고, 대응되는 ECReport의 값을 BESpec이 처리 중에 사용할 수 있도록 키워드를 가진다. BizAF 사용자에 의해서 작성된 ProviderSpec(230a)은 BizAF에 등록할 수 있고, 등록 시에 참조할 수 있는 이름을 같이 등록함으로써 BESpec에서 참조이름을 통해서 ProviderSpec(230a)을 사용할 수 있다.

도 3a는 ProviderSpec(230a)의 스키마를 도시한다. 도3a에 도시된 바와 같이, ProviderSpec(230a)의 스키마에 포함된 엘리먼트인 ECSpec은 하나만 존재할 수 있으며, ECSpec의 세부적인 스키마는 ALE 스펙 1.1을 참조하기 바란다.

도3b는　ProviderSpec(230a)의 예시를 도시한다. 도3b에 도시된 바와 같이, BizAF가 RFID 미들웨어와 연결되어 있는 Lreader0이라는 논리적 RFID 리더에 수집되는 EPC 정보를 전달받는 것을 의미하며, 예를 들어 4초 마다 한 번씩 중복된 EPC가 제거된 정보를 가지고 있는 ECReport를 전달 받게 된다. ProviderSpec(230a)은 ProviderSpec(230a)에 의해서 RFID 미들웨어로 부터 전달받게 되는 ECReport를 참 조할 수 있도록 바람직하게는 이하 표1과 같은 키워드를 제공할 수 있다.

키워드 명	설명
epcList	epc 값의 목록을 참조
tagList	tag 값의 목록을 참조
count	epc의 개수를 참조
eventTime	ECReport의 발생 시간 참조

[표 1]

도3c는 도3b의 ProviderSpec(230a)이 RFID 미들웨어에 정의 되었을 때, BizAF가 RFID 미들웨어로 부터 전달받게 되는 ECReport의 예시를 도시한다. 도 3c에 있어서, 두 개의 태그가 RFID 리더에 읽혔고 태그가 가지고 있는 EPC 정보를 전달 받았음을 확인할 수 있다. 여기서, ECReport에 포함 되어 있는 속성 정보는 키워드를 사용함으로써 참조가 가능하다. 키워드의 사용 형식은 다음과 같다. ($String)의 String은 변수를 의미한다.

- #($참조이름).($reportName).($키워드)

- #($참조이름).eventTime

만약, BizAF에 상기 도3b와 같은 ProviderSpec(230a)이 provider1 이라는 참조 이름으로 등록되었다면, #provider1.report1.epcList 와 같은 기술로 참조하고, 참조를 통해서 얻을 수 있는 값은 다음과 같은 EPC의 목록이 될 수 있다.

- urn:epc:id:gid:173015040.1552.5520031849

- urn:epc:id:gid:173015040.1552.5520031845

다음으로, CaptureSpec(230b)은 EPCIS에 RFID의 이력정보를 저장하기 위해서 정의하는 명세이다. apureSpec은 EPCIS 스펙 1.0의 CaptureService에서 EPCIS Event를 참조한다. EPCIS 이벤트는 Object Event, Aggregation Event, Quantity Event, Transaction Event를 말하며 각각의 이벤트는 여러 속성을 가지고 있다.

도3d는 CaptureSpec(230b)의 스키마를 도시한다. 도3d에 도시된 바와 같이, CaptureSpec(230b)의 스키마는 EPCIS 이벤트(EPCIS Event)(342)를 포함한다. BizAF는 정의된 EPCIS 이벤트에 따라서 EPCIS 이벤트를 생성하여 EPCIS에 저장한다. BESpec은 ProviderSpec(230a)의 참조를 통해서 실시간으로 전달받게 되는 ECReport의 내용을 입력 값으로 사용하고, CaptureSpec(230b)을 참조하여 EPCIS에 EPCIS 이벤트를 저장 할 수 있다. 이 경우에, 실시간으로 전달받는 RFID 이벤트에 포함되어 있는 속성정보는 CaptureSpec(230b)을 정의하는 시점에 미리 알 수가 없으므로, 바람직하게는 # 키워드를 사용한다.

도3e는 CaptureSpec(230b)의 예시를 도시한다.

도 3e에 있어서, Object 이벤트 하나를 정의하였으며, <action>과 <bizStep>, <readPoint> 엘리먼트에서는 정적으로 값을 정의하였음을 알 수 있다. <eventTime>. <epcList> 엘리먼트에는 각각 키워드(#)가 사용되었는데, BESpec의 해석 중에 이 키워드가 지정되어 있는 엘리먼트의 이름을 사용해서 동적으로 값을 할당하여 EPCIS 이벤트를 생성하게 된다.

다음으로, QuerySpec(230c)은 EPCIS 저장소에 저장되어 있는 EPC와 관련한 이력정보 또는 고유정보를 질의하기 위한 명세이며, BESpec에서 참조된다. EPCIS를 이용해서 EPC와 관련한 정보를 질의하기 위해서는, EPCIS 스펙 1.0의 EPCIS 질의 제어(EPCIS Query Control) 인터페이스를 준수하여야 한다. EPCIS 질의 제어 인터페이스 중에서 poll()은 동기적인 방식으로 EPCIS에 저장되어 있는 정보를 질의할 수 있는 오퍼레이션이고, QuerySpec(230c)에서는 poll()을 사용하여 이력정보와 고유정보를 획득하도록 정의하였다.

도 3f는 QuerySpec(230c)의 스키마를 도시한다. QuerySpec(230c)의 스키마는 queryName, queryParams로 구성될 수 있다. queryName은 어떠한 종류의 질의를 할지를 정의하며 queryParams에는 질의 조건을 입력한다. queryName과 queryParams의 스키마는 EPCIS 스펙을 참조한다. QuerySpec(230c)의 경우에도 작성되는 시점에는 어떠한 EPC에 대한 물품의 관련정보를 질의해야 할 지가 정해져 있지 않으므로 #epc라는 키워드로써 동적으로 epc 값을 정의할 수 있다.

도3g는 EPC를 가지는 물품의 제조일 정보를 질의하기 위한 예시를 도시한다. queryName에는 고유정보를 질의한다는 의미를 가지는 SimpleStaticQuery가 명기 되었고, params에는 세 가지 조건이 설정 되었다. 조건 중에서 EQ_epc 라는 문자열은 특정 EPC와 일치하는 것을 찾는다는 의미인데 여기서는 #epc 라는 키워드가 기술되었고, 추후에 동적으로 EPC의 값을 설정하여 EPCIS에 질의할 수 있도록 정의되었다. 임의의 EPC값이 설정되었다고 가정하고 EPCIS에 질의 했을 때 2007-07-05T16:51:24.000+09:00 와 같은 제조일 정보를 획득할 수 있다.

도3h는 EPC를 가지는 물품의 이력정보를 질의하는 예시이다. SimpleEventQuery(382) 라는 QueryName은 이력정보를 질의한다는 의미이며, params로 Object 이벤트(384) 라는 조건과 #epc 키워드가 사용되었다. 특정 urn:epc:id:gid:173015040.1552.5520031849 라는 EPC 값이 설정되었다고 가정하고 EPCIS에 질의했을 때 관련된 Object 이벤트가 결과로 리턴된다.

한편, BESpec은 액티비티 라는 여러 처리과정을 포함하고 있는데, 각 액티비티 사이에서 처리된 결과를 넘겨주거나, 전달받기 위한 매개체로서 변수를 사용한다. BESpec이 지원하는 변수형은 기본형인 int, string과 RFID의 특화 형인 EPC, tag, event가 있고, 시간 표현형인 dateTime이 있다. EPC와 tag형은 태그의 EPC값을 저장하고 참조할 수 있도록 정의 되었으며, event형은 EPCIS 이벤트 하나를 저장하고 참조할 수 있도록 정의되었다. dateTime형은 xmlschema의 dateTime과 같은 형태이다. 그리고 모든 변수형은 list 속성을 통해서 특정 형의 목록을 표현하고 참조할 수 있도록 설계되었다.

도 3i는 변수의 스키마를 도시한다. 도 3i에 도시된 바와 같이, 변수의 스키마를 나타내며 <variables> 라는 엘리먼트로 표현한다. type에서 변수형을 지정하고 list에서 목록의 형태인지 아닌지를 설정하고, initValue 에서 초기값을 지정할 수 가 있다. list 가 설정되어 있을 경우에는 초기값을 지정할 수가 없다. 스키마에서 표현되는 일반적인 데이터 형과 구분하기 위하여 BESpec에서의 변수는 bespec 이라는 네임 스페이스로 지정하고 목록형태의 변수는 변수명+List 로 표현한다.

그리고, 도3j는 각 변수형에 대한 예시이다.

액티비티는 RFID 비즈니스 이벤트를 생성하기 위한 작업의 기본적인 단위로써 BESpec에서 정의되었다. RFID 비즈니스 이벤트를 생성하기 위해서는 RFID 미들웨어, ONS, EPCIS DS, EPCIS와의 상호작용이 필요하고 각각의 구성요소로 부터 받은 정보를 가공하는 여러 처리가 요구된다. 각각의 작업은 독립적인 액티비티로서 정의되고, 각 액티비티는 BESpec 내에서 어떻게 조합되는가에 따라서 다른 비즈니 스 이벤트를 정의할 수 있다.

액티비티 명	설명
Providers	실시간 이벤트 제공자로부터 실시간 이벤트를 수집
ONS	ONS로부터 고유정보를 보유한 EPCIS 주소 질의
EPCIS DS	EPCIS DS로부터 이력정보를 보유한 EPCIS DS 주소 질의
EPCIS	EPCIS로부터 속성정보, 이력정보를 질의
List	변수의 목록형에 대한 반복처리
Compute	산술연산 처리
Event	룰의 적용 및 비즈니스 이벤트 생성

[표 2]

BESpec 에서 정의된 액티비티의 종류는 상기 표 2와 같다. 각 액티비티는 고유의 업무를 처리하며, 내부적으로 처리를 위한 속성을 가진다. 액티비티는 작업의 특성상 내부에 다른 액티비티를 포함할 수 있는 경우도 있다.

여기서, 도 4에 도시된 바와 같이, 포함 가능 액티비티와 단일 액티비티로 분류될 수 있다. 또한 앞 절에서 소개된 참조 명세는 특정 액티비티에서 작업의 처리를 위해서 사용된다.

한편, Providers 액티비티는 ProviderSpec(230a)을 참조하여 실시간 이벤트를 수집하는 처리를 담당한다. 현재는 실시간 이벤트 제공자를 RFID 미들웨어로 한정하므로 ALE 인터페이스를 준수하여 ECSpec을 전달하고, ECReport를 받을 수 있는 역할로 규정한다.

도3k에 도시된 바와 같이, Providers 액티비티의 구조는 <ALE> 엘리먼트와 <within> 엘리먼트로 구성된다. <ALE> 엘리먼트는 어떤 ProviderSpec(230a)을 참조하여 사용할 것인가에 대한 정의를 담당한다. 그러므로 <ALE> 엘리먼트의 값은 ProviderSpec(230a)의 참조 이름이 작성되어야 한다. 또한 여러 ProviderSpec(230a)이 정의되어 있다면 여러 <ALE> 엘리먼트를 반복 기술함으로써 여러 ECReport의 값을 참조할 수 있다.

<within> 엘리먼트는 밀리세컨드의 숫자 값을 가질 수 있는데 Provider 액티비티에 <ALE> 엘리먼트가 두 개 이상 존재했을 때 정의가 가능하다. <within> 에 기술되는 숫자 값의 의미는 다음 식의 t 와 같다.

Where CE = Composite Event, RE = RFID Event,

CE = Within( RE0, RE1 ,… , REn, t)

즉, 기술된 ProviderSpec(230a) 하나당 RE가 수집되게 되는데, 제일 처음에 정의된 ProviderSpec(230a)과 연관된 RE가 발생한 시점부터 t 시간 이내에 발생한 모든 RE를 집합화한 것이 CE 이다.

<ALE> 엘리먼트가 하나 일 경우에는 당연히 <within> 엘리먼트가 기술되지 않아야 하지만, 두 개 이상일 경우에도 <within> 엘리먼트가 기술 되지 않을 수 있다. <within> 엘리먼트가 존재하지 않는 여러 <ALE> 엘리먼트의 의미는 모든 <ALE> 엘리먼트에서 참조된 ProviderSpec(230a)에 대응하는 BEReport 중에서 제일 먼저 수집되는 BEReport를 기준으로 해서 모든 연관된 BEReport 가 수집될 때 까지 기다리면서 집합화를 하는 것이다.

도3l은 Providers 액티비티의 예제이다. 다른 ProviderSpec(230a)이 세 개 작성 돼서, ProviderA, ProviderB, ProviderC 라는 참조명을 각각 가지고 있다고 가정했을 때 <within> 엘리먼트의 값이 5000이 정의되었다. 도3l에 도시된 바와 같이, 작성된 Providers 액티비티의 처리는 도 5에 도시된 예시를 통해 알 수 있다. 각 ProviderSpec(230a) 정의를 통해서 받게 되는 ECReport를 ECReportA, ECReportB, ECReportC 라고 한다면, 각 ECReport는 RFID 미들웨어가 주기적으로 BizAF에 전달하게 된다. 이 때, ECReportA0를 받은 시점부터 5000 밀리세컨드 이내에 받는 ECReport를 집합화 하고, 중간에 ECReportA1을 받은 시점부터 다시 집합화를 하게 된다. 이러한 Prviders 액티비티의 처리는 다른 형태로 정의된 여러 RFID 이벤트를 조합하여 RFID 비즈니스 이벤트를 생성할 때 더 고 수준의 의미를 가질 수 있도록 한다. 또한 RFID 이벤트 뿐 만이 아니라 추후에 RTLS, 센서 이벤트를 수집할 수 있도록 확장 됐을 때 각기 다른 형태의 이벤트를 조합하여 사용할 수 가 있다. EPC와 연관된 물품의 고유정보는 일반적으로 제조업체의 EPCIS를 통해서 질의할 수 있는데, ONS 액티비티는 고유정보를 가지고 있는 EPCIS의 주소를 획득하기 위하여 ONS와의 상호작용을 정의한다.

도 3m은 ONS 액티비티의 구조를 도시한다. 도 3m에 도시된 바와 같이, address 속성은 ONS의 주소 정보이며, epc 속성은 질의를 위해 ONS에 전달할 epc 값을 가지고 있는 변수가 설정되어야 한다.

도 3n은 ONS 액티비티의 예시이다. 도 3n에 도시된 바와 같이, ONS의 주소가 기술 되었고, 질의할 EPC 정보가 vEPC 라는 EPC 형 변수에 저장돼 있다고 가정하여 설정하였고, 이때 해당 ONS에 질의를 던져서 결과로 받게 되는 EPCIS의 주소는 vManufactureEPCISAddress 라는 string형 변수에 저장된다. ONS 액티비티가 생략될 수 도 있는데, 그런 경우에는 BizAF에 기본적으로 설정돼 있는 ONS에 질의하도록 처리된다. 특정한 EPC의 물품과 연관이 있는 이력정보는 물류의 흐름에 따라서 글로벌하게 분산된 EPCIS에 흩어져서 저장되므로 이력정보가 정확히 어디 있는지 찾 는 것은 어려운 일이다. 이러한 문제 때문에 이력 정보를 검색하기 위해서는 먼저 물품의 이력정보가 저장돼 있는 EPCIS 주소의 목록을 찾아주는 EPCIS DS를 사용해야만 한다. EPCIS DS 액티비티는 특정 EPCIS DS와의 상호작용을 담당한다.

도 3o는 EPCIS DS 액티비티의 구조를 나타낸다. 도 3o에 도시된 바와 같이, operation 속성에 EPCIS DS의 지원 오퍼레이션을, epc 속성에 질의할 EPC 변수를 정의한다. opertation 속성에는 EPC에 대한 이력정보를 제공하는 EPCIS의 주소목록을 리턴하는 getEPCMovingLocation 을 지원한다. address 속성에는 상호작용할 EPCIS DS의 주소를 기술 할 수 있는데 이를 기술하지 않으면 BizAF에 설정된 기본 EPCIS DS의 주소를 사용한다.

예시는 도 3p와 같다. vEPC 변수에 저장돼 있는 EPC 값에 대한 이력정보를 저장한 EPCIS의 주소목록이 vEPCISAddrList 변수에 저장된다. EPCIS 액티비티는 EPCIS와의 상호작용을 처리하는데, 물품의 고유정보 또는 이력정보의 질의를 처리하거나 이력정보를 EPCIS에 저장하는 처리에 대한 정의를 담당한다. EPCIS 액티비티에는 QuerySpec(230c)과 CaptureSpec(230b)을 참조하여 EPCIS와 관련된 처리를 수행하게 된다.

도 3q는 EPCIS 액티비티의 구조를 도시한다. 도 3q에 도시된 바와 같이, 상호작용할 EPCIS의 주소가 설정될 address 속성이 있고, 액티비티의 처리 목적에 따라서 <getEventData>, <getStaticData>. <captureEventData>가 선택되어 사용된다. <getEventData> 엘리먼트는 이력정보를 질의하기 위해 사용되며, query 속성에 특정 QuerySpec(230c)의 참조명을 기술하여 EPCIS 질의를 수행하는데 참조한다. epc 속성에는 QuerySpec(230c)의 키워드인 #epc 자리에 질의할 EPC값을 설정하도록 EPC 변수명을 정의한다. <getStaticData> 엘리먼트는 고유정보를 질의하기 위해 사용되며, QuerySpec(230c)의 참조와 epc 속성에 관한 부분이 <getEventData> 엘리먼트와 동일하다. <captureEventData> 엘리먼트는 EPCIS에 이력정보를 저장하기 위한 부분으로써 CaptureSpec(230b)을 참조하여 EPCIS에 캡처한다. CaptureSpec(230b)에서 정의한 키워드에 값을 할당하기 위해서는 키워드가 정의된 CaptureSpec(230b)의 특정 엘리먼트 구조를 <captureEventData> 엘리먼트 내부에 작성하여 전달하도록 한다.

도 3r은 EPCIS 액티비티의 예시이다. 도 3r에 도시된 바와 같이, 첫 번째 EPCIS 액티비티는 고유정보를 질의하도록 명세되었다. StaticDataQuery1 이라는 참조명을 가진 QuerySpec(230c)을 참조하고 질의한 결과를 vDateOfManufacture 라는 dataTime 형 변수에 저장하도록 정의가 된 것을 알 수 있다. 두 번째 액티비티는 이력정보를 질의하도록 명세되었다. EventDataQuery 라는 참조명을 가진 QuerySpec(230c)을 참조하고 질의한 결과를 목록 형태의 event 변수인 vEventList 에 저장하도록 정의됐음을 알 수 있다. 세번째 EPCIS 액티비티는 이력정보의 저장이 명세되었다. EventDataCapture1 이라는 CaptureSpec(230b)을 참조하도록 정의되었는데, 참조하는 CaptureSpec(230b) 에서 정의한 키워드를 통하여 시간 정보와 EPC 정보를 동적으로 할당할 수 있도록 정의 된 것을 알 수 있다. RFID 미들웨어로 부터 수집되는 ECReport에는 EPC의 목록이 포함되어 있다. 그러므로 여러 EPC에 대해서 동일한 작업의 반복처리가 필요하게 되는데 List 액티비티는 이와 같은 반복 처리를 담당한다.

도 3s에 도시된 바와 같이, List 액티비티는 <list> 엘리먼트를 사용하여 정의한다. <list> 엘리먼트는 source와 assign 두 개의 속성을 가진다. source 속성은 반복처리를 수행할 대상 리스트를 기술하는데 목록형태의 EPC 변수가 정의될 수 있다. List 엘리먼트 내부에는 다른 액티비티들이 포함될수 있는데, source에 명기된 목록 변수의 크기만큼 반복하여 포함된 액티비티의 작업을 수행한다. assign 속성에는 source에 정의된 목록의 특정 값을 할당하여 list 요소의 내부에 포함된 액티비티에서 사용할 변수명을 기술한다.

도 3t는 List 액티비티의 예시이다. 도 3t에 도시된 바와 같이, source 속성에서 EPC의 목록 값을 가지고 있는 vEPCList 변수가 설정되었고, assign 속성에는 vEPC라는 단일 EPC 값을 저장하기 위한 변수가 설정되었다. vEPCList 에 저장되어 있는 EPC의 갯수만큼 내부에 있는 ONS와 EPCIS 액티비티의 처리를 반복한다. RFID 비즈니스 이벤트를 생성하는데 있어서 특정 숫자의 총 합을 계산한다던가 특정 비즈니스 룰을 만족하는 EPC의 개수를 구하는 것과 같은 기본적인 산술 처리가 필요하다. Compute 액티비티는 이러한 처리작업을 지원할 수 있도록 하기위해 기본적인 산술 연산을 지원한다.

도 3u는 Compute 액티비티의 구조를 도시한다. 도 3u에 도시된 바와 같이, <expression> 엘리먼트에 변수를 사용하여 산술 연산식을 정의할 수 있는데, 지원 연산자는 표3과 같다. 그리고, 도3v는 int 형의 vProductSum 변수를 사용한 예시이다.

종류	연산자
산술 연산자	+, -, *, /
할당 연산자	=
우선 순위 연산자	(, )

[표 3]

Event 액티비티는 RFID 이벤트와 이와 연관된 여러 참조정보, 연산결과를 이용하여 최종적으로 RFID 비즈니스 이벤트를 생성하는 처리에 관한 정의를 담당한다.

도3w에 도시된 바와 같이, Event 액티비티의 구성은 이벤트를 구분하기 위한 name 속성, <condition> 엘리먼트, <action> 엘리먼트, <dataSet> 엘리먼트로 이루어져 있다.

<condition> 엘리먼트에는 비즈니스 이벤트를 생성하기위한 조건식이 기술된다. 조건식이 참이라면 비즈니스 이벤트를 생성하고 참이 아니라면 이벤트를 생성하지 않는다. 조건식을 지원하는 연산자는 표4와 같다.

종류	연산자
관계 연산자	==, !=, >, <, >=, <=
논리 연산자	&, \|
우선 순위 연산자	(, )

[표 4]

<action> 엘리먼트는 내부에 다른 액티비티를 포함 할 수 있는데 <condition> 엘리먼트에서 참일 경우에 포함된 액티비티를 수행하게 된다. 그러나 별도의 다른 액티비티의 처리가 필요하지 않다면 <action> 엘리먼트는 생략 될 수 있다.

<dataSet> 엘리먼트는 조건을 만족하여 비즈니스 이벤트가 생성될 시에 물품 의 고유정보 또는 이력정보와 같은 연관정보를 포함할 수 있도록 정의되었다. <dataSet> 엘리먼트는 고유의 독립적인 정보를 의미하는 <data> 엘리먼트의 집합으로 구성될 수가 있다.

도3x는 물품이 특정 날짜 이전에 제조된 것에 관해 리콜 처리를 하기 위해서 정의된 Event 액티비티의 사용 예시이다. <condition> 엘리먼트에서 특정 날짜가 정의된 변수와 물품의 제조일이 저장되도록 정의된 변수와 비교하여 조건을 만족할 경우에 RecallBizEvent 라는 이름을 가지는 비즈니스 이벤트를 발생하는 것으로 정의 되었고, 이에 따르는 연관정보로 상품정보가 정의 되었다.

의미적으로 호칭되는 비즈니스 이벤트는 BEReport(Business Event Report)라는 형태의 XML 메세지로 정의된다. BEReport는 BizAF에 의해서 생성되며, 응용시스템의 수신 주소에 발송되게 된다.

도 3y는 BEReport의 스키마를 도시한다. 하나의 BESpec에 여러 Event 액티비티가 정의될 수 있는데 각각의 액티비티가 생성하는 이벤트가 BEReport의 <BizEvent>엘리먼트와 대응된다. <BizEvent> 내부의 <dataSet> 엘리먼트는 <Event> 액티비티에서 정의된 <dataSet> 엘리먼트의 구성과 동일하게 정의된다.

그리고, 도3z는 도3x에서 표현된 Event 액티비티의 예시에 대응하는 BEReport의 예시이다.

위와 같이, BESpec을 정의하고, 정의된 BESpec은 BizAF를 통하여 실제 정보 획득, 가공 처리, 전송을 수행하게 된다.

이하에서는 BizAF에 관한 구성 및 구현에 대해 기술한다.

BizAF가 비즈니스 이벤트 서비스를 제공하기 위해서는 BESpec를 실제로 해석하고,　RFID 미들웨어, EPCIS DS, ONS, EPCIS와 통신하는 모듈이 필요하다. 또한 BizAF 사용자가 RFID 비즈니스 이벤트를 정의할 수 있는 유저 인터페이스가 필요하다. 이러한 요구사항에 따라서 도 6과 같은 BizAF의 내부 구성 모듈이 분석 되었다.

BizAF의 내부 모듈은 User 인터페이스(601), Event 매니저(602), External 액세서(603), EPCIS 액세서(604), Biz 이벤트 코어(605), BizAF 매니저(606), Biz 이벤트 디스패처(607)로 구성되며 각각의 모듈은 외부 구성요소와의 상호작용을 전담하거나, 내부적으로 모듈을 관리, 정보를 가공하는 각자의 역할을 담당하고 있다.

User 인터페이스(601) 모듈은 BizAF와 BizAF 사용자와의 상호작용을 담당하는 역할을 가지고 있다.

도7a는 User 인터페이스(601)의 구성도이다. 내부적으로 UserInterfaceManager(701)가 흐름을 전체 관리하며 ConfigurationManager(702)를 통해 참조 시스템의 정보를 관리한다. ProviderSpecManager(703), CaptureSpecManager(704), QuerySpecManager(705)를 통해 각 참조 명세를 획득하고 BusinessEventManager(706)를 통해 BESpec을 획득, 그리고 비즈니스 이벤트를 생성하는 서비스의 시작과 정지를 수행한다. BizAF 사용자는 이러한 인터페이스를 통해서 이벤트 서비스를 생성하거나 삭제를 할 수 있고, 참조 명세를 관리할 수 있다.

BizAF는 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 RFID 이벤트를 실시간으로 수집해야 한다. 또한 모니터링을 위하여 RFID 미들웨어의 상태, RFID 리더의 상태 또는 구성 정보를 수집해야 한다. 이를 위해, 애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가, 애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 RFID 이벤트를 실시간으로 수집하는 Event 매니저(602) 모듈을 포함한다. 그리고, BESpec에 의해 상기 RFID 미들웨어 계층을 통하여 전달받는 상기 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 실시간 RFID 비즈니스 이벤트를 정의한다.

도7b에 도시된 바와 같이, Event 매니저(602) 모듈은 비동기적인 이벤트를 요청하고 수신할 수 있도록 송신 모듈과 수신 모듈 구조로 설계되었다. 또한 추후에 RFID 미들웨어 이외에도 센서, RTLS와 같은 다양한 이벤트 제공자들과 통신을 할 수 있도록 확장되더라도 ProviderConnection(711) 이라는 세부 모듈을 상속 하여 추가시킬 수 있도록 구성하였다.

도 7c에 도시된 바와 같이, External 액세서(603) 모듈은 ONS, EPCIS DS와의 통신을 담당하는 역할을 가지고 있다. AssessorConfig(721)에서 ONS, EPCIS DS의 주소를 관리하고, 실제적인 통신은 ONSAccessor(722), EPCISDSAccessor(723)에서 처리한다.

도 7d와 같은 EPCIS 액세서(604) 모듈은 EPCIS와의 통신을 담당한다. EPCISConfig(731)에서 참조 EPCIS의 물리적 위치 정보를 관리하고 EPCIS 인터페이스 중 신규 데이터 추가를 위한 capture 인터페이스를 사용하는 경우에는 CapturingAccessor(732)에서 데이터 전송을 수행한다. 반면 이력정보 및 물품 정보를 조회하기 위한 경우에는 QueryAccessor(733)를 통해 EPCIS에 질의를 처리한다.

Biz 이벤트 코어(605) 모듈은 각 명세를 해석하고 그에 따라 다른 여러 모듈의 기능을 사용하여 작업을 수행하고, 최종적으로 RFID 비즈니스 이벤트 또는 EPCIS 이벤트를 생성하는 BizAF 내의 여러 모듈 중에서도 가장 핵심적인 모듈이라고 할 수 있다.

도 7e는 Biz 이벤트 코어(605) 모듈의 구조를 도시한다. CaptureProcess(741)와 BizProcess(742) 모듈은 각각 RFID 비즈니스 이벤트 서비스와 EPCIS 캡처링 서비스에 해당한다.

CaptureProcess(741)는 ProviderSpec(230a)의 정보를 참조하고 EventManger(602) 모듈을 사용하여 RFID 미들웨어에 ECSpec을 전달한다. Event 매니저(602)를 통해서 RFID 이벤트를 수신하면 CaptureSpec(230b) 정보를 참조하여 이 이벤트를 EPCIS Event 로 변환한 후 EPCIS 액세서(604) 모듈을 사용하여 EPCIS에 저장하는 작업을 수행한다.

BizProcess(742)는 BESpec에서 정의된 변수와 액티비티에 대응하는 클래스를 포함한다. BESpec의 각 액티비티는 독립적인 Process 클래스들로 표현되며, 각 Process는 Biz 이벤트 코어(605) 외부의 다른 모듈을 사용하여 작업을 수행한다. ProcessSpec에서는 이러한 Process의 목록을 순서대로 가지고 있게 되며 BizProcess(742)가 ProcessSpec의 Process 목록을 차례대로 수행시킨다. 이러한 구조는 추후에 BESpec의 특정 액티비티의 정의가 수정되거나 새로운 액티비티가 추가되더라도 전체 구조에 영향을 주지 않도록 고려되었다.

BizAF 매니저(606) 모듈은 BizAF 의 메인 모듈이며, BizAF의 모든 서비스, 참조 명세, 설정 정보를 관리하고 BizAF 내의 다른 모듈을 초기화 하고 관리하는 역할을 담당한다.

도 7f는 BizAF 매니저(606)와 관련된 세부 동작 관계를 도시한다. BizAFServer(비즈니스 인식 프레임워크 서버)가 RMI 서버로 동작하고 상세 모듈인 BizAF 매니저(606) 에서 RFID 비즈니스 이벤트 서비스, 참조 명세, 사용자 정보를 관리한다. User 인터페이스(601) 모듈은 이러한 BizAF 매니저(606) 모듈의 인터페이스를 사용하여 화면처리를 수행한다. BizAF에 사용자에 의해 생성된 이벤트 서비스나 등록된 참조 명세는 BizAF 서버가 중지되었다가 다시 실행된다 하더라도 영속적으로 정보를 유지 할 수 있도록 RepositoryManager(751)를 통하여 파일 형태로 관리된다.

도 7g에 도시된 바와 같이, Biz 이벤트 디스패처(607) 모듈은 Biz 이벤트 코어(605) 모듈에 의해서 생성된 RFID 비즈니스 이벤트를 응용시스템에 전달하는 역할을 담당한다. Biz 이벤트 코어(605) 모듈에서 DispatcherManager(761)의 인터페이스를 통하여 이벤트를 발송할 수 있다. 비즈니스 이벤트는 두 가지 형태로 응용시스템에 전달 될 수 있는데 TCP 소켓을 이용하여 BEReport를 발송하는 방법과 BPEL 엔진에 배치된 비즈니스 프로세스를 호출하는 방법이 있다. 각각의 방법은 BEReportDispatcher(762)와 BPInvoker(763)를 통해서 제공된다.

BizAF의 내부 모듈은 위와 같이 구성되었으며, 도 8은 실제 물리적인 배치도를 보여준다. BizAF 관리자에 의해서 EPC 네트워크의 구성 시스템 정보를 관리하고, 관련된 참조 명세를 관리하게 된다. BizAF사용자는 관리자에 의해 등록된 정보를 웹환경에서 조합하여 새로운 비즈니스 이벤트를 생성할 수 있으며, 생성된 비즈니스 이벤트는 BEReport의 형태로 수신되어 진다.

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.

도 1은 종래 EPC 네트워크 아키텍쳐 구성도이다.

도 2는 본 발명의 일 실시예에 따른 비즈니스 이벤트 명세의 구성도 이다.

도 3a내지 도3z는 본 발명의 일 실시예에 따른 비즈니스 이벤트 명세의 스키마와 예시에 따른 XML형태의 명세이다.

도 4는 본 발명의 일 실시예에 따른 비즈니스 이벤트 명세 중 액티비티 요소의 구성도이다.

도 5는 본 발명의 일 실시예에 따른 비즈니스 이벤트 명세 중 다수의 실시간 데이터에 대한 이벤트 주기에 대한 예시이다.

도 6은 본 발명의 일 실시예에 따른 비즈니스 인식 프레임워크의 전체 구성도이다.

도 7a 내지 도7g는 본 발명의 일 실시예에 따른 비즈니스 인식 프레임워크의 내부 모듈 구성도이다.

도 8은 본 발명의 일 실시예에 따른 비즈니스 인식 프레임워크의 물리적 배치도이다.

<도면의 주요 부분에 관한 부호의 설명>

601: User 인터페이스 602: Event 매니저

603: External 액세서 604: EPCIS 액세서

605: Biz 이벤트 코어 606: BizAF 매니저

607: Biz 이벤트 디스패처

Claims

애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가,

애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 RFID 이벤트를 실시간으로 수집하는 Event 매니저 모듈;

상기 RFID 비즈니스 인식 프레임워크와 RFID 비즈니스 인식 프레임워크 사용자와의 상호작용을 담당하는 User 인터페이스 모듈;

ONS, 및 EPCIS DS와의 통신을 담당하는 External 액세서 모듈;

EPCIS와의 통신을 담당하는 EPCIS 액세서 모듈;

RFID 비즈니스 이벤트 또는 EPCIS 이벤트를 생성하는 Biz 이벤트 코어 모듈;

상기 RFID 비즈니스 인식 프레임워크의 서비스, 참조 명세, 설정 정보를 관리하는 BizAF 매니저 모듈; 및

상기 Biz 이벤트 코어 모듈에 의해서 생성된 RFID 비즈니스 이벤트를 응용시스템에 전달하는 Biz 이벤트 디스패처 모듈을 포함하고,

비즈니스 이벤트 명세(BESpec)에 의해 상기 RFID 미들웨어 계층을 통하여 전달받는 상기 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 RFID 비즈니스 이벤트를 정의하는 것을 특징으로 하 는, RFID 비즈니스 인식 프레임워크.
제 1 항에 있어서, 상기 User 인터페이스 모듈은,

사용자에게 참조 명세, 참조 시스템의 정보를 등록가능하며, 참조 명세를 조합하는 것에 의해 새로운 이벤트 서비스를 생성하거나 수정, 삭제, 이벤트 모니터링, 사용자 인증을 관리하는 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.
제 1 항에 있어서, 상기 Event 매니저 모듈은,

상기 RFID 미들웨어와 통신하여 상기 RFID 이벤트를 실시간으로 수집하고 모니터링 서비스를 위하여 RFID 미들웨어 상태, RFID 리더의 상태 또는 구성 정보를 수집하기 위해 비동기적인 이벤트를 요청하고 수신할 수 있도록 송신 모듈과 수신 모듈로 구성되며, RTLS 및 센서데이터 수집의 확장이 가능한 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.
제 1 항에 있어서, 상기 Biz 이벤트 코어 모듈은,

상기 RFID 비즈니스 인식 프레임워크의 RFID 비즈니스 이벤트 서비스를 생성해야 될 이벤트가 정의된 상기 비즈니스 이벤트 명세와 관련된 참조 명세를 해석하고, 그에 따라 각각의 프로세스를 동작시켜 다른 여러 모듈의 기능을 호출하여 정보 획득 및 가공 작업을 수행하고, 최종적으로 상기 RFID 비즈니스 이벤트를 관리하는 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.
제 1 항에 있어서, 상기 BizAF 매니저 모듈은,

RFID 비즈니스 이벤트 서비스와 EPCIS 캡처링 서비스, 참조 명세, 사용자 정보를 관리하고, 상기 RFID 비즈니스 인식 프레임워크에 사용자에 의해 생성된 이벤트 서비스나 등록된 참조 명세는 비즈니스 인식 프레임워크 서버가 중지되었다가 다시 실행된다 하더라도 영속적으로 정보를 유지할 수 있도록 파일 형태로 관리되고, 상기 비즈니스 인식 프레임워크 서버는 RMI 서버로 동작하는 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.
제1 항에 있어서, 상기 비즈니스 이벤트 명세는

상기 RFID 비즈니스 인식 프레임워크에서 RFID 비즈니스 이벤트 서비스 제공하는데 있어 비즈니스 인식 프레임워크 사용자에 의해서 어떻게, 어떤 순서를 가지고 EPC 네트워크 아키텍처의 여러 구성요소와 통신하여 정보를 획득하고, 이 정보에 비즈니스 룰을 적용하여 실시간 비즈니스 이벤트를 생성할지에 관련된 변수 선언, 액티비티 부분, 참조 명세에 대한 XML 형태의 정의가 기술되어 지는, RFID 비즈니스 인식 프레임워크.
제 6 항에 있어서, 상기 비즈니스 이벤트 명세의 참조 명세는,

상기 RFID 미들웨어와의 상호작용을 처리하는 프로바이더 명세(ProviderSpec), EPCIS와의 상호작용을 처리하는 EPCIS 질의 명세(QuerySpec) 및 EPCIS 캡쳐 명세(CaptureSpec)를 포함하는 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.
애플리케이션 계층(Application Layer)과 RFID 미들웨어 계층(RFID Middleware Layer) 사이에 구성되는 RFID 비즈니스 인식 프레임워크가,

　애플리케이션으로부터 서명(subscribe) 요청을 받은 후, 목적지로부터 정보를 인지하고 현재 발생한 이벤트를 최종 목적지에 전달하는 역할을 담당하고, 비즈니스 이벤트의 생성을 위해서 RFID 미들웨어와 통신하여 RFID 이벤트를 실시간으로 수집하는 Event 매니저 모듈을 포함하고,

비즈니스 이벤트 명세(BESpec)에 의해 상기 RFID 미들웨어 계층을 통하여 전달받는 상기 RFID 이벤트를 참조 데이터 및 비즈니스 룰과 결합하여 RFID 응용 애플리케이션이 활용할 수 있는 실시간 RFID 비즈니스 이벤트를 정의하는 것을 특징으로 하는, RFID 비즈니스 인식 프레임워크.