[첨단 헬로티]

이제 사람들은 누구나 눈앞으로 다가온 변혁을 잘 인식하고 있다. 연결된 사물이 수백만, 어쩌면 수십억 개에 달하며 사물인터넷(IoT)과 산업용 사물인터넷 (IIoT) 인프라의 촉수는 무한대로 뻗어 나가는 것만 같다. 그 위에는 클라우드가 존재한다. 

사람 간에 서로 연결되고, 클라우드에 연결하기 위해서는 다양한 장치가 필요하고, 여러 가지 전략이 그 변화를 주도하고 있다. 연결된 장치와 그에 연관된 시스템은 시간이 지날수록 극히 복잡해지고 있다. 

사물이 서로 연결된 형태는 새로운 개념은 아니다. 일찌감치 1968년 딕 몰리(Dick Morley)가 프로그램 가능한 논리 제어장치(Programmable Logic Controller, PLC)를 발명했고, 뒤이어 래더 로직 프로그래밍을 개발됨으로써 새로운 산업 자동화의 시대가 열리게 됐다. 또 최근에는 감시 제어 데이터 수집(Supervisory Control and Data Acquisition, SCADA)과 필드버스 기술 개발 덕분에 산업 자동화 운동이 개혁됐으며, 이것이 오늘날까지 업계에 유리한 작용을 하고 있다. 

하지만 판도는 다시 한 번 바뀌고 있다. 이제는 모든 것이 연결돼야 하는 시대가 도래했기 때문이다. 게이트웨이, 경계 장치, 스마트 센서, 저성능(Dumb) 센서, 종단 노드(로컬 서버까지 포함) 등 수많은 장치가 데이터를 수집, 집계, 처리하고 IIoT 인프라 아래위로 전송하는 임무를 일부 맡고 있다[그림 1].

▲ 그림 1. IoT 토폴로지가 점차 복잡해지고 있다.

여기에 각자의 분야에서 문제를 해결하기 위해 애쓰고 있는 수많은 헌신적인 전문가들까지 더해진다. 예를 들어 상용 미들웨어 공급업체, 사용자 그룹, 통신 프로토콜 전담 컨소시엄, 클라우드 제공업체, 반도체 기업뿐 아니라 보안 솔루션 제공업체도 빼놓을 수 없다. 이 세상에는 이제까지 우리가 알고 있던 현대식 공장 자동화를 변혁할 잠재력을 가진 전문가들로 구성된 탄탄한 생태계가 등장하게 된 셈이다. 

또한 연결된 장치의 수와 유형이 늘어나면서 IoT 토폴로지가 발달되고, IIoT 시스템 구현의 복잡성이 전보다도 더 큰 문제로 대두되고 있다. 최근 팬톤 미디아(Penton Media)에서 실시한 설문조사[그림 2] 응답자의 피드백에는 IoT/IIoT 복잡성과 세분화 상태가 여실히 드러났고, 우려해야 할 점으로 보안을 꼽았다. 이는 위험과 비용이 늘어나고 비즈니스 기회를 잃고 있는 것으로 해석할 수 있다. 하지만 우리는 실용주의적인 관점에서 생각해 보겠다. 다양한 솔루션에 대해 모든 것을 다 안다는 것이 과연 가능할까? 앞에서도 언급했듯이 모든 것은 심하게 세분화돼 있고, 점점 커지기만 하는 솔루션과 공급업체의 에코시스템이라는 테두리 아래에서 비용이 점차 증가하는 양상이다. 특히 클라우드 연결을 위해 지원, 연결, 이식, 규모 확장, 통합까지 해야 하는 수많은 장치의 경우 더 심하다.

▲ 그림 2. IoT 채택에 어려운 점들 (출처: Penton Media)

서로 다른 여러 솔루션 사이에 간극이 존재하고 정해진 표준이 미비하다는 사실에는 의문의 여지가 없다. 하지만 이미 TCP/IP 프로토콜에 MQTT(Message Queue Telemetry Transport)와 같은 특정 표준으로 HTTP에서의 연결 보안을 확보하고자 하고, 업계에서 연합이 이뤄지기기 시작했다. 그러나 아직도 갈 길은 멀다. 

차세대 IoT 아키텍처에 필요한 전반적인 요구사항 범주를 크게 네 가지로 분류된다. 현재 업계에서 이런 요구사항 중 몇 가지를 세분화된 형태로 다루고 있는 것은 사실이지만, 장치 제조업체에서는 이런 요구사항에 좀 더 전체론적으로 접근해 후속의 고객에게 능률적이고 효과적인 형태로 솔루션을 제공해야 한다. 

 

네 가지 범주는 다음과 같이 나뉜다. 

1. 종합적인 장치 관리

2. 알 수 없거나 예측할 수 없는 클라우드를 위한 설계

3. 투자 확장성 및 재활용 극대화

4. 원격 진단과 상태 모니터링 사용

종합적인 장치 관리

종합적인 장치 관리는 각종 IIoT 전략에 핵심적인 요구사항이다[그림 3]. 무엇보다 중요한 것은 임의의 IIoT 시스템에서 사용자들이 연결된 모든 장치를 간편하고 효과적으로 관리할 수 있게 지원하는 방법을 구축하는 것이다. 온보딩과 인증을 통해 모든 연결된 장치가 클라우드 인프라에 참가할 권한이 있도록 확실히 하려면 어떤 방법을 취해야 할까? 또 장치를 기본적인 작동을 위해 구성하는 것(이름 짓기, 적절한 언어, 표준 시간대 설정 등)과 같이 비교적 단순한 작업을 하고 원격 재설정, 구성 다운로드, 공장 기본값 복원과 같은 기본적인 제어 명령을 실행하려면 어떻게 해야 할까?

▲ 그림 3. 성공적인 장치 관리 전략에서는 각종 게이트웨이, 종단 노드 장치뿐 아니라 멀티 클라우드 백엔드까지 고려해야 한다.

이를 위해서는 더 복잡한 작동 형태를 고려해야 한다. 예를 들어 장치 업데이트와 유지관리(애플리케이션 사용 설정 포함), OS 업데이트와 패치, 펌웨어 롤백, 대량 출시 등이 대표적이다. 물론 이 모든 것을 안전하고 종합적인 형태로 달성해야 한다는 것과 IoT 인프라 전체에 걸쳐 수평적으로 이뤄져야 한다는 점도 간과할 수 없다. 

예측할 수 없는 클라우드

저자가 기업체에 상품을 판매하는 장비 제조업체 관계자와 나눈 수많은 논의 중에서 한 가지는 확실한 사실로 드러났다. 이들도 자사의 장비가 어느 클라우드와 통합될지 예측할 수 없다는 것이다. 일례로 자동차 제조업체와 거래하는 로봇공학 기업을 생각해보자. 과연 모든 자동차 제작사가 똑같은 클라우드를 이용할까? 그럴 가능성이 있긴 하지만, 사실 이는 가능성이 높은 일은 아니다. 자사 비즈니스에 사용할 장비는 직접 제작하는 기업체와 이야기를 나눠도, 클라우드 관련 결정은 항상 유동적인 편이다. 

어떤 클라우드 환경에서도 잘 통합되게 하려면 장비를 어떻게 설계하고 제조해야 할까? 설게자는 클라우드 공급업체에서 제공하는 임베디드 소프트웨어 개발 키트(SDK) 구성요소에 얼마나 많이 의존해야 할까? 투자금 재활용을 극대화하려면 어떻게 해야 할까?

 

투자 확장성과 재활용

장치가 복잡하고 다양한 유형이 존재하고 비즈니스 전략을 구현하는 데 필요한 토폴로지가 계속해서 진화를 거듭하기 때문에 IoT 아키텍처를 구현하기 위한 천편일률적인 공식은 존재하지 않는다. 어떤 장치도 예외 없이 서로 다른 대상 플랫폼이 있고, 그에 맞는 맞춤식 구현이 필요하게 된다. 

[그림 4]는 IIoT 인프라를 나타낸다. 파란색 상자는 스마트 센서, 녹색 상자는 게이트웨이, 갈색 상자는 컨트롤러다. 장치마다 구체적인 용도와 정해진 몇 가지 요구 사항이 있기 때문에 이들 장치는 각각 하나의 맞춤형 구현으로 변환된다. 스마트 센서 장치의 경우 오픈 소스 RTOS를 지정된 운영 체제로 해 Arm Cortex-M4에서 실행돼야 한다고 가정하겠다. 게이트웨이 장치의 경우 x86 애플리케이션 센서 외에 상용 리눅스(Linux)의 풀서비스 기능이 필요하다. 컨트롤러 장치의 경우 Arm Cortex-A53 애플리케이션 프로세서에서 멘토 뉴클리어스(Nucleus) RTOS와 같이 안전성이 인증된 운영 체제에서 실행해야 한다. 

▲ 그림 4. 개방형, 확장 가능한 IoT 솔루션의 필요성. 대다수의 클라우드

SDK는 장치 소프트웨어 복잡성과 확장성 문제를 해결해주지 않는다.

이런 장치는 OS, 프로세서 아키텍처 또는 프로세스 등급과 상관없이, 하나도 빠짐없이 장치 관리, 클라우드 백엔드 통합, 보안 등을 포함한 유사한 기능을 통합해야 한다. 그 결과 각 연결된 OEM 장치가 매번 특수 제작한 맞춤 구현 장치가 된다. 궁극적인 목표는 여러 플랫폼에 걸쳐 확장할 수 있고 코드 재활용을 극대화하며 솔루션의 재가공(Re-engineering)을 최소화할 수 있는 솔루션을 확보하는 것이다. 

원격 진단과 시스템 상태 모니터링 사용

모든 비즈니스의 목표는 이윤을 극대화하면서 동시에 우수한 고객 경험을 제공하는 것이다. 장치 제조업체에서는 이를 위해 설치된 장치를 모니터링해서 잠재적인 문제점을 파악하고(시스템 상태 모니터링) 문제점을 진단 또는 예측해 예정된 유지관리 방문 중에 해결할 수 있도록 해야한다. 시스템 상태 모니터링을 예로 들면 CPU·메모리·네트워크 사용량 관찰 또는 감시 장치(Watchdog) 디먼, 기타 시스템 수준 모니터링 등이 있다. 시스템 성능 저하 또는 오류가 발생하면 경계 또는 종단 노드에서 원격으로 실행할 수 있는 광범위한 진단 기능이 존재한다. 이를 통해 장치 제조업체에 유용한 정보를 제공하는 것이다. 궁극적으로 원격 시스템 상태 모니터링과 진단 기능은 IIoT 시스템 업타임과 사용자 만족도를 개선해주면서 장치 제조업체 입장에서 장비를 유지관리, 정비 또는 교체할 비용을 절감해주는 효과가 있다.

문제를 더욱 심층적으로 고찰하기

IIoT 시스템에는 고민해야 할 사안이 많다. 그렇다면 많은 문제 중에서 거의 모든 IIoT 시스템이 직면할 수밖에 없는 근본적인 문제는 과연 무엇일까? 간략하게 말해, 비즈니스가 발전하고 자사 IoT 전략을 확대하는 과정에서 두 가지 서로 다른 간극에 직면하게 된다. 하나는 IoT 역량 간극이고, 다른 하나는 장치 구현 간극이다. 간단히 설명해서 IoT 역량 간극이란 비즈니스에서 필요로 하는 것과 클라우드 공급업체가 지원하는 것 사이의 차이점이라 할 수 있다. 장치 구현 간극의 경우 특정 하드웨어 플랫폼에 클라우드 백엔드 역량을 통합해 IoT 아키텍처의 경계 또는 종단 노드에 연관되게 만드는 데 필요한 작업이라고 할 수 있다[그림 5].

▲ 그림 5. 지금 필요한 것은 클라우드 공급업체 SDK를 보완하고 이를 확장해주면서 동시에 IIoT 시스템의 통합과 휴대성을

지원하는 프레임워크다.

IoT 역량 간극: 클라우드 공급업체는 정도는 다르지만 모두 연결된 임베디드 장치를 지원해 클라우드 백엔드 기능을 유리하게 활용할 수 있게 하는 데 투자하고 있다. 이런 투자의 정도는 연결된 프로토콜의 간단한 임베디드 라이브러리(예: MQTT)를 제공하는 것부터 임베디드 SDK 후크를 제공해 텔레메트리 데이터를 수집하도록 하거나, 백엔드에서 소프트웨어 업데이트를 시작하는 것 등 다양하다. 대부분의 제조업체의 경우, ‘바람직한 IoT 역량’은 앞에 언급한 것은 물론 그 이상까지 포함하는 개념이다. 다만 다양한 클라우드 백엔드 솔루션이 ‘바람직한 IoT 역량’의 수요를 맞추기 위해 제공하는 것이 거의 없을 수도 있다. 따라서 이 둘 사이의 차이를 IoT 역량 간극이라 부르는 것이다. 

장치 구현 간극: 클라우드 제공업체는 백엔드에 어떤 유형의 장치라도 연결하게끔 지원하기 위한 투자에 집중하지 않는다. 이는 애초에 불가능한 일이기 때문이다. 연결된 장치는 단순한 센서 같은 저성능 장치부터 기계 학습과 인공지능 프로그램을 실행할 수 있는 스마트 에지 게이트웨이 등 고도로 복잡한 장치까지 다양하고 광범위하다. 이들은 실행되는 운영 체제 자체가 없을 수 있고, RTOS나 리눅스에서도 실행되지 않을 수 있다. 주로 이런 장치는 x86나 Arm과 같은 프로세서 아키텍처에서 실행된다. 

따라서 OEM 제조업체에서 자사 장치가 클라우드 백엔드에서 실행되도록 연결하기 위해 투자를 한다면 이런 기능은 원래 의도된 용도에 맞는 특정 임베디드 플랫폼에서 구현해야만 하다. 여기에는 앞서 언급한 ▲SDK 후크를 플랫폼에 통합하는 것 ▲소프트웨어 업데이트를 위해 특정 부팅 전략을 구현하는 것 ▲이런 장치가 중요한 시스템 상태 모니터링, 진단 데이터를 제공하도록 계측 기능을 탑재해 백엔드에서 활용하도록 조처하는 것 등이 포함된다. 즉, 이것이 장치 구현 간극이다. 여기에는 엄청난 양의 엔지니어링 수고가 들며 연결된 IoT 장치를 제작하는 팀에서 테스트에 많은 시간을 소모해야 한다. 

이 문제를 앞에서 논한 4가지 요구 사항 범주를 통해 생각해보면, 장치 제조업체에서 직면한 여러 가지 문제를 쉽게 확인할 수 있다. 또한 업계 생태계의 세분화는 이 문제를 해결하지 못하고 있으며, 사실상 악화시키고 있다는 점도 알게 된다. OEM 제조업체는 다운스트림 고객의 점점 확장되는 IoT 아키텍처에서 요구하는 여러 가지 사항에 부합하기 위해 경주를 벌이고 있다. 따라서 문제는 지금 이 순간에 인정받고 인지도를 쌓는 것이며 제조업체에서는 이를 위한 해법을 모색 중이다. 

 

세분화 문제를 해결하고 바람직한 IoT 역량을 달성할 IIoT 솔루션

멘토 임베디드 IoT 프레임워크(Mentor Embedded IoT Framework, MEIF)는 멘토의 IIoT 솔루션으로 장치 제조업체에서 이런 간극을 해결하고, 그런 과정에서 자사 다운스트림 고객에게 솔루션을 효과적이고 능률적인 형태로 제공하도록 지원하는 제품이다[그림 6]. 이 프레임워크는 이미 클라우드 공급업체에서 제공한 기존의 기술과 투자를 대체하는 것이 아니다. 그보다는 기술을 보완하고 확장해 IoT 역량 간극을 채우고, 주어진 기능을 경계 또는 종단 노드 OS/하드웨어 장치 플랫폼에 완전히 통합해 장치 구현 간극을 없애는 역할을 한다.

▲ 그림 6. 멘토 임베디드 IoT 프레임워크는 클라우드 공급업체의 SDK를 보완하고 확장하며 기본 플랫폼으로의 통합과 휴대성을 지원한다.

Mentor의 MEIF 설계를 이용하면 클라우드 공급업체 측에서 제공한 임베디드 SDK(그림 6에서 짙은 회색으로 표시된 부분)를 잘 정의된 MEIF 장치 API(그림 6에서 옅은 파란색 부분, 필요에 따라 확장 가능)와 함께 통합하도록 지원된다. MEIF는 이런 프레임워크 접근법을 통해 강력한 게이트웨이에서 스마트 센서까지 광범위한 장치의 학습, 구현과 이식과 관련된 비용을 최소한으로 줄여준다. 

MEIF 솔루션의 주요 특성은 다음과 같다. 

- 프레임워크 에이전트

MEIF 프레임워크 에이전트는 클라우드 공급업체에서 제공한 SDK 후크를 일반적인 장치 관리 API와 연결해 클라우드 SDK API와 멘토 장치 관리 API로 구성된 일관된 API 세트를 포함한 솔루션을 지원한다. API를 활용한 애플리케이션을 여러 가지 임베디드 플랫폼에 이식하고 확장할 수 있으며, 동시에 코드를 다시 쓰고 테스트하는 과정은 최소한으로 줄여준다. 

- 종합적인 장치 관리

MEIF는 클라우드 백엔드를 활용하고 클라우드 SDK 함수를 이용해(가능한 경우) 안전한 장치 온보딩, 구성과 제어를 구현하고 데이터 통신 보안을 보장하며 경계, 종단 노드 장치의 장치 텔레메트리를 구현한다. 

- 원격 소프트웨어 업데이트

이 프레임워크는 일반적으로 클라우드 공급업체 SDK에 제공되는 업데이트 후크를 구현함으로써 부팅 로더, 운영 체제, 애플리케이션 데이터는 물론 플랫폼 수준까지 안전한 소프트웨어 업데이트를 구현한다. 이 솔루션에는 GUI 기반 유틸리티가 포함돼 있어 장치로 전달할 아티팩트를 서명, 암호화해서 패키지화 한다. 이로써 장치 측에서 모든 다운로드된 패키지(예: 소프트웨어 업데이트 또는 보안 패치)를 설치하기에 앞서 검증하고 인증하도록 지원한다. 

- 시스템 상태 모니터링과 진단

MEIF는 임베디드 플랫폼의 상태와 작동을 원격으로 분석할 수단을 제공한다. 시스템 수준 기능과 디먼을 사용하면 시스템 상태를 모니터링할 수 있고, 보안 텔레메트리 채널을 통해 클라우드 백엔드에 있는 시계열 (Time-series) 데이터베이스로 데이터를 전송할 수 있다. 그러면 이 데이터 클라우드를 시스템 이상 현상을 식별하고 향후 오류를 예측하는 데 사용할 가능성이 높고, 시스템 디버깅에 사용할 진단 데이터를 제공하고 필수 소프트웨어 업데이트를 정의할 수 있다. 

- 프로파일링

시스템 프로파일링에는 임베디드 장치에 특정 관심 메트릭을 수집하도록 하는 작업이 포함된다. 예를 들어 애플리케이션이나 시스템 성능, 또는 특정 시스템 리소스의 활용도 등의 메트릭이 대표적이다. 멘토의 검증된 소서리 애널라이저(Sourcery Analyzer) 기술을 이용하면 필요한 기능을 탑재한 시스템은 시계열 데이터를 생성할 수 있고, 클라우드를 통해 액세스함으로써 OS/플랫폼 진단, 장치 프로파일링을 위해 원격으로 분석할 수 있다. 

- 운영 체제 추상화 계층(OSAL)

OSAL은 멘토 임베디드 IoT 프레임워크의 또 다른 주요 구성요소다. MEIF에는 장치 관리 에이전트, 프레임워크 서비스와 클라우드 공급업체 SDK 구성요소에 대한 API가 잘 정의돼 있기 때문에 OSAL이 이런 API를 기본 플랫폼에서 이용할 수 있는 API에 대해 매핑할 수 있다. 다시 말하지만 MEIF 내의 OSAL 구성 요소는 여러가지 OS와 하드웨어 플랫폼에 걸쳐 휴대성을 극대화하고 미들웨어에 투자한 것의 재사용을 도모하도록 설계돼 있다.

- 멀티 클라우드

MEIF는 마이크로소프트의 애저(Azure), 아마존 웹 서비스(Amazon Web Services, AWS), 지멘스 (MindSphere) 등 외에도 다양한 대형 클라우드 공급업체에서 제공하는 백엔드 함수와 통합돼 이를 보완해준다. MEIF에 Eclipse IoT를 통합하면 장치 관리와 액세스를 위해 온프레미스 또는 원격 서버로 지원되기도 한다. 

- 휴대 가능, 확장 가능

MEIF는 애초에 여러 가지 운영 체제, 강력한 멀티코어 SoC에서 마이크로컨트롤러급 프로세서까지 광범위한 여러 프로세서 등급, Arm과 x86 등 다양한 하드웨어 아키텍처를 망라해 활용할 수 있도록 설계한 솔루션이다. 앞서 언급한 모든 기능에 투자한 것을 여러 가지 플랫폼에서 다양하게 활용할 수 있으므로 임베디드 IoT 장치를 개발하는 데 수반되는 위험 요소와 비용을 절약할 수 있다. 

- 보안

멘토 임베디드 플랫폼은 보안 온보딩, 보안 통신, 보안 소프트웨어 업데이트 외에도 종합적인 장치 보안을 지원하므로 미사용 데이터부터 사용 중인 데이터와 이동 중인 데이터에 이르기까지 보안을 확보할 수 있다. 멘토의 전담 보안팀은 취약성이 발견되면 이를 평가해 플랫폼과 개발 툴에 보안 패치를 제공할 수 있다.

 

결론

IIoT 시스템에 투자한 기업은 더욱 복잡하고 광범위한 IoT 아키텍처를 구현하고 있다(일례로 더 복잡한 토폴로지에서 더 많은 경계 및 종단 노드 장치 구현). 그 결과 장치 제조업체에서는 장치 관리, 알 수 없는 복수의 클라우드, 휴대성, 확장성 등은 물론 장치를 원격으로 모니터링하고 진단해야 하는 필요성과 관련해 여러 가지 새로운 문제에 직면하고 있다.

멘토의 MEIF는 클라우드 공급업체에서 투자한 거금의 투자 내용을 보완하고 확장해 경계 하드웨어 또는 종단 노드 디바이스까지 구현할 수 있고 여러 플랫폼과 클라우드에 걸쳐 이식할 수 있는 종합적인 IIoT 기능을 제공한다. 

글 : 스캇 모리슨(Scot Morrison) 멘토 지멘스비즈니스 플랫폼 사업부 총괄 책임자(GM)