EP&C News UPDATED. 2017.10.18 수 14:10

상단여백
HOME EM FOUCS 포커스 뉴스레터
생산성 가속화하는 그래픽 기반 프로그래밍 '랩뷰'임베디드 머신, 정확한 타이밍에 동작시키는 리얼타임 프로그래밍
이나리 기자 | 승인 2017.06.19 10:42

적합한 프로그래밍 언어 선택, 랩뷰 아니면 C?

“랩뷰(LabVIEW)가 C보다 좋은 이유는 무엇입니까?”란 질문을 수 차례 받아왔다. 솔직히 이 질문은 잘못됐다고 본다. 올바른 질문이 되려면 좀 더 구체적인 부연 설명을 덧붙여야 한다. 예를 들어 “이 작업에, 이런 제약 조건에 처한 경우 무엇이 더 적합합니까?”처럼 말이다. 이런 추가 설명이 없다면, “밀가루보다 빵이 좋은 이유가 무엇입니까?”라고 묻는 것과 다를 바 없다.

내쇼날인스트루먼트(이하 NI)의 랩뷰 시스템 디자인 소프트웨어와 C의 관계는 한 마디로 빵과 밀가루의 관계다. 샌드위치를 만들려면 빵을 사용하고, 케이크를 만들려면 밀가루를 사용해야 하는데, 처음부터 밀가루로 빵을 만들다 보면 시간과 비용만 낭비할 뿐이다. 하지만 케이크라면 밀가루가 없어서는 안 된다. 마찬가지로 어떤 프로그래밍 언어가 해당 작업에 가장 적합한지 결정하다 보면 종종 어려움을 겪기도 한다. 결국 작업에 따라 적합한 툴을 사용하는 것이 가장 중요하다는 것을 뜻한다.

뷰 시스템 디자인 소프트웨어는 C 같은 로우레벨 언어 사용으로 인한 리스크, 비용과 직접 구축의 불편을 해소할 수 있기 때문에 측정 또는 컨트롤 시스템을 구축하는데 효과적이다. 그렇다고 랩뷰가 C보다 ‘나은’ 프로그래밍 언어라는 말은 아니다. 특히, 랩뷰 대부분이 G 뿐만 아니라 C, C++로 프로그래밍되어 있다는 점을 감안하면 더욱 그렇다. 오히려 프로그래머가 반드시 알고 있어야 하는 LabVIEW의 강점은 따로 있다.

 

로우레벨 컨트롤을 위한 언어 ‘C’

 

C는 리소스가 충분하지 않아 면밀하게 관리해야 하는 애플리케이션에 효과적이다. C는 로우레벨 언어이기 때문에 메모리 할당이나 스레드같이 가장 미세한 부분까지 직접 지정해야 한다. 뛰어난 프로그래머라면 대부분 고급 언어를 구현할 때 발생하는 오버헤드를 제거하기 위해 로우레벨 언어의 제어 기능을 사용한다. 또한 로우레벨에서는 타깃 아키텍처를 활용하거나 운영체제 속성을 호스팅해 성능을 높일 수도 있다.

NI 프로그래머들이 대부분의 랩뷰 라이브러리를 C 또는 C++로 프로그래밍한 이유도 바로 여기에 있다. 파일 I/O나 분석 같은 연산 작업은 C 만큼이나 랩뷰에서도 빠르다. 이 연산들 역시 로우레벨 언어로 프로그래밍됐고, 랩뷰가 지원하는 플랫폼과 운영 체제에 최적화돼 있기 때문이다.

어떤 면에서는 개발자의 효율성이 직접 코딩을 통한 최적화보다 중요하다. 직접적인 코딩 기능을 다소 포기하고 다른 프로그래머들의 문제 해결 방법을 이용한다면 품질이나 생산성 면에서 여러 프로젝트에 이롭게 작용할 수도 있다. 프로그래밍 언어는 더 높은 추상화 수준을 향해 끊임없이 발전하고 있다. 따라서 컴퓨팅의 세부 사항이 아닌 당면한 문제를 해결하는 데 도움된다.

병렬 실행과 실제 I/O를 위한 랩뷰

구현 언어가 무엇이 되었든 간에 하이레벨 시스템 디자인과 로우레벨 구현은 반드시 구분돼야 한다. 측정과 컨트롤 애플리케이션을 개발할 때 프로그래밍은 시스템 디자인의 한 부분일 뿐이다. 또 엔지니어들이 컴퓨팅, 측정 하드웨어나 운영체제 등의 고급 기능을 지원할 목적으로 기존의 소프트웨어를 학습하거나 재프로그래밍하기에는 시간이 부족할 수도 있다. 새로운 방법으로 메모리 할당이나 스레드 풀을 처리한다고 해서 가치가 창출되는 것은 결코 아니다.

과제 해결에 집중할 수 있는 그래픽 기반 언어

실제로 가치를 창출하기 위해서는 먼저 실제 데이터가 어떻게 수집, 조작, 표현되는지 정확히 알고 있어야 한다. 시스템 구축 시 랩뷰를 이용하면, NI의 로우레벨 코드 라이브러리도 테스트하고 지원해 유지할 수 있다. 자체적으로 로우레벨 라이브러리를 구현, 지원, 유지하거나 업체로부터 구매할 필요가 있을 때는 프로그래밍 언어로 C를 선택하게 된다(NI는 이런 경우를 위해 NI LabWindows/CVI 소프트웨어와 NI Measurement Studio를 제공한다).

텍스트 구문 기반인 C는 명령어를 순차 실행하는 데 최적화돼 있어 처리 속도가 CPU 만큼이나 빠르다. 특히 실행해야 할 작업이 하나뿐이고, 기본 명령어로 돼 있다면 연산 작업을 하는 데 이상적이다. 반면, 랩뷰의 그래픽 기반 구문은 실제 시간적 제약으로 인해 작업을 병렬 실행해야 하는 경우에 효과적이다.

어떤 면에서는, 개발자의 효율성이 수동 코딩을 통한 최적화 요건보다 중요하다. 직접적인 코딩 기능을 다소 포기하고 다른 프로그래머들의 문제 해결 방법을 이용한다면 품질이나 생산성 면에서 이롭게 작용할 수도 있다.

랩뷰는 단순히 프로그래밍 언어나 그에 관련된 라이브러리가 아니다. NI 하드웨어와 함께 랩뷰 통합 개발 환경(IDE)을 이용하면 단순한 통합 결과를 능가하는 시너지 효과를 경험할 수 있다. 이 소프트웨어는 가용한 하드웨어 리소스를 인지한 후 I/O 채널과 실행 타깃을 메뉴 방식과 프로젝트 항목으로 표시함으로써 잘못된 구성을 방지할 수 있다. 혹시 잘못된 구성이 있다고 해도 편집 중에 발견되기 때문에 디버깅이 힘들고 큰 비용을 초래하는 런타임 오류를 걱정할 필요가 없다. 특히 차세대 측정 하드웨어(NI PXIe­5644R 벡터 신호 트랜시버 등)는 랩뷰를 통해 하드웨어 펌웨어도 직접 정의할 수 있게 함으로써 기존의 고유 프로그래밍 언어와 계측기로는 엄두도 못 낼 성능 수준까지 도달하게 됐다.

오늘날 개별 소스를 취합하는 데 따른 수고를 과소평가해 프로젝트가 지체되거나 예산을 초과하는 경우를 쉽게 찾아볼 수 있다. 하지만 랩뷰에서는 하드웨어 드라이버가 분석 라이브러리의 소비 형식과 동일한 형식으로 데이터를 반환할 뿐만 아니라 UI 위젯이 분석 라이브러리의 생산 형식과 동일한 형식으로 기술 데이터를 표시하기 때문에 각 구성요소를 종합할 필요가 없다.

측정 시스템을 설정하고 트리거를 받아 스트레인 게이지의 주파수를 측정하고 100Hz 보다 높으면 담당자에게 이메일을 전송하는 프로그램


효율성과 생산성을 높여주는 랩뷰

[그림 1]의 블록 다이어그램에서 표현하는 시스템을 구현하기 위해서 엔지니어나 프로그래머가 어디서부터, 어떻게 시작해야 할지 감이 쉽게 잡히는가? 개념으로는 이해되지만 실제로 표현하고 제작 단계로 넘어가기 위해서는 설계의 시각화가 필수적이다. 이는 프로젝트를 심도 깊게 이해할 수 있도록 도와줄 뿐 아니라 원활한 커뮤니케이션을 촉진하고 개발 단계에서 조기에 문제를 발견하도록 지원한다. 설계를 시각화 할 때에는 설계를 성공적으로 구현하는 데 필요한 모든 상세 정보를 포함시켜야 한다.

특히 소프트웨어 설계 시각화는 추상적인 특성, 무한한 유연성, 본질적인 복잡성으로 인해 수많은 과제를 안고 있다. 따라서 소프트웨어 설계와 개발 생산성 향상은 프로젝트에 상당한 영향을 미칠 수 있어 중요하다. 내쇼날인스트루먼트(이하 NI)에서 시스템 설계 소프트웨어 랩뷰(LabVIEW)를 개발한 이유도 여기에 있다.

랩뷰는 그래픽 기반의 데이터 흐름 블록 다이어그램과 인터랙티브 프런트 패널을 사용해 모듈형 소프트웨어 기반 계측기의 계층 구조를 생성한다. 이로 인해 랩뷰는 설계를 시각화 하는 동시에 코드를 구현함으로써 생산성을 향상시킬 수 있다.

블록 다이어그램을 그대로 시각화하여 구현한 LabVIEW 코드


설계 시각화와 코드 구현을 동시에 지원

랩뷰는 시각화와 코드 구현을 동시에 지원한다. 따라서 신속한 프로토타이핑과 점진적 개발에 적합한 툴이며, 값에 따른 데이터 흐름을 한 눈에 보여줘 설계의 안전성과 확장성이 향상된다. 또 모든 레벨에서 일관된 계층 구조가 구현되므로 실행 동작 역시 일관적이다. 모듈별 프런트패널은 설계의 모든 단계에서 디버깅, 유닛 테스트, 조작을 편리하게 수행하도록 돕는다. 이런 모든 특성은 랩뷰의 생산성을 한층 높여준다.

다른 소프트웨어 툴과 차별화되는 랩뷰의 가장 중요한 특성 중 하나는 데이터 흐름이 병렬적으로 구현된다는 점이다. 기존 프로그래밍 언어들은 순차적으로 실행되는 언어인데. 순차 언어는 애초에 병렬로 동작하는 프로세스와 맞지 않는다. 즉, 다양한 산업 환경에서 멀티코어 머신과 FPGA가 널리 활용되는 추세에 이런 순차 언어 사용만으로는 한계가 있다. 존 배커스(John Backus)는 1977년에 일찌감치 순차적 아키텍처의 한계로 데이터 병목 현상뿐만 아니라 지적 병목 현상을 지적했다. 35년 정도가 지난 지금, 이와 같은 지적 병목 현상은 기존 텍스트 기반 순차 언어에 완전히 고착화됐다.

랩뷰 데이터 흐름 언어는 이런 문제를 극복하며, 가상 물리 시스템은 물론 궁극적으로 사물 인터넷에서 현재 제기되는 설계 관련 문제점을 해결하는데 유용하다. 이 그래픽 기반 접근 방식은 소프트웨어 시각화와 기본적인 하드웨어 기능에 초점을 맞춰 다양한 연구 영역에서 발전을 거듭하고 있다.

랩뷰 특징


임베디드 머신, 정확한 타이밍에 동작시키는 리얼타임 프로그래밍

또 하나 NI의 플랫폼이 집중해 진행 중인 연구 영역 중 하나는 타이밍이다. 대부분의 소프트웨어 애플리케이션은 정확한 타이밍 대신 전반적 성능에 최적화 돼 있다. 그러나 임베디드 시스템에서는 정확한 타이밍이 무엇보다 중요하다. 랩뷰는 타임드(Timed) 루프를 사용해 필수 타이밍을 시각적으로 표현하고 리얼타임 실행 성능을 구현할 수 있다. 설계자는 리얼타임 트레이스 뷰어(Real-Time Trace Viewer)를 통해 런타임 실행을 세부적으로 시각화 할 수 있지만, 설계 과정에서 상세한 타이밍 성능을 미리 예측하기는 어렵다.
컴파일러는 센서와 액추에이터의 정확한 타이밍만을 지정해야 하기 때문에 I/O에 맞춰 다른 소프트웨

어를 스케줄링해야 한다. 또 표현 기법의 혁신을 통해 나머지 소프트웨어의 타이밍을 전반적으로 제약하지 않으면서 정확한 I/O 타이밍을 훨씬 쉽게 지정할 수 있다. 현재 정확한 타이밍을 갖춘 분산 가상 물리 시스템의 구축은 가능하지만, 미래에는 시간에 대한 더욱 명확한 소프트웨어 표현 형식과 함께 등시성 통신을 위한 하드웨어 개선사항을 통해 이런 과정이 훨씬 간단해질 것이다.

타이밍과 구성은 현재 NI 플랫폼의 기능을 확장하기 위해 주력하고 있는 다양한 연구 영역 중의 일부에 지나지 않는다. 플랫폼 기반 시스템 설계 방식을 활용하면, 기존 설계 방식에 비해 생산성을 향상시킬 뿐 아니라 전체 비용을 절약할 수 있는 유연하고 확장성 높은 시스템을 구축할 수 있다. 또한 그래픽 기반 접근 방식이 지속적으로 발전하면서 추가적인 성능과 생산성 향상 효과도 기대할 수 있다.

작성: 조한길 한국내쇼날인스트루먼트 소프트웨어 담당 대리

이나리 기자  narilee@epnc.co.kr

<저작권자 © EP&C News, 무단 전재 및 재배포 금지>

이나리 기자의 다른기사 보기
icon인기기사
여백
여백
여백
여백
여백
여백
여백
여백
icon
여백
여백
여백
신제품
여백
여백
여백
여백
여백
Back to Top