산업 메타버스 연합 디지털트윈 운영 플랫폼 기술 요소 연구

2.1 산업 메타버스 디지털트윈 현황

한국의 제조업과 메타버스의 중요성을 설명하면 다음과 같다. 한국은 전체 GDP에서 제조업이 차지하는 비율이 27.5%로, 주요 국가들(일본 20.7%, 독일 19.1%, 미국 10.9%, 프랑스 9.8%, 영국 8.7%)에 비해 높은 수준이다[4]. 이러한 배경에서 메타버스와 같은 혁신적인 기술이 제조업 업무방식 및 비즈니스 모델을 어떻게 변화시킬 수 있을지, 그리고 급변하는 환경 속에서 제조기업들이 지속 가능한 경쟁력 확보에 어떻게 기여할 수 있을지 논의가 필요하다. 최근에는 관련 기술의 발전에 따라 메타버스의 정의가 가상세계 중심에서 범용/포괄적인 의미로 확대되고 있다. 이제는 메타버스를 단순히 유희나 게임의 영역으로 한정하지 않고, 현실 세계처럼 사회적, 경제적, 문화적 활동이 이루어지며 상호작용이 가능한 3차원 가상공간으로 보고 있다[5]-[8]. 따라서 산업 메타버스를 정의할 때, 제조기업들이 현실과 가상의 상호작용을 통해 제품개발, 생산, 물류, 마케팅, 영업 서비스 등을 실행할 수 있는 3차원 가상공간으로 개념화할 수 있다.

디지털트윈의 발전과 사례를 정리하면 다음과 같다. 디지털트윈 기술은 복잡한 시뮬레이션을 신속하고 정확하게 수행할 수 있는 ROM(Reduced Order modelling) 기술과 HPC(High Performance Computing)를 통해 성능 예측, 최적화, 고장 예지 진단을 실시간으로 수행할 수 있게 되면서 가속화되었다[9]. 이러한 장점 때문에 다양한 분야에서 디지털트윈을 도입하는 사례가 늘어나고 있습니다. 예를 들어, 현대자동차는 2022년에 현실의 ‘스마트 팩토리’를 메타버스로 옮긴 ‘메타팩토리’를 통해 공장 운영을 고도화하겠다는 계획을 발표했다[10]. 메타팩토리는 공장 운영 전에 최적화된 가동률을 고려한 운영 계획 수립을 가능하게 하며, 공장 내 발생하는 설비, 공정, 품질 문제를 신속하게 파악하고 원격으로 해결할 수 있게 한다. 또한, 지멘스의 스마트팩토리 EWA(Electronics Works Amberg)는 실시간 품질 정보를 분석하여 불량 재공품이 후속 공정에 투입되는 것을 사전에 방지한다[11].

현대중공업은 해상 선박 운항 환경을 디지털트윈으로 조성해, 실제 시 운전에서 구현하기 어려운 조건에서 시스템을 사전 테스트함으로써 시 운전 비용을 절감하고자 한다[12].

이러한 시도는 자동차, 항공, 전자제품 등 다양한 분야에서도 유사하게 이루어지고 있습니다. 또한, 디지털트윈에서 수집된 설비데이터를 기존 BOM(Bill of Material)에 반영하여 공정 BOM을 최적화하려는 사례도 보고되고 있다[13].

2.2 산업 메타버스 디지털트윈 문제점 분석

산업메타버스의 디지털 트윈의 문제점을 제시하기에 앞서 우선 스마트팩토리만 한정하더라도 산업 메타버스 디지털트윈을 구축의 다양한 어려움을 다음과 같이 요약할 수 있다.

첫째, 물리 환경을 모두 가상화하는 경우 현재는 개발사별 사용하는 솔루션 및 도구들을 사용하여 서비스간의 인터페이싱이 자유롭지 못하다. 즉, 표준화되지 못한 인터페이싱으로 서비스를 구성하고 있어 컨소시엄으로 참가하는 기업 간 표준화에 대한 별도의 협의가 필요하다.

둘째로 가상화하는데 데이터와 연계/연동하기보다는 비동기식의 데이터를 교류하거나 가상화 객체만을 생성하여 사실 데이터가 연계된 가상세계가 아닌 동영상 수준인 경우가 많다.

셋째로, 확장성에 있어 매우 제한적이다. 디지털트윈의 각 레이어와 객체로 만들어 자산화하는 것이 아니고 개별 단위의 패키지 형태의 디지털트윈을 만들어 적용하는 경우가 대부분이다. 이에 따라서, 디지털트윈을 확장 시 새로운 시나리오에 적용하려면 극히 제한적이다.

넷째, 서비스 간의 통합 및 배포에 있어 통합 서비스를 구현하기가 매우 어렵다.

좀 더 구체적으로 쉽게 설명하면 다음과 같다. 스마트팩토리와 스마트 시티 같은 산업에서 메타버스 디지털트윈 서비스를 제공하려면 실제 물리 환경의 모든 자원을 디지털화해야만 한다. 이에 따라 정확한 진단 및 예측이 가능해진다.

지금까지 국내에서는 분야별, 제조사별로 다른 기술과 솔루션을 사용해왔기 때문에 디지털 전환 시 표준화된 정보가 아닌 개별 정보관리 시스템으로 관리되고 운영되는 환경만 구축할 수 있었다.

그 결과로, 새로운 디지털트윈 시뮬레이션 서비스 개발과 메타버스 환경 조성에 매번 추가 개발 비용과 유지보수 비용이 들고 있다. 또한 자원의 비효율적 사용으로 인해 서비스 제공의 가용성이 떨어지고 성능도 지원되지 않아, 비싼 비용을 들여 구축한 시스템이 제대로 운영되지 않는 경우가 많다[14][15].

지능형 사물인터넷 시스템의 관점에서의 문제점은 다음과 같다. 스마트 시티, 스마트 제조, 스마트 홈 등 지능형 사물인터넷 시스템은 여러 종류의 자율 사물들로 구성되며, 이를 통해 사용자 맞춤형 서비스를 제공할 수 있다[16]. 특히, 스마트 제조시스템에서 대규모 개인화 서비스나 스마트 시티에서의 무인 교통관리와 같이 사용자마다 다른 요구사항을 충족시키기 위해 자율 사물들은 상황에 따라 동적으로 변화하며, 다수의 다양한 사물들이 협업하는 복합 체계를 구성한다[17][18].

복합 협업 체계의 신뢰성 보장에 대한 문제점은 다음과 같다. 주변 환경 정보, 시스템 상태, 서비스 요구사항 등 다양한 요소로 인해 복합 협업 체계는 여러 특징을 가지게 된다. 이러한 체계의 신뢰성을 보장하려면 서비스 제공 전에 반드시 운영에 대한 검증과 최적화가 이루어져야 한다[19]. 디지털트윈은 정교한 시뮬레이션과 인공지능 기술을 활용한 데이터 분석을 통해 복합 협업 체계를 검증하고 최적화하는 서비스를 제공할 수 있다[20]. 디지털트윈의 컴퓨팅 부하 문제에 대한 요약은 다음과 같다. 지능형 사물인터넷 시스템에는 여러 복합 협업 체계가 동시에 운영될 수 있으며, 이를 검증하고 최적화하기 위해 많은 디지털트윈이 동시에 실행되어야 한다. 하지만 각 디지털트윈은 정교한 서비스를 제공하기 위해 고해상도 시뮬레이션 모델이나 많은 은닉 계층을 포함하는 인공지능 모델을 사용하기 때문에, 많은 컴퓨팅 부하가 발생할 수 있다[21][22]. 이러한 부하는 각 디지털 트윈이 제시간에 실행되지 못하게 할 수 있으며, 검증과 최적화가 적절히 이루어지지 않은 협업 체계에서는 사용자의 요구를 충족시키지 못할 수 있다[23][24].

3.1 기술 요소 제시 근거

다양한 산업이 공정관리 시스템을 활용 중이나, 글로벌 산업경쟁 고도화 및 환경변화로 운영관리 공정의 혁신 필요성 증대됨에 따라 산업용 메타버스 활용을 통한 국내 주력산업 경쟁력 강화 하며 운영관리 공정의 자동화·자율화로 최적생산, 유연 생산, 예측, 대응이 가능한 메타버스 운영관리 플랫폼 개발 및 실증가능 한 운영 플랫폼이 필요하다.

그림 1에서 제시하는 산업메타버스 연합디지털트윈 운영 플랫폼 아키텍처는 이러한 복잡하고 다양한 산업환경을 수용할 수 있고 기존의 사일로화 된 산업의 구조를 통합할 수 있는 기술을 위하여 해결하기 위한 기술 요소로써 총 10가지 분야로 정리하였다. 또한 10가지 분야로 기술을 나눈 근거를 표 1에 제시하였다. 메타버스 전문가들에게 자문하여 AS_IS의 이슈와 문제점을 도출하여 TO_BE를 제시하고자 한다. 표 1에서 제시한 AS_IS와 TO_BE의 키워드를 중심으로 왜 그림 1과 같이 구성되어야 하는지 설명하고자 한다. 우선 첫 번째 기술은 단순히 데이터를 메타버스에 연결하는 것이 아니라 데이터 기반의 생태계가 운영될 수 있도록 플랫폼 형태로 제공하기 위한 것이다.

Fig. 1.

Industrial metaverse federation digital twin operations platform architecture

Table 1.

Expert consultation: federated digital twin needs

두 번째 기술은 현재 메타버스 구성 시 가상 객체를 자산화(Assets)하지 않고 필요할 때마다 매번 만들고, 한번 사용하면 끝나는 형태가 아니라 가상 객체를 자산화하고 라이브러리화한 형태로 제공하는 것이다. 이를 통해 다양한 가상 객체 자산을 가지고 확장할 수 있게 된다.

세 번째 기술은 현재는 로봇을 동작시키기 위한 PLC를 티칭하고 이를 메타버스 반영에 많은 시간이 소요 된다. 그러나 티칭하지 않아도, 즉 데이터를 수정하지 않아도 비전시스템과 알고리즘을 제공하여 자동으로 코드를 수정하여 반영하는 것을 의미한다.

기업별로 이러한 서비스를 제공받지 못하면 결국 몇 달이 걸리는 티칭을 진행해야 한다. 네 번째 기술은 현재는 배포하는 전략은 개발사가 맡고 있어 메타버스를 통합하여 서비스 제공 시 동기화에 많은 문제가 발생한다. 이에 대하여 배포 그룹을 플랫폼 내에 통합서비스로 운영하여 메타버스 간 동기화 할 수 있는 배포 서비스를 제공한다는 것이다.

다섯 번째 기술은 API 게이트웨이를 통하여 기존에 없었던 디지털트윈 간에 연결 객체를 제공하는 것이다. 여섯 번째는 다양한 컨소시엄들이 만든 메타버스를 연결하여 연합 디지털트윈으로 만들 수 있는 UI/UX를 제공하겠다는 것이다. 일곱 번째 기술은 현재 생산 운영 상태 데이터가 수집되지 않고 있으나, 향후 생산 운영 상태 데이터 수집하여 작업 효율성을 제공하겠다는 것이다.

여덟 번째는 언제든지 조절 변수를 변경하여 적용할 수 있는 서비스를 제공하겠다는 것이다. 아홉 번째는 단일 시나리오가 아닌 여러 시나리오를 한꺼번에 적용할 수 있는 기술을 말한다. 열 번째는 현재는 물리 제조시스템의 피드백은 있으나, 이를 저장하여 다시 물리 제조시스템에 적용하지는 않는다. 향후, 이를 가능하게 하는 기술을 말한다. 이를 종합하여 그림 1과 같이 최종 목표 아키텍처를 제시할 수 있게 되었다.

3.2 기술 목표 아키텍처 제시

이에 대한 구체적인 기술 아키텍처 구성과 기능을 설명하면 다음과 같이 제시할 수 있다.

첫 번째로 Data Driven Eco-System이다. Data Driven Eco-System이란 데이터소스 즉, 내부 및 외부 데이터의 수집/변환/적재함을 의미하며, 이때 데이터는 센서 및 IoT 장치를 통하여 수집하고, 이를 저장할 수 있는 데이터베이스 및 데이터 웨어하우스를 구축하는 것이다. 여기에는 API(응용 프로그래밍 인터페이스)를 하는 데이터 통합도 포함된다. 데이터 기반 생태계에서는 데이터 분석 도구 및 기계학습, 인공지능을 활용할 수 있는 환경을 제공하는 것이다. 또한, 데이터 공유/협업이 가능함을 의미한다. 최종적으로 사용자에게 데이터를 시각화하고 의사결정 지원시스템을 제공한다. 이렇게 구축한 데이터 중심 생태계는 데이터 기반의 인사이트를 제공하여 의사결정에 도움을 주며, 프로세스 자동화 및 최적화로 운영 효율성을 줄 수 있다. 사실, 데이터를 활용하여 새로운 기회, 트렌드 및 혁신을 식별함으로써 경쟁우위를 확보할 수 있게 된다.

두 번째로 Meta/Asset Management 그룹이다. 메타 관리에서는 메타 저장소(Repository) 역할로 데이터 자산을 쉽게 검색하고 활용할 수 있도록 데이터 사전 (Data catalog)와 데이터 계보(Data lineage) 정보를 제공할 수 있다. 결국 이러한 구성으로 데이터의 정확성, 완전성, 일관성을 보장할 수 있는 데이터 품질관리가 효율적으로 이루어질 수 있다. 또한, 보안/접근 정책 수립이 쉬워진다. 메타 자산(Assets)은 비즈니스 메타데이터, 기술, 운영, 프로세스, 보안, 품질 메타데이터를 자산으로 설정하여 서비스로 제공할 수 있다. 이는 메타버스의 확장성과 관련된 것으로 매우 중요한 요소이다.

세 번째로, 비즈니스 모델 조합이 있다. 이는 최소한의 기능을 제공하는 핵심 비즈니스(CB: Core Business)를 기반으로 여러 CB를 조합하여 하나의 작업을 완료하는 작업 비즈니스 (JB, Job Business)로 통합된 서비스를 제공하는 것을 말한다. 이렇게 구성된 JB는 서열 시스템 및 생산라인 구성에 따라 우선순위와 통합을 거쳐, 서비스 형태의 검증 가능한 이벤트 시나리오를 제공한다. 즉, 기존 산업 현장의 다양한 브랜드별 제조 공정에서 발생하는 데이터를 별도 수정 없이 PLC 어댑터에서 수집하고, 이를 제조 운영 플랫폼에서 사용할 수 있는 정보로 가공할 수 있다. 이를 실현하기 위해서는 메타데이터 표준(온톨로지)에 따라 분류(텍사노미) 개념으로 데이터를 관리할 수 있어야 한다. 물리 공간의 동일 가상공간은 디지털트윈 공정을 1:1로 구축하여 시뮬레이션할 수 있어야 하며, 가상공간의 자산 저장소(Asset repository)는 물리 공간에 적용되었거나 새롭게 적용할 수 있는 모든 자산을 추가할 수 있어야 한다.

이렇게 구축된 시뮬레이션 모델은 다른 디지털트윈 공정에서도 활용할 수 있는 가장 작은 단위의 모듈 또는 객체 형태로 관리되며, 이를 조합하여 새로운 공정을 시뮬레이션할 수 있다.

이러한 모듈은 모든 디지털트윈에서 공통으로 적용되어야 하는 공통 기능(CF, Common Function, 예: 로그 수집, 타이머, 엑추에이터 등)과 비즈니스의 최소 단위로 나눌 수 있는 핵심 객체(Core Object, CO), 그리고 이들을 조합하여 서비스 시나리오 형태로 제공할 수 있는 비즈니스 객체(BO, Business Object)로 구분할 수 있다. 즉, 하나의 비즈니스 객체(BO)는 여러 개의 핵심 객체(CO) 또는 다른 비즈니스 객체(BO)를 조합할 수 있다. 이는 복잡한 공정 시나리오를 이벤트 단위로 구분한 것이다. 이렇게 만들어진 이벤트 시나리오는 이벤트 정의서에 명시되어 문서 또는 온라인으로 관리된다.

네 번째로 배포(Release, CI/CD) 그룹이다. CI(Continuous Integration)는 지속적인 통합을 의미한다. 이는 버전관리시스템, 자동화된 빌드 및 테스트, 피드백 루프로 구성된다.

자동화된 빌드는 코드가 통합될 때마다 자동으로 빌드가 실행되고, 이는 코드가 제대로 컴파일되는지 확인한다. 또한 자동화된 테스트는 빌드 후 자동화된 테스트 스위트를 실행하여 코드 변경이 기존 기능을 손상하지 않는지 확인하는 것이다. 또한 피드백 루프는 빌드 테스트 결과, 즉시 개발자에게 피드백으로 제공되어, 문제를 신속하게 수정할 수 있도록 한다. CD(Continuous Deployment)는 지속적인 배포를 의미한다. 이는 배포 파이프라인, 환경관리, 자동화된 배포, 모니터링 및 롤백으로 구성되어 있다. 여기서 배포 파이프라인은 자동화된 배포 파이프라인을 통해 코드가 테스트 환경을 거쳐 프로덕션 환경에 배포됨을 의미한다. 환경관리는 배포 프로세스 중 여러 환경 즉, 개발, 테스트, 스테이지, 프로덕션을 사용하여 단계별로 검증하는 것이다. 자동화된 배포는 승인된 코드 변경 사항은 자동으로 프로덕션 환경에 배포되며 배포 주기를 단축하고 인적오류를 최소화하게 된다. 모니터링 및 롤백은 배포 후 시스템을 모니터링 후 문제가 발생하면 자동으로 롤백할 수 있는 기능을 말한다. 이를 적용할 때는 모델 업데이트, 애플리케이션 코드, 시뮬레이션 및 테스트, 실시간 데이터 통합에 요소를 고려해야 한다. 우선 모델 업데이트는 디지털트윈 모델의 업데이트가 필요할 때마다 CI/CD 파이프라인을 통해 새로운 모델 버전을 통합하고 테스트하여 신뢰성을 확보하는 것이다. 애플리케이션 코드는 디지털트윈과 상호작용하는 애플리케이션 코드 역시 CI/CD를 통해 자주 통합되고 배포됨을 의미한다. 시뮬레이션 및 테스트는 디지털 트윈의 정확성을 보장하기 위해 시뮬레이션과 테스트가 자동화된 모델이 실제 환경과 잘 일치하는지 확인하는 것이다. 디지털트윈의 실시간 데이터 통합시 실시간 데이터수집/ 분석하는 경우, 이러한 데이터 스트림의 통합 및 처리 로직도 CI/CD 파이프라인을 통해 관리된다.

다섯 번쨰, 연합 디지털트윈의 API 게이트웨이는 여러 디지털트윈 시스템과의 통신을 관리하고 보안을 강화하며, 성능을 최적화하는 핵심 역할을 하게 된다. 주요 역할은 중앙집중식 관리로 서비스별로 마이크로 서비스아키텍처로 구성된 JB 인스턴트들을 분산처리 할 수 있도록 인프라스트럭처를 구축하고 모든 API 요청을 중앙에서 일관된 접근과 보안을 제공한다. 라우팅은 클라이언트 요청을 적절한 서비스나 디지털트윈 모델로 라우팅하며, 여러 서비스와의 통신을 효율적으로 관리하는 역할을 한다. 또한 보안을 강화할 수 있는데, 인증 및 인가, 데이터 암호화, SSL 종료 등을 통해 연합 디지털트윈의 보안을 강화할 수 있다. 또한 트래픽 제한, 부하분산, 캐싱을 통해 시스템의 성능을 최적화하고 안전성을 유지한다. 또한, API요청과 응답을 모니터링하고 로깅하여 성능분석 및 문제해결을 쉽게 한다. FDT(연합디지털트윈)의 API 게이트웨이의 주요 기능은 인증 및 인가, 요청 및 응답 변환, 속도제한, 부하분산, 캐싱, 모니터링 및 분석의 기능을 제공한다. 인증 및 인가에서는 API 요청에 대한 사용자 인증 및 권한 부여를 처리한다. OAuth, JWT(Json Web Token) 토큰 등을 사용하여 안전한 접근을 보장하는 기능이며, 요청과 응답 변환은 API 요청과 응답을 필요에 따라 변환하여 서로 다른 포맷의 데이터를 통신할 수 있게 한다. 예를 들어서 XML,과 JSON으로 변환하는 기능을 제공한다. 속도제한(Rate Limiting)은 특정시간 내에 API호출 수를 제한하며, 과도한 요청으로 인한 시스템 과부하를 방지한다. 또한, 부하분산은 들어오는 트래픽을 여러 서비스 인스턴스에 분산하여 시스템 성능과 가용성을 높인다. 캐싱은 자주 요청되는 데이터를 캐시하여 API 응답 시간을 단축하고 서버 부하를 줄인다. 마지막으로 모니터링 및 분석은 API 사용량, 성능, 오류 등을 실시간으로 모니터링하고 분석하여 운영 상태를 파악하고 개선점을 찾는 기능을 수행한다.

여섯 번째로 3D UI/UX 시각화(Visualization)의 영역은 연합 디지털트윈을 통하여 다양한 산업 분야에서 복잡한 시스템과 프로세스를 시각화하고 상호작용할 수 있게 한다. 구체적으로 실시간 데이터 시각화를 통하여 기계와 시스템의 현재 상태를 실시간으로 표시한다. 그리고 정밀한 3D모델과 동작, 작업흐름, 프로세스 등을 동적으로 표현할 수 있어 직관적 이해 정보를 전달한다. 또한, 사용자가 3D환경에서 자유롭게 탐색하고 확대, 축소할 수 있는 기능을 제공하며, 클릭, 터치, 드래그 등을 직관적인 제스처를 통해 3D 객체와 상호작용할 수 있게 한다. 시뮬레이션 및 예측, 협업 기능제공, 데이터 통합 및 관리의 용이성, 직관성, 일관성을 제공한다. 보안 및 접근제어, 가상 및 증강현실을 지원하여 직관적인 의사결정 통로를 제공한다.

일곱 번째, 현재 운영 중인 Physical Factory Status를 파악하게 한다. 이는 제조 장비의 객체(Physical object)와 물리적 제조 현장의 데이터(Physical data), 과업관리(Task management)로 구성되어 있다. 이렇게 운영되고 있는 실시간 물리 객체 상태 데이터수집 기능을 한다. 여덟 번째는 물리적 시나리오에 대한 조절 변수를 설명하는 것이다. 즉, 공정 단계, 크기, 범위, 시간, 온도, 투입인력 등에 대한 관리와 설정을 의미한다. 다양한 물리적 제조 시나리오를 아무리 설정하였다 하더라도 위에서 언급한 조절 변수에 따라 매우 다른 결과가 도출되며 이러한 결과 값에 대한 오차 범위를 다시 정의한다. 아홉 번째로 검증시나리오 실행이다. 검증시나리오는 다양한 시나리오와 조절 변수로 구성되어 있고 이를 편집, 실행하여 관리할 수 있는 기능을 제공한다. 열 번째로 테스트 시나리오를 적용한 결과에 대하여 오차 값 수정 및 시나리오 변경을 적용한 후 물리적 공정에 다시 반영하는 것을 말한다. 앞서 말한 CI/CD의 역할을 통하여 물리적 공간에서 확인된 결과를 디지털트윈 시나리오에 다시 대입이 쉬워진다.

그림 2는 물리적 공장에서 메타 PLC의 어댑터 서비스를 어떻게 구성할 것인지를 보여준다. 우선 Meta PLC 어댑터는 물리적 시스템과 PLC Library를 연결한 구조이다. 여기서 PLC Library는 Field-bus, File Server, Ladder, View, History로 구성한다. Field-bus는 파일시스템을 통해 데이터를 통신하는 간단하고 유연한 방법을 제공한다. 이는 임베디드시스템, 데이터로깅, 백업 및 복원, 애플리케이션 간 통신 등 다양한 분야에서 활용될 수 있다. 성능과 확장성 면에서 제한이 있을 수 있지만, 간편성과 호환성 측면에서 많은 장점이 있다. Ladder는 산업 자동화 및 제어 시스템에서 널리 사용되는 그래픽 기반 프로그래밍 언어로, 전기회로와 유사한 형식으로 설계되어 직관적이고 이해가 쉽다. 즉, 직관적 프로그래밍 방식, 신뢰성, 디버깅의 용이성 등 여러 장점이 있지만, 복잡한 논리를 구현하는데 한계가 있을 수 있다.

Fig. 2.

MetaPLC manufacturing operations platform common PLC adaptor design

그러나 전기 및 자동화 분야에서 전통적으로 사용되는 표준 프로그래밍 언어이다. Meta PLCs 어댑터 서비스는 메타, 비즈니스, CI/CD, Logger로 구성되어 있어 서비스를 통합하는데 필요한 프론트엔드의 어댑터 서비스이다.

일반적으로 Meta PLC(Programmable Logic Controller) 어댑터는 다양한 제조 및 산업 자동화 시스템에서 사용되는 PLC장치와 상호작용하고, 데이터를 통합 및 관리하기 위한 인터페이스 역할을 한다. 주요 역할은 PLC 장치로부터 실시간 데이터수집 후 이를 중앙시스템으로 전송하며, 여러 PLC 장치의 데이터를 통합하여 일관된 데이터 흐름을 제공한다. 또한, 프로토콜 변환 역할을 하는데 다양한 제조장치와 시스템이 사용하는 여러 통신프로토콜을 변환하여 상호호환성을 보장한다. 예를 들어 Modbus, Ethernet/IP, OPC, UA 등의 프로토콜을 지원한다. 실시간으로 PLC 장치의 상태를 모니터링하고, 필요한 경우 중앙시스템에서 제어 명령을 전송할 수 있다. 긴급상황에서 빠른 대응이 가능하게 된다.

그림 2에서 공통 PLC 어댑터를 구축해야 하는 이유는 다음과 같다. 본 연구에서 앞서 언급한 바와 같이 단일한 디지털트윈의 구성이 아니기 때문이다. 기존의 디지털트윈의 자산과 신규로 생성한 디지털 트윈을 연합하기 위함이다. 이러한 브랜드별, 기업별 PLC 제어 스트립트를 통합적으로 처리해 줄 기술적 요소를 구축하지 않으면 매번 추가인 비용이 소요되게 된다.

그림 3에서는 개발자 환경을 제공하는 포털의 구성이다. 개발자 포털에서는 통합(Integration), 인도(Delivery), 배포(Deployment), 버전관리(Version management), 클라우드 감시 로그(Cloud watch logs), 람다(Lambda), 자원관리(Resource management)의 기능을 제공할 것이다.

Fig. 3.

MetaPLC manufacturing operations platform developer portal services and features

통합(Integration)은 서로 다른 시스템, 애플리케이션, 데이터소스를 연결하여 일관된 작업을 수행하게 한다. 개발자 포털에서는 다양한 API, 데이터베이스, 서드파티 서비스 등을 통합하여 개발자가 쉽게 접근하고 사용할 수 있도록 지원한다. 인도(Delivery)는 소프트웨어 개발의 마지막 단계로 완성된 애플리케이션이나 업데이트를 최종 사용자에게 제공하는 과정이다. 앞서 언급한 바와 같이 개발자 포털에서는 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인을 설정하여 코드 변경이 자동으로 테스트, 빌드, 배포되는 과정을 지원한다.

이를 통해 신속하고 안전하게 새로운 기능을 사용자에게 제공할 수 있게 된다. 버전관리(Version management)는 개발자 포털에서는 버전 관리시스템(예: Git)을 사용하여 코드의 변경 사항을 추적하고 협업을 쉽게 만든다. 버전관리를 통해 다양한 버전의 소스를 안전하게 관리하고, 이전 버전으로의 롤백, 분기(branch), 병합(Merge) 등을 쉽게 할 수 있다.

클라우드 감시 로그(Cloud watch logs)는 클라우드 인프라와 애플리케이션의 상태와 성능을 모니터링하기 위해 생성되는 로그 데이터이다. 개발자 포털에서는 이러한 로그를 수집, 분석, 시각화하여 시스템의 운영 상태를 실시간으로 파악할 수 있게 한다. 이는 문제를 신속히 감지하고 해결하며, 성능 최적화를 도와준다. 람다(Lambda)는 AWS Lambda를 포함하여 서버 리스(Server-less) 컴퓨팅 서비스를 의미한다. 개발자 포털에서는 람다 함수를 설정하고 관리하여 이벤트 기반으로 코드를 실행할 수 있다. 람다는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있게 한다. 이는 확장성과 비용효율성을 제공한다. 이벤트에 따라 자동으로 실행된다. 자원관리(Resource management)는 클라우드 환경에서 컴퓨팅, 스토리지, 네트워크 등 다양한 IT 자원을 효율적으로 할당, 모니터링, 관리하는 것을 의미한다. 개발자 포털에서는 자원관리 도구를 통해 자원의 사용현황을 파악하고, 필요에 따라 자원을 추가하거나 제거하여 최적의 비용을 투입할 수 있게 한다. 자원태크, 권한 설정, 모니터링 등을 통해 체계적으로 자원을 관리한다.

종합적으로 개발자 포털은 소프트웨어 개발의 안전성, 확장성을 확보하게 한다.

그림 4는 클라우드 가상머신의 구조와 컨테이너의 구조를 설명한 것이다. 우선 WAS(Web Application Server)는 애플리케이션 실행 환경, 비즈니스 로직 처리, 세션 관리, 데이터베이스 연결, 보안관리, 트랜잭션 관리 기능을 제공한다. 예를 들어 Apache Tomcat, IBM WebSphere, Oracle WebLogic, JBoss(WildFly) 등이 있다. WEB (Web service)는 네트워크를 통해 애플리케이션 간에 데이터를 교화하는 기능을 호출하는 표준화된 방법이다. 주요 특징은 표준화된 프로토콜 (HTTP, HTTPS, SMTP) 등 네트워크 프로토콜을 사용하여 통신하고, 주로 XML, JSON 형식으로 데이터를 교환한다.

Fig. 4.

Microservice infra architecture

XM은 주로 SOAP(Simple Object Access Protocol) 웹 서비스에서 JSON은 RESTful 웹 서비스에서 주로 사용된다. 여기서 REST(Representational State Transfer)라는 것은 웹의 기존 HTT 프로토콜을 기반으로 한 아키텍처 스타일을 말한다. 자원을 식별하고 HTTP 메소드인 GET, POST, PUT, DELETE 등을 통해 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행한다.

Monolithic 구조란 소프트웨어 아키텍처의 한 형태로, 모든 기능이 하나의 코드 베이스와 실행파일에 통합된 단일 애플리케이션을 말한다. 애플리케이션의 모든 구성요소는 하나의 단일 단위로 결합 되어 배포된다. 여기서 구성요소는 UI, 비즈니스 로직, 데이터 접근계층 등을 말한다. 또한, Cloud VM의 일반적 구조는 하이퍼바이저, 가상 머신이미지, 스토리지, 네트워킹으로 구성되어 있다. 하이퍼바이저는 물리적 서버 위에서 가상머신을 실행하는 소프트웨어이며, 물리적 하드웨어의 자원을 가상머신 간에 분할 하여 제공한다. 예를 들어 VMware ESXi, Microsoft Hyper-V, KVM 등이다.

또한 가상머신 이미지는 운영체제와 기본 소프트웨어가 설치된 템플릿이다. 이를 기반으로 새로운 가상머신을 신속하게 생성할 수 있다. 스토리지는 가상머신의 데이터를 저장하는 가상디스크를 포함한다. 클라우드 스토리지 서비스와 연동되어 데이터 저장 및 백업을 제공한다. 네트워킹은 가상 네트워크 인터페이스를 통해 다른 가상머신이나 외부 네트워크와 통신할 수 있다. 클라우드 네트워크 서비스를 통해 가상네트워크를 설정하고 관리한다. 컨테이너/MSA 구조는 다음과 같다. 우선 컨테이너는 애플리케이션을 실행하는데 필요한 모든 구성요소를 포함하는 독립된 실행 환경이다. 여기서 모든 구성요소란 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정을 말한다. 또한 컨테이너는 일관된 환경에서 에플리케이션을 실행할 수 있게 하여, 개발부터 배포까지의 프로세스를 단순화하고 효율적으로 만든다.

마이크로서비스아키텍처(MSA, Micro-Services Architecture)은 애플리케이션을 독립적으로 배포할 수 있는 작은 단위의 서비스들로 구성하는 아키텍처 스타일을 말한다. 각 서비스는 특정 서비스 기능을 수행하며, 다른 서비스와 느슨하게 결합 되어 있다. 주요 특징은 독립적 배포와 개별 개발, 모듈화, 분산 시스템이다. 우선 독립적 배포란 하나의 서비스에 변경이 있어도 전체 시스템을 다시 배포할 필요가 없다.

개별 개발은 각 마이크로서비스는 독립적으로 개발할 수 있으며, 서로 다른 팀이 다른 기술 스택을 사용할 수 있는 것을 말한다. 모듈화는 서비스를 독립적 모듈로, 특정 비즈니스 기능에 초점을 맞춘 것이다. 이는 유지보수를 쉽게 하는 것이다. 분산 시스템은 각 서비스는 분산된 환경에서 실행할 수 있으며, 네트워크 통신을 통해 상호작용하는 것이다.

주요 구성은 서비스, API 게이트웨이, 데이터베이스, 서비스 디스커버리, 컨테이너와 오케스트레이션으로 구성되어 있다. 여기서 컨테이너와 마이크로서비스아키텍처와의 관계를 설명하면 다음과 같다. 컨테이너는 마이크로서비스아키텍처의 각 마이크로서비스는 컨테이너화 되어 배포된다. 이는 서비스 간 격리성을 높이고, 독립적인 배포와 확장을 쉽게 만든다.

오케스트레이션은 컨테이너와 오케스트레이션 도구를 사용하여, 마이크로서비스의 배포, 확장, 복구를 자동화할 수 있다. Kubernetes는 이러한 오케스트레이션에 널리 사용되는 도구이다. 즉, 컨테이너와 마이크로서비스아키텍처는 현대 애플리케이션 개발과 배포의 핵심기술이다. 컨테이너는 애플리케이션을 경량화하고, 이식성을 높이며, 격리된 환경을 제공한다. 마이크로서비스아키텍처는 애플리케이션을 독립적으로 배포할 수 있는 작은 서비스들로 구성하여, 확장성과 유지보수성을 향상할 수 있게 된다. 이 두 기술을 결합하면, 복잡한 애플리케이션(Application)을 보다 유연하게 효율적으로 관리할 수 있게 된다.