KR101553253B1 - Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템 - Google Patents

Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템 Download PDF

Info

Publication number
KR101553253B1
KR101553253B1 KR1020140010542A KR20140010542A KR101553253B1 KR 101553253 B1 KR101553253 B1 KR 101553253B1 KR 1020140010542 A KR1020140010542 A KR 1020140010542A KR 20140010542 A KR20140010542 A KR 20140010542A KR 101553253 B1 KR101553253 B1 KR 101553253B1
Authority
KR
South Korea
Prior art keywords
epcis
sensor data
event
data
epc
Prior art date
Application number
KR1020140010542A
Other languages
English (en)
Other versions
KR20150089654A (ko
Inventor
강용신
박일하
이승하
염세경
방세중
Original Assignee
동국대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 동국대학교 산학협력단 filed Critical 동국대학교 산학협력단
Priority to KR1020140010542A priority Critical patent/KR101553253B1/ko
Publication of KR20150089654A publication Critical patent/KR20150089654A/ko
Application granted granted Critical
Publication of KR101553253B1 publication Critical patent/KR101553253B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
    • G16Z99/00—Subject matter not provided for in other main groups of this subclass
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템에 관한 것으로, 보다 구체적으로는 EPC 이벤트 데이터획득부가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 단계; 센서 데이터획득부가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 단계; 및 데이터변환부가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장하는 단계;를 포함한다.
이러한 구성에 의해, 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템은 이동 중인 객체의 정보를 포함하는 EPC 이벤트 데이터와 객체의 이동경로 주변 상태를 나타내는 센서 데이터를 EPCIS 규격에 부합하도록 통합하여 저장함으로써, EPCIS 이벤트 데이터와 센서 데이터의 저장공간을 최소화시킬 수 있는 효과가 있다.

Description

EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템{Combination storing method and system of EPC and sensor data according to EPCIS structure, combination processing method and system using the same}
본 발명은 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템에 관한 것으로, 특히 물류 서비스에서 사용되는 EPCIS 규격에 적합하도록 EPC 이벤트 데이터와 센서 데이터를 통합하여 저장 및 처리할 수 있는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템에 관한 것이다.
최근 들어 기술의 발달에 따라 제품의 생산 및 이동 과정을 보다 정확하고 효율적으로 관리하기 위한 방법으로서, 제품에 RFID(Radio Frequency Identification)를 접목시킨 전자 상품 코드 정보 서비스 표준(Electronic Product Code Information Service, 이하, EPCIS 라고 사용한다.)에 부합하는 EPC 글로벌 기술이 연구되고 있는 추세이다.
EPC 글로벌이란, 정보기술 서비스 업체의 전자태그 관련 EPCIS의 규격을 결정하고, 표준화하는 국제 민간 표준기구를 나타낸다.
이때, 상기 EPCIS는 RFID를 통해 수집한 상품 데이터를 거래 기업 간에 공유할 수 있도록 제정한 표준으로서, 거래 당사자들에게 상품에 대한 추적, 진위성 여부 등에 대한 정보 제공을 가능하게 하는 데이터 모델과 인터페이스를 제공한다. 또한 기업들이 이러한 EPCIS를 도입하는 경우, 표준 기반으로 안전하게 상품의 이동정보를 공유함으로써, 공급 체인의 가시성과 업무 프로세스를 개선하는 효과를 볼 수 있다.
즉, 기업 입장에서는 제품에 RFID 기술을 접목시키면, 제품에 부착된 RFID 태그를 리드하여 개별 부품 단위로 물류와 생산 이력을 추적하는 것이 가능하며, 기업에서는 실시간 재고 파악을 통해 생산과 물류 정보를 제공받음으로써 탄력적인 생산 계획을 수립하는 데 활용하고 있다.
또한, 제품을 생산하는 생산 공정 또는 물류 프로세스 과정에서 제품의 생산 또는 이동 시 주변 환경을 각종 센서들을 통하여 센싱하여 센서 데이터를 획득한다.
예를 들어, 자동차 제조 기업 내 도장 공장에서는 차체의 이동뿐만 아니라 건조 단계에서 오븐의 적정 온도를 확인하기 위하여 온도 센서 데이터를 수집한다. 차체 공장에서는 압축공기 생산 시 과도한 전기의 낭비를 줄이기 위해 센서를 설치하여 압축공기의 유량과 압력에 대한 데이터를 수집한다. 또한, 품질 이상이 발생한 완제품이나 부품의 공정을 추적하여 불량의 원인인 공정 환경을 파악하고, 동일한 공정을 거친 불량 예상 제품 및 부품을 추적하고, 데이터를 분석하여 차량의 품질 상태를 미리 예측할 수도 있다.
하지만, 이와 같이, 제품에 부착된 RFID 태그로부터 획득한 RFID 데이터와 제품의 생산 과정에서 획득한 센서 데이터가 일부 EPCIS 규격에 부합하지 않으므로 해당 데이터를 저장하거나, 빅 데이터를 신속하게 처리하기 어려운 문제점이 발생했다.
KR 10-2013-0056392 (EPC 글로벌 네트워크에서의 개별 제품의 비정상 유통 판별 시스템 및 그 방법, 한미아이티 주식회사) 2013.05.30.
상기와 같은 종래 기술의 문제점을 해결하기 위해, 본 발명은 이동 중인 객체의 정보를 포함하는 EPC 이벤트 데이터와 객체의 이동경로 주변 상태를 나타내는 센서 데이터를 EPCIS 규격에 부합하도록 통합하여 저장함으로써, 저장공간을 최소화하면서도 데이터 처리 속도를 향상시키는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템을 제공하고자 한다.
위와 같은 과제를 해결하기 위한 본 발명의 한 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법은 EPC 이벤트 데이터획득부가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 단계; 센서 데이터획득부가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 단계; 및 데이터변환부가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 변환하고, 변환된 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 단계;를 포함한다.
특히, 상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하는 EPCIS 이벤트 데이터를 포함할 수 있다.
특히, 상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어지는 EPC 이벤트 데이터를 포함할 수 있다.
특히, MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장하는 데이터베이스부가 변환된 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 단계를 포함할 수 있다.
특히, 상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 EPCIS 규격에 맞도록 변환된 센서 데이터를 추가하여 저장하는 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계를 포함할 수 있다.
특히, 상기 MangoDB 내 하나의 컬렉션(collection)에 상기 EPCIS 이벤트 데이터를 저장하는 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계를 포함할 수 있다.
특히, 상기 MangoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장하는 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계를 포함할 수 있다.
특히, 상기 객체의 이동 시 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나의 정보를 포함하는 센서 데이터를 포함할 수 있다.
위와 같은 과제를 해결하기 위한 본 발명의 다른 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법은 EPC 이벤트 데이터획득부가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 단계; 센서 데이터획득부가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 단계; 데이터베이스부가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 구조에 맞도록 변환하고, 변환된 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 단계; 및 EPCIS 서버가 적어도 하나의 샤드키를 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리하는 단계;를 포함한다.
특히, 상기 객체에 대한 센싱 지점 및 이벤트 발생시간 중 적어도 하나를 샤드키로 선정하는 EPCIS 서버가 분산처리하는 단계를 포함할 수 있다.
위와 같은 과제를 해결하기 위한 본 발명의 또 다른 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 시스템은 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 EPC 이벤트 데이터획득부; 상기 객체의 이동 경로 내 적어도 하나의 위치에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 센서 데이터획득부; 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 구조에 맞도록 변환하고, 변환된 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 데이터베이스부;를 포함한다.
특히, 상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하는 EPCIS 이벤트 데이터를 포함할 수 있다.
특히, 상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어지는 EPC 이벤트 데이터를 포함할 수 있다.
보다 바람직하게는 MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장하는 데이터베이스부를 포함할 수 있다.
특히, 상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 EPCIS 규격에 맞도록 변환된 센서 데이터를 추가하여 저장하는 데이터베이스부를 포함할 수 있다.
특히, 상기 MangoDB 내 하나의 컬렉션(collection)에 EPCIS 이벤트 데이터를 저장하는 데이터베이스부를 포함할 수 있다.
보다 바람직하게는 상기 MangoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장하는 데이터베이스부를 포함할 수 있다.
특히, 상기 객체의 이동 시 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나를 포함하는 센서 데이터를 포함할 수 있다.
위와 같은 과제를 해결하기 위한 본 발명의 또 다른 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템은 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 EPC 이벤트 데이터획득부; 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 센서 데이터획득부; 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 구조에 맞도록 변환하고, 변환된 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 데이터베이스부; 및 적어도 하나의 샤드키를 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리하는 EPCIS 서버;를 포함한다.
특히, 상기 객체에 대한 센싱 지점 및 이벤트 발생시간 중 적어도 하나를 샤드키로 선정하는 EPCIS 서버를 포함할 수 있다.
본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템은 이동 중인 객체의 정보를 포함하는 EPC 이벤트 데이터와 객체의 이동경로 주변 상태를 나타내는 센서 데이터를 EPCIS 규격에 부합하도록 통합하여 저장함으로써, EPCIS 이벤트 데이터와 센서 데이터의 저장공간을 최소화시킬 수 있는 효과가 있다.
또한 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템은 EPC 이벤트 데이터와 센서 데이터를 동일한 EPCIS 규격에 맞도록 통합함으로써, 빅데이터 처리 시 분산 처리 속도를 향상시킬 수 있는 효과가 있다.
도 1은 본 발명의 일 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 시스템의 블록도이다.
도 2는 본 발명의 다른 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법의 순서도이다.
도 3은 EPCIS 이벤트 데이터의 종류를 나타낸 도면이다.
도 4는 EPCIS 이벤트 데이터의 속성을 나타낸 도면이다.
도 5는 Embeded 방식에 따른 EPCIS 이벤트 데이터의 컬렉션 설계를 나타낸 도면이다.
도 6은 Linking 방식에 따른 EPCIS 이벤트 데이터의 컬렉션 설계를 나타낸 도면이다.
도 7은 제품의 물류 프로세스 과정을 나타낸 도면이다.
도 8은 MongDB 에서의 맵 리듀스 쿼리를 나타낸 도면이다.
이하, 본 발명을 바람직한 실시 예와 첨부한 도면을 참고로 하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며, 여기에서 설명하는 실시 예에 한정되는 것은 아니다.
도 1은 본 발명의 일 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 시스템의 블록도이다.
도 1에 도시된 바와 같이, 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 시스템(100)은 EPC 이벤트 데이터획득부(120), 센서 데이터획득부(140) 및 데이터베이스부(160)를 포함한다.
EPC 이벤트 데이터획득부(120)는 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득한다. 이때, 상기 EPCIS 이벤트 데이터는 상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하며, 특히, 상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어진다.
센서 데이터획득부(140)는 상기 객체의 이동 경로 내 적어도 하나의 위치에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득한다. 이때, 상기 센서 데이터는 상기 객체의 이동 시 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나를 포함할 수 있다.
데이터베이스부(160)는 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장한다. 이러한 데이터베이스부(160)는 MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장할 수 있는데, 특히, 상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 센서 데이터를 추가하여 저장한다. 또한, 상기 데이터베이스부(160)는 상기 MangoDB 내 하나의 컬렉션(collection)에 EPCIS 이벤트 데이터를 저장하고, 상기 MangoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장한다.
이하, 도 2를 참조하여 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법에 대하여 자세히 살펴보도록 한다.
도 2는 본 발명의 다른 실시 예에 따른 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법의 순서도이다.
도 2에 도시된 바와 같이, 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법은 EPC 이벤트 데이터획득부(120)가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득한다(S210).
이때, 획득한 EPCIS 규격에 따르는 EPCIS 이벤트 데이터는 상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하며, 보다 구체적으로는 상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어진다.
도 3은 EPCIS 이벤트 데이터의 종류를 나타낸 도면이다.
도 3에 도시된 바와 같이, EPCIS 이벤트 데이터는 객체이벤트(ObjectEvent), 결합이벤트(AggregationEvent), 처리이벤트(TransactionEvent) 및 수량이벤트(QuantityEvent) 등의 종류로 나누어지며, 이 중에서 객체이벤트(ObjectEvent)는 상기 객체에 발생하는 이벤트를 정의하여, 특정 시간과 장소, 비즈니스 스텝에서 관측된 하나 이상의 EPC 리스트를 나타낸다.
결합이벤트(AggregationEvent)는 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하여, 특정 시간과 장소, 비즈니스 스텝에서 EPC 들간의 물리적인 부자관계를 나타낸다.
처리이벤트(TransactionEvent)는 상기 객체에 발생한 이벤트의 처리상황을 정의하여, 상기 객체로부터 획득한 EPC와 비즈니스 트랜잭션이 관련되었음을 나타낸다.
수량이벤트(QuantityEvent)는 상기 객체에 대한 수량을 정의하여, 특정 시간과 장소에서 상품의 수량을 표현한다.
이하, 도 4를 참조하여 EPCIS 이벤트 데이터 중 객체이벤트, 결합이벤트, 처리이벤트의 속성을 자세히 살펴보도록 한다.
도 4는 EPCIS 이벤트 데이터의 속성을 나타낸 도면이다.
도 4에 도시된 바와 같이, action의 경우에는 이벤트 마다 그 의미가 다르다는 것을 알 수 있다. 객체이벤트(ObjectEvent)의 경우 ADD는 EPC가 처음으로 객체에 부여되어 인식 되었을 때를 나타내고, OBSERVE는 EPC가 부여된 개체가 이동 중 인식되었을 때를 나타내며, DELETE는 더 이상 해당 EPC가 인식될 필요가 없을 때를 나타낸다. 결합이벤트(AggregationEvent)의 경우 ADD는 자식 EPC가 부모 EPC와 처음으로 결합(aggregation) 되었을 때를 나타내고, OBSERVE는 자식 EPC와 부모 EPC가 결합된 상태로 관측되었을 때를 나타내며, DELETE는 하나 이상의 자식 EPC가 부모 EPC와 결합이 해제(disaggregation) 되었을 때를 나타낸다. 마지막으로, 처리이벤트(TransactionEvent)의 경우 ADD는 EPC가 비즈니스 트랜잭션과 처음으로 관련 되었을 때를 나타내고, OBSERVE는 EPC와 비즈니스 트랜잭션이 관련된 상태로 관측되었을 때를 나타내며, DELETE는 하나 이상의 EPC가 비즈니스 트랜잭션과의 관련이 해제 되었을 때를 나타낸다.
다시 도 2로 돌아와서, 센서 데이터획득부(140)가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득한다(S220). 이때, 상기 센서 데이터는 상기 객체의 생산 또는 이동 시 작업장 또는 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나의 정보를 포함한다.
데이터베이스부(160)가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장한다(S230). 특히, 상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 상기 센서 데이터를 추가하여 저장한다.
또한, 이러한 데이터베이스부(160)가 MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장한다. 이때, 사용되는 MongoDB 란, 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템을 말한다. 이와 같이, NoSQL 데이터 베이스로 분류되는 MongoDB 는 JSON 과 같은 동적 스키마형 문서들을 선호함에 따라, 전통적인 테이블 기반 관계형 데이터베이스 구조의 사용을 금한다. 이에 따라, 특정한 종류의 애플리케이션을 보다 쉽고, 빠르게 데이터를 통합할 수 있도록 한다.
이러한 MongoDB의 보다 쉬운 이해를 돕기 위해, 하기에 도시된 표 1을 참조하여 MongoDB와 관계형 데이터베이스간 기능에 따른 용어를 상호 비교해보도록 한다.
관계형 데이터베이스 MongoDB
테이블 (Table) 컬렉션 (Collection)
행 (Row) 도큐먼트 (Document)
열 (Column) 필드 (Field)
기본키 (Primary key) 오브젝트 ID 필드 (Object_ID_Field)
관계 (Relationship) Embedded, Linking
상기 표 1에 기재된 바와 같이, MongoDB는 관계형 데이터베이스와 유사한 의미를 가진 요소들에 대해 다른 용어를 사용한다. 예를 들어, 관계형 데이터베이스의 테이블은 MongoDB에서 컬렉션에 해당한다. 이때, 상기 MangoDB 내 하나의 컬렉션(collection)에 상기 EPCIS 이벤트 데이터를 저장할 수 있다.
또한 관계형 데이터베이스의 행과 열은 도큐먼트와 필드라고 지칭하며, 관계형 데이터베이스에서 기본키는 테이블을 식별할 수 있는 유일한 값으로, MongoDB에서는 기본키가 아닌 오브젝트 ID 필드로 다른 도큐먼트와 구별한다. 또한 관계형 데이터베이스의 JOIN과 같은 테이블 간 관계를 MongoDB에서는 Embedded 혹은 Linking으로 표현한다.
또한, 상기 MangoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장한다.
즉, 여러 개의 값을 갖는 필드의 경우에, MongoDB의 데이터 설계 구조는 크게 Embedded 또는 Linking 방식으로 나누어 구성한다. 이때, 상기 Embedded 방식은 필드 값을 배열형식으로 내장하는 방식을 나타내며, 상기 Linking 방식은 물리적으로 다른 컬렉션을 만들어 관계형 데이터베이스의 외래키처럼 두 개의 컬렉션 간 오브젝트 ID 필드로 연결고리를 설정하고, 필드 값을 별도의 컬렉션에 저장하는 방식을 나타낸다.
특히, EPCIS 이벤트 데이터에는 다중 값을 갖는 epcList, bizTransactionList, extension 필드가 각각 존재한다. 기본적으로 EPCIS 이벤트 데이터를 Event 컬렉션에 저장한다고 가정했을 때, 상기 세가지 필드를 Embedded 방식으로 Event 컬렉션에 포함시키거나, 또는 Linking 방식으로 물리적으로 컬렉션을 분리할 것인지에 대한 선택이 필요하다.
이하에서는 상기 각 epcList, bizTransactionList, extension 필드에 대해 Embedded 방식과 Linking 방식에 따른 각각의 설계안에 대하여 설명하기로 한다.
먼저, EPCIS 이벤트 데이터는 앞서 기재한 바와 같이 객체이벤트, 결합이벤트, 처리이벤트, 수량이벤트 등의 네 가지가 존재한다. 이에 따라, 각 이벤트 별로 컬렉션을 구성할지 아니면 한 컬렉션(예: Event 컬렉션)에 네 가지 이벤트를 모두 저장할지에 대한 의사결정이 필요하지만, 각 이벤트별 필드의 구성이 크게 다르지 않고, MongoDB 특성상 상이한 필드를 갖는 도큐먼트를 한 컬렉션에 저장할 수 있으므로, 본 발명에서는 Event 컬렉션에 네 가지 EPCIS 이벤트를 저장하는 방식을 선택한다.
한편, EPCIS 표준에 따르면 확장 영역(extension field)에는 fieldName, prefix, value가 핵심적으로 포함되어야 할 필드이며, 각각 센서유형, 네임스페이스의 prefix, 값으로 매칭하여 센서 데이터를 저장할 수 있다.
도 5는 Embeded 방식에 따른 EPCIS 이벤트 데이터의 컬렉션 설계를 나타낸 도면이다.
도 5에 도시된 바와 같이, 데이터베이스부가 Embedded 방식을 선택하는 경우 그림 6과 같이 EPCIS 이벤트 데이터의 다중 값 필드 중 epcList는 배열 형태로 Event 컬렉션에 포함시키고, bizTransactionList과 extension은 서브 도큐먼트 형태로 Event 컬렉션에 포함시킨다.
이에 따라, 쿼리가 단순해지고 JOIN문을 실행할 필요가 없으므로, 도큐먼트 단위의 데이터 저장에 효과적이며 빠른 성능이 보장될 수 있다. 하지만, 데이터의 양이 증가할수록 읽기 성능의 이점을 보장할 수 없는 단점이 있다. Embedded 방식의 경우 빈번히 조회가 이뤄지는 필드와 그렇지 않은 필드 모두가 하나의 컬렉션에 포함되게 되는데, 이러한 경우 불필요한 필드까지 모두 탐색해야 하기 때문에 읽기 성능이 감소하게 된다.
또한, "다대다" 관계를 Embedded로 설계할 경우에는 데이터 중복 문제가 발생하며 데이터 양이 늘어날수록 문제가 심화될 수 있지만, 적절한 인덱스 키를 설정함으로써 문제를 해결할 수 있다.
표 2는 Event 컬렉션의 스키마 상세를 나타낸 표이다.
번호 컬럼 ID Data Type
(Size)		 Null 여부 비 고
event_id String NOT NULL
eventType String NOT NULL
eventTime TImestamp NOT NULL
recordTime TImestamp NULL
eventTimeZoneOffset String NOT NULL
action String NOT NULL
bizStep String NULL
disposition String NULL
readPoint String NULL
bizLocation String NULL
bizTransactionList Biztransaction NULL
epcList Array
extension Extension
하기의 표 3은 Extension 컬렉션 데이터베이스의 스키마 상세를 나타낸 표이다.
번호 컬럼 ID Data Type
(Size)		 Null 여부 비 고
fieldname String NOT NULL 센서유형
prefix String NOT NULL
value 64-bit integer NULL
또한 상술한 Embeded 와 달리, Linking 방식은 다 대 다 관계에서 특히 유연성을 보이며, 데이터 중복성의 문제가 발생하지 않는다. Linking 방식에 따르는 EPCIS 이벤트 데이터가 저장되는 데이터베이스부는 도 6과 같이, Event 컬렉션을 기준으로 EPCList 컬렉션과 Extension 컬렉션이 연결되는 구조로 설계할 수 있다.
도 6은 Linking 방식에 따른 EPCIS 이벤트 데이터의 컬렉션 설계를 나타낸 도면이다.
도 6에 도시된 바와 같이, 이때, EPCList 컬렉션과 Extension 컬렉션은 Event 컬렉션의 오브젝트 ID 필드(_id)를 연결값으로 저장함으로써 Event 컬렉션과 Linking 관계를 가지게 된다. 하지만, bizTransactionList의 경우 모든 이벤트에 항상 포함되는 필드가 아니고 Event 컬렉션과 약한 관계에 해당하기 때문에 Linking 구조로 연결할 필요가 없다.
Lingking 방식의 경우에는 MongoDB가 JOIN 연산을 제공하지 않기 때문에 서로 연관된 데이터를 검색하기 위해서는 사용자 또는 애플리케이션에서 다중 쿼리를 해야 한다. 하지만, 읽기 성능이 조금 느리더라도 데이터 중복으로 인해 불필요한 용량을 차지하는 것을 방지하기 위해, Linking 방식을 통해 별도의 물리적 구조로 저장하도록 설계하는 것이 적절하다.
이하, 표 4 내지 6은 각 Event 컬렉션과 EpcList 컬렉션, Extension 컬렉션의 스키마 상세를 나타낸 표이다.
번호 컬럼 ID Data Type
(Size)		 Null 여부 비 고
event_id String NOT NULL
eventType String NOT NULL
eventTime TImestamp NOT NULL
recordTime TImestamp NULL
eventTimeZoneOffset String NOT NULL
action String NOT NULL
bizStep String NULL
disposition String NULL
readPoint String NULL
bizLocation String NULL
bizTransactionList Array NULL
번호 컬럼 ID Data Type
(Size)		 Null 여부 비 고
event_id Object ID NOT NULL
fieldname String NOT NULL 센서유형
prefix String NOT NULL
Value 64-bit integer NULL
번호 컬럼 ID Data Type
(Size)		 Null 여부 비 고
event_id Object ID
Array		 NOT NULL
epcList String NOT NULL
더불어, 상술한 EPCIS 구조에 따른 EPC 및 센서 데이터를 통합하여 저장하는 방법을 이용하여 EPCIS 구조에 따른 EPC 및 센서 데이터를 통합하여 처리할 수 있다.
본 발명의 다른 실시 예에 따른 EPCIS 구조에 따른 EPC 및 센서 데이터의 통합 처리 방법은 EPC 이벤트 데이터획득부가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득한다.
이어서, 센서 데이터획득부가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득한다.
데이터베이스부가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장한다.
EPCIS 서버가 적어도 하나의 샤드키를 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리한다.
이때, EPC 이벤트 데이터를 획득하고, 센서 데이터를 획득하며, 획득한 EPC 이벤트 데이터와 센서 데이터를 EPCIS 규격에 맞도록 통합하여 저장하는 과정은 앞서 기술한 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법과 동일함에 따라, 이하 설명은 생략하도록 한다.
이처럼, EPCIS 규격에 맞도록 저장된 EPC 이벤트 데이터와 센서 데이터에 대하여 EPCIS 서버가 적어도 하나의 샤드키를 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리하는데 있어서, EPCIS 서버가 상기 객체에 대한 센싱 지점 및 이벤트 발생시간 중 적어도 하나를 샤드키로 선정할 수 있다.
이때, 샤드키를 얼마나 적절하게 잘 선택했느냐에 따라 MongoDB의 성능이 달라질 수 있다. 또한, 일단 샤드키를 생성하고 나면 이후, 변경이 불가능하기 때문에 적절한 샤드키의 선택은 굉장한 중요성을 가진다. 모든 데이터를 삭제하고 샤드키를 변경한 후 다시 저장할 수도 있지만, 대용량 데이터일 경우 그 작업이 번거롭고, 오래 걸리므로 실제 실행으로 옮기기 어렵다.
상기 EPCIS 서버에 의해 적어도 하나의 샤드키가 선택되면 해당 샤드키는 인덱스로 선정된다. 선정된 인덱스를 기준으로 설명한다면 샤드키는 인덱스의 생성을 고려할 수 있는 필드 또는 대용량 데이터의 빠른 검색이 요구되는 필드를 샤드키로 결정하는 것이 좋다.
또한, 샤드키는 적절한 카디널리티를 가진 필드가 선택되어야 한다. 카디널리티(Cardinality)는 필드가 가질 수 있는 값의 종류의 정도를 나타내는 값이다. 카디널리티가 너무 높거나 (값의 종류가 많음), 낮은 (값의 종류가 적음) 필드의 경우에는 데이터가 저장되는 파일인 청크가 분할되지 못하여 하나의 서버에 데이터가 집중되는 현상이 발생할 수 있다.
이상적인 샤딩은 값이 밀집되지 않은 키(카디널리티가 적절한 키)의 장점과 세분화된 키(카디널리키가 높은 키)의 장점이 조합된 복합 샤드키를 이용하는 것이다.
상기 EPCIS 서버가 MongoDB 기반 EPCIS의 적절한 데이터 분산을 위해 복합 샤드키의 첫 번째 키를 선택해야 하는데 있어서, EPCIS 이벤트 데이터의 필드 중 카디널리티가 적절한 필드는 readPoint 이다. 상기 readPoint는 객체가 인식되는 지점을 나타내는 값으로서, 주로 RFID 안테나 번호를 나타낸다. 기업 내 물류 프로세스가 정의되고 readPoint가 정해지면 상품이나 박스와 같은 객체들은 정해진 프로세스에 따라 거의 동일한 readPoint들을 통과하게 되기 때문에 readPoint가 가질 수 있는 값의 종류가 한정되어 있고, 종류별 이벤트 발생 개수가 유사하여 시간에 따라 발생되는 EPCIS 이벤트 데이터를 MongoDB로 삽입하는데 있어서, 고르게 분산이 가능하다.
이어서, EPCIS 서버의 복합 샤드키의 두 번째 키 선정을 위해 EPCIS 이벤트 데이터의 필드 중 카디널리티가 높은 필드의 후보는 eventTime과 _ID 필드이다. 상기 eventTime은 이벤트가 발생한 시간을 뜻하며, 각 이벤트가 시간 순서로 발생하기 때문에 값이 오름차순으로 증가하는 성격의 필드이다. 상기 _id는 다른 도큐먼트(레코드)와 구별될 수 있는 관계형 데이터베이스의 대체키 성격의 필드이다. 상기 eventTime 필드와, _ID 필드는 모두 카디널리티가 높고 오름차순으로 저장될 수 있는 값을 가진 필드이다. 특히, eventTime이나 _ID 와 같이 데이터를 삽입할 때마다 값이 증가하는 필드를 두 번째 샤드키로 선정하게 되면 비슷한 시간 때의 이벤트 데이터가 같은 샤드에 저장될 수 있으므로 시간 범위로 데이터를 조회할 때 효과적이며(예: 오늘 출고된 제품은?), 특정 readPoint에서 다른 readPoint 보다 이벤트가 자주 발생하여도 시간 기준으로 데이터를 분할 저장할 수 있는 기준이 있어 청크의 분할이 항상 보장되어 효과적이다.
결론적으로, MongoDB 기반 EPCIS는 {readPoint, eventTime} 혹은 {readPoint, _id} 조합으로 복합 샤드키를 고려할 수 있다. 하지만, _id는 EPCIS 이벤트 데이터들 간 구분을 위한 필드로써 조회에 사용되지 않아 인덱스를 생성할 필요가 없기 때문에 (이유: 샤드키를 선정하면 해당 필드가 인덱스화 됨) 조회에 많이 사용되는 필드인 eventTime을 복합키의 두 번째 필드로 선정하여 인덱스화 하는 것이 적절하다. 따라서 본 발명에서는 MongoDB 기반 EPCIS의 샤드키를 {readPoint, eventTime}의 복합샤드키로 선택한다.
이하에서는 readPoint 한 개만 샤드키로 선정했을 때와 {readPoint, eventTime} 복합키를 샤드키로 선정했을 때의 분산 정도를 실험을 통해 비교하였다.
도 7은 제품의 물류 프로세스 과정을 나타낸 도면이다.
도 7에 도시된 바와 같이, 먼저 EPCIS 이벤트 데이터 발생을 위해 그림 8과 같이 일곱개의 readPoint를 가지는 내부 물류 프로세스를 정의하였다. RP-1에서는 제품이 생산되어 RFID 태깅 후 RFID 안테나에 의해 인식된다. RP-2에서는 박스에 RFID 태깅 후 대기하고 있다가 포장하기 위해 이동할 때 RFID 안테나에 의해 인식된다. R3에서는 제품이 박스에 포장되며, RP-5에서는 RP-4를 통해 태깅 후 투입된 팔레트에 박스가 결합된다. R6에서는 트럭에 팔레트가 상차되고 RP-7에서 출고된다. 15개의 제품을 한 개의 박스에 포장 하고, 여덟 개의 박스를 한 개의 팔레트에 적재한다. 그리고 여덟 개의 팔레트를 한 대의 트럭에 상차하도록 정의하였다.
이러한 방식으로 EPCIS 이벤트 데이터를 발생시키면 RP-1에서 다른 readPoint 보다 이벤트 데이터가 많이 발생하는데, 그 이유는 RP-1에서는 개별 제품이 생산될 때 마다 EPCIS 이벤트가 발생하며, 그 이벤트에는 생산된 제품 EPC만 포함하기 때문이다. 이후, readPoint에서는 여러 제품이 한 박스에 결합되고, 여러 박스가 한 팔레트에 적재되어 같이 이동하기 때문에 RFID 인식 관점에서는 같은 시간, 같은 장소에 서 여러 EPC들을 인식하는 것과 같다. 각 제품이나 박스, 팔레트가 동시에 이동할 때 각 EPC 별 EPCIS 이벤트를 발생시키는 것이 아니라 한 EPCIS 이벤트에 여러 EPC를 포함시켜 발생시키기 때문에 RP-1이 다른 readPoint 보다 많은 이벤트를 발생시킨다.
MongoDB에서 Event 컬렉션에 100GB 정도의 데이터를 발생시켜, 샤드키로 {readPoint} 하나만 선택하였을 때와 {readPoint, eventTime} 와 같은 복합키를 선택하였을 때의 분산 정도를 비교하였다.
하기의 표 7은 단일 샤드키와 복합 샤드키의 분산 정도를 비교한 표이다.
샤드키 Shard1 Shard2 Shard4
{readPoint} 640,006 1,638,406 26,214,406
{readPoint,eventTime} 9,389,709 9,677,698 9,425,411
상기 표 7에 도시된 바와 같이, 단일 샤드키인 {readPoint}와 복합 샤드키인 {readPoint, eventTime} 설정 시에 각 샤드 별 저장된 EPCIS 이벤트 데이터의 수를 확인할 수 있으며, {readPoint}의 단일 샤드키 보다 {readPoint, eventTime} 복합 샤드키를 설정하였을 때 보다 나은 데이터 분배가 된 것을 확인할 수 있다.
이와 마찬가지로, EPCIS 구조에 따른 EPC 및 센서 데이터의 통합 처리 시스템은 EPC 이벤트 데이터획득부, 센서 데이터획득부, 데이터베이스부 및 EPCIS 서버를 포함할 수 있다.
이때, 상기 EPC 이벤트 데이터획득부, 센서 데이터획득부, 데이터베이스부는 상술한 EPCIS 구조에 따른 EPC 및 센서 데이터의 통합 저장 시스템과 동일한 구성 및 기능을 가짐에 따라, 구체적인 설명은 생략하기로 한다.
이때, 상기 EPCIS 서버는 적어도 하나의 샤드키를 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리한다. 이러한 EPCIS 서버(EPCIS: Electronic Product Code Information Service Server)는 로컬 저장소에 저장되는 RFID 기반으로 이루어진 데이터를 교환하는 서버를 나타낸다. 객체(또는 상품)가 생산되는 사업장 내에서 발생되는 EPC이벤트를 획득하여 저장하고, 사내 시스템이나 파트너 사의 시스템에서 상기 EPC이벤트를 쿼리(Quiry)할 수 있도록 쿼리 인터페이스(Quiry interface)를 제공한다.
EPCIS 쿼리 파라미터는 이미 정의된 파라미터(예; GE_eventTime, MATCH_EPC, EQ_readPoint 등)를 기준으로 쿼리를 수행한다. MongoDB 컬렉션의 쿼리는 'db.컬렉션명.find()'로 수행하며, find()의 매개변수로 조건을 설정할 수 있다.
산업에서 요구하는 대표적인 비즈니스적 이력 조회에 따른 MongoDB 쿼리 구현 방식은 다음과 같다.
1. EPC X를 포함하는 모든 이벤트 조회 즉, EPC X의 이동이력은?
A. Embedded 구조 설계안
db.Event.find({ "epcList": "X" });
B. Linking 구조 설계안
var myCursor = db.Epcs.find({epcList:"X"});
var user_id = myCursor.count > 1 ? (myCursor.hasNext() ? myCursor.next() : null) : myCursor[0];
db.Event.find({event_id : user_id.event_id});
2. X 시간 이상 Y 시간 이하 readPoint A, B, C에서 발생한 모든 이벤트는?
A. Embedded 구조 설계안
var start = ISODate("X");
var end = ISODate("Y");
db.Event.find({"eventTime": {"$gte": start, "$lt": end}, "readPoint": { "$in": ["A", "B", "C"] }});
B. Linking 구조 설계안
var start = ISODate("X");
var end = ISODate("Y");
db.Event.find({"eventTime": {"$gte": start, "$lt": end}, "readPoint": { "$in": ["A", "B", "C"] }});
3. X 이상, Y 이하의 온도 값을 포함하는 모든 이벤트는?
A. Embedded 구조 설계안
db.Event.find({"extensions.value":{"$gte":"X", "$lte":"Y"}});
B. Linking 구조 설계안
var myCursor= db.Extension.find({"extensions.value":{"$gte":"X", "$lte":"Y"}});
var user_id = myCursor.count > 1 ? (myCursor.hasNext() ? myCursor.next() : null) : myCursor[0];
db.Event.find({event_id : user_id.event_id});
특히, MongoDB는 SQL문에서 사용하는 Group 형식을 별도로 제공하지 않기 때문에 비슷한 방식으로 맵-리듀스 방식을 사용해야 한다. 그룹으로 묶어서 사용할 필드를 키로 맵핑을 하고, 리듀스로 그룹으로 묶은 키 값들을 하나로 묶어 값을 계산한다. 그룹 쿼리를 위해 MongoDB 맵-리듀스를 활용하여 EPCIS 쿼리를 수행하고, 해당 쿼리의 이벤트 별로 필요한 결과값을 묶어 수량, 합계, 평균값을 구한다. 도 8은 MongoDB 맵-리듀스 쿼리 합계를 구하는 예를 보여주며, 해당 사항에 따라 수량, 합계, 평균값을 구한다.
이에 따라, EPCIS 이벤트 데이터와 센서 데이터를 통합적으로 저장 가능하며, 대용량의 데이터를 빠르게 저장하고 분석 처리하는 것이 가능하다.
제품이나 부품의 품질 문제 원인을 생산설비의 센서데이터를 분석해, 과거 경험적이고, 해석적인 방법의 불량 원인 분석보다 더 정밀한 불량 원인 탐색이 가능하며, 물류에서 각종 센서를 통해 연료사용량, 탄소배출량, 공회전 수 등을 빠르게 분석 가능하다. 또한, 식품 유통에서 ID와 위치정보를 고려해 배송의 우선순위 변경, 배송지 변경 (급판매), 폐기 등 다양한 유통 운영 의사결정에 활용 가능하다.
또한, 이러한 본 발명은 컴퓨터로 실행하기 위한 프로그램이 기록된 컴퓨터 판독가능 기록매체에 저장될 수 있다. 이때, 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다. 컴퓨터가 읽을 수 있는 기록 장치의 예로는 ROM, RAM, CD-ROM, DVD±ROM, DVD-RAM, 자기 테이프, 플로피 디스크, 하드 디스크(hard disk), 광데이터 저장장치 등이 있다. 또한, 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 장치에 분산되어 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템은 이동 중인 객체의 정보를 포함하는 EPC 이벤트 데이터와 객체의 이동경로 주변 상태를 나타내는 센서 데이터를 EPCIS 규격에 부합하도록 통합하여 저장함으로써, EPCIS 이벤트 데이터와 센서 데이터의 저장공간을 최소화시킬 수 있는 효과가 있다.
또한 본 발명의 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 저장 방법 및 시스템, EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법 및 시스템은 EPC 이벤트 데이터와 센서 데이터를 동일한 EPCIS 규격에 맞도록 통합함으로써, 빅데이터 처리 시 분산 처리 속도를 향상시킬 수 있는 효과가 있다.
상기에서는 본 발명의 바람직한 실시 예에 대하여 설명하였지만, 본 발명은 이에 한정되는 것이 아니고 본 발명의 기술 사상 범위 내에서 여러 가지로 변형하여 실시하는 것이 가능하고 이 또한 첨부된 특허청구범위에 속하는 것은 당연하다.
120: EPC 이벤트 데이터획득부 140: 센서 데이터 획득부
160: 데이터베이스부

Claims (21)

  1. EPC 이벤트 데이터획득부가 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 단계;
    센서 데이터획득부가 상기 객체의 이동 경로 내 적어도 하나의 지점에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 단계;
    데이터베이스부가 상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장하는 단계; 및
    EPCIS 서버가 상기 객체에 대한 센싱 지점과 이벤트 발생시간을 포함하는 복합키를 샤드키로 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리하는 단계;를 포함하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  2. 제1항에 있어서,
    상기 EPCIS 이벤트 데이터는
    상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  3. 제2항에 있어서,
    상기 EPC 이벤트 데이터는
    상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어지는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  4. 제1항에 있어서,
    상기 데이터베이스부가 상기 센서 데이터와 상기 EPCIS 이벤트 데이터를 통합하여 저장하는 단계는
    MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  5. 제4항에 있어서,
    상기 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계는
    상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 상기 센서 데이터를 추가하여 저장하는 것을 특징으로 하는 EPC EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  6. 제5항에 있어서,
    상기 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계는
    상기 MongoDB 내 하나의 컬렉션(collection)에 상기 EPCIS 이벤트 데이터를 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  7. 제6항에 있어서,
    상기 데이터베이스부가 상기 센서 데이터와 EPCIS 이벤트 데이터를 통합하여 저장하는 단계는
    상기 MongoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  8. 제1항에 있어서,
    상기 센서 데이터는
    상기 객체의 이동 시 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나의 정보를 포함하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 방법.
  9. 삭제
  10. 삭제
  11. 제1항 내지 제8항 중 어느 한 항에 따른 방법을 컴퓨터로 실행하기 위한 프로그램이 기록된 컴퓨터 판독가능 기록매체.
  12. 이동 경로를 통해 이동하는 객체로부터 고유한 ID를 나타내는 EPC 정보를 포함하는 적어도 하나의 EPCIS 이벤트 데이터를 획득하는 EPC 이벤트 데이터획득부;
    상기 객체의 이동 경로 내 적어도 하나의 위치에서 상기 이동 경로의 주변 환경상태를 나타내는 센서 데이터를 획득하는 센서 데이터획득부;
    상기 센서 데이터를 전자상품코드정보서비스(EPCIS: Electronic Code Information Service) 규격에 맞도록 상기 EPCIS 이벤트 데이터와 통합하여 저장하는 데이터베이스부; 및
    상기 객체에 대한 센싱 지점과 이벤트 발생시간을 포함하는 복합키를 샤드키로 선정하여 상기 센서 데이터와 EPC 이벤트 데이터를 분산처리하는 EPCIS 서버;를 포함하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  13. 제12항에 있어서,
    상기 EPCIS 이벤트 데이터는
    상기 객체에 대한 EPC 고유번호, 제조데이터, 거래 데이터, 인식지점, 인식시점, 저장시점, 프로세스 상태, 객체 상태 중 적어도 하나를 포함하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  14. 제13항에 있어서,
    상기 EPC 이벤트 데이터는
    상기 객체에 발생하는 이벤트를 정의하는 객체이벤트(ObjectEvent), 상기 객체와 다른 객체간의 결합 또는 해체 이벤트를 정의하는 결합이벤트(AggregationEvent), 상기 객체에 발생한 이벤트의 처리상황을 정의하는 처리이벤트(TransactionEvent), 상기 객체에 대한 수량을 정의하는 수량이벤트(QuantityEvent)들 중 적어도 하나의 형태로 이루어지는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  15. 제12항에 있어서,
    상기 데이터베이스부는
    MongoDB를 기반으로 센서 데이터와 EPCIS 이벤트 데이터를 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  16. 제15항에 있어서,
    상기 데이터베이스부는
    상기 EPCIS 이벤트 데이터의 확장 영역(extension field) 내부에 상기 센서 데이터를 추가하여 저장하는 것을 특징으로 하는 EPC EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  17. 제16항에 있어서,
    상기 데이터베이스부는
    상기 MongoDB 내 하나의 컬렉션(collection)에 EPCIS 이벤트 데이터를 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  18. 제17항에 있어서,
    상기 데이터베이스부는
    상기 MongoDB 내 하나의 컬렉션 내 복수 개의 필드 값이 존재하면, 상기 필드 값을 배열 형식으로 저장하거나, 다른 컬렉션을 생성하여 상기 필드 값을 생성된 다른 컬렉션에 저장하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  19. 제12항에 있어서,
    상기 센서 데이터는
    상기 객체의 이동 시 이동경로 주변의 온도, 습도, 이산화탄소 농도 중 적어도 하나를 포함하는 것을 특징으로 하는 EPCIS 규격에 따른 EPC 및 센서 데이터의 통합 처리 시스템.
  20. 삭제
  21. 삭제
KR1020140010542A 2014-01-28 2014-01-28 Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템 KR101553253B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020140010542A KR101553253B1 (ko) 2014-01-28 2014-01-28 Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020140010542A KR101553253B1 (ko) 2014-01-28 2014-01-28 Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템

Publications (2)

Publication Number Publication Date
KR20150089654A KR20150089654A (ko) 2015-08-05
KR101553253B1 true KR101553253B1 (ko) 2015-10-01

Family

ID=53886057

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140010542A KR101553253B1 (ko) 2014-01-28 2014-01-28 Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템

Country Status (1)

Country Link
KR (1) KR101553253B1 (ko)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010110193A1 (ja) 2009-03-24 2010-09-30 日本電気株式会社 情報共有装置、情報共有方法、プログラム及び情報共有システム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010110193A1 (ja) 2009-03-24 2010-09-30 日本電気株式会社 情報共有装置、情報共有方法、プログラム及び情報共有システム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Kristina Chodorow, ‘MongoDB: The Definitive Guide’, O’REILLY, 2013.05*
Rui Wang 외 4인, ‘Data Analysis and Simulation of Auto-ID enabled Food Supply Chains based on EPCIS Standard’, Proceedings of the IEEE International Conference on Automation and Logistics, 2011.08, pp.5*
TaiHyun Ahn 외 4인, ‘A Method for the Fast and Extendable EPC Information Service’, Proceedings of the Third International Conference on Emerging Database, 2011, pp.172-179*

Also Published As

Publication number Publication date
KR20150089654A (ko) 2015-08-05

Similar Documents

Publication Publication Date Title
US8180779B2 (en) System and method for using external references to validate a data object's classification / consolidation
CN111459985B (zh) 标识信息处理方法及装置
AU2006236390A1 (en) Supply chain process utilizing aggregated and cleansed data
WO2011102160A1 (ja) イベント情報管理システム、イベント管理方法およびプログラム
CN102004954A (zh) 一种产品信息系统和产品设计系统的信息集成方法
CN114416846A (zh) 一种高架库上物料的虚拟盘点方法及装置
US8195703B1 (en) System and method for storage of disparate items by a database
US7337029B2 (en) Design data management system and trace system
KR101553253B1 (ko) Epcis 규격에 따른 epc 및 센서 데이터의 통합 저장 방법 및 시스템, epcis 규격에 따른 epc 및 센서 데이터의 통합 처리 방법 및 시스템
US20080294697A1 (en) Automated data archive tool
US8793268B1 (en) Smart key access and utilization to optimize data warehouse performance
KR101410252B1 (ko) Ｅｐｃ 글로벌 네트워크 내 객체의 이동 추적방법
US20200364725A1 (en) Regulatory category assignment via machine learning
CN116402437A (zh) 批次管理方法、装置、设备和储存介质
CN115878623A (zh) 一种物流行业数据资产目录管理方法及系统
EP3920115A1 (en) Method and system for enabling to store genealogically related data within a blockchain network
Leung et al. A hybrid RFID case-based system for handling air cargo storage location assignment operations in distribution centers
CN102339284B (zh) 数据库索引的建立方法及其电脑系统
US20020040302A1 (en) Agile information system and management method
US8533125B2 (en) System and method for analyzing transportation data
Rozsnyai et al. Automated correlation discovery for semi-structured business processes
CN109726203A (zh) 一种重构图的数据存储方法
US20110078178A1 (en) View Server and Method for Providing Specific Data of Objects and/or Object Types
Ingvaldsen et al. Semantic business process mining of SAP transactions
Khabbazi et al. Object-oriented Design Framework for Stock Keeping Unit Generating System

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20180831

Year of fee payment: 4