[첨단 헬로티]

최근 IoT(Internet of Things)나 Industrie 4.0 등의 키워드 하에 생산 정보를 고도 활용함으로써 생산 공정의 플렉시빌리티나 생산성을 향상시키는 대응이 활발하게 이루어지고 있다. 이것을 실현하는 수단으로서 PC(Personal Computer) 중심의 생산 시스템인 PAC(PC-based Automation Controller)이 산업기기 제어 분야에서도 점차 보급되고 있다. PAC 도입이 추진되고 있는 배경으로서 이하를 들 수 있다.

 (1) 생산 시스템 소프트웨어 개발 코스트 증가

     →IT 툴 도입에 의한 개발 효율 향상

 (2) 생산 시스템 소프트웨어 개발자 부족

     →비제조 분야 IT 기술자의 활용

 (3) 생산 시스템의 복잡화

     →오픈된 표준 IT 기술의 활용

더구나 오픈된 산업기기용 필드 네트워크인 EtherCAT, POWERLINK, PROFINET 등에 의해 PC에서 생산 설비의 각 기기를 직접 제어하는 것이 가능해진 것도 PAC 보급의 요인이다.

한편, 소프트웨어 면에서도 PAC가 매우 범용적인 기술이고, 실장의 자유도가 높기 때문에 기능 설계를 필요로 하는 부분이 많아 도입이 반드시 쉽지는 않다. 이것에 대응하기 위해 PAC에 알맞은 프레임워크가 요망되고 있다.

이 글에서는 PAC의 프레임워크에 오토메이션용 오픈 표준 미들웨어 규격인 ORiN(Open Resource for the Network)를 활용한 사례에 대해서 소개한다.

그림 1. 생산 시스템의 규모와 제작 수·다양성

또한, 이 글은 생산 설비 중에서 그림 1에 나타낸 ‘소량(1～약 1000 이하)’ 그리고 ‘다종’ 제작되는 것을 대상으로 한다. 각종 디바이스를 조합해 유닛이 구성되고, 또한 그 조합으로  셀, 라인이 구성된다. 디바이스→유닛→셀→라인으로 규모가 커짐에 따라 제작 수는 감소하는데, 반대로 조합에 의한 다양성은 증대한다.

기본적으로 이 ‘소량 다종’ 영역 설비의 설계·설정은 효율이 낮고, 설비 코스트 절감을 위해서는 그 향상이 필요하다. PAC 도입에 의한 개발 효율 향상은 이 과제에 대한 효과적인 해결책이 될 수 있다.

자동화 시스템 아키텍처

Industrie 4.0의 주안은 플렉시빌리티(재이용성․호환성)이다. 생산 설비는 설비 내 전기 신호를 제어하는 PLC(Programmable Logic Controller), 제품·부품의 반송, 조립을 하는 로봇, 금속 부품가공을 하는 CNC(Computerized Numerical Control) 등의 각종 기기로 구성되어 있으며, 이들을 통합한 시스템의 플렉시빌리티 향상이 많이 시도되어 왔다.

그림 2. 현재 생산 시스템의 전형적인 아키텍처

그러나 생산 시스템은 복잡하고 다기능이기 때문에 이들 기기의 단순한 조합으로 필요한 플렉시빌리티를 실현하는 것은 어려웠다. 그림 2에 나타냈듯이 생산 시스템을 구성하는 기기는 각각 독자의 처리 방책(Strategy)·관리 기능(Management)·제어 기능(Control)을 유지하고 있다. 그렇기 때문에 시스템 전체를 최적·플렉시블하게 하는 것은 어렵다.

그림 3. 제안하는 생산 시스템 아키텍처

시스템의 플렉시빌리티를 실현하기 위해서는 우선 처리 방책·관리 기능·제어 기능 3요소의 분리가 필요하다. 그러기 위해서는 그림 3과 같은 간단화, 오브젝트 지향 방법의 캡슐화가 효과적이다. 즉, 각 기기가 갖는 제어 방책·관리 기능에 대해서는 그 공통항을 시스템 전체에서 정리해 통일적으로 관리하는 한편, 제어 기능에 대해서는 기기 고유 부분으로서 개별적으로 관리함으로써 보다 간단화된 시스템 구성이 가능하다.

이와 같은 간단화·캡슐화는 IT 업계에서는 일반적인 방법이다. 그렇기 때문에 PAC 사업을 이미 시작하고 있는 메이커(예 : Beckhoff Automation, B&R, Phoenix Contact 등)도 있다. 그러나 현실적으로는 생산 시스템 제어기술자는 PAC에 대응한 기술을 제공하는 특정 메이커의 최신 기기뿐만 아니라, 오래된 각사 기기나 다른 플랫폼 기술을 포함하는 시스템을 제어할 필요가 있기 때문에 이들 전체를 그림 3과 같이 간단화해 제어하는 것은 힘들었다.

ORiN

PAC를 간단화하기 위해서는 PAC에 적합한 프레임워크가 필요하다. 이에 독일 Fraunhofer IESE는 미들웨어 프로젝트(BaSys 4.0)를 2016년에 개시했다. 

일본에서도 동일한 목적으로 ‘오토메이션용 오픈 표준 미들웨어’ 프로젝트 ORiN을 1999년에 개시했으며, ORiN협의회 멤버가 계속적으로 그 유지·개량을 추진하고 있다. ORiN의 특징은 이하와 같다.

· ORiN은 3가지 표준을 정의하고 있다. 즉, CAO(Controller Access Object), CRD(Controller Resource Definition), CAP(Controller Access Protocol)이다.

· CAO는 디바이스․애플리케이션 쌍방에 대한 표준 프로그램 인터페이스를 제공한다.

· CRD는 디바이스 프로파일과 같은 정적 정보를 표기하는 표준 데이터 스키마를 제공한다.

· CAP는 리모트에 설치된 CAO 시스템에 대한 표준 통신 프로토콜을 제공한다.

· 이들 표준은 통일된 콘셉트에 기초하고 있는데, 단독 사용도 가능하다.

이 중에서 PAC를 구성하는 데 있어 중요한 기술은 CAO이다. 그 개요에 대해 이하에 설명한다.

1. CAO의 개요

CAO는 표준 프로그램 인터페이스를 제공하는 ORiN의 핵이 되는 사양으로, 엔진부와 프로바이더부의 2가지 하드웨어로 구성된다. 엔진부는 애플리케이션 프로그램에 대해 유일한 인터페이스를 제공, ‘애플리케이션용 인터페이스’라고 부른다. 또한, 엔진부는 각 FA 디바이스에 의존하지 않는 범용적인 기능을 제공한다.

그림 4. CAO의 개요

한편, 프로바이더부는 FA 디바이스와 CAO의 추상 디바이스의 차이를 흡수하는 모듈이다. 프로바이더부는 엔진부에 대해 유일한 인터페이스를 제공, 이것을 ‘디바이스용 인터페이스’라고 부른다(그림 4).

CAO에 의해 애플리케이션 개발자는 디바이스에 크게 의존하지 않고 애플리케이션을 개발할 수 있으며, 반대로 디바이스 메이커는 애플리케이션에 의존하지 않고 기능 공개가 가능하다. 또한, 엔진부와 프로바이더의 2가지 하드웨어로 분리함으로써 디바이스에 의존하는 부분을 흡수한다는 본질적으로 필요한 부분의 개발을 쉽게 한다.

CAO 애플리케이션의 프레임워크는 이하와 같다.

① CAO 애플리케이션은 CAO 엔진으로 추상화된 디바이스 오브젝트를 조작한다.

② CAO 엔진은 그 조작 요구에 기초해 실제 디바이스에 의존하지 않는 범위의 처리를 실시한다.

③ CAO 프로바이더는 CAO 엔진으로는 처리할 수 없는 실제 디바이스에 의존하는 처리를 실시한다.

이 프레임 워크에 의해 그림 3에 나타낸 생산 시스템 아키텍처는 이하와 같이 실현 가능하다.

· 제어 방책 : 제어 애플리케이션 개발자는 ORiN이 제공하는 ‘애플리케이션용 인터페이스’를 이용함으로써 기기에 의존하지 않고 시스템 전체에서 통일된 제어 방책에 기초한 애플리케이션을 개발할 수 있게 된다. (앞에서 말한 ①에 대응)

· 관리 기능 : 기종에 의존하지 않는 시스템 공통의 관리 기능은 CAO 엔진이 제공하는 기능에 의해 대응할 수 있게 된다. (앞에서 말한 ②에 대응)

· 제어 기능 : 각 기기 고유의 제어 기능은 프로바이더에 의해 각 기기에 대응한 처리로 변환되어 실행할 수 있게 된다. (앞에서 말한 ③에 대응)

그림 5. CAO의 오브젝트 모델

2. CAO의 오브젝트 모델

CAO의 오브젝트 트리를 그림 5에 나타냈다. ORiN에서는 기기가 갖는 기능을 Variable(변수), File(파일), Task(내장 프로그램), Robot(동작), Extension(확장 기능), Command(커맨드 기능) 등의 카테고리로 나누어 클래스 정의하고 있다. 또한, CAO의 아키텍처는 엔진부와 프로바이더부의 2층으로 분리되어 있으며, 오브젝트 모델도 2가지로 나누어져 있다. 프로바이더부의 모델은 컨트롤러 내의 대상 리소스와 거의 일대일로 대응하는 선언적인 심플한 모델로 되어 있다.

ORiN PAC과 그 메리트

ORiN PAC이란 ‘PC-based Automation Controller utilizing ORiN as middleware’를 의미, ORiN을 PAC 개발의 프레임워크해 이용하고 있다. 그 메리트는 이하와 같다.

1. 기기 통신 접속 기능의 제공

PAC를 실현하기 위해서는 PC와 주변기기 간에 통신 접속하는 것이 필수이다. 그러나 공업용 기기의 통신 규격은 일반적으로 표준화되어 있지 않고, 메이커 간은 물론이고 동일한 메이커라도 제품의 세대에 따라 통신 규격이 다른 것이 일반적이다. 그렇기 때문에 PAC 개발에서는 각 기기와의 통신 처리 개발이 큰 부담이 된다.

이 문제를 ORiN은 풍부한 프로바이더로 해결한다. ORiN은 1999년의 개발 시작 이래, 공장 내에서 사용되는 기기를 중심으로 이미 많은 접속 실적이 있고 그들의 기기용 프로바이더를 제공하고 있다. 그렇기 때문에 통신 접속 기능을 개발하지 않고 PAC를 개발하는 것이 가능하다.

또한, ORiN은 프로바이더를 효율적으로 개발하기 위한 SDK(Software Development Kit)를 제공하고 있다. ORiN은 ‘온건한 표준화’의 방침 하에 기기와의 통신에 대해서는 기기 고유의 통신 기능을 그대로 사용, 프로바이더 내에서 그들의 기능을 ORiN이 갖는 프로바이더부 오브젝트 모델에 매핑함으로써 접속 가능하게 하고 있기 때문에 기존의 통신 기능을 변경하지 않고 ORiN에 접속할 수 있다.

2. 기기 고유 처리의 은폐

공업용 기기는 통신 규격뿐만 아니라 기기의 조작이나 상태에 관한 개념(내부 정보 참조․변경 방법, 내부 상태 모드 등)도 다양하므로, PAC 개발에 있어서는 기기마다 사양서를 잘 읽어 기기 고유의 개념·커맨드 체계 등을 이해할 필요가 있었다.

이 문제에 대해 ORiN은 전문가에 의한 거듭된 의논 및 풍부한 실제 공정 적용 사례의 지식에 기초한, 범용적이고 실용성 높은 오브젝트 모델을 제공함으로써 대응하고 있다. 즉, ORiN에서는 로봇, PLC, CNC 등 여러 가지 기종이 갖는 기능을 메이커·기종 등에 의존하지 않고 CAO 모델로서 매핑하고 이것을 소프트웨어 기술자에게 제공하고 있다. ORiN으로 제공되는 오브젝트 모델은 많은 애플리케이션 개발에 의해 충분한 기능을 가지고 있는 것이 실증되어 있으며, PAC 개발에 있어서는 한번 ORiN의 오브젝트 모델을 이해하면 이후에는 기종이나 메이커의 차이를 의식하지 않고 소프트웨어를 개발할 수 있다. 통신 프로토콜 등의 기종 고유 처리는 ORiN를 사용함으로써 은폐되기 때문에 소프트웨어 기술자는 즉시 PAC 개발의 본질인 알고리즘 개발을 할 수 있고, 공수의 대폭적인 절감이 가능해진다.

IT 세계에서는, 예를 들면 데이터베이스 접속에서 ODBC(Open Database Connectivity)가 널리 보급되어 있으며, 이것에 의해 각사마다의 기능 차이가 은폐되어 통일된 방법으로 각사 데이터베이스에 액세스할 수 있다. ORiN은 동일한 기능을 각종 기기에 대한 액세스에서 실현하는 것이다.

그림 6. 독일 Automatica 전시회 ORiN협의회 부스

3. 높은 신뢰성 확보

ORiN는 ORiN협의회에 의해 보급 촉진 활동이 추진되고 있으며, PR 활동으로서 일본 국내 전시회뿐만 아니라 독일 Automatica 전시회에서 초청을 받아 전시하는 등 해외에서도 보급 활동을 활발하게 하고 있다(그림 6).

그 결과, ORiN는 설비․제품에 유상 라이선스 적용 수가 약 30,000라이선스에 달하는 등 폭넓은 활용이 추진되고 있으며, 또한 다양한 용도에 적용 실적이 있다. 이들의 적용을 통해 ORiN의 높은 신뢰성을 실적으로서 확인받고 있기 때문에 ORiN을 중핵으로 프로바이더를 활용해 PAC를 구성하는 것이 PAC 전체의 신뢰성 향상에도 크게 공헌하는 것이라고 생각한다.

ORiN PAC 애플리케이션 사례

ORiN PAC 도입에 의해 여러 메이커의 기기로 구성된 시스템의 통일적인 제어가 가능해진다. 이하에 그 사례를 2가지 들었다.

그림 7. 생산 셀 통합 컨트롤러 시스템

그림 7에 나타낸 사례에서는 설비를 구성하는 전체 기기가 프로바이더를 통해 ORiN PAC에 접속되고, 1개의 Visual Basic 프로그램이 전체 시스템을 제어하고 있다. 기존에는 설비를 구성하는 기기에 대해, 그 통신 방법이나 기기 고유의 동작 프로그램 작성 방법을 소프트웨어 기술자가 이해할 필요가 있었다. 그러나 ORiN PAC의 도입에 의해 소프트웨어 기술자는 FA 기기와의 통신 처리에 관한 상세한 지식이 필요 없고, 일반적인 PC 디바이스(주변기기)와 동일하게 설비 제어 프로그램을 개발하는 것이 가능해졌다.

그림 8. 여러 메이커의 로봇 제어 시스템

그림 8은 기존에 개발이 어려웠던 여러 메이커의 로봇 통합 제어 시스템 사례이다. 다른 4사(덴소웨이브, 가와사키중공업, 야마하발동기, 야스카와전기)의 로봇이 1대의 ORiN PAC에 접속되어, 그 지시 하에 연계 작업을 실현하고 있다.

로봇 메이커는 각사 독자의 통신·명령체계를 가지고 있으며, 이들을 일괄해서 제어하기 위해서는 대상 로봇 전체에 대해 통신 방법이나 동작 사령 방법을 파악할 필요가 있었다. 그러나 ORiN PAC의 도입에 의해 통신 처리 프로그램 등을 메이커 차이에 관계없이 공통화할 수 있고, 모든 메이커의 로봇을 통일된 사고, 프로그램으로 제어하는 것이 가능해졌다.

ORiN PAC 리얼타임 확장

ORiN PAC은 시스템 전체를 PAC에 의해 제어하는 것인데, 기존 전용 컨트롤러 등으로 실시하고 있던 리얼타임 처리의 취급이 문제가 될 가능성이 있다. 예를 들면 기존 PLC를 사용해 설비 제어하고 있던 것을 ORiN PAC으로 변경하는 경우, PLC와 동등한 고속의 응답 속도가 요구될 가능성이 있다. 그러나 ORiN는 리얼타임 시스템을 대상으로 한 표준 규격이 아니기 때문에 ORiN PAC만으로는 응답 속도는 보증할 수 없어 제약 요인이 된다.

이에 ORiN PAC에서는 리얼타임 제어가 필요한 경우에 ‘리얼타임 확장’이라고 불리는 확장 기능 소프트웨어와 연계하는 기능을 준비하고 있다. 이것에 의해 고속 응답이 필요한 처리에 대해서도 ORiN PAC으로 대응할 수 있게 하고 있다.

그림 9. ORiN PAC 리얼타임 확장 사례

그림 9는 자동화 시스템용 리얼타임 확장 사례이다. 이 사례에서는 산업용 PC상에 Beckhoff사의 리얼타임 확장인 TwinCAT와 비리얼타임 처리를 담당하는 ORiN의 양쪽이 탑재, 양자가 ADS(Automation Device Specification)이라고 불리는 규격에 대응한 ORiN 프로바이더를 통해 내부 연계하고 있다. 이 구성에 의해 단일 PC 상에서 모션 제어, PLC 처리 등의 리얼타임 처리를 TwinCAT 상에서 실행시키면서 동시에 ORiN이 서포트하는 폭넓은 기기와 정보 교환하는 것도 가능해진다.

ORiN PAC – OSS 연계

OSS(Open Source Software)의 오피스 오토메이션 분야의 성공은 공장자동화에도 영향을 미치고 있다. ROS는 그 사례의 하나로, 연구 용도로서 보급되고 있다. 그러나 ‘산업용’으로서는 안전 인증(ISO, UL 등), 필드넷 인증(EtherCAT, PROFINET 등), 각종 자동화기기(PLC, 로봇 등)이나 각종 상위 시스템(각종 IoT 애플리케이션 플랫폼 등)과의 통신 기능 등의 면에서 과제가 남아 있다. 이것은 일반적으로 OSS 커뮤니티에서는 이들 메이커 의존 고유 기술에 대해 적극적으로 대응하지 않기 때문이다.

그림 10. ORiN과 ROS의 암 로봇(위), 이동 로봇(아래)에 대한 적용 사례

여기에서 ORiN PAC과 OSS를 조합함으로써 OSS의 적용 분야 확장이 가능해진다. 그림 10에 나타낸 사례에서는 ORiN PAC이 제공하는 ROS 라이브러리(CAP-ROS node, ROSSerial-CAO 게이트웨이 프로바이더)를 이용하고 있다. 이 시스템 구성에 의해 MoveIt! 등 ROS 상에서 개발된 애플리케이션을 이용해 ORiN에 의해 서포트된 암 로봇이나 이동 로봇이 동작하는 시스템이 실현되고 있다.

그 외의 특징

ORiN PAC에는 다른 것에는 없는 이점이 있다. 이하에 3가지 사례를 들었다.

1. 통합 개발 환경

산업용 디바이스 메이커는 기본적으로 독자의 개발 툴을 제공하고 있다. 산업기기의 소프트웨어 개발자는 이들의 사용 방법 습득이 필요하며, 그것이 산업기기 소프트웨어의 생산성 저하의 요인 중 하나가 되고 있다.

그림 7, 8, 9에 나타낸 사례에서는 산업기기 소프트웨어 개발자는 IT 소프트웨어 개발자와 동일하게 Microsoft Visual Studio를 사용할 수 있다. 또한, Subversion이나 Git 등의 소프트웨어 구성 관리 툴 등도 활용할 수 있다. 

ORiN PAC의 도입에 의해  IT 세계에서 일반적이었던 통합 개발 환경을 그대로 이용하는 것이 가능하고 개발의 효율화가 도모되는 동시에, 산업기기 소프트웨어 개발자의 범위를 이들의 통합 개발 환경으로 연결된 IT 기술자까지 넓히는 것이 가능해진다.

그림 11. 통합 개발 환경

통합 개발 환경의 사례를 그림 11에 나타냈다. 이 사례에서는 ORiN PAC 전체를 제어하는 GUI 애플리케이션, 설비 제어를 담당하는 PLC 프로그램, ORiN과 기기를 접속하기 위한 프로바이더의 3가지를 Microsoft Visual Studio 상에서 통합해 개발하고 있다.

2. 디지털 트윈

디지털 트윈은 실제 세계의 생산 설비 등의 상태를 가상 시뮬레이션 환경 상에서 재현시킴으로써 효율적인 생산 설비의 제어, 관리를 가능하게 하는 기술이다. 이 기술은 대량 생산 시스템용으로 생각되어 왔는데, 소량 생산 시스템에서도 유효하다.

그림 12. 디지털 트윈 환경

예를 들면 생산 라인 설계 시에 ORiN PAC을 통해 실제 디바이스․가상 환경을 조합한 개발 환경(그림 12)을 준비함으로써 설비의 완성을 기다리지 않고 실제 디바이스의 소프트웨어 개발을 병행해 실시할 수 있어 개발 기간의 대폭 단축이 가능해진다.

3. ORiN IoT

Industrie 4.0 키워드의 하나로 CPS(Cyber Physical System)가 있다. CPS는 실제 세계(Physical)에서 얻은 데이터를 네트워크상(Cyber)에 놓인 각종 시스템으로 처리함으로써 유익한 정보를 얻는 것을 말한다.

그림 13. ORiN IoT 아키텍처

ORiN에서는 CPS에 대응한 ORiN IoT 아키텍처(그림 13)를 제창하고 있다. ORiN IoT에서는 상위 시스템으로서 각사 IoT 애플리케이션 플랫폼 외에 클라우드 서비스나 데이터베이스 시스템 등과의 접속 기능을 준비하고 있다. ORiN IoT 시스템과 ORiN PAC는 CAP을 통해 쉽게 접속 가능하며, ORiN PAC 측에서 독자의 통신 수단을 개발하지 않고 CPS와 연계할 수 있게 된다.

맺음말

이 글에서는 ORiN을 PC 시스템 인티그레이션의 프레임워크로서 활용하는 ORiN PAC에 대해서, 그 사례와 가능성을 해설했다. 이 글이 스마트팩토리 실현에 계기가 되길 바란다.

榊原 聰, DENSO WAVE