게으른 엔지니어가 사는 법~~~ :: Model-Based Design 을 이용한 임베디드 시스템의 개발(1/4), 2007년 7월

아래 내용은 마이크로소프트웨어 2007년 7월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다.

Model-Based Design을 이용한 임베디드 시스템의 개발

요 약

기존에 개발하던 방법의 문제점과 Model-Based Design을 이용할 경우의 잇점을 보며, MBD를 수행할 수 있는 대표적인 툴인 Simulink에 대한 소개를 한다.

제 1 절 임베디드 소프트웨어

임베디드 소프트웨어 프로그래머라면 어떤 일을 하는 사람일까? 임베디드 소프트웨어에 관련한 프로그래머라고 하면 대부분 운영체제를 특정 하드웨어에 포팅하거나 혹은 특정한 디바이스에 대한 드라이버를 작성하는 프로그래머라고 생각한다. 몇 년간의 마소지의 기사를 보면 이런 포팅이나 드라이버 작성에 대한 내용이 대부분이다. 개발될 제품에 임베딩하기 위한 운영체제의 포팅과 디바이스 드라이버 작성은 가장 먼저 해야 할 작업이지만, 운영체제의 서비스나 디바이스 드라이버를 이용한 응용프로그램을 작성하는 것이 최종 목적이다.

실제로 운영체제의 포팅이나 드라이버의 작성은 하드웨어에 의존적인 부분이기 때문에 하드웨어 메뉴얼을 기초로 하여, 전체 개발 기간중에 한번만 하면 되는 작업이다. 또한 운영체제를 포팅할 경우 대부분 상용 운영체제의 BSP를 활용하게 되므로 전체 코드를 새로 작성하는 경우는 드물다. 하지만 응용 프로그램은 요구사항을 만족 시키도록 프로그램이 작성되어야 하므로, 임베디드 소프트웨어 개발 시간의 대부분을 응용 프로그램을 개발하는데 사용하게 된다. 임베디드 시스템은 점차 복잡하게 되어 가고 있으며, 이런 복잡한 시스템을 이용하여 필요한 임무를 수행하기 위해서 응용 프로그램은 더욱더 복잡하게 만들어 진다.

임베디드 소프트웨어는 우리가 간단하게 들고 다닐 수 있는 MP3플레이어, PMP, 핸드폰 등에도 포함되지만, 자동차, 비행기 등 주변에 움직이는 모든 시스템에 포함되어 있다. 특히나 자동차나 비행기와 같이 제품의 프로토 타입을 만들기가 쉽지 않은 경우에는 임베디드 소프트웨어의 테스트 및 디버깅하기가 쉽지 않다. 이런 경우 운영체제나 드라이버의 작성은 하드웨어가 있어야 하기 때문에 하드웨어의 제작이 어느 정도 완료될때까지 작업하지 못하지만, 응용 프로그램의 경우 하드웨어 없이 테스트가 가능하므로, 실제 하드웨어가 개발되기 전에 응용 프로그램 자체를 가능한 많은 테스트를 해서 실제로 적용했을때 생기는 문제점을 최소화 해야 한다.

본 기사는 임베디드 시스템의 응용 프로그램을 개발할 때 사용하는 기존의 개발 방법과 Model-Based Design(MBD) 개발 방법과의 차이점, 그리고 MBD를 적용하기 위한 툴에 대한 소개를 하고자 한다. 전체 연재 기사는 이런 MBD를 적용해서 개발하는 과정을 보여 주고자 한다.

제 2 절 기존의 개발 방법과 Model-Based Design 개발 방법

그림 1:

임베디드 제어 시스템

임베디드 제어 시스템은 그림 1에 있는 것처럼 제어할 대상체(앞으로 플랜트라고 하겠다)와 제어기로 구성되어 있다. 이런 플랜트는 비행기나 자동차처럼 큰 대상이 될수도 있지만, 자판기나 모터등도 포함될 수 있다. 실제로 임베디드 시스템에 임베딩되는 소프트웨어는, 플랜트를 제어하는 제어기를 C로 구현하여 다운로드해서 플렌트가 요구 사항을 만족하는 행동을 하도록 제어 하는 것이다. 일반적으로 제어기를 C로 직접 구현하기 전에 플랜트를 제어하는 알고리즘을 개발하여, 요구 사항에 명시되어 있는 내용데로 제어가 되는지를 시물레이션하고 이를 구현하는 방법을 많이 사용한다.

2.1 V 모델 개발 프로세스

그림 2:

전형적인 V 모델 개발 프로세스

그림 2는 임베디드 시스템을 개발할때의 전형적인 V 모델 개발 프로세스를 나타내고 있다. V 모델은 IT제품 개발에 사용할 수 있는 모델이자, Waterfall 방식을 확장하여 만들어진 소프트웨어 개발 프로세스이다¹. V 모델을 소프트웨어 개발 프로세스로 접근해 보면 V 모델의 왼쪽 부분은 다음과 같은 개발 단계를 가진다.

요구사항 분석
시스템 레벨에서의 디자인
전체적인 시스템과 아키텍처를 디자인 한다.
서브 시스템 디자인
시스템을 모듈 단위로 나누어 세부적인 내용을 디자인 한다.
실제 구현(코딩)

V 모델의 오른쪽 부분은 검증을 위한 단계를 나타내며, 다음과 같은 검증 단계를 나타낸다.

서브 시스템 통합 및 테스트
시스템 레벨에서의 통합 및 테스트
전체 시스템 통합 및 테스트

2.2 기존의 개발 방법

그림 3:

기존의 개발 방법

그림 3는 일반적으로 임베디드 시스템 제품 개발시에 대부분 직면하고 있는 내용을 표시한 것이다. 요구 사항을 분석해서 그에 따른 프로토 타입을 만들어서 알고리즘이 제대로 되었는지 테스트 하며, 알고리즘의 검증이 끝난 경우 임베딩하기 위한 C 로 코딩을 해서 제품에 다운로드해서 테스트 하게 된다.

요구 사항 분석을 위해서 여러가지 방법을 사용하지만, 결국 마지막에 저장하는 것은 문서 형식으로 저장하거나 혹은 요구 사항을 관리하기 위한 특정한 소프트웨어를 사용하게 된다.²

디자인 단계에서는 임베디드 시스템의 프로토 타입 형태의 하드웨어가 만들어 지며, 이 하드웨어를 동작 시키기 위해서 운영체제의 포팅과 디바이스 드라이버 작성을 하게 된다. 그리고 요구 사항에 맞게 하드웨어를 동작 시키기 위해서 응용 프로그램을 작성하게 된다. 응용 프로그램을 직접 C로 작성하기 전에, 알고리즘을 검증하기 위해서 특정한 소프트웨어를 사용하여 시물레이션을 하게 되고, 검증이 끝난 알고리즘을 C로 작성하게 된다. MP3 플레이어등과 같이 간단한 임베디드 시스템은 알고리즘을 테스트하는 소프트웨어가 따로 있지 않고 바로 C로 코딩하는 경우가 많지만, 수학적 및 공학적 알고리즘등이 들어 가야 하는 임베디드 시스템, 예를 들어 자동 항법 장치 같은 것을 만든다고 생각하면, 목적에 맞는 알고리즘을 먼저 개발/테스트 해야 한다. 이런 경우 물론 C로 전부 만들 수 있지만, 특정 소프트웨어를 이용하는 것이 알고리즘을 검증하는데 훨씬 편리하다. C를 이용해서 수학적 및 공학적인 알고리즘을 검증하기 위해서는 알고리즘 자체보다 알고리즘을 구현하기 위해서 작성해야 할 너무나 많은 기본적인 함수들이 많기 때문에, C로 알고리즘의 검증은 잘 하지 않게 된다.

구현 단계에서는 응용 프로그램을 임베딩해야 하므로 디자인 단계에서 검증된 알고리즘을 C로 직접 코딩하게 된다. 그리고 나서 임베디드 시스템에 다운로드하고 나서 테스트를 하는 과정을 계속 반복하게 된다.

기존의 개발 방법을 좀 더 자세히 보게 되면, 그림 3처 럼 각 단계는 벽이 있는 것처럼 실제로 작업을 하는 팀이 서로 다르며, 각각이 사용하는 툴이 다르므로 서로간에 의사 소통이 문제가 된다. 문서로 만들어진 요구 사항이 각각의 팀으로 넘겨 지고, 이런 요구 사항 문서는 모호하면서 완전하지 않으므로 각 팀은 넘겨 받은 문서를 팀에서 다시 이해해야 하고 각 팀에 맞는 작업을 수행하게 된다. 하지만 전달 받은 문서에 있는 정보가 정확한지 확인하기도 어렵다. 이런식으로 문서를 옮기다 보면 모호하고 불완전한 문서를 바탕으로 전체 작업이 수행되게 된다. 때문에 문제점을 개발의 앞 단계에서 찾기가 힘들고 거의 마지막 단계에서나 찾게 된다. 또한 이러한 문제점이 발견되었을때 어느 부분이 문제가 있는지 찾기 위해서 각 단계를 다시 거슬러 올라 가서 어디에 문제가 있는지 찾아야 한다. 만약 요구 사항에 있는 내용이 잘못 되었으면, 전체를 다시 만들어야 하는 경우가 생길 수도 있다. 이미 널리 알려져 있듯이 문제점의 발견은 뒤에서 발견될 수록 수정하기 위해서 들여야 하는 시간과 비용이 크게 늘어 난다.

그림 4:

기존 방법을 사용한 V 개발 프로세스

기존의 개발 방법을 요약해서 말하자면 문서 중심의 개발 방법이라고 할 수 있다. 이를 V 모델 개발 프로세스에 접목하게 되면 그림 4와 같이 문제점이 생길수 있는 부분들이 표시되며, 이런 문제점들 때문에 정해진 시간내에 제품을 출시하기 어렵게 된다.

일반적으로 시스템을 동작시키는 응용 프로그램의 알고리즘이 복잡해 질 수록 프로그램 코딩보다는 알고리즘 개발에 더 많은 시간을 투자해야 하며, 알고리즘을 검증하고 이를 다시 코딩해야 하는 이중 작업을 하게 된다. 즉 알고리즘을 검증하기 위해서 사용하는 툴이 따로 있고, 검증된 알고리즘을 다시 C로 옮겨야 하는 일을 해야 하는 것이다.

응용 프로그램을 작성하는 프로그래머는 C로 작성된 코드가 문제 없이 실행이 되는지 테스트 하는 것 뿐만 아니라, 기존에 검증한 알고리즘과 같은 결과를 주는지를 여러 가지 방법으로 테스트 해야 한다. 때문에 응용 프로그램을 작성하는 프로그래머는 운영 체제를 포팅하는 작업이나 디바이스 드라이버를 작성할때 생기는 문제점과는 다른 어려움을 겪게 된다.

실제로 복잡한 알고리즘을 작성해야 하는 응용 프로그래머는 첫 번째로 해결해야 하는 일이 바로 정확한 알고리즘을 작성하는 것이다. 즉 코딩보다는 알고리즘 개발에 더 많은 비중을 둬야 한다. 하지만 국내에서 개발하는 사례들을 보면 실제 알고리즘 개발보다 임베딩 시키기 위해서 C 코드 작성에 더 많은 시간을 쓰고 있는 실정이다.

또 다른 문제점을 들자면, 기존의 개발 방법은 알고리즘을 검증하고자 할때 C로 코딩을 해서 실행해봐야 하기 때문에 프로토타입 형태로라도 하드웨어가 있어야 하며, 포팅된 OS와 디바이스 드라이버가 있어야 한다. 알고리즘의 검증이 하드웨어가 준비될 때까지 지연된다. 하드웨어를 개발하는 팀과 알고리즘을 개발하는 팀은 다른 팀이므로 평행하게 진행될 수 있는 작업이 서로간에 연계성이 생기므로, 어느 한쪽이라도 문제가 생기면 전체적인 개발 시간과 비용을 더 많이 부담해야 한다.

이런 기존 방법에 대한 문제점을 해소하고자 나온 방법이 Model-Based Design이다.

2.3 Model-Based Design이란?

그림 5:

MBD를 이용한 V 개발 프로세스

Model-Based Design(MBD)을 요약해서 설명하자면, 하나의 툴에서 알고리즘을 구현한 모델을 만들어서 시물레이션 및 테스트 하고, 그 모델로부터 자동 코드 생성 기능을 이용해서 직접 C로 다시 코딩하는 작업을 하지 않는 방법이다. 이를 V 모델 개발 프로세스에 적용하면 그림 5와 같이 V의 왼쪽 부분에서 최대한 시물레이션 및 테스트를 하며, 검증된 모델로부터 자동 코드 생성하여서 임베디드 시스템에 다운로드해서 실제 테스트를 하는 것이다. 때문에 검증된 알고리즘을 직접 다시 C로 프로그램을 작성해서 생기는 문제점을 원칙적으로 없앨 수 있다.

그림 5를 보게 되면 모델이 진화하는 개념을 볼 수 있는데, 이는 처음부터 간단한 모델로 시작해서 점차적으로 모델을 자세하게 만들어서 사용한다는 것이다. 각 팀간에 의사 소통은 문서뿐만 아니라 모델을 이용하여 하게 되고, 받은 모델이 제대로 동작하는지 시물레이션을 통하여 확인할 수 있다. 즉, 일단 모델이 만들어 지면 시물레이션을 할 수 있으므로, 알고리즘 초기 단계부터 항상 테스트와 검증 작업을 할 수 있다. V 모델로 보면, 테스트를 담당하고 있는 왼쪽 단계의 작업들을 가능한한 오른쪽 단계인 알고리즘 개발 단계에서 문제점을 찾는 것이다. 이렇게 함으로써 개발 초기 단계에 문제점을 찾을 수 있으므로 개발 시간과 비용을 현저하게 줄일 수 있다.

외국의 경우는 이미 시물레이션의 중요성을 인식하고 있어서 아예 안전과 관련된 임베디드 시스템을 만들때 따라야 하는 규약을 만들어서 시물레이션을 강제 사항으로 하고 있다. 이런 예로서 IEC 61508³나 DO-178B⁴등이 있다. 이들에 대한 내용은 다음에 기회가 있으면 자세한 내용을 설명하도록 하겠다.

그림 6:

자동 생성된 코드와 다른 부분과의 통합

그러면 MBD를 사용하게 되면 코딩이라는 것을 전혀 안해도 되는 걸까? 물론 코딩의 과정이 필요한 경우가 있다. 그림 6에 나와 있는 것처럼, 툴을 이용해서 코드를 자동 생성할 수 있는 부분은 중요한 알고리즘 부분이다. 운영 체제의 포팅에도 그렇고, 디바이스 드라이버 작성시에도 코딩은 필요한 경우이다. 또한 자동 코드 생성 기능으로 작성된 코드를 기존의 코드와 같이 사용할 수 있도록 인터페이스 부분도 물론 직접 코드를 작성해야 한다. MBD의 장점은 알고리즘 부분을 시물레이션하고 테스트한 그대로 코드를 생성해 내서 사용한다는 점이다. 이 부분에 대한 내용은 다른 기사에서 좀 더 자세하게 설명하겠다.

제 3 절 MBD를 수행할 수 있는 툴

널리 알려져 있는 MBD를 구현할 수 있는 툴은 Simulink⁵, SCADE⁶, LabVIEW⁷가 있다. 각 툴은 장단점을 가지고 있으나, 여기서는 필자가 주로 사용하는 툴인 Simulink를 이용하여 MBD로 개발하는 과정을 보여 주도록 하겠다.

3.1 MATLAB, Simulink

Simulink는 The MathWorks의 소프트웨어로서, 동역학 시스템이나 통신 시스템을 모델링, 시물레이션, 분석할 수 있는 소프트웨어이다. 모델링시에는 블럭 다이어그램을 그리듯이 블럭을 이용하여 모델링을 하며, 동역학 시스템을 해석할때 필요한 ODE solver⁸를 기본으로 제공하는 프로그램이다. Simulink는 단독으로 실행이 가능하지 않고, MATLAB(MATrix LABoratory)이라는 프로그램이 실행된 상태에서 실행이 가능하다.

그림 7:

MATLAB 데스크탑 환경

MATLAB⁹은 그림 7에 서 보이는 것처럼 공학적 문제를 해결하기 위한 플랫폼으로 이미 업계 표준으로 자리 잡고 있다. MATLAB은 제품 이름이 말하듯이 모든 수학적 계산을 행렬 연산으로 계산한다. 데이타 분석과 알고리즘 개발에 필요한 수학적 함수, 데이타를 그래프로 보여 주기 위한 2D/3D 그리기 함수, GUI(Graphic User Interface)를 위한 함수, 다른 프로그래밍 언어, 특히나 C와의 연동을 할 수 있는 API 등을 제공하여 테크니컬 컴퓨팅을 할 수있는 모든 환경을 제공한다¹⁰. 게다가 에디터, 프로파일러, 디버거등 프로그래밍을 할때 필요한 모든 툴을 제공하고 있으므로, 테크니컬 컴퓨팅을 위해서 전세계적으로 가장 많이 쓰고 있는 프로그램이다.

그림 8:

Simulink 개발 예

MATLAB의 경우 프로그래밍 언어로 사용되며, 함수를 기본으로 해서 코딩을 하게 된다. Simulink의 경우 이런 코딩이 아니고 그림 8와 같이 블럭을 연결해서 전체 시스템을 모델링 하기 때문에 코딩에 의한 실수가 없으며, 체크하고 싶은 값은 그림 8에 보이는 것처럼 스코프를 이용하거나, 혹은 MATLAB으로 보내서 강력한 2D/3D 그래픽 기능으로 시각화 할 수 있다. 이런 부분에 대해서는 다음 연재 기사에서 좀 더 자세히 알아 보도록 하자.

3.2 자동 코드 생성 기능

MBD를 설명하면서 자동 코드 생성 기능을 이용한다고 했는데, Simulink 자체는 자동 코드 생성 기능을 가지고 있지 않다. 하지만 Simulink 모델로부터 자동 코드를 생성해 내는 제품이 따로 있다. 유명한 제품으로는 Simulink와 같은 회사에서 만든 Real-Timw Workshop Embedded Coder와 TargetLink¹¹가 있다. 이런 제품들은 코드를 생성할 때 옵션을 가지고 있어서 생성되는 코드를 어느 정도 조정할 수 있게 해준다. 뒤의 연재에서 Real-Time Workshop Embedded Coder에 대해서 좀 더 자세하게 알아 보도록 하겠다.

다음 연재 기사는 그림 1와 같은 전형적인 임베디드 시스템에서 제어기를 설계하기전에 플랜트 부분을 어떻게 모델링하고 설계하는지를 Simulink로 모델링하고, 모델링한 플랜트를 3D로 시각화하는 방법을 보도록 하겠다.