본문 바로가기

블로그

LG CNS 기술블로그 DX Lounge에서 최신 IT 소식을 만나보세요!

스마트 물류/팩토리

‘나’와 다른 ‘너’와의 상호 작용을 위한 IT의 역할(11편) – Manufacturing as a Production Vs. Manufacturing as a Service –

2015.03.06

지난 시간에는 제조 시스템의 지능화를 가능하게 하는 자동화 단계 중, 일부 내용과 각각의 단계 속에서 시스템 내의 종적인 흐름을 통합하는 IT 역할에 대해 살펴보았는데요.

이어서 오늘 이 시간에는 자동화 단계의 나머지 세부 내용들을 자세히 알아보겠습니다.

● ‘나’와 다른 ‘너’와의 상호 작용을 위한 IT의 역할(9편) : http://blog.lgcns.com/713
● ‘나’와 다른 ‘너’와의 상호 작용을 위한 IT의 역할(10편) : http://blog.lgcns.com/716

공장 자동화와 그 운영 기술들속의 IT

(3) 레벨 2(Operator Level – 관점: Level 1 / 대상: 공정 및 사건들)

주로 프로세스형 제조에서 이 단계가 많이 사용되는데요. 일반적으로 마스터 PLC 등으로 제어가 가능한 이산형에 비해 공정 자체와 다루는 신호들이 더 복잡하고 기술자, 작업자 등의 개입, 감수가 자주 이루어지는 단계입니다.

앞선 단계의 센서 등 필드 기기의 하드-소프트 인터페이스들로부터 수집된 데이터들을 바탕으로 공정의 비정상적인 상태 및 에러들에 대한 경고를 HMI로 판별하는 식으로, 상대적으로 작업자(사람)들의 지식과 경험에 많이 의존하는 편입니다. 이산형 제조의 PLC에서 온/오프 사다리 로직을 사용하였다면, 여기서는 PID Loops(proportional-integral-derivative controller mechanism)을 사용하여 제어하는 대상(공정의 온도, 압력 등의 아날로그 변수)의 (아날로그) 센서 출력 값을 연속적으로 측정하여 이를 설정 값과 비교해 오차 값을 계산합니다. 그리고 이 오차값을 이용해 제어에 필요한 제어 파라미터 값을 도출해 내는 튜닝 과정 등을 거칩니다.

이 레벨에서는 크게 DCS(Distributed Control System) 과 SCADA(supervisory control and data acquisition) 등의 두 가지 소프트웨어 가상 시스템으로 실행이 되는데요. 최근에는 그 구별 자체가 많이 없어지는 추세이기도 하지만, 원래 DCS는 공정 기반이고, SCADA는 사건 기반으로, 데이터 획득에 보다 초점을 맞추고 있습니다. 즉 DCS는 주로 하나의 장소에서 연결된 설비들로 구성된 여러 작업 공정들의 대규모 공정을 제어하는 역할에 초점을 맞추는 반면, SCADA는 더 넓은 지역에 퍼져 있는 상대적으로 작은 장치/설비 등에 대한 애플리케이션들에서 다양한 분산 데이터를 수집하고 이를 보다 거시적으로 관장하는 역할을 합니다.

또한, DCS는 데이터 저장에 특화되기보다는 실시간으로 필요한, 일종의 휘발성 Analytical 데이터들을 단일 데이터베이스에 수집하고, 운전자와 시스템에 일관적인 제어의 목적만으로 제공하기 위한 시스템이라 할 수 있습니다. 그러다 보니, 대체로 모든 장비들이 단일 공급 업체에서 공급되는 요소들로 통합된 패키지 형태로 제공되는 경우가 많습니다.

SCADA의 경우는 보다 통합에 초점을 맞추게 되는데, 즉 하위에 분산된 각각의 설비를 담당하는 PLC나 RTU들에서 발생하는 이벤트들을 저장하는 각각의 분산 데이터 베이스를 가질 수 있고, 이러한 분산 이벤트들을 상위에서 관장하고 분산 데이터들을 업데이트 하는 방식을 따르고 있습니다. 그러다 보니, 보다 다양한 업체들의 장비 또한 포괄할 수 있는 기능을 가지게 됩니다.

  <DCS(상)와 SCADA 시스템(하)의 제조 현장 실제 적용의 예(출처: www.synergistscada.com/)>

위에 제시한 그림을 통해 두 시스템이 실제로 현장에서 어떻게 적용되는지 비교해 볼 수 있는데요. Siemens(독일), ABB(스위스), Emerson Process Management(미국), Rockwell Automation(미국), Schneider electric(프랑스), Honeywell(미국), Omron(일본), Yokogawa(일본) 등의 업체에서 주력으로 개발 보급하고 있는 실정입니다.

(4) 레벨3(Factory Management Level – 관점: 제품 / 대상: 공장, 물류 창고 등에서의 제품 흐름)

이 단계부터는 직접적인 제어라는 개념 보다는 제품과 관계된 전체적인 Workflow 및 제어 레벨에서 전해지는 정보들과 비즈니스 레벨에서 하달되는 명령들의 조정/관리에 더 초점을 맞춘 자동화 단계에서 일종의 중간자 역할을 하는 가상 시스템들이라 할 수 있습니다. 통칭하여 ‘Manufacturing Operations Management Systems(MOMS)’으로 분류합니다. MES (Manufacturing Execution System), WMS(Warehouse Management System), LIMS(Laboratory Information Management System), BES(Batch Execution System), EMS(Energy Management System), DH(Data Historian) 등이 있습니다.

즉 제조 시스템의 다양한 현장(공장, 물류 창고, 실험실, 등)의 총괄 관리를 담당하는 가상의 소프트웨어 시스템들이라 할 수 있고, 현장의 워크플로우, 레시피의 제어, 각종 기록 데이터들을 유지/보존하고, KPI(Key Performance Index), 대쉬보드, 스코어카드 등을 이용해 제조/생산 공정의 성능을 관찰하고 평가/최적화하는 기능을 수행합니다.

 <MES의 뼈대라 할 수 있는 Workflow 모델 – Orchestrated 유한 상태 제어 모델의 예>

공장 전체의 제어와 관련해서는 하위 계층의 컨트롤러들과 긴밀히 통신하며 그것들을 종합적으로 관장하는 일종의 조정자가 필요할 것입니다. 그림에서는 여러 MOM 중 그러한 조정을 가능케 하는 MES의 Workflow의 예를 보여 주고 있습니다. 이것을 통해 하위 제어 레벨과의 상호 작용이 도식화되고 하위 시스템의 이벤트를 기반으로 ‘알림’을 나타내거나, 어떤 의사 결정을 내려 변경된 지시를 하달할 수도 있습니다.

또한 Workflow 모델을 통해 실제 코드도 생성될 수가 있습니다. 보다 직접적인 중앙 집중식 관장인 ‘Orchestrated’ 방식, 분산 제어의 지도와 같은 역할을 하는 ‘Choreographed’ 방식이 있는데요. 이 레벨에서 사용되는 시간 단위는 시프트별로 seconds, minutes, hours로 실시간에 가깝게 관리/제어한다고 볼 수 있습니다. 이 시간 단위는 결국 시스템의 성능 및 다루는 정보의 양과 관계가 깊은데, 개발 초기보다는 컴퓨팅/IT의 발전으로 점점 줄어들고 있습니다.

즉, 하위의 제어 시스템들과는 그 시스템들과 흡사하게 초나 분 단위의 실시간으로 상호 작용하여 즉각 즉각 의사 결정을 내리고, 현장의 최신 상태를 반영하려 합니다. 그러나, 관점과 정보 흐름의 빈도 자체가 다른 상위의 비즈니스 시스템들과는 그보다는 더 늘어난 시간 단위로 현장의 상황을 보고하는 식입니다.

<MES와 타 레벨 시스템 및 개체들과의 상호 작용(참조: ISA95 standards; http://www.mesa.org/en/index.asp)>

위의 그림은 MES의 기본적인 기능들 및 MES 와 다른 레벨의 가상 시스템들 간의 상호 작용 및 교환되는 정보들에 대해 보여 주고 있습니다. 즉 중간 단계에서 비즈니스 시스템의 다소 추상적인 주문 정보(무엇을 얼마나 만들 것인지에 대한)를 실제 생산 라인의 과정들에 대한 정보(작업의 적절한 배분을 통해 어떻게 만들 것인지에 대한)들로 구체화함으로써 가상 비즈니스와 물리적 생산과의 가교 역할을 한다고 보시면 될 것 같습니다. ERP 같은 비즈니스 시스템이 거래/재정적인 경영에 관심을 가지면서 보다 거시적인 의사 결정에 초점을 맞춘다면, MES는 공장의 여러 자원의 사용을 최적화하며 품질 및 실제 생산 절차의 유효성을 극대화 하기 위한 단기 생산 활동 운영에 관한 의사 결정에 초점을 맞춘 시스템인데요. 그래서 현장 환경의 실시간 감시 및 통합 제어, 물류 및 작업 내역 추적 관리, 상태 파악, 불량 관리 등을 수행하여 계획된 생산 목표를 달성하도록 하는 공장의 최고 관리자 역할과 정보의 연결자 역할을 동시에 수행합니다.

즉, 아래 그림과 같이 다양한 레벨 및 소스들(PDA 등을 이용한 직접 입력, 센서/컨트롤러 등의 자동 입력)로부터 공장 운영과 관계된 데이터를 수집하여 일종의 버퍼 데이터베이스를 통해, 의사 결정을 위한 분석을 시행합니다. 그리고 이 버퍼 데이터베이스는 오른쪽 그림에서처럼 앞서 소개한 B2MML 등의 표준 프로토콜을 이용하여 ERP, PLM, CRM 등의 비즈니스 시스템의 메인 데이터베이스들과 연동합니다. 그 정보를 전부 혹은 비즈니스 레벨에서 필요한 정보들로 선별하여 업데이트하고, 또한 비즈니스 시스템의 Transaction을 반대로 버퍼 데이터베이스로 업데이트 하기도 합니다.

<다양한 소스들로부터의 데이터 수집을 통한 공장 운영 관리자와 중간자 역할을 하는 MES
(출처: amitadeshpande.blogspot.kr/; wso2.com/)>

최근에는 ERP 시스템의 범위에 따라서 일부 제조업 전용 ERP 팩키지에서는 그중 생산 관리 파트가 MES와 일치하기도 하고, 단일 데이터베이스를 이용하여 데이터 중복과 상태 업데이트 등의 비효율성을 피하는 식으로, 비즈니스와 생산을 통합/연계하고자 하려는 시도를 하고 있습니다.

IT 기반 솔루션 업체뿐만 아니라, 제조업을 보유한 대기업들이 이 MES를 포함한 MOM의 개발에 뛰어들고 있는데요. 중소 제조업의 자동화 비율이 더 높은 유럽 및 미주 지역의 경우는 우리나라보다 더 활발히 개발 및 사용되고 있는 상황입니다.

앞서 소개했던 LG CNS 의 EZ-MES, Siemens, GE Intelligent Platform 및 Rockwell (AutoSuite, PharmaSuite, CPGSuite, FactoryTalk), ATS (Rolls-Royce MES), Parsec Automation의 TrakSys, Schneider-Invensys MES 등 업종별로 특화되거나, 혹은 범용적으로 사용 가능한 솔루션들이 나와있는 상황입니다.

가장 최근에는 HTML5에 기반하여 가상의 터미널 없이, 웹브라우저에서 바로 실행이 가능한 모바일 및 클라우드 기반 솔루션도 등장하고 있습니다. 이로 인해, 직접 설치 없이, 같은 기능들을 서비스 형태로 사용할 수 있게 되었고, 현장의 사건들에 따라 다양한 방식(이메일, 메시지, HMI 등)으로 등록된 이해 관계자들에게 실시간으로 ‘알림’을 전송하는 기능 또한 추가 되고 있는 추세입니다.

(5) 레벨 4(Enterprise Level – 관점: 제품에 대한 수요, 주문, 생산 결과 등의 트랜잭션 / 대상: 공장의 전체 자원 및 공급 사슬의 이해 관계자들)

이 단계에서는 사무실 컴퓨팅 환경에서 전사적인 정보를 위한 계획, 경영 관리 등을 한다고 생각하시면 됩니다. ERP나 Product Lifecycle Management(PLM), Customer Relationship Management(CRM), Human Resource Management(HRM), Master Data Management(MDM) 같은 비즈니스 시스템이 존재하고, 패키지의 이름이 말해 주듯이 어떤 중심 개체들(Product, Resource, Process, 마스터데이터 혹은 이들 전부를 포괄하거나)을 대상으로 관리하는지에 따라 그 기능이 나뉩니다.

그 중, 가장 포괄적인 정보를 다루는 ERP 가상 비즈니스 시스템의 경우는 업무 거래 관리자(Transaction Manager)라고도 불리며, 공장(들), 물류 창고 등 기업이 관리하는 모든 제조 활동의 전반에 관계된 가상의 부서들을 컴퓨터 모듈화하여 관리합니다. 즉 제조 기업의 실제적인 부서나 현장 등과 흡사하게 아래 그림과 같이 마케팅, 제조(생산, 재료 구매, 물류 등으로 더 세분화됨), 회계, 인사 등의 구분된 기능으로 나뉘어집니다.

<ERP 내의 모듈화된 가상 부서들 및 ‘Order To Cash – Order Fulfillment’의 예를 통한 가상 부서들 사이의 Business Process (출처: mainthing.ru/tag/acm/)>

제조 업체와 관련된 이해 관계자들(실제 고객들이나 공급 업체)와의 메시지 등의 온라인 트랜잭션 이벤트 등을 입력으로 시작하여, 가상 부서들의 여러 활동 사이를 연결하는 데이터베이스 트랜잭션들 및 메시지/정보 흐름들로 구성된 Business Process를 통해 실행이 됩니다. 거래 대상 고객이나 사용자에게 리포트나 정보 등의 무형의 가치, 즉 서비스를 제공하는 것을 목적으로 하고 있는데요. 그러한 목적을 바탕으로 다양한 거래(Transaction) 정보를 계획하고 관리하는 것이죠.

예를 들어, 왼쪽 그림에서는 고객의 판매 주문부터 제품 배달, 대금 지급까지 커버하는 ‘Order Fulfillment’ 비즈니스 프로세스의 간단한 예를 보여 주고 있습니다. 이러한 예와 같이 여러 가상부서들의 활동을 연계하는 크고 작은 다양한 비즈니스 프로세스의 조합들이 생성될 수 있고, 결과적으로는 ERP 가상 시스템의 활용 여부는 그 프로세스들을 얼마나 효과적으로 생성, 관리, 조합하여 실행하는지에 달려있다고 볼 수 있습니다.

위의 오른쪽 그림에서는 ‘자재 구매 주문’의 트랜잭션이 어떻게 공급자의 가상 생산 부서의 추상적인 활동들(주문 접수–주문 이행 계획 수립–주문 이행 완료)과 연계되는지를 나타내는 비즈니스 프로세스라 할 수 있습니다. 이와 흡사하게 조금 더 범위를 좁혀서, ‘주문 이행 계획 수립’과 관련해서는 아래 그림과 같이 더 세부적인 비즈니스 프로세스로 계획의 여러 단계가 표현될 수 있겠습니다. 여기서도 푸른색 화살표는 데이터베이스 트랜잭션으로 필요한 정보들을 검색하여 계획 알고리즘을 거쳐 필요한 정보를 MES에 전달하게 됩니다.

앞서 언급했듯이 과거, 현재, 그리고 예측에 관계된 다양한 정보를 집합된 입력을 이용하여 계획을 수행하기 때문에 그 계획에 사용되는 시간 단위는 시프트별로 Days, Weeks, Months 등으로 나뉩니다. 앞서 MES와 마찬가지로, 점점 발전하여 그 시간 단위가 줄어들고 있는 추세인데요. 일반적으로는 최소 일주일 단위로 계획을 생성합니다.

그러나, 이 계획이라는 것은 컴퓨팅의 성능이 허락만 한다면, 가장 최신의 현장 상황을 바탕으로 더 자주 업데이트해 주는 것이 전체 시스템의 가시성 확보 차원에서 더 좋을 것으로 보입니다. ERP의 비즈니스 시스템의 출력 정보로 생성된 생산 주문은 결국 MPS를 통한 총 생산량, MPS의 총 생산량을 기반으로 한 MRP의 자재 구매량, 그리고, 현재 재고량 등의 값으로 오른쪽 그림처럼 MES 공장 관리자에게 메시지로 전달되게 되겠죠.

<생산 계획에 관계된 비즈니스 프로세스와 주문 정보를 기반으로 한 SAP ERP-MES의 상호 작용의 예 (출처: help.sap.com/)>

자재 구매 계획(MRP) 시스템이 모체인 ERP 가상 시스템은 그 후로 계속 진화하여, 범용의 일반 ERP, IERP(Industry-oriented ERP; 산업별로 특화된), 주문자 제작된 IERP 등으로 차별화되기도 합니다. 그리고 이 세 가지를 모두 통합하는 Entire Resource Planning를 통해 외부 환경에 해당하는 Social 및 에너지 자원과의 관계까지 포괄하는 형태로 발전하게 되는데요. 또한 애플리케이션 자체를 클라우드에서 가상으로 지원하는 서비스를 통해 복잡한 설치 과정 및 비용 또한 생략할 수 있게 되고, 필요할 때만 빌려 쓸 수도 있게 되었죠. 가상 서비스를 통해 보다 다양한 컴퓨팅 자원들과 연계가 가능해짐으로써 ERP 레벨에서 더 심화된 Business Intelligence 또한 가능하게 되었습니다. Epicor ERP와 Oracle Fusion, SAP HANA Cloud Platform 등이 좋은 예라 할 수 있겠습니다.

결국 이렇게 진화하는 이유는 더 광범위해진 정보의 소스들로 인한 Comprehensive Flow Theory에 입각하고 있는데요. 즉, 오늘날의 (제조)기업을 둘러싼 이해 관계자들의 확장과 적극적인 개입, 그리고 그로 인해 마치 나비 효과처럼, 외부 환경의 작은 변화에도 기업의 수익이 영향을 받을 수 있다는 것을 체감하고 있기 때문입니다. 또한, 흡사하게 내부적으로는 말단 기계의 작은 변화가 제조 시스템의 생산량 및 성능, 제품의 품질에 미치는 영향을 더 이상 간과하지 않으려는 노력들입니다.

이런 이유로 시스템 내 외부의 상황을 보다 실제적으로 파악하기 위해 그 만큼 정보의 흐름 자체가 복잡해지고, 그 빈도 또한 많아지고 있기도 합니다. 일반적인 예로, 제조 공급 사슬 시스템 전반에 크게 제품의 물리적 흐름, 돈과 정보의 흐름 등이 있습니다. 이 세 가지 흐름은 서로의 진행을 제한하기도 하는데요. 예를 들면 실제 시스템에서 물건 배달이 완료되지 않으면 고객은 돈을 지불하지 않겠죠. 이 경우는 물리적 흐름이 돈의 흐름을 제한하고 있습니다. 또한 정보 전달이 제품과 돈의 흐름을 제한하기도 하는데요. 제품에 대한 배송 정보가 판매 부서에서 넘어오지 않으면, 물류 부서에서는 제품 출하를 할 수가 없게 되겠죠. 회계 부서를 통해 제품에 대한 청구서가 고객에게 발급되지 않으면, 고객은 돈을 지불하려고 해도 할 수가 없는 식으로 말입니다.

이렇듯, 이러한 모든 거래 정보의 흐름을 관장하는 ERP 가상 시스템은 앞서 고객의 주문부터 지불까지의 비즈니스 프로세스의 예와 같이 생산된 제품을 수익으로 전환하는 사이클을 보다 빠르고 원활하게 처리하여, 기업의 재정적인 성능을 높이는 데 가장 큰 목적이 있다고 할 수 있겠습니다.

그러기 위해서는, 당연히 ‘제어 가능 인자’부터 우선 잘 살펴봐야겠죠. 그 제어 가능 인자 중 하나는 결국 하위 레벨의 시스템에 제공되는 생산량이겠지요. 보다 투명하고 최신의 현장 정보를 바탕으로 업데이트된 정보를 다시 하위 레벨 시스템에 공급하는 것이 필수일 텐데요. 결국, 문제를 좁히면, MES와 ERP의 긴밀한 관계와 통합된 정보가 그 해결책일 것입니다. 그러나, 앞서도 확인했지만, 앞선 레벨 3의 시간 단위와 레벨 4의 스케일/관점이 크게 다르다는 것을 알 수 있습니다.

이는 둘 사이의 가시성을 저해하는 요소가 되어 왔습니다. 재고량의 예를 들자면, MES에서는 각각의 제품에 대한 부품들의 Sub-Lot에 대한 재고량과 재고의 현재 위치 (생산 재고(WIP) 인지 혹은 입고, 출고 재고 인지 등의 구별) 등이 실시간으로 업데이트되는데 반해, 정작 현재 생산 현장에서 쓰여지고 있는 할당된 주문과 스케줄은 이미 과거의 정보(ERP가 계획을 생성할 당시의 재고량, 주문량, 수요 예측량 등)가 되어버린 생산 계획을 바탕으로 한 것들입니다. 참으로 모순되는 사실이 아닐 수 없습니다.

그래서 결국 둘 사이의 통합된 정보가 무척 중요한 이슈로 떠오르고 있는데요. 그런 이유로 두 시스템을 하나로 통합하거나, 버퍼 데이터베이스를 두거나, 자동화된 데이터 입출력을 가능케하는 여러 인터페이스들을 개발하기 위한 노력이 많이 진행되고 있는 상황입니다. 또한 APS등의 도움을 받아 더 최신의 환경/고객/공급 및 현장의 정보(실시간으로 변화하는 공급 상황과 수요, 재고량, 자원의 가용 여부 등)를 바탕으로 아래 그림과 같이 더 세밀한 시간 단위의 Rolling Horizon 계획 등에 대한 연구도 진행되고 있습니다.

한편, 자동화된 데이터의 상호 작용을 위해서는 주요 MES, ERP 개발업체, 그리고 외부 솔루션 업체들이 각각 주축이 되어 개발을 주도하는 상황입니다. Memex Merlin ERP Connector, Rockwell ERP Integration Gateway, EOH SAP Service 등의 솔루션 등이 대표적인 예라 할 수 있습니다.

<더 세밀한 시간 단위를 이용한 Rolling Horizon 계획 수립(출처: ntl.bts.gov/)>

지금까지 자동화 운영 기술과 정보 시스템의 단계들 사이의 상호 작용을 위한 IT의 역할을 살펴보았습니다. 다음 시간에는 제조 산업의 과거, 현재를 통해 핵심 동향과 IT를 통한 우리나라 제조 산업의 미래를 고찰해 보는 시간을 갖도록 하겠습니다.

l 글 이승엽 연구원

챗봇과 대화를 할 수 있어요