[첨단 헬로티]

최근 로봇 시스템의 소프트웨어 개발에서 로봇 미들웨어가 널리 이용되고, 상호 접속성이나 소프트웨어 자산의 축적·재이용성이 향상돼 시스템 인티그레이션이 용이해지고 있다. 더구나 소프트웨어 일반에 대해서도 오픈소스화의 흐름에 더해, github 등 소스코드의 공유, 커뮤니티의 형성이나 활동을 서포트하는 서비스의 출현, 애자일 개발, DevOps 등의 소프트웨어 개발 패러다임의 변화, Docker나 Docker hub 등 컨테이너 기술과 그것을 재이용하는 기술의 출현 등으로 소프트웨어 개발의 효율이 비약적으로 높아지고 있다.

이러한 배경에서 로봇 기술을 활용한 신규 시장 창출의 움직임도 활발하다. 로봇 공학이나 AI 기술의 진전, 특히 심층학습을 비롯한 혁신적 기술의 출현에 의해 로봇의 새로운 애플리케이션, 비즈니스를 전개하려고 하는 기운이 높아지고 있다. 한편, 이러한 로봇 기술을 활용한 신규 시장 자체는 이들 기술 혁신의 스피드만큼은 확대되지 않고 있는 것이 현재 상황이다.

앞에서 말했듯이 소프트웨어 관련 기술의 진화에 의해 학술 분야의 연구 개발 성과가 제품에 적용되기까지의 기간은 단축되었지만, 연구 개발에 있어 소프트웨어 품질과 제품에 있어 소프트웨어 품질 사이에는 아직 큰 괴리가 있다는 것도 지적되고 있다. 이러한 홈을 메우지 않으면, 소프트웨어 기술 진전의 혜택을 로봇의 이활용이나 시장 확대에 효율적으로 활용할 수 없다. 

이 글에서는 로봇의 이활용이나 시장 확대를 목적으로 연구 개발된 RT 미들웨어(RTM : Robot Technology Middleware)의 배경을 한 번 더 재검토하는 동시에, 로봇 시스템의 소프트웨어 개발 기술을 해설한다. 앞으로의 로봇 시장 확대를 위해 로봇 시스템 개발, 특히 소프트웨어 개발의 기술적 과제, 비기술적 과제에 대해, 해결에 필요한 기술을 시스템 인티그레이션의 관점에서 살펴본다.

로봇 산업 구조와 RT 미들웨어

로봇 기술을 보다 저렴하게, 효율적으로 여러 가지 애플리케이션 영역에서 이용하고 싶다는 요구는 대인·대물 서비스나 농업·개호·재해 대응 등의 서비스 로봇 분야뿐만 아니라, 제조 분야의 로봇 미활용 영역 등 여러 가지 분야에서 이전부터 많이 존재하고 있었다.

일본로봇공업회에 의한 보고서에서는 로봇 기술(RT : Robot Technology)이 이러한 요구에 대응하기 위해서는 RT 기능 요소를 저렴하고 입수하기 쉬운 형태로 오픈화·부품화하는 것에 더해, 로봇 산업을 제조·판매를 주체로 하는 형태로부터 그림 1에 나타냈듯이 솔루션 비즈니스로 전환해 다수의 소규모 시장이 지속적으로 발전이 가능한 산업 구조를 확립하는 것이 중요하다고 지적하고 있다.

2015년 2월에 일본 정부가 발표한 로봇 시책에 관한 액션 플랜 ‘로봇 신전략’에서는 로봇 혁명 실현의 방법(제1부 제1절)으로서 유저의 요구에 적절하게 대응할 수 있는 로봇 창출력 강화를 위해 로봇의 플랫폼화를 추진하고, 그를 위한 기반으로서 로봇 미들웨어(로봇 OS)와 그 표준화의 중요성이 지적되어 있다.

로봇의 산업 구조에 대한 전환을 지원하는 기술로서 RT 기능 요소의 소프트웨어 부품화·오픈화를 목표로 해, ‘RT 미들웨어 프로젝트’(2002년도～2004년도, 정식 명칭 : NEDO 21세기 로봇 첼린지 프로그램 ‘로봇 기능 발현을 위해 필요한 요소 기술 개발’)이 산업기술종합연구소(산종연), 마츠시타전공, 일본로봇공업회의 3자에 의해 실시됐다. 이 프로젝트에서는 소프트웨어 플랫폼으로서 RT 미들웨어와 소트프웨어 부품화를 위한 기틀로서 RT 컴포넌트(RTC : RT-Component) 프레임워크가 개발됐다.

그림 1. 로봇 기능 요소의 모듈화에 의한 새로운 로봇의 산업 구조와 RT 미들웨어가 하는 역할

그 후 NEDO ‘차세대 로봇 공통 기반 개발 프로젝트’(2003～2007년도)에서는 로봇 실현의 기반이 되는 하드웨어의 개발, 소프트웨어 개발을 위한 툴(RTCBuilder, RTSystemEditor)과 조립용 RTM으로서 RTC-Lite와 RTC-CAN의 개발이 실시됐다. NEDO ‘차세대 로봇 지능화 기술 개발 프로젝트(통칭 : 지능화 프로젝트)’(2007～2012년도)에서는 차세대 로봇의 모듈화된 로봇 요소 기술의 집적을 목표로, 매니퓰레이션, 이동, 대화지능에 관한 많은 소프트웨어 모듈군이 개발됐다. 그러나 이러한 소프트웨어 모듈을 실제 제품에 이용하기 위해서는 집적만으로는 충분하지 않고, 품질의 담보, 계속적인 보수, 라이선스․특허 문제의 클리어, 서포트 등도 포함한 주변 환경의 정비도 필요하다는 것이 분명해졌다.

1. RT 미들웨어 기술 개발

로봇 시스템 인티그레이션을 효율화하기 위해 기능 요소를 부품화하고, 그 유통의 촉진, 시스템 구축의 분업 체제 확립을 위해서는 개발 프로세스의 체계화와 이것을 지원하는 구조가 필요하다. 이러한 배경에서 RT 미들웨어의 연구 개발에서는 1) 로봇 기능 요소를 자유로운 입도로 모듈화(부품화)할 수 있는 것, 2) 특정 언어나 OS에 의존하지 않고 기능 요소 간의 연계가 쉬운 것, 3) 작성한 모듈은 여러 가지 대상에 대해 재이용 가능한 것, 그리고 4) 기존의 소프트웨어 자산을 쉽게 모듈화할 수 있는 것을 목표로 했다.

이러한 요소를 만족시키기 위해 고안된 것이 소프트웨어 기반으로서 RTM 및 모듈화의 틀 구축으로서 RTC 프레임워크이다. 그 실장 예로서 필자 등에 의해 개발된 OpenRTM-aist는 오픈소스 소프트웨어로서 공개되어 자유롭게 이용할 수 있다.

그림 2. RT 컴포넌트의 기본 기능.

RTC 프레임워크가 제공하는 기능으로서는 주로 그림 2에 나타낸 4개의 기능이 있다. 실행 컨텍스트(그림 2 (a))는 RTC 공통의 상태 천이를 정의함으로써 다수의 RTC로 구성되는 시스템 제어를 쉽게 하는 동시에, 복수의 RTC 실행을 밀접하게 연계시키는 등 로직 실행 형태의 다양성을 실현하는 구조이다. 컴포넌트 간의 상호 작용을 실현하는 구조로서 데이터 포트와 서비스 포트가 제공되고 있다. 데이터 포트는 주로 통신 빈도가 높고 데이터를 주체로 한 하위층에서 이용되는 것을 가정(그림 2 (b)), 서비스 포트는 로봇 제어의 상위층이나 모듈의 상세 기능에 대한 액세스에서 이용하는 것을 가정해 설계됐다(그림 2 (c)). 또한, RTC의 재이용성을 향상시키기 위한 기능으로서, RTC 내부의 여러 가지 파라미터를 실행할 때에 외부에서 설정 가능하게 하는 컨피규레이션 기능을 갖추고 있다(그림 2 (d)).

이 외에 CORBA의 이용이나 OS 추상화층을 실장함으로써 복수의 언어․OS로 동작하는 RT 컴포넌트의 상호 운용을 실현하고 있다. 기존의 소프트웨어 자산을 신속하게 RT 컴포넌트화하기 위해 RTC 프레임워크를 작성, 사양에서 템플레이트 코드를 생성하기 위한 코드 제너레이터 rtc-template, RTCBuilder 등이 개발됐다. 이것에 의해 기존 소프트웨어를 OS·언어에 상관없이 용이하게 RT 컴포넌트화하고, 다른 기존 컴포넌트와 협조시키는 것을 가능하게 했다.

2. 표준화

RTM 프로젝트(2002～2004년도)에서는 소프트웨어 플랫폼으로서 RT 미들웨어를 확립하는 동시에, 그 성과물로서의 실장과 사양을 공개했다. 공개 사양에 기초하는 호환 실장을 소프트웨어 벤더가 개발·판매, 로봇 메이커나 시스템 인티그레이터 등 산업계의 이용 촉진을 목표로 2004년부터 국제표준화단체 OMG(Object Management Group)에서 표준화를 개시했다.

RTC에 관한 표준 사양 제안 공모(RFP : Request for Proposal)에 대해 일본에서 산종연이 OpenRTM-aist-0.2에 기초하는 사양 원안을, 미국 Real-Time Innovations, Inc.(현 RTI사)가 동사의 제품을 베이스로 한 사양 원안을 각각 제출, 2가지 사양을 의논한 끝에 통합해 최종적으로 OMG에서 정식 표준 사양 ‘Robotic Technology Component Specification version 1.0’(RTC 표준)이 2008년 4월에 공개됐다. 

그 후 RTC 표준은 1번의 버전업을 거쳐 현재 버전 1.1이 되어 있다. 표준 사양의 공개에서 10년이 경과됐는데, 지금까지 RTC 표준 준거의 실장이 몇 가지 발표됐다(표 1). 또한, 혼다기술연구소가 개발하는 RT 미들웨어 : HRTM에서는 상태 천이형 컴포넌트의 프레임워크가 제안되어, 이것을 기초로 RTC 표준에 관련된 표준 사양으로서 FSM4RTC가 2016년 4월에 발효되는 등 표준 사양의 갱신이나 확장이 이루어지고 있다.

이와 같이 표준화함으로써 복수의 개발원이 호환성 있는 미들웨어 실장을 개발하는 것이 가능해지고, 실장의 선택지 확대, 사양의 계속성 담보, 실장 기술의 진화에 대한 추종 등 실장자, 이용자 모두 메리트를 얻을 수 있다. 

개발 프로세스와 주변 기술

RT 미들웨어는 그림 1에 나타낸 로봇 산업 구조의 확립을 위해 분업 체제나 개발 효율화에 이바지하는 실용적인 로봇 개발 프로세스의 체계화를 목적으로 하고 있다. 개발 프로세스란 제품 개발에서 여러 개발자나 스테이크홀더 간의 의사통일을 도모, 목적한 제품을 효율적으로 개발하기 위해 실시해야 할 처리와 그 절차를 정한 것이다. 

개발 프로세스에는 ISO/IEC12207이나 ISO/IEC15288 등 국제표준화된 것이 있고, 또한 이들을 보다 구체화한 ESPR2(Embedded System development Process Reference ver.2) 등이 알려져 있다. 

RT 미들웨어는 실장 시의 이용에 그치는 것이 아니라, 개발 프로세스의 요건 정의나 설계 및 최종적인 텍스트에 이르는 여러 단계에서 개발 작업을 지원하는 기능을 제공하는 것을 목표로 하고 있다. 그림 3에 RT 미들웨어 및 관련 툴 등을 ESPR2로 정의되는 V자 프로세스에 매핑한 것을 나타냈다. V자 프로세스 최하부의 실장뿐만 아니라, 전후의 설계나 테스트에서 필자 등이 개발한 툴뿐만 아니라, 일반적으로 이용 가능한 툴이나 프레임워크와 조합해 효율적인 개발을 실현한다.

그림 3. V자 개발 모델의 예와 RT 미들웨어의 관계

그림 3의 개발 프로세스는 크게 나눠 시스템, 세이프티, 소프트웨어/하드웨어의 각 엔지니어링 프로세스로 나누어진다.

시스템 엔지니어링 프로세스에서는 하드웨어, 소프트웨어를 포함하는 로봇 전체의 설계가 이루어지고, 그 후 하드웨어(기계, 전기 등) 및 소프트웨어 각각의 설계·개발 프로세스로 진행한다. 또한, 로봇의 안전성에 관해서는 시스템 요구 정의의 초기 단계에서, 안전 요구 정의를 포함하는 세이프티 엔지니어링 프로세스를 실시할 필요가 있다.

이 글에서는 RT 미들웨어를 포함하는 소프트웨어 엔지니어링 프로세스 및 그 전 단계인 시스템 엔지니어링 프로세스에 초점을 맞추고, 세이프티 엔지니어링 프로세스에 대해서는 언급하지 않는다. 또한, 기계, 전기계를 포함하는 하드웨어 엔지니어링 프로세스에 대해서도 할애한다.

1. 시스템 엔지니어링 프로세스

로봇 개발의 초기 단계에서는 대상 로봇에 요구되는 기능 등을 명확하게 하기 위해 시스템 요구 정의를 한다. 시스템 설계에서는 요구 정의에 기초해 시스템 거동의 정의, 하드웨어와 소프트웨어의 역할 분담, 시스템을 구성하는 기능 블록의 조사 등 시스템의 전체 구성(아키텍처)을 구체화한다.

이 단계에서는 시스템 모델링 언어 SysML을 이용할 수 있다. SysML은 시스템 설계의 여러 가지 요소를 모델화하기 위해 OMG로 표준화된 모델링 언어의 하나이다. SysML로는 시스템의 요구, 거동, 구조를 그림(다이어그램)으로서 모델화할 수 있고, 시스템 요구 정의 단계에서는 요구도나 유스케이스, 시스템 설계 단계에서는 내부 블록도나 액티비티도, 시퀀스도를 이용해 개념 설계를 할 수 있다.

SysML 자체는 소프트웨어에 한하지 않고 시스템의 여러 가지 요소의 관계나 거동을 기술하는 것이 가능하다. 이 이후에는 하드웨어(기계, 전기), 소프트웨어는 각각 기존의 방법으로 설계하게 되는데, 시스템 전체의 요구와 기능, 하드웨어와 소프트웨어의 각 구성 요소 간의 관계는 여기에서 관련지을 수 있다. 이렇게 함으로써 개발에 있어 빠지거나 누락하는 것을 없애고, 개발 전체의 트레이서빌리티 확보에도 도움이 된다.

2. 소프트웨어 엔지니어링 프로세스

시스템 요구 정의와 시스템 설계에서 소프트웨어로 실현해야 할 기능이 분명해지고, 여기에서 소프트웨어에 대한 요건을 정의, 소프트웨어 전체 설계(기본 설계 혹은 아키텍처 설계)로 구체화해 간다. 

요건 정의에 관해서는 SysML이나 UML의 요구도와 유스케이스도, 아키텍처에 관해서는 내부 블록도, 컴포넌트도, 액티비티도 등을 이용해 구조를 밝혀 간다. UML은 SysML의 기초가 된 소프트웨어의 모델링에 특화한 모델 기술 언어이다.

또한, OMG의 RTC 표준에서는 RTC 그 자체는 UML의 컴포넌트 모델을 계승하고 있으며, UML의 컴포넌트도나 SysML의 내부 블록도에서 컴포넌트나 블록과 등등한 기능을 실현한 것으로 되어 있다. 이것은 즉, 내부 블록도나 컴포넌트로 기술한 기능 요소를 쉽게 RTC에 매핑할 수 있는 것을 의미한다.

이것과는 별도로 RTC에 의한 시스템 구조의 기술 방법으로서 ‘RTSProfile’ 사양이, RTC 자체의 사양 기술 방법으로서 ‘RTCProfile’이 개발됐다. RTSProfile은 RTC 간의 접속과 해당 시스템의 설정 정보를, RTCProfile은 RTC의 기본 정보나 포트, 컨피규레이션 파라미터 등의 정보를 XML이나 YAML의 형식으로 기술할 수 있다. 이러한 사양 기술을 위한 형식을 정의해 둠으로써 개발 프로세스 단계 간 및 거기서 사용되는 툴 간에 설계 정보를 확실하게 이어받는 것이 가능해진다.

예를 들면, 시스템 구성 툴의 하나인 RTSystemEditor를 이용해 기본 설계를 하고 RTSProfile을 파일로서 생성, 이 파일을 이용해 시스템 테스트 시에 다시 RTSystemEditor에 입력해 시스템을 재구성하거나, 커맨드 라인 툴인 rtshell에 입력시킴으로써 시스템 실행 시에 자동적으로 RTC 간의 접속이나 설정을 할 수 있다.

그림 4. astah* SysML-RTM과 RTCBuilder, RTSystemEditor와의 연계

다른 예로서 주식회사 체인지비전의 UML/SysML 툴인 ‘astah*’에는 OpenRTM와의 연계 플러그인이 있고, 이것을 이용하면 astah*로 작성한 내부 블록도로부터 각 블록을 RTC의 사양(RTCProfile)로 써낼 수 있다(그림 4). RTCProfile을 RTC 작성 툴인 RTCBuilder에 입력시킴으로써 임의의 언어인 RTC의 모형 코드를 생성하는 것이 가능하며, 기본 설계에서 상세 설계 및 실장에 필요한 코드 생성으로 심리스하게 작업하는 것이 가능해진다.

3. 내부 로직의 설계·검증과 실장

상세 설계에서는 RTC로서 실장하는 모듈의 내부 로직의 실현 방법을 검토한다. 이 작업은 소프트웨어의 일반적인 개발로, 이어서 UML을 이용해 소프트웨어의 구조(클래스도, 오브젝트도)나 로직의 거동(시퀀스도, 스테이트 머신도)을 검토할 수 있다. 

특히 상태를 갖는 거동을 실현하기 위해 유한 상태 머신(FSM : Finite State Machine)이 이용되는데, 이것을 RTC로서 실현하는 방법으로서 FSM4RTC 표준과 이것을 실장하는 프레임워크가 제안되고 있다. FSM4RTC는 2016년에 OMG에서 표준화된 RTC의 확장 사양으로, RTC 내부에 로봇 등의 거동을 실장하는 FSM 프레임워크를 가지며, FSM의 구조 취득이나 설정, 상태의 취득, 이벤트 입력 등을 하기 위한 인터페이스가 정의되어 있다.

그림 5. CSP 및 FDR에 의한 로직의 검증과 FSM4RTC 프레임워크에 의한 실장

복잡한 상태를 갖는 RTC끼리의 연계에서는 설계 시에 데드록 등의 의도하지 않은 불량을 포함하는 경우가 많고, 이러한 로직의 설계․검증․실장을 하는 방법으로서 CSP(Communicating Sequential Processes)를 베이스로 한 로직의 모델화, 모델 검사기 FDR(Failures Divergence Refinement)에 의한 검증 방법 및 FSM4RTC에 의한 실장 방법도 제안되고 있다(그림 5).

4. 테스트와 품질 보증

V자 개발 프로세스에서는 설계의 각 단계에 대응한 입도로, 단체 테스트, 통합 테스트, 종합 테스트 등의 테스트를 해, 개발된 소프트웨어의 품질을 검증한다.

로직 자체의 테스트에 관해서는 소프트웨어 일반의 테스트 방법(유닛 테스트나 테스트를 계속해서 실시하는 방법 ‘계속적 인티그레이션’=CI: Continuous Integration 등)을 이용할 수 있다.

로직을 실장한 후의 단계에서 RTC 그 자체를 테스트하는 방법으로서, 테스트 컴포넌트 생성 기능을 RTCBuilder에 추가했다. 생성되는 RTC와 쌍이 되는 테스트용 RTC가 동시 생성되어, 개발 대상 RTC에 대해 테스트 컴포넌트로부터 여러 가지 입력을 대상 RTC에 주거나, RTC의 출력을 검증하거나 하는 것이 가능해졌다. 

또한, RTC를 조합해 테스트하는 통합 테스트나 시스템 전체를 대상으로 한 종합 테스트에 대해서는 현재 RTSystemEditor에 의한 수동 테스트나 rtshell을 이용한 시스템 테스트 스크립트에 의한 테스트가 가능하다. 단, 통합 테스트나 종합 테스트를 통일적으로 하는 방법은 지금 현재 확립되어 있지 않다. 특히 로봇의 경우 최종적으로는 하드웨어와 조합해 테스트를 할 필요가 있으며, 시뮬레이터나 실제 기기를 이용하는 방법 등을 생각할 수 있다.

로봇 활용형 시장화 적용 기술 개발 프로젝트

로봇의 개발 프로세스, 특히 소프트웨어 개발의 각 단계에서 각각의 작업을 지원하는 방법에 대해서 툴이나 미들웨어, 사양 기술 방식을 개발함으로써 문제의 일부를 해결해 왔다. 그러나 개발 프로세스에서 고려해야 할 사항이나 과제는 다른 것도 존재한다. 

예를 들면 아키텍처의 설계에 대해서는 현상 설계자의 경험과 감에 의존하는 바가 크다. 소프트웨어의 테스트 방법은 여러 가지 것이 있는데, 하드웨어와 조합했을 때에도 개발 중 혹은 제품 릴리스 후에도 계속적으로 품질을 확보하는 방법은 개발자나 그룹의 역량에 의존하는 부분도 크다.

또한, 오픈소스 소프트웨어(OSS)를 이용할 때에 소프트웨어의 품질이나 라이선스 혹은 포함되는 특허 등의 문제 때문에 고도의 기능을 무상으로 이용할 수 있음에도 불구하고 실제 제품에 탑재할 수 없는, 혹은 탑재를 스스로 피한다고 하는 목소리도 듣는다. 이러한 기능에 직접 관여하지 않는 이른바 비기능 요건에 대해서도 대응할 필요성이 지적되고 있다.

2017년도부터 NEDO에 의한 위탁사업으로서 시작한 ‘로봇 활용형 시장화 적용 기술 개발 프로젝트’(이하 ‘시장화 프로젝트’)는 로봇 미활용 영역에 대해 도입을 촉진하는 것을 목표로 한 프로젝트이다. 특히 로봇 시스템의 소프트웨어에 관해서는 오픈소스를 활용하면서 소프트웨어의 공통화·플랫폼화를 촉진함으로써 인티그레이션 코스트의 절감과 효율화를 촉구한다.

그림 6. 소프트웨어 플랫폼과 비기능 요건

시장화 프로젝트에서는 로봇의 소프트웨어는 그림 6에 나타냈듯이 OS·미들웨어 등의 기반 영역과 로봇 기능을 실현하는 분야·기능별 소프트웨어, 시스템을 통합하기 위한 SI 영역이 있으며, SI 영역 이외의 공통부분을 플랫폼으로서 확립해 메이커 간에 공유함으로써 개발의 효율화와 코스트 절감을 목표로 한다. 소프트웨어의 공통분을 가급적 크게 하고, 개별 개발이 되는 SI 비용을 압축하는 것이 미활용 영역에 대한 로봇 도입의 열쇠가 된다. 아울러 소프트웨어 개발에 관련된 기능과는 직접 관계가 없는 부분, 즉 테스트․검증에 의한 소프트웨어 품질 보증, 라이선스․특허 문제의 해결, 소프트웨어의 보수․운용 체제의 확립 등 비기능 요건에 관한 문제를 해결, 개발 때마다 따라오는 작업 코스트를 어떻게 줄일지가 과제이다.

이와 같이 시스템 인티그레이션의 관점에서는 미들웨어나 로봇 요소 기술에 대한 기술 개발뿐만 아니라, 비기능 요건에 관한 과제의 해결이 요구되고 있다.

맺음말

이 글에서는 로봇의 시스템 인티그레이션의 관점에서 RT 미들웨어를 비롯해, 설계 개발 작업을 지원하는 프레임워크, 툴이나 사양 기술에 관해 해설했다. 개발 프로세스 전체를 부감했을 때에 각각의 단계는 밀접하게 연계시킬 필요가 있으며, 이것을 지원하는 이러한 기술의 필요성에 대해 해설했다. 또한, 시스템 개발의 기술적․기능적이 아닌 문제에 대해, 현재 실시되고 있는 로봇 활용형 시장화 적용 기술 개발 프로젝트에서 대응하고 있는 예를 소개했다.

安藤 慶昭, 산업기술종합연구소