KR102375966B1

KR102375966B1 - 시나리오를 포함하는 통합 시스템

Info

Publication number: KR102375966B1
Application number: KR1020200086141A
Authority: KR
Inventors: 김진용; 송태승; 권종원; 김기연; 추연준; 박선영; 황다혜; 김철호; 이상진; 안진석; 최열현; 조현보
Original assignee: 한국산업기술시험원
Priority date: 2020-07-13
Filing date: 2020-07-13
Publication date: 2022-03-18
Also published as: KR102368720B9; KR102375966B9; KR20220008052A; KR102368721B9; KR102298777B1; KR102298777B9; KR102368721B1; KR102375969B1; KR20220008053A; KR20220008050A; KR102375965B9; KR102375965B1; KR20220008054A; KR102375969B9; KR102368720B1; KR20220008051A

Abstract

본 발명의 통합 시스템은, 공급망 관리 시스템(SCM), 진일보된 생산 관리 시스템 (APS), 기업 자산 관리 시스템 (ERP), 객체 관계 관리시스템(CRM), 제품 수명주기 관리 시스템 (PLM), 제조 실행 시스템 (MES), 창고 관리 시스템(WMS), 품질 관리 시스템 (QMS), 가상 물리생산 시스템 (CPPS), 공장 에너지 관리 시스템 (FEMS) 중 적어도 하나를 포함하는 개별 어플리케이션 시스템; 각각의 상기 개별 어플리케이션 시스템이 비오디를 주고 받는 프로세스인 시나리오가 저장되는 시나리오 데이터베이스부; 를 포함한다.

Description

시나리오를 포함하는 통합 시스템{INTEGRATED SYSTEM INCLUDING SCENARIO}

본 발명은 시나리오를 포함하는 통합 시스템에 관한 것이다.

스마트팩토리는 클라우드, 빅데이터, 인공지능, 사물인터넷, 모바일 등의 디지털 기술들과 결합되어 공장 내 모든 요소가 유기적으로 연결되고 지능적으로 운영되는 공장을 말한다.

미래형 스마트팩토리의 핵심 키워드는 연결성과 데이터로, 비즈니스 생태계 전반을 수직 및 수평 통합하여 생산성 혁신을 가능하게 한다. 종래의 제조 아키텍처는 제조 응용 시스템 간 경계가 뚜렷한 계층적 구조였으나, 기업 내 요소들의 연결성이 강조되면서 제조 응용 시스템 간 경계의 파괴가 가속화 되고 있다. 즉, 데이터 수직 및 수평 통합을 통해 KPI(Key Performance Indicator) 중심의 시스템을 구축하여 열린 비즈니스 생태계를 지향하고, 제조 경쟁력을 강화하는 것이 필요하다.

대한민국 특허 공개공보 1020200074652

본 발명의 목적으로는 파편적으로 산재되어 발생하는 데이터의 활용성을 향상시키기 위한 표준 기반 데이터 모델을 제공하고, 이를 활용하기 위한 서비스를 지원하는 통합 시스템을 제공함에 있다.

종래의 기업들은 이전부터 비즈니스 경쟁력 확보를 위해 데이터의 중요성을 인식하고 다양한 IT 어플리케이션을 단계적으로 도입하고 운영해 왔다. 그러나 신규 시스템 도입을 고려하지 않은 인터페이스 구축 및 제조 데이터 표준 체계의 부재로 인해 데이터의 활용 및 분석에 어려움을 겪고 있다. 예를 들어, 필수 데이터 값 누락, 업무간 유효한 형식 및 약속값 미준수, 동일한 데이터 중복, 개별 어플리케이션 시스템 간 데이터 불일치, 필요한 시점에서의 데이터 제공 누락 등의 문제가 빈번하게 발생하고 있다. 이와 같이 일관성 없는 데이터는 잘못된 의사결정의 주요 요인이 될 수 있으며, 데이터를 검증하기 위해 많은 시간과 비용 및 노력이 소요될 수 있다.

이를 위해 데이터 통합을 이루기 위한 데이터 구조 표준이 필요하다. 이러한 문제를 해결하기 위해 데이터 교환 및 시스템 아키텍처 표준이 수년 동안 활용되고 있으나, 제조 가치 사슬을 다루기 위한 통합 표준에는 많은 중복이 발생하고 있다. 예를 들어, OAGIS(Open Application Group Integration Schema), B2MML(Business to Manufacturing Markup Language)에는 제조 응용 시스템을 저수준 시스템, ERP, EAM 및 기타 엔터프라이즈와 다양한 세부 수준으로 통합할 수 있는 메시지를 정의하며, MIMOSA와 ISA-95는 기업 내에서 기업과 자산을 다양한 수준으로 모델링하기 위한 구조를 정의하고, ISO130303 STEP 및 ISO-15926에는 제품 정보 수명주기 모델링을 지원할 수 있다. 그러나 이러한 국제 표준은 국내 제조현장에서 쓰이는 속성, 용어, 의미 등과의 괴리감으로 국내 현장에 적용하기는 어려운 실정이며, 혼란스럽고 복잡한 구조로 인해 사용자들에게 사용자들이 활용하기에 어려움을 느낄 수 있다.

국제 표준 뿐만 아니라 국내 현장의 특성을 반영한 제조 데이터 표준 스키마 데이터베이스 구축을 통해 국제표준과 부합될 수 있는 제조 응용 시스템 개발이 가능하고, 이로 인해 글로벌 통합 솔루션 패키지와 쉽게 호환될 수 있다.

또한 통합 서비스 플랫폼을 통해 솔루션 공급기업은 이기종 시스템 간 인터페이스를 위해 필요한 작업을 효율적으로 수행할 수 있다. 또한 관리 시스템을 통해 실제 표준을 활용하는 민간 기업에서 표준 데이터 모델 업데이트에 참여하여 표준의 활용성 및 현장 적용성을 향상시킬 수 있으며, 민간 기업의 신청에 따라 신규 생성되는 데이터는 관리 기관에서 표준화 된 구조로 관리하기 때문에 일관된 방법으로 관리할 수 있다.

이를 통해 제조 기업의 현장 데이터 수집부터 분석 및 활용 단계까지 동일한 구조로 데이터를 관리할 수 있으며, 비즈니스 생태계 내에서 모든 구성요소들이 참여하여 양방향 정보공유가 가능한 협업 플랫폼 구축 기반을 조성할 수 있다.

오늘날의 경쟁이란 하나의 공급 사슬과 다른 공급 사슬간의 경쟁을 의미하고, 단일 기업간 경쟁으로부터 생태계 간 경쟁의 형태로 변화되고 있다. 차별화된 경쟁력을 갖추기 위해서는 비즈니스 생태계를 강화시킬 수 있는 전략이 필요하다. 모회사와 자회사 간 효율적 협업 체계를 확보할 필요가 있다.

이를 감안한 본 발명은 다음과 같은 기업의 니즈(Needs)를 충족시킬 수 있다. 협력사간 스마트 팩토리 확대 필요, 정보 소통 및 협업 강화, 협력사 자생력 강화, 정보 및 데이터 공유 필요, 비즈니스 프로세스 통합, 새로운 플랫폼 구축을 통한 협업 구현, 동반 성장 강화, 파트너쉽 강화, 글로벌 제조품질 경쟁력 향상, 적기 부품 공급, 품질 확보, 제품 개발 협업, 부품 원가 경쟁력 확보, 유연한 부품 공급망 확보 등이 본 발명이 만족하는 기업의 니즈일 수 있다.

본 발명의 비오디 스키마 또는 통합 시스템의 핵심은 연결과 공유이다.

기업의 수직적 협업 체계는, 모기업 - 모기업에 직접 납품하는 1차 부품 협력사 - 1차 부품 협력사에 납품하는 2차 부품 협력사 - 2차 부품 협력사에 납품하는 일반 구매 협력사를 포함할 수 있다. 본 발명은 수직적 협업 체계를 구성하는 구성사 상호간의 효율적 협업 체계 구축을 달성할 수 있다.

본 발명은 다양한 제조 응용 어플리케이션을 활용하여, 스마트 공장으로 이루어진 부품 공급 생태계 전반에 걸쳐 수평적 연계성을 강화 또는 차별화한 경쟁력을 확보할 수 있다.

본 발명의 통합 시스템을 통해 비즈니스 프로세스내 구성요소는 서로 연결되어 상호 작용이 가능할 수 있다.

각 어플리케이션 또는 각 어플리케이션을 구성하는 기능 모듈은 전체 시스템 상에서 하나의 능동형 객체로 취급될 수 있다. 적은 엔지니어링 달성에 의한 플러그 앤 프로듀스(Plug and Produce)를 지원할 수 있다. 설비와 장치 및 공장의 유연성을 확보할 수 있다. 끊임없는 수직 및 수평 통합을 추구하며 엔드 투 엔드 엔지니어링(End to End Engineering)을 달성할 수 있다. 개선된 확장성을 갖고, 개방된 기술로서 혁신을 가능하게 한다.

본 발명은 ERP, CRM, PDM 등 무엇이든지 플러그 앤 프로듀스 방식으로 통합 시스템에 연결하여 상호 정보 교환이 가능하고 모든 사용자의 접근성이 높은 열린 생태계를 달성할 수 있다. 불량 및 오류 알람을 포함한 실시간 상황 대응이 가능하다. 품질 관리 기반 데이터 베이스가 구축되고, 이를 활용하여 설비 예지 보건, 전사적 장비 효율 관리를 달성할 수 있다.

도 1은 본 발명의 개방형 서비스 통합 시스템의 구성을 개략적으로 나타내는 그림이다.
도 2는 본 발명의 통합 시스템의 포털 사이트 홈페이지 화면이다.
도 3의 본 발명의 시나리오로서 제품을 생산하기 위해 자재명세(BOM) 정보를 생성하고 동기화하는 프로세스를 설명한다.
도 4는 본 발명의 비오디(BOD)의 구조를 나타내는 블록도이다.
도 5는 본 발명의 'SyncBOM'이라는 명칭을 갖는 비오디의 XML 코드를 도시한다.
도 6은 본 발명에서 정의한 비오디(BOD)를 통한 시스템 간 데이터 교환을 보여주는 예시이다.
도 7은 본 발명의 어플리케이션 영역의 트리 구조를 도시한 블록도이다.
도 8은 본 발명의 액션 동사부의 구조를 나타내는 그림이다.
도 9는 본 발명의 리스판스 동사부의 구조를 나타내는 그림이다.
도 10은 본 발명의 리퀘스트 동사부의 구조를 나타내는 그림이다.
도 11은 본 발명의 명사부의 구조를 나타낸 그림이다.
도 12는 본 발명의 데브에디터를 사용하는 절차를 개략적으로 도시한 것이다.
도 13은 본 발명의 데브에디터와 익스플로러의 활용을 보여주는 그림이다.
도 13a는 본 발명의 데브에디터에 입력되는 XSD 파일과, 데브에디터에서 출력되는 XML 또는 JSON 파일을 설명하는 블록도이다.
도 14는 본 발명의 트랜스 에이피아이의 구조를 개략적으로 도시한 것이다.
도 15는 본 발명의 트랜스 에이피아이를 통해 데이터를 송신하는 것을 개략적으로 나타낸 그림이다.
도 16은 본 발명의 인터페이스 테이블을 통해 연계하는 경우의 흐름을 도시한 것이다.
도 17은 본 발명의 데이터 통신을 통해 연계하는 경우의 흐름을 도시한 것이다.
도 18은 본 발명의 관리 시스템 사용을 위한 절차를 나타낸 그림이다.
도 19 이하는 본 발명의 통합 시스템의 사용자 인터페이스를 도시한다.

본 발명은 다음의 개별 어플리케이션 시스템을 표준 비오디 스키마를 사용하여 수직적 및 수평적으로 통합할 수 있다. 통합 시스템을 통해 개별 어플리케이션 시스템을 통합할 때, 표준 데이터 요소로서 비오디(BOD) 또는 비오디 스키마를 활용함으로써, 연결성과 공유성을 강화시킬 수 있다.

본 발명에서 비오디(BOD)는 비오디 스키마와 동일한 용어로 사용될 수 있다. 비오디(BOD)는 표준 데이터 요소를 의미하고, 비오디 스키마는 비오디가 표준 스키마로서 사용되는 개념을 포괄하는 용어로 사용될 수 있다.

■ 개별 어플리케이션 시스템

개별 어플리케이션 시스템은 공급망 관리 시스템(SCM), 진일보된 생산 관리 시스템 (APS), 기업 자산 관리 시스템 (ERP), 객체 관계 관리시스템(CRM), 제품 수명주기 관리 시스템 (PLM), 제조 실행 시스템 (MES), 창고 관리 시스템(WMS), 품질 관리 시스템 (QMS), 가상 물리생산 시스템 (CPPS), 공장 에너지 관리 시스템 (FEMS) 중 적어도 하나를 포함할 수 있다.

(1) 공급망 관리 시스템 (SCM : Supply Chain Management) - 부품 제공업자로부터 생산자, 배포자, 고객에 이르는 물류의 흐름을 하나의 가치사슬 관점에서 파악하고 필요한 정보가 원활히 흐르도록 지원하는 시스템을 말한다. 자재 발주, 납품 관리, 수주 관리, 매출 관리 모듈 중 적어도 하나를 포함할 수 있다.

(2) 진일보된 생산 관리 시스템 (APS : Advanced Planning & Scheduling) - MRP나 ERP와 같은 생산 관련 관리 프로그램으로 생산 계획을 수행하는 프로그램을 통칭한다. 생산 계획, 수요 관리, 납기 약속, 자원 운영 모듈 중 적어도 하나를 포함할 수 있다.

(3) 기업 자산 관리 시스템 (ERP : Enterprise Resource Planning) - 회계 관리, 인사 관리, 영업 관리, 무역 관리, 구매 자재 관리, 재고 관리, 생산 관리, 외주 관리, 기준 정보 관리, 물류 관리, 원가 관리, 품질 관리, 설비 관리, 프로젝트 관리 모듈 중 적어도 하나를 포함할 수 있다.

(4) 객체 관계 관리시스템(CRM : Consumer Relationship Management) - 고객 관리, 영업 분석 모듈 중 적어도 하나를 포함할 수 있다.

(5) 제품 수명주기 관리 시스템 (PLM : Product Life-cycle Management) - 프로젝트 관리, BOM 관리, 변경 관리, 개발 품질 관리, 기술 자산 관리, 기준 정보 관리, 제품 정보 관리, 개발 협업 관리 모듈 중 적어도 하나를 포함할 수 있다.

(6) 제조 실행 시스템 (MES : Manufacturing Execution System) - 생산 관리, 설비 관리, 기준 정보 관리, 성과 관리, 모니터링 모듈, 자재 관리, 품질 관리, 공정 관리, 물류 관리 모듈 중 적어도 하나를 포함할 수 있다.

(7) 창고관리시스템(WMS : Warehouse Management System) - 입고, 적치, 재고, 피킹, 출고 등 물류센터 프로세스 전체를 통합 관리하여 고객기업의 물류관리 및 운영을 위한 시스템을 말한다. 입고 관리, 실적 관리, 반품 관리, 출고 관리, 재고 관리 모듈 중 적어도 하나를 포함할 수 있다.

(8) 품질 관리 시스템 (QMS : Quality Management System) - 부적합 관리, 클레임 관리, 협력사 관리, 품질 심사, 변경 관리, SPC, PPAP 모듈을 포함할 수 있다. SPC란 Statistical Process Control의 약자로서, 통계적 자료와 분석기법을 활용하여(S) 품질변동의 원인과 공정상태를 파악하고(P), 품질목표가 달성될 수 있도록 관리(C)하는 모듈일 수 있다. PPAP(Production Part Approval Process)는 생산부품승인절차를 위한 모듈일 수 있다.

(9) 가상 물리생산 시스템 (CPPS : Cyber Production Physical System) - 인더스트리 4.0 에서 대두된 것으로서, 서로 다른 가상과 물리 체계에서 모든 정도(scale)와 수준(level)에서 치밀하게 통합하는 모듈일 수 있다.

(10) 공장 에너지 관리 시스템 (FEMS : Factory Energy Management System) - 공장의 에너지 관리 시스템으로서, 에너지 진단 모듈, 에너지 저장 모듈(ESS), 에너지 분석 모듈, 부하제어관리 모듈 중 적어도 하나를 포함할 수 있다.

본 발명은 비즈니스 통합 시나리오와 표준 기반 데이터 모델을 기반으로 비즈니스 프로세스를 통합하기 위해 지식 공유 기반 통합 시스템의 다양한 지원 서비스를 이용할 수 있다.

■ 개방형 서비스 통합 시스템

본 발명의 개방형 서비스 통합 시스템은 비즈니스 통합 시나리오 및 표준 데이터 모델의 활용 및 업데이트 등을 위한 지식 공유 기반의 웹사이트로 사용자들에 의해 생성된 데이터를 공유하고 활용할 수 있다.

도 1은 개방형 서비스 통합 시스템의 구성을 개략적으로 나타내는 그림이다. 통합 시스템은 통합 시나리오 및 표준 데이터 모델 비오디(BOD), 관리 시스템, 데브 에디터, 익스플로러, 트랜스에이피아이를 포함할 수 있다.

도 2는 통합 시스템의 포털 사이트 홈페이지 화면이다. 통합 시스템의 기본 메뉴는 총 6개로 구성되어 있다. 본 발명의 전반적인 소개를 포함하는 소개메뉴, 기술문서, XSD 파일 등 관련 자료를 다운로드 받을 수 있는 다운로드 메뉴, 지원도구 소개 및 접속을 위한 툴 키트 메뉴, 사용자 참여형 비오디 관리 시스템인 신규 제안(New Proposal) 메뉴, 서비스 이용 신청을 위한 멤버쉽 메뉴를 포함한다.

■ 비즈니스 통합 시나리오

비즈니스 통합 시나리오는 전 산업에 공통적으로 적용 가능한 비즈니스 프로세스를 정의한 것으로, 제조 응용 시스템 간 메시지를 교환하는 비오디(BOD)의 흐름으로 나타낼 수 있다. 시나리오의 정보교환 주체는 제조 응용 시스템 단위가 아닌 제조 시스템의 기능 단위로 정의하여, 제조 환경 내에서 각각의 기능들이 참여자로써 서로 상호작용할 수 있는 메쉬(Mesh)형 네트워크 구조를 형성할 수 있다. 이를 통해 생산현장에서 발생하는 데이터들을 쉽게 공유할 수 있고, 기업의 제조 수준 및 특성에 맞는 KPI(Key Performance Indicator) 또는 원하는 정보를 실시간으로 파악할 수 있다. 즉, 비오디(BOD)는 각 개별 어플리케이션 시스템을 유기적으로 연결할 수 있으며, 다수의 개별 어플리케이션 시스템의 유기적 조합은 시나리오를 형성할 수 있다.

시나리오는 각 개별 어플리케이션 시스템이 표준화된 데이터인 비오디(BOD)를 사용하며 요청과 응답을 수행하는 프로세스로 정의할 수 있다. 제1 개별 어플리케이션 시스템이 제2 개별 어플리케이션 시스템을 향하여 제1 비오디(BOD)를 전송하고 제1 요청을 요구하며, 제1 요청에 대한 제1 응답으로서 제2 개별 어플리케이션 시스템이 제1 개별 어플리케이션 시스템을 향하여 제2 비오디(BOD)를 전송하며 제1 요청에 제1 응답으로 대화하는 프로세스일 수 있다. 개별 어플리케이션 시스템 및 비디오 스키마는 더 많은 수로 확장될 수 있다. 단, 시나리오 내에서 구성요소의 자체 프로세스는 비오디(BOD)가 아니다.

시나리오는 UML(Unified Modeling Language) 시퀀스 다이어그램(Sequence Diagram)으로 표현될 수 있다. UML(Unified Modeling Language)은 프로그램 설계를 표현하기 위하여 주로 그림으로 된 표기법을 의미할 수 있다. 객체지향 모델링 언어로 볼 수 있다. 코딩을 하기 전에 모델을 설계하는데, 시각적 모델링을 위하여 UML 이 사용될 수 있다.

시나리오는 시나리오 데이터베이스부에 저장될 수 있다.

도 3의 시나리오는 제품을 생산하기 위해 자재명세(BOM) 정보를 생성하고 동기화하는 프로세스를 설명한다. 이를 위해 도 3의 시나리오의 개별 어플리케이션 시스템으로는 제품 수명 주기 시스템(PLM), 기업 자산 관리 시스템(ERP), 제조 실행 시스템(MES)이 포함될 수 있다. 제품 수명 주기 시스템(PLM)이 없는 경우에는 기업 자산 관리 시스템(ERP)이 PLM 역할을 대체할 수 있다.

도 3에 도시된 시나리오에 따르면, 개별 어플리케이션 시스템인 PLM에서 생성된 자재명세(BOM) 정보를 개별 어플리케이션 시스템인 ERP에 동기화하기 위해 싱크봄(SyncBOM)이라는 비오디(BOD)를 전송하면서 제1 요청을 전달할 수 있다. 제1 요청에 대하여 ERP는 PLM을 향하여 싱크리스판스봄(SyncResponseBOM)이라는 비오디(BOD)를 전송하면서 제1 요청에 대한 응답인 제1 응답을 전달할 수 있다.

다음으로, PLM에서 MES에 싱크봄(SyncBOM)이라는 비오디(BOD)를 전송하여 MES에 BOM 정보 동기화를 요청하는 제2 요청을 전달할 수 있다. 제2 요청에 대한 응답인 제2 응답으로서, MES는 PLM을 향하여 싱크리스판스봄(SyncResponseBOM)이라는 비오디(BOD)를 전달할 수 있다.

■ 표준 데이터 모델 비오디(BOD)

비오디(BOD)는 "Business Object Document"의 약자로, 시스템 간 원활한 데이터 교환을 위해 가져야하는 공통된 메시지 구조인 데이터 스키마(Schema)일 수 있다. 스키마(Schema)는 데이터 베이스에 메타 데이터 형태로 저장될 수 있으며, 현실 세계의 특정한 한 부분의 표현으로서 특정 데이터 모델을 이용해서 만들어질 수 있다. 본 발명의 비오디(BOD)는 IEC 62264등 국제 표준을 벤치마킹한 결과물로, 국내 제조현장의 특징을 반영하여 국내에서도 쉽게 활용될 수 있도록 국제 표준에서 정의하는 비오디(BOD)를 재구성하여 개발하였다. 이 때 국제 표준에서 정의하는 용어 의미와 카멜 표기법을 적용하여 추후 국제 표준과의 호환성을 고려하였다.

본 발명은 정보의 재사용이 가능한 다계층 구조로 이루어진 비오디(BOD)를 활용하여 데이터의 관리, 전달 및 공유를 표준화시킬 수 있다. 종래에는 서로 다른 개별 어플리케이션 시스템의 데이터의 호환이나 표준화가 이루어지지 않았으나, 비오디(BOD)를 통해 이를 통합할 수 있다. 제안하는 비오디(BOD)는 업종에 제약이 없으며, 어플리케이션 간 (A2A: Application to Application) 데이터 교환에서 모두 적용할 수 있다. 즉, 하나의 기업 내에서 다수의 어플리케이션이 존재하는 경우 뿐만 아니라 서로 다른 기업의 어플리케이션 간 (B2B: Business to Business) 인터페이스에도 적용 가능하다. 또한 비오디(BOD)는 통신이 가능한 현장 설비영역부터 비즈니스 의사결정 시스템 영역까지 적용할 수 있다.

도 4는 본 발명의 비오디(BOD)의 구조를 나타내는 블록도이다. 도 4를 참조하면, 비오디(BOD)는 어플리케이션 영역, 데이터 영역을 포함할 수 있다. 데이터 영역은 동사부와 명사부를 포함할 수 있으며, 명사부는 필드부와 참조 필드부를 포함할 수 있다. 동사부와 명사부의 조합을 통해 비오디(BOD)의 이름을 명명할 수 있다.

비오디(BOD)는 XML 또는 JSON으로 표현될 수 있다. XML(Extensible Markup Language)는 HTML과 유사한 기반의 마크업 언어(text based markup language)로서, 데이터를 저장하고 전달할 목적으로 만들어진 것이다. XML 태그는 HTML 태그처럼 미리 정의되어 있지 않고 사용자가 직접 정의할 수 있다. XML은 다른 시스템끼리 다양한 종류의 데이터를 손쉽게 교환할 수 있고, 새로운 태그를 만들어 추가해도 계속해서 동작하므로 확장성이 좋다. XML은 데이터 자체를 보여주기보다, 데이터를 전달하고 저장하는 것을 주 목적으로 할 수 있다. XML은 텍스트 데이터 형식의 언어로서, XML 문서는 유니코드 문자로만 이루어져 범용성이 좋을 수 있다.

도 5는 'SyncBOM'이라는 명칭을 갖는 비오디의 XML 코드를 도시한다. 최상위에 비오디의 명칭인 'SyncBOM'이 <SyncBOM> 으로 도시될 수 있다. 비오디는 <Application Area> 태그로 표시되는 어플리케이션 영역과, <DataArea> 태그로 표시되는 데이터 영역을 포함할 수 있다.

도 6은 정의한 비오디(BOD)를 통한 시스템 간 데이터 교환을 보여주는 예시이다. 정보를 가지고 있는 시스템(Sender)이 자재명세서(BOM: Bill Of Material) 정보를 다른 시스템에 동기화(Sync)하기 위한 메시지(SyncBOM)를 보내면, 정보를 받는 시스템(Receiver)에서 처리결과와 함께 회신 메시지(SyncResponseBOM)를 보낸다. 이와 같이 송신 어플리케이션에서 정보 처리, 필요한 정보에 대한 요청 비오디 메시지를 보내면, 수신 어플리케이션에서는 받은 비오디 메시지에 대한 회신 비오디 메시지를 전송하는 것이 바람직하다.

■ 표준 데이터 모델 비오디(BOD) 구조 - 어플리케이션 영역

어플리케이션 영역(Application Area)은 비오디 송수신 어플리케이션의 IP 주소, 비오디의 송신 날짜 등 비오디 메시지 처리를 위해 통신 계층에서 필요한 정보를 전달한다. 또한 비오디 메시지의 식별과 인증을 위해 필요한 정보도 포함할 수 있다.

도 7은 본 발명의 어플리케이션 영역의 트리 구조를 도시한 블록도이다. 어플리케이션 영역은 1차 속성(attributes)으로서 송신자(Sender), 수신자(Receiver), 생성 시간(CreationDateTime), 시나리오 ID(ScenarioID), 비오디 ID(BODID) 중 적어도 하나를 포함할 수 있다.

1차 속성(attributes)인 '송신자' (Sender)는 비오디 메시지를 전송하는 개별 어플리케이션 시스템을 의미한다. 송신자(Sender)는 2차 속성(attributes)으로 송신 어플리케이션의 IP, 서버 포트 등 시스템의 위치에 대한 정보인 호스트 주소(Host), 어플리케이션 아이디(ApplicationID)를 담고 있다. 또한 수신 어플리케이션에 비오디 메시지를 잘 받았는지에 대한 간단한 확인 요청 여부에 대한 확인코드(ConfirmationCode)를 포함한다.

1차 속성(attributes)인 '수신자' (Receiver)는 비오디 메시지를 수신하는 개별 어플리케이션 시스템을 의미한다. 수신자(Receiver)는 2차 속성(attributes)으로 송신자 속성(attributes)과 유사하게 호스트 주소(Host), 어플리케이션 아이디(ApplicationID) 중 적어도 하나를 포함할 수 있다.

1차 속성(attributes)인 생성 시간(CreationDateTime)은 비오디가 생성된 시간 정보를 담을 수 있다.

1차 속성(attributes)인 시나리오 ID(ScenarioID)는 비오디와 관련된 통합 시나리오에 대한 정보를 담을 수 있다.

1차 속성(attributes)인 비오디 ID(BODID)는 비오디를 식별하기 위한 아이디 정보를 나타낼 수 있다.

■ 표준 데이터 모델 비오디(BOD) 구조 - 데이터 영역

데이터 영역(Data Area)은 비오디 메시지가 전달하는 정보를 포함하며, 동사부(Verb)와 명사부(Noun)으로 구성될 수 있다.

동사부는 수신 어플리케이션이 수행할 동작 또는 송신 어플리케이션의 요청에 대한 응답 등 정보와 연결된 동작을 나타낼 수 있다. 비오디(BOD)는 송신 어플리케이션에서 정보처리, 필요한 정보에 대한 요청 메시지를 보내면 수신 어플리케이션에서는 받은 메시지에 대한 회신 메시지를 전송하는 것을 원칙으로 한다. 이와 같이 메시지를 보내는 상황에 따라 사용해야 하는 동사의 유형이 결정된다. 동사의 유형은 액션 동사부, 리스판스 동사부, 리퀘스트 동사부로 정의할 수 있다.

액션 동사부(Action Verb)는 비즈니스 객체를 생성하거나 비즈니스 객체를 가지고 어떤 행동을 하는 동사를 말한다. 액션 동사부는 전달하는 정보의 특정 처리를 요청하는 상황에서 사용될 수 있다. 정보의 특정 처리는 정보의 추가, 변경, 삭제 등 데이터 또는 비오디에 취해야 하는 동작을 나타낸다. 도 8은 액션 동사부의 구조를 나타내는 그림이다. 액노우리지 코드(acknowledgeCode)는 액션 타입의 동사부에 응답하는 비오디 메시지의 회신 여부를 결정한다. 액션 크리테리아는 정보에 취해야 할 동작(actionCode)와 그 대상에 대한 정보(Xpath)를 포함한다. 액션 동사부의 구체적인 종류로는 싱크(Sync), 체인지(Change), 캔슬(Cancel), 프로세스(Process), 노티파이(Notify)를 들 수 있다.

리스판스 동사부(Response Verb)는 수신자인 원래 메시지에 대해 요청된 처리에 대한 결과를 보고하거나 결과를 반환하는 경우에 사용하는 동사를 말한다. 도 9는 리스판스 동사부의 구조를 나타내는 그림이다. 리스판스 크리테리아는 이전의 요청 메시지에 의해 전달받은 정보의 처리 결과(actionCode)와 반환해야 할 내용(Xpath)을 포함한다. 리스판스 동사부의 종류로는 싱크리스판스(SyncResponse), 체인지액노우리지(ChangeAcknowledge), 캔슬액노우리지(CancelAcknowledge), 액노우리지(Acknowledge), 쇼우(Show), 컨펌(Confirm) 을 들 수 있다.

리퀘스트 동사부(Request verb)는 수신 어플리케이션의 특정 데이터를 요청할 때 사용하는 동사를 말한다. 도 10은 리퀘스트 동사부의 구조를 나타내는 그림이다. Expression에 수신 어플리케이션에 요청할 사항을 Xpath로 표현한다. 리퀘스트 동사부의 종류로는 겟(Get)일 수 있다.

명사부는 동사부에서 정의된 동작을 적용할 정보를 포함한다. 도 11은 명사부의 구조를 나타낸 그림이다. 명사부는 참조필드부와 필드부로 구성된다. 참조필드부는 다른 테이블을 참조하기 위한 키 값으로, 정보의 재사용을 가능하게 하여 인터페이스 시 유연성 및 확장성을 확보할 수 있게 하며, 필드부는 다른 테이블을 참조하지 않는 값이다. 명사부의 내용은 각 정보를 전달하기 위해 국내 현장에서 공통적으로 쓰이고 있는 데이터 속성들을 정리하여 국제 표준 용어 및 표기법을 적용하여 정의하였다. 예를 들어, 명사부의 명칭 및 설명은 다음과 같다.

(1) 자재명세서(BOM): 품목을 구성하거나 품목을 생산하기 위해 투입되는 자재명세서를 의미할 수 있다.

(2) 아이템 마스터(ItemMaster): 품목코드, 품목명, 규격 등과 각종 속성값을 관리하는 품목 마스터를 의미할 수 있다.

■ 시나리오 및 BOD 활용을 위한 지원도구

본 발명은 비오디(BOD)를 이용하여 인터페이스 중심의 제조 데이터 표준화를 달성할 수 있다. 비오디(BOD)를 기본 요소로 하여 표준 활용성 증대를 위한 지원도구인 데브에디터, 익스플로러, 트랜스 에이피아이를 제안한다.

데브에디터는 사용자의 상황에 맞는 비즈니스 프로세스와 비오디를 만들어주는 개발자 협업 도구를 말한다. 도 12는 데브에디터를 사용하는 절차를 개략적으로 도시한 것이다. 데브에디터를 통해 도 12의 절차를 거치게 되며, 프로젝트에 참여하는 멤버가 검토완료를 마쳐야 다음 단계로 넘어갈 수 있다. 이와 같이 데브에디터를 활용하면 프로젝트를 생성하여 실제 시스템 인터페이스 프로젝트 협업을 수행할 수 있으며, 원활한 협업을 위한 알림, 채팅 등의 기능을 활용할 수 있다.

익스플로러는 본 발명의 통합 시스템에서 제공하는 시나리오, 비오디의 속성을 검색할 수 있는 도구이다. 익스플로러를 활용하면 시나리오와 비오디, 비오디의 속성의 정확한 의미를 파악할 수 있다. 익스플로러는 사용자의 상황에 적합한 시나리오와 비오디 추천 서비스를 제공할 수 있다.

도 13은 데브에디터와 익스플로러의 활용을 보여주는 그림이다. 사용자는 데브에디터와 익스플로러를 통해 통합 시스템에서 표준으로 제공되는 시나리오와 비오디(BOD)를 조회할 수 있다.

데브에디터를 통해 생성된 사용자 정의 시나리오 또는 비오디(BOD)는 별도로 저장되어 익스플로러에 공유될 수 있다.

사용자가 통합 시스템의 포털 사이트에 로그인없이 접속하면 데브 에디터의 설명 화면이 표시될 수 있다. 반면에 사용자가 포털 사이트에 로그인 후 포털 사이트의 데브 에디터 메뉴를 클릭하면 데브 에디터가 실행될 수 있다. 데브 에디터는, 사용자의 협업을 위한 알림 또는 채팅 기능을 제공할 수 있다.

사용자가 로그인 방식으로 데브 에디터에 접속하면, 데브 에디터에 의하여 비오디가 생성 또는 편집될 수 있다. 비오디의 속성은 데브 에디터로 편집될 수 있다.

도 13a는 본 발명의 데브에디터에 입력되는 XSD 파일과, 데브에디터에서 출력되는 XML 또는 JSON 파일을 설명하는 블록도이다.

데브 에디터의 입력측에는 XSD 파일이 입력되고, 출력측에는 XML 파일 또는 JSON 파일이 출력될 수 있다. 데브 에디터에 입력된 하나의 XSD 파일은 각각의 개별 어플리케이션 시스템별로 복수의 XML 파일 또는 JSON 파일로 구분 출력될 수 있다.

데브 에디터는 XSD 파일을 입력받고 제1 개별 어플리케이션 시스템에 제1 XML 파일 또는 제1 JSON 파일을 출력할 수 있다. 데브 에디터는 XSD 파일을 입력받고 제2 개별 어플리케이션 시스템에 제2 XML 파일 또는 제2 JSON 파일을 출력할 수 있다.

XSD 파일과 각각의 XML 파일 또는 JSON 파일은 동사부가 변화없이 동일할 수 있다. 도 13a에 따르면 공통의 동사부로서 SyncBOM이 도시된다.

명사부의 필드부는 데브 에디터를 거치면서 각 개별 어플리케이션 시스템의 특성에 맞게 분리될 수 있고, 분리된 명사부의 필드부는 각 개별 어플리케이션 시스템에 할당될 수 있다.

도 13a를 참조하면, XSD 파일의 명사부는 제1 필드부와 제2 필드부를 포함할 수 있다. 제1 필드부는 Field 1으로 도시되고, 회사 ID를 나타낼 수 있다. 제2 필드부는 Field 2로 도시되고, 품목 사양을 나타낼 수 있다.,

XSD 파일의 제1 필드부는 데브 에디터를 거쳐 제1 개별 어플리케이션 시스템에 전달될 수 있고, XSD 파일의 제2 필드부는 데브 에디터를 거쳐 제2 개별 어플리케이션 시스템에 전달될 수 있다.

제1 필드부는 제1 개별 어플리케이션 시스템에 제1 XML 파일 또는 제1 JSON 파일 형식으로 전달될 수 있다. 제1 XML 파일 또는 제1 JSON 파일에는 Field 1으로 도시된 회사 ID가 저장될 수 있다. Field 2로 도시된 품목 사양은 제2 필드부이며, 제1 개별 어플리케이션 시스템의 설계 용도에는 불필요하므로 제조 목적의 개별 어플리케이션 시스템인 제2 개별 어프리케이션에 제2 XML 파일 또는 제2 JSON 파일 형식으로 전달될 수 있다.

명사부의 속성은 명사부에 포함된 필드부 또는 참조 필드부의 명칭, 타입, 길이 중 적어도 하나를 포함할 수 있다. 데브 에디터는 동사부는 그대로 유지한 채, 명사부의 속성을 분리하여 개별 어플리케이션 시스템별로 맞춤형으로 할당할 수 있다.

데브 에디터는 시나리오에 비오디를 추가하거나, 시나리오에 추가된 비오디의 속성을 사용자가 원하는대로 편집하므로, 사용자 맞춤형 비오디를 생성하거나 사용자 맞춤형 시나리오를 생성할 수 있다. 데이터는 공유되므로 프로젝트 수행을 위한 개발자 협업 도구로서 데브 에디터가 사용될 수 있다.

데브 에디터는 비오디를 생성 또는 편집할 수 있다. 도 13a와 같이 개별 어플리케이션 시스템별로 전달되는 비오디의 명사부의 속성이 구분 할당될 수 있다. XSD 파일의 명사부의 속성이 XML 파일 또는 JSON 파일의 명사부의 속성으로 할당될 수 있다.

트랜스 에이피아이는 개별 어플리케이션 시스템 간의 원활한 인터페이스를 지원하는 도구가 될 수 있다.

트랜스 에이피아이는 시스템마다 정의한 데이터명이 다르기 때문에 사용자의 활용성 및 현장 적용성을 종합적으로 고려하여 표준 맵핑 기능을 탑재한 통합 패키지 형태로 개발되었다. 도 14는 트랜스 에이피아이의 구조를 개략적으로 도시한 것이다. 통합 시스템 지원도구에서는 표준 데이터 모델과 시스템 데이터의 일대일 맵핑을 수행할 수 있다. 또한 데브에디터의 완료 프로젝트 정보를 받아 비오디(BOD) 정보 및 스키마 파일을 로컬 PC에 내려받을 수 있다.

■ 인터페이스 지원도구 트랜스 에이피아이

통합 시스템의 트랜스 에이피아이와 연동되어 기업의 현장에서 시스템 인터페이스를 지원하는 어댑터(Adapter)의 역할을 수행할 수 있다. 도 15는 트랜스 에이피아이를 통해 데이터를 송신하는 것을 개략적으로 나타낸 그림이다. 이 경우는 인터페이스 테이블을 이용한 데이터 통신 방법을 사용한다고 가정한다. 데이터를 송신하기 위해 송신 시스템에서는 URL의 형태로 트랜스 에이피아이를 호출하면, 트랜스 에이피아이는 송신 시스템의 인터페이스 테이블에 접근하여 인터페이스 데이터를 가져온다. 트랜스 에이피아이의 맵핑 테이블을 통해 스키마를 표준 기반 XML 문서로 변환하고, 비오디(BOD) 스키마 XSD 파일과 비교하여 데이터 정합성을 검증한다. 이 후 다시 수신 시스템의 스키마로 데이터를 변환하여 수신 시스템의 인터페이스 테이블에 데이터를 삽입한다.

이와 같은 일련의 과정을 수행하기 위해 트랜스 에이피아이는 반드시 각 개별 어플리케이션 시스템의 인터페이스 테이블의 접근 권한을 가져야 한다.

그리고 트랜스 에이피아이에서 이루어지는 이벤트 및 로그를 로그 데이터베이스에 저장 및 관리하여 각 어플리케이션 간 인터페이스 현황을 실시간 조회할 수 있다.

■ 트랜스 에이피아이를 통한 데이터 연계 방식

어플리케이션 간 데이터 인터페이스 방법으로는 인터페이스 테이블을 이용한 방법과 데이터 통신을 이용한 방법이 있을 수 있다. 본 발명의 트랜스 에이피아이는 두 가지 방식을 모두 지원할 수 있다.

도 16은 인터페이스 테이블을 통해 연계하는 경우의 흐름을 도시한 것이다. 인터페이스 테이블을 이용하는 경우에는 각각의 어플리케이션 사이에 별도의 인터페이스 테이블을 두고 상호 연계하는 방식으로, 연계하고자 하는 데이터에 대해 임시로 생성한 인터페이스 테이블을 가질 수 있다. 단, 트랜스 에이피아이는 각 시스템의 인터페이스 테이블의 데이터를 Select 및 Insert를 하기 위해 인터페이스 테이블에 대한 접근권한을 반드시 가져야 한다.

인터페이스 테이블에는 연계하고자 하는 데이터 뿐만 아니라 송수신 일시, 송수신 상태 등 송수신을 위해 필요한 항목들을 추가하여 설계할 수 있다. 트랜스 에이피아이는 사용자가 통합 시스템에 입력한 데이터 속성 맵핑 테이블을 통해 각각의 개별 어플리케이션 시스템에 인터페이스 테이블을 생성하며, 기존에 인터페이스 테이블이 존재하고 있으면 이를 생성하기 위한 스크립트를 별도 공간에 저장한다.

생성된 인터페이스 테이블은 송수신 일시, 송수신 상태 등의 인터페이스 필수 항목과 함께 비오디(BOD) 구조에 기반하여 명사부의 참조필드와 필드로 구성될 수 있다. 이 때 송수신 어플리케이션의 인터페이스 테이블 구조는 동일할 수 있다.

도 17은 데이터 통신을 통해 연계하는 경우의 흐름을 도시한 것이다. 데이터 통신을 통한 인터페이스 방식의 경우, 연계하고자 하는 데이터 형식을 XML 파일로 전달하면 수신측에서 파싱(Parsing)하여 이를 해석하는 방식일 수 있다. XML 파일은 비오디(BOD)의 구조로 생성되며, 생성된 XML 파일은 FTP(File Transfer Protocol)를 통해 전송될 수 있다.

두 가지 방식 모두 트랜스 에이피아이에서 XSD 파일을 통해 정합성 검증을 수행할 수 있다. 인터페이스 테이블을 이용하는 경우 트랜스 에이피아이에서 XML 파일로 데이터를 변환하여 트랜스 에이피아이가 가진 XSD 파일과 비교하여 데이터 정합성을 검증할 수 있다. 데이터 통신을 이용하는 경우에도 수신측으로 XML 파일을 전송하기 전에 트랜스 에이피아이가 가진 XSD 파일을 통해 데이터를 검증할 수 있다.

■ 시나리오 및 비오디(BOD) 관리 시스템

제조 데이터 스키마는 공급 기업과 수요 기업의 요구사항 변경, 기술의 발전 등에 따라 추가 및 변경될 수 있다. 이러한 제조 데이터 스키마의 추가 및 변경 사항은 표준 절차에 따라 지속적이고 일관성 있는 관리가 필요하다. 본 발명에서는 제조 데이터 스키마의 표준화된 관리 체계를 시스템화하여 제공함으로써, 일관된 방법으로 스키마를 관리할 수 있도록 지원할 수 있다.

관리 시스템을 활용하는 이해관계자는 사용자, 관리기관, 심의위원회가 있다. 사용자는 제조 데이터 스키마의 관리(생성/수정/삭제)를 제안하고, 관리기관에서는 사용자가 제안한 제조 데이터 스키마 관리(생성/수정/삭제)를 제조 데이터 관리 시스템에서 처리하며, 심의위원회는 제조 데이터 스키마 관련 산/학/연 전문가로 구성되어 관리기관의 제조 데이터 스키마 관리에 대해 승인 또는 반려 여부 심의를 수행한다.

도 18은 관리 시스템 사용을 위한 절차를 나타낸 그림이다. 제조 데이터 스키마 정의 단계에서는 개발될 스키마의 범위를 정의하고 참여 멤버를 구성하는 것을 목적으로, 스키마 범위, 시나리오, 등록 및 변경될 스키마 메시지 및 데이터(XML 항목), 스키마 등록 및 변경 계획 / 관련된 기관 및 자원, 스키마 관련 가정 사항, 타 스키마와의 의존 관계 및 이슈 등을 포함하여 정의한다. 개발 단계에서는 스키마의 내용, 관련 문서 및 예제를 작성하는 것을 목적으로, XML 스키마 예시 작성 등의 관련 문서 작성을 포함한다. 스키마 검토 및 승인 단계에서는 제조 데이터 스키마 이해관계자들이 등록 및 변경되는 제조 데이터 스키마가 기존 업무를 지원할 수 있는지 확인하고 등록 및 변경된 기존 스키마보다 더 나은 결과물임을 보장하기 위한 것을 목적으로, 심의위원회에서 이를 검토한다. 스키마 발간 단계에서는 등록 및 변경된 제조 데이터 스키마를 스키마 관리기관의 홈페이지에 게시하여 발표하는 것을 목적으로, 등록 및 변경된 새로운 스키마를 스키마 관리기관의 인터넷 홈페이지에 게시 및 이해관계자에게 알림 이메일 송부하고 최종 버전에 병합한다.

■ 데브 에디터의 사용자 인터페이스

데브 에디터의 핵심 기능은 다음과 같다.

(1) 사용자 맞춤형 시나리오 및 비오디 생성 기능 - 데브 에디터를 통하여 사용자는 원하는대로 시나리오 및 비오디를 생성할 수 있다. 데브 에디터를 통하여 사용자는 시나리오에 비오디를 추가하거나, 시나리오에 추가된 비오디의 속성을 사용자가 원하는대로 편집 가능하다.

(2) 사용자들이 생성한 시나리오 및 비오디는 웹사이트에 공유되거나 익스플로러에서 조회 가능하다. 시나리오 및 비오디의 공개 가능한 범위는 통합 시스템 정책에서 정할 수 있다.

(3) 프로젝트 수행을 위한 개발자 협업 도구로서 데브 에디터가 사용될 수 있다. 효율적인 업무 수행을 위한 대쉬보드, 알림, 채팅 등 온라인 협업 도구로서 데브 에디터가 사용될 수 있다. 데브 에디터는 이기종 시스템 연동 프로젝트에서 연계성을 높일 수 있다.

툴 키트 3종은 사용자의 로그인 후 실행되는 제2 기능에 포함된다.

통합 시스템의 홈페이지 상단의 툴 키트 메뉴 중 데브 에디터는 사용자 로그인 후 클릭시 실행될 수 있다.

통합 시스템의 제2 기능은 포털 사이트에 접속한 사용자가 로그인을 하면 실행할 수 있다. 일반 사용자는 수요 기업 사용자와 공급 기업 사용자를 포함할 수 있다.

사용자와 관련된 프로젝트 목록이 표시될 수 있다. 로그인한 사용자의 프로젝트 목록을 보여줄 수 있다. 프로젝트 등록 메뉴도 표시될 수 있다. 프로젝트 등록 메뉴는 수요 기업 사용자에게만 표시될 수 있다.

수요 기업 사용자에게만 표시되는 프로젝트 생성창이 표시될 수 있다. 사용자가 프로젝트명을 클릭하면 프로젝트 상세 정보 화면으로 이동될 수 있다.

도 19는 프로젝트의 등록 또는 수정을 위한 인터페이스이다. 프로젝트에 참여하는 공급 기업 또는 개별 어플리케이션 시스템이 도 18의 팝업창에서 선택된 것이 반영되어 있다. 등록된 공급 기업 또는 개별 어플리케이션 시스템은 프로젝트 기본정보에서 삭제 또는 추가할 수 있다.

도 20은 데브 에디터에서 선택한 프로젝트의 상세 화면이다.

데브 에디터는 대쉬 보드, 자료 목록, 프로젝트 논의 사항, 시나리오, 비오디 중 적어도 하나를 탭 형식으로 표시할 수 있다.

도 21은 데브 에디터의 자료 목록 탭을 클릭하면 보여주는 화면이다. 프로젝트 상세 화면의 문서 탭을 클릭하면 프로젝트와 관련된 자료 또는 문서를 등록하거나 공유할 수 있다. 도 22는 문서를 삭제하는 창이다.

도 23은 프로젝트 논의 사항을 탭으로 열어놓은 인터페이스이다. 프로젝트에 관한 의견을 표시하고, 의견을 등록하거나, 수정하거나 삭제할 수 있다. 이와 같이 통합 시스템은 프로젝트에 관한 다수 사용자의 의견을 서로 공유할 수 있는 장점이 있다.

도 24는 프로젝트 상세 화면의 시나리오 탭을 클릭하면 실행되는 인터페이스이다. 시나리오를 추가할 수 있다. 시나리오 정보를 입력할 수 있는 빈 레코드가 생성되며 시나리오 내용을 입력할 수 있다. 시나리오를 추가하는 경우 시나리오 내용을 입력하고 저장하는 것이 바람직하다.

도 25를 참조하면, 시나리오가 추가/저장 혹은 삭제되면 왼쪽 트리의 My Workspace 목록이 갱신되는 것을 볼 수 있다. 트리에서 항목을 선택하면 탭 화면에 내용이 표시될 수 있다.

도 26은 생성된 시나리오의 비오디를 추가 및 설정하는 화면이다.

시나리오 또는 비오디를 조회하는 익스플로러가 호출될 수 있다. 해당 팝업창에서 적용하고자 하는 시나리오와 비오디를 추가할 수 있다. 시나리오가 편집되면 비오디 목록을 포함하는 시나리오의 다이어그램이 표시될 수 있다. 시나리오가 완성되면 프로젝트의 다른 참여자에게 시나리오 검토가 요청되며 메시지가 전달될 수 있다.

도 27을 참조하면, 시나리오 및 비오디를 조회할 수 있다. 시나리오 상세 화면에서 프로세스 추가시 팝업창으로 오픈될 수 있다. 입력된 키워드로 시나리오 및 비오디를 통합 검색할 수 있다. 시나리오를 선택하면 선택된 시나리오에 포함된 비오디 전체가 추가될 수 있다. 선택된 비오디를 추가하며 동일 비오디의 중복 추가도 가능할 수 있다. 시나리오별 비오디 구성 및 시나리오의 다이어그램 표시 화면을 호출할 수 있다.

도 28을 참조하면, 시나리오별 상세 정보 팝업창이 표시될 수 있다. 시나리오별 비오디 목록 및 시나리오의 다아아그램 정보가 표시될 수 있다. 적용할 비오디를 선택할 수 있고, 선택된 비오디가 적용되면 시나리오 다이어그램이 표시될 수 있다.

도 29는 시나리오에 비오디를 추가한 결과를 보여주는 화면이다. 비오디 등록 후 송신자가 되는 개별 어플리케이션 시스템 및 수신자가 되는 개별 어플리케이션 시스템을 설정할 수 있다. 비오디의 개별 어플리케이션 시스템 정보를 설정할 수 있고, 이를 저장하면 시나리오의 다이어그램이 생성될 수 있다. 오른쪽 다아아그램 창에 시나리오가 UML 다이어그램으로 표시될 수 있다. 다이어그램 창의 UML은 다운로드 가능할 수 있다.

도 30은 프로젝트 상세 화면의 비오디 탭이다. 비오디를 클릭하면 비오디의 속성 선택을 할 수 있다.

도 31은 사용자 맞춤형 비오디를 생성하기 위한 속성 선택 화면이다.

표준으로 제공하는 비오디의 속성 정보가 표시될 수 있다. 전체 속성 중에서 사용자가 원하는 속성을 선택하고 저장하면, 선택된 속성만 포함된 비오디 스키마를 다운로드받을 수 있다. XSD 파일 또는 JSON 파일로 설정 내용을 다운로드받을 수 있다.

도 53은 새로운 프로젝트 등록 화면이다. 사용자는 프로젝트 명칭을 입력하고, 프로젝트에 대한 설명을 디스크립션 창에 입력할 수 있다. 수요 기업의 이름을 입력하거나 수요 기업 담당자의 이름을 입력할 수 있다.

프로젝트 관리 테이블에는 프로젝트에 참가하는 업체 명, 개별 어플리케이션 시스템 명칭, 관리자 정보 중 적어도 하나가 표시될 수 있다.

프로젝트 정보 관리 버튼이 마련될 수 있으며, 이를 클릭하면 프로젝트 정보를 수정할 수 있다. 프로젝트 관리 테이블을 통하여 프로젝트를 생성, 관리, 삭제할 수 있다.

■ 익스플로러의 사용자 인터페이스

다음은 익스플로러에 대하여 설명한다. 도 32를 참조하면, 익스플로러 메인 화면이 표시된다. 상단의 검색창에 키워드를 입력하면 키워드를 포함하는 시나리오 및 비오디를 조회할 수 있다.

도 33은 익스플로러의 검색창에 키워드를 입력한 결과 검색된 시나리오 또는 비오디를 표시할 수 있다. 도 34는 도 33의 주요부를 확대한 그림이다. 검색 결과는 키워드와 관련된 모든 결과를 보여줄 수 있다. 예를 들면, 시나리오, 비오디, 동사, 명사, 참조 필드, 필드 등이 보여질 수 있다.

도 35는 시나리오 속성, 시나리오에 포함된 비오디 목록, 시나리오의 다이어그램을 보여주는 팝업창이다.

시나리오 상세 내용은 비오디 명칭, 송신자가 되는 개별 어플리케이션 시스템 명칭, 수신자가 되는 개별 어플리케이션 시스템 명칭 중 적어도 하나를 포함할 수 있다. 시나리오는 비오디 명칭, 송신자가 되는 개별 어플리케이션 시스템 명칭, 수신자가 되는 개별 어플리케이션 시스템 명칭 중 적어도 하나를 포함하는 UML형식의 다이어그램으로 표시될 수 있다.

도 36은 통합 시스템에 등록된 시나리오 목록을 표시할 수 있다. 시나리오 목록에는 비오디 명칭, 설명, 시나리오의 사용 빈도가 표시될 수 있다.

도 37 및 이를 부분 확대한 도 38에 따르면, 통합 시스템에 등록된 개별 어플리케이션 시스템의 목록이 표시될 수 있다. 개별 어플리케이션 시스템의 상태는 개별 어플리케이션 시스템의 명칭, 설명, 개별 어플리케이션 시스템의 사용 빈도 중 적어도 하나를 포함할 수 있다.

■ 트랜스 에이피아이이의 사용자 인터페이스

XSD 파일을 통해 정합성 검증을 수행하는 트랜스 에이피아이가 마련될 수 있다.

인터페이스 테이블을 이용하는 경우, 트랜스 에이피아이에서 XML 파일로 데이터를 변환하고, 트랜스 에이피아이가 가진 XSD 파일과 비교하여 데이터 정합성을 검증할 수 있다.

데이터 통신을 이용하는 경우, 수신측으로 XML 파일을 전송하기 전에 트랜스 에이피아이가 가진 XSD 파일을 통해 데이터 정합성을 검증할 수 있다.

트랜스 에이피아이는 이기종 시스템간 인터페이스를 위한 어댑터가 될 수 있다. 트랜스 에이피아이는 상기 두 가지 기능을 모두 지원할 수 있다.

트랜스 에이피아이는 표준 데이터와 시스템 데이터의 일대일 맵핑을 지원할 수 있다. 트랜스 에이피아이를 통하여 인터페이스 현황 조회가 가능하다.

도 39를 참조하면, 명사부의 목록이 표시되고, 명사부를 선택하면 명사부의 상태와 개별 어플리케이션 시스템의 컬럼명을 매핑할 수 있는 목록이 우측에 표시된다. 명사부에 대하여 개별 어플리케이션 시스템에서 정의한 데이터 속성과 표준 데이터 속성을 맵핑할 수 있다.

도 40은 완료된 프로젝트 상세 보기 화면이다. 테이블 정보의 엑셀 다운로드가 가능하다. 비오디 리스트의 엑셀 다운로드가 가능하다. 시나리오를 선택 또는 변경하면 해당하는 시퀀스 다이어그램이 표시될 수 있다.

■ 기타 메뉴의 사용자 인터페이스

도 41은 트레이닝 및 서비스 메뉴의 상세 화면이다.

도 42는 비오디 관리 시스템인 신규 제안(New Proposal) 메뉴에 대한 상세 화면이다. 심의 요청 목록이 표시될 수 있다. 검색창에 입력된 심의 정보를 보여줄 수 있다. 요청 제목을 클릭하면 상세 화면으로 이동할 수 있다.

도 43을 참조하면 New Proposal 심의 요청 화면이 표시된다. 요청 타입을 선택할 수 있다. 입력한 내용으로 심의 요청이 이루어질 수 있다.

도 44 및 도 45 는 심의 요청(New Proposal) 된 메시지의 처리 결과가 표시된다.

수요 기업 사용자 또는 공급 기업 사용자는 시나리오 또는 비오디의 생성, 수정, 삭제를 요청할 수 있다. 수요 기업 사용자 또는 공급 기업 사용자는 새로운 제안에 대한 심의 요청을 통합 시스템을 통하여 입력하고, 심의 위원은 입력된 심의 요청을 심사하여 결과를 응답할 수 있다.

도 52는 심의 요청(New Proposal) 리스트를 보여준다. 심의 요청 리스트는 심의 요청 타입, 심의 요청 명칭, 사용자 이름, 심의 요청 일자, 심의 요청 상태 중 적어도 하나의 항목을 포함할 수 있다.

심의 요청 타입은 시나리오, 필드부, 명사부 중 적어도 하나에 대한 것일 수 있다.

심의 위원이 심의 요청을 심사한 결과는 심의 위원과 사용자가 공유할 수 있다. 심의 요청 상태는 Accepted(승인), Rejected(거절), Reviewd(검토중), Queued(대기중) 중 적어도 하나를 포함할 수 있고, 심의 요청 상태는 선택 메뉴의 형태로 심의 위원 및 사용자가 공유할 수 있다.

도 46은 동사부 관리 화면이다. 동사부 관리 테이블은 동사부의 명칭, 등록일자, 사용여부, 동사부의 속성 관리 메뉴 중 적어도 하나를 포함할 수 있다. 사용자 또는 관리자가 동사부의 명칭을 신규로 입력하면 새로운 동사부를 추가할 수 있다. 동사부의 상태를 미사용으로 변경하면 해당 동사부와 연관된 비오디도 미사용으로 상태 변경될 수 있다.

도 47은 명사부 관리 화면이다. 명사부 관리 테이블은 명사부의 명칭, 사용 여부, 등록 일자, 명사부의 속성 관리 메뉴 중 적어도 하나를 포함할 수 있다. 사용자 또는 관리자가 명사부의 명칭을 신규로 입력하면 새로운 명사부를 추가할 수 있다. 명사부의 상태를 미사용으로 변경하면 해당 명사부와 연관된 비오디도 미사용으로 상태 변경될 수 있다. 명사부의 속성을 관리할 수 있는 메뉴창도 선택 가능하다.

도 48은 명사부의 속성 관리 화면이다. 명사부의 속성은 명사부에 포함된 필드부 또는 참조 필드부의 명칭, 타입, 길이, PK 여부, NULL 허용, 포맷 중 적어도 하나를 포함할 수 있다. 명사부의 속성을 추가하고 편집할 수 있다.

도 49는 비오디 관리 화면이다. 비오디 관리 테이블은 비오디의 명칭, 상세 내용, 등록 일자, 동사부, 명사부 중 적어도 하나를 포함할 수 있다. 비오디의 속성 관리 메뉴도 표시될 수 있다.

도 50은 시나리오 관리 화면이다. 시나리오 관리 테이블은 시나리오명, 상세 내용, 시나리오의 종류, 사용 여부, 등록 일자, 시나리오 속성 관리 메뉴 중 적어도 하나를 포함할 수 있다. 시나리오 명칭을 입력하여 검색 가능하다.

시나리오의 추가도 가능하다. 시나리오 명칭을 입력하고 시나리오 정보를 입력하며 시나리오 관리 테이블의 항목을 완성하면 새로운 시나리오를 추가할 수 있다. 시나리오 관리 화면에서 비오디 설정 화면도 팝업될 수 있다.

도 51은 팝업된 비오디 설정 화면이다. 비오디 속성 및 시나리오 다이어그램이 표시될 수 있다.

Claims

스마트팩토리용 데이터들을 교환하기 위한 통합 시스템으로서,
개별 어플리케이션 시스템들; 및
상기 개별 어플리케이션 시스템들과 연결되며, 상기 개별어플리케이션 시스템들간 데이터를 상호 입출력하고, 어플리케이션영역과 하나의 동사부와 명사부를 포함하는 데이터영역을 포함하는 각 비오디(BOD)를 사용하여 데이터를 교환하고, 상기 개별 어플리케이션 시스템들이 상기 비오디를 주고 받는 프로세스인 시나리오가 수행되는 플랫폼 서버;를 포함하며,
상기 플랫폼 서버에는,
상기 비오디 및 상기 시나리오를 상기 개별 어플리케이션 시스템들의 특성에 따라 생성 또는 편집하여 제공하는 데브에디터,
상기 시나리오와 상기 비오디를 검색하는 익스플로러, 및
상기 개별 어플리케이션 시스템들간의 상기 비오디를 매칭시키는 트랜스에이피아이가 설치되고,
상기 플랫폼 서버가 제공하는 포털사이트는,
상기 데브에디터, 상기 익스플로러, 상기 트랜스 에이피아이, 및 심의 요청 메뉴의 사용자 인터페이스와,
상기 동사부, 상기 명사부, 상기 비오디, 및 상기 시나리오의 관리 인터페이스를 제공하며,
상기 포털사이트의 상기 데브에디터의 사용자 인터페이스는, 제1 개별 어플리케이션 시스템 및 제2 개별 어플리케이션 시스템의 정보, 상기 개별 어플리케이션 시스템들이 주고받는 비오디의 정보, 상기 비오디의 상호 교환 프로세스로 정의되는 시나리오의 정보, 상기 시나리오의 집합체인 프로젝트에 관한 정보를 표시하고,
상기 포털사이트의 상기 익스플로러의 사용자 인터페이스는 상기 시나리오와 상기 비오디의 목록화면을 표시하고,
상기 포털사이트의 상기 트랜스 에이피아이의 사용자 인터페이스는 데이터 맵핑 화면을 표시하고,
상기 포털사이트의 심의 요청 메뉴의 사용자 인터페이스는 상기 비오디 및 상기 시나리오 중 적어도 하나에 대한 제안 내용을 입력받는 심의 요청 리스트를 표시하며,
상기 포털사이트의 동사부의 관리 인터페이스는 상기 비오디의 상기 동사부를 생성 또는 관리하는 동사부 관리 테이블을 표시하고,
상기 포털사이트의 명사부의 관리 인터페이스는 상기 비오디의 상기 명사부를 생성 또는 관리하는 명사부 관리 테이블을 표시하고,
상기 포털사이트의 비오디의 관리 인터페이스는 상기 비오디에 관한 정보를 관리하는 비오디 관리 테이블을 표시하고,
상기 포털사이트의 시나리오의 관리 인터페이스는 UML 시퀀스 다이어그램으로 표현되는 상기 시나리오의 정보를 관리하는 시나리오 관리 테이블을 표시하고,

상기 데브에디터는 표준 비오디 XSD 파일을 입력받아 상기 제1 개별 어플리케이션 시스템용 제1 XML 파일 또는 제1 JSON 파일이나 상기 제2 개별 어플리케이션 시스템용 제2 XML 파일 또는 제2 JSON 파일로 출력하여 사용자정의 비오디를 생성하며, 상기 XSD 파일의 명사부가 제1 필드부와 제2 필드부를 포함하는 경우, 상기 제1 XML 파일 또는 제1 JSON 파일의 명사부에 상기 제1 필드부를 포함하고, 상기 제2 XML 파일 또는 제2 JSON 파일의 명사부에 상기 제2 필드부를 포함되게 할 수 있고,
상기 트랜스 에이피아이는 상기 개별 어플리케이션 시스템들간 데이터 인터페이스를 매칭시키기 위하여 인터페이스 테이블을 이용하고, 상기 인터페이스 테이블은 상기 제1 개별 어플리케이션 시스템과 제2 개별 어플리케이션 시스템 사이에 전송되는 상기 비오디를 각 개별 어플리케이션 시스템에 대응되는 데이터 스키마로 변환하고,
상기 사용자는 상기 제안 내용을 상기 심의 요청 메뉴에서 처리하고,
상기 제안 내용이 상기 심의 요청 메뉴에 입력되면 상기 심의 요청에 대한 응답 메시지가 상기 심의 요청 메뉴에 표시되며,
상기 심의 요청 메뉴에는 심의 요청 리스트가 표시되고,
상기 심의 요청 리스트는 심의 요청 타입, 심의 요청 명칭, 사용자 이름, 심의 요청 일자, 심의 요청 상태 중 적어도 하나의 항목을 포함하고,
상기 심의 요청 타입은 상기 시나리오, 상기 비오디를 구성하는 명사부, 상기 명사부를 구성하는 필드부 중 적어도 하나에 대한 것이며,
상기 심의 요청 상태는 Accepted(승인), Rejected(거절), Reviewd(검토중), Queued(대기중) 중 적어도 하나를 포함하는 스마트팩토리용 데이터 통합 시스템.
삭제
제1항에 있어서,
상기 시나리오는 사용자 정의 시나리오로 편집되고,
상기 사용자 정의 시나리오는 별도로 저장되며, 상기 익스플로러에 공유하는 스마트팩토리용 데이터 통합 시스템.
제3항에 있어서,
상기 개별 어플리케이션 시스템은 제1 개별 어플리케이션 시스템 및 제2 개별 어플리케이션 시스템을 포함하고,
상기 시나리오는,
상기 제1 개별 어플리케이션 시스템이 상기 제2 개별 어플리케이션 시스템을 향하여 제1 비오디(BOD)를 전송하고 제1 요청을 요구하며, 상기 제1 요청에 대한 제1 응답으로서 상기 제2 개별 어플리케이션 시스템이 상기 제1 개별 어플리케이션 시스템을 향하여 제2 비오디(BOD)를 전송하며 상기 제1 요청에 상기 제1 응답으로 대화하는 프로세스를 포함하는 스마트팩토리용 데이터 통합 시스템.
제3항에 있어서,
상기 개별 어플리케이션 시스템은 제1 개별 어플리케이션 시스템 및 제2 개별 어플리케이션 시스템을 포함하고,
상기 제1 개별 어플리케이션 시스템이 상기 제2 개별 어플리케이션 시스템을 향하여 싱크봄(SyncBOM)이라는 비오디(BOD)를 전송하면서 제1 요청을 전달하거나,
상기 제1 요청에 대하여 상기 제2 개별 어플리케이션 시스템은 상기 제1 개별 어플리케이션 시스템을 향하여 싱크리스판스봄(SyncResponseBOM)이라는 비오디(BOD)를 전송하면서 상기 제1 요청에 대한 응답인 제1 응답을 전달하는 스마트팩토리용 데이터 통합 시스템.
제5항에 있어서,
상기 시나리오는 각 개별 어플리케이션 시스템들이 데이터를 주고받는 프로세스의 단위이고,
상기 비오디(BOD)는 각 개별 어플리케이션 시스템들이 주고받는 데이터의 단위이며,
상기 하나의 비오디(BOD)는 하나의 동사부만 포함하는 스마트팩토리용 데이터 통합 시스템.
제1항에 있어서,
상기 동사부는 액션 동사부, 리스판스 동사부, 리퀘스트 동사부 중 하나이며,
상기 비오디는 상기 동사부의 종류에 따라 액션 비오디, 리스판스 비오디, 리퀘스트 비오디 중 어느 하나에 해당되는 스마트팩토리용 데이터 통합 시스템.
제7항에 있어서,
상기 액션 비오디는 상기 동사부가 싱크(Sync), 체인지(Change), 캔슬(Cancel), 프로세스(Process), 노티파이(Notify) 중 하나를 포함하는 비오디이고,
상기 리스판스 비오디는 상기 동사부가 싱크리스판스(SyncResponse), 체인지액노우리지(ChangeAcknowledge), 캔슬액노우리지(CancelAcknowledge), 액노우리지(Acknowledge), 쇼우(Show) 중 하나를 포함하는 비오디이며,
상기 리퀘스트 비오디는 상기 동사부가 겟(Get)을 포함하는 비오디인 스마트팩토리용 데이터 통합 시스템.
삭제
삭제
삭제