게으른 엔지니어가 사는 법~~~

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

제 1 절  Overview

Green IT는 위키피디아의 정의에 의하면 Green Computing과 같은 개념으로 본다. Green Computing은 컴퓨터 자원을 효율적으로 활용하여, 유해 물질의 사용 최소화나 에너지 사용 효율의 극대화, 자원의 재활용, 친환경 에너지 개발을 하는 것이다. 본 편에서는 임베디드 소프트웨어가 이러한 Green IT 개념에 어떻게 적용되는지를 친환경 차, 친환경 대중 교통 수단인 바이모달 트램, 다양한 자연 에너지(예를 들어 풍력) 발전소에 대해서 그 기본 개념과 개발 방식 및 소프트웨어의 역할을 보도록 한다.

제 2 절  친환경 그린카

2009년 5월19일 버락 오바마 미국 대통령은 지구 온난화에 큰 영향을 주는 배기가스 배출 기준을 대폭 강화했으며, 자동차 연비를 높여서 석유의 의존도를 줄이고자 하는 규제안을 발표했다.

규제안에 따르면 배기가스 배출량을 30% 줄이고, 현재 적용되는 갤런당 평균 25마일의 연비를 갤런당 평균 35마일로 높여야 하는 기준을 제시했으며, 차종별로 2012년부터 단계적으로 2016년까지 적용되며, 최종적으로 승용차는 갤런당 42마일, 경트럭과 지프형 차량 및 밴은 26마일로 연비를 높여야 한다.

또한 EU(유럽연합)에서도 비슷한 형태의 규제 법안을 내놓았으며, 법안을 만족 시키지 못할 경우 과중한 벌금을 내도록 규제하고 있다.

이런 규제들을 만족시키기 위한 다양한 시도가 있었으며, 그중 대표적으로 친환경 그린카 라고 부를 수 있는 다음과 같은 종류가 있다.¹.

클린 디젤 자동차

현재 유럽쪽에서 구현되고 있으며, 가솔린 차량보다 효율이 높은 디젤 차량의 장점을 살려 기존 문제점이었던 미세 먼지, 질소산화물 등의 배출 가스를 현저히 줄인 자동차

하이브리드 자동차

구동 시 내연 기관과 전기 모터를 같이 이용하는 자동차, 주행의 상태에 따라 두 동력 장치를 적절히 연동시켜 연비를 향상시킴

플러그인 하이브리드 자동차

내연기관과 전기모터를 같이 이용하지만, 가정용 전기로 충전할 수 있는 배터리를 장착하여 단거리 주행시 전기 모터로만 구동하는 자동차

수소 연료전지 자동차

탱크에 저장된 수소를 산소와 반응시켜 생산한 전기로 전기모터를 작동시키는 자동차

전기 자동차

순수하게 배터리의 힘으로만 움직이는 자동차

단순히 연비를 만족시키기 위해서는 클린 디젤 엔진을 활용하면 가능할 수 있지만, 온실효과를 일으키는 CO₂의 배출 기준을 만족시키는 것은 현 기술로는 거의 불가능하다. 연비와 배출가스의 기준을 만족시키는 가장 좋은 방법은 전기 자동차이다. 하지만, 아직까지 전기 자동차는 몇 가지 난관을 가지고 있으며, 현재 기술로는 토요타의 프리우스와 같은 가솔린 엔진(혹은 디젤 엔진)과 전기 모터가 결합된 형태인 하이브리드 카(Hybird Electric Vehicle, HEV)가 각광을 받고 있다.

2.1  하이브리드 카

세계 최초로 대량 생산된 하이브리드 카인 토요타의 프리우스는 1997년 일본에서 처음 발매되었으며, 2000년에 미국에 발매된 이후로 전세계적으로 2009년 초반까지 120만대 이상을 판매하였다. 환경 규제 법안을 만족 시키기 위해서는 이런 하이브리드 카에대한 연구가 지속적으로 수행될것이며, 국내 업체인 현대/기아에서도 이미 ‘연비 개선 로드맵’에 따라 2015년에 미 연방정부의 규제를 만족시킬 수 있는 갤런당 35마일로 높이기로 내부 목표를 세웠다.

---

---

지난 4월에 있었던 모터쇼에서 현대/기아는 이미 아반떼 하이브리드 LPI 및 포르테 하이브리드 LPI를 소개했으며, 7월과 8월에 각각 출시할 예정이다. 또한 내년에는 쏘나타 하이브리드를 미국 시장에 투입시킬 예정이다. 아직까지는 외국계 회사의 하이브리드 카에 비해서는 연비가 떨어지지만 점차 높여서 나가서 ‘연비 개선 로드맵’에 맞추어 개발할 예정이다².

이런 하이브리드 카의 원리를 간단하게 살펴 보고, 소프트웨어의 역할을 확인해 보자.

2.1.1  하이브리드 카의 작동 원리

하이브리드 카의 경우 가솔린(혹은 디젤) 엔진과 전기 모터를 활용하여, 연료의 효율을 높이고 화석 연료를 최소화해서 사용하므로 배출 가스를 대폭 줄일 수 있다. 일반적인 상태에서는 가솔린 엔진이 작동하며, 특정 모드에서는 가솔린 엔진과 전기 엔진이 모두 동작하게 된다.

구성

---

---

그림 2는 토요타의 프리우스의 Hybrid Synergy Drive 시스템의 구성을 간략하게 표현한 것으로 일반적인 가솔린(혹은 디젤) 엔진과 같은 구성을 볼 수 있으며, 변형된 동력 전달 장치와 전기 모터, 발전기 및 대용량의 배터리등을 볼 수 있다. 또한 동력 분산 장치(Power Splitter)의 경우 전기적 파워와 기계적 파워를 변경 가능하도록 하는 장치이다.

구성 장치는 현재 운전이 어떤 모드로 되는지에 따라서 동작하는 것이 달라지게 된다. 여기서는 총 5가지로 모드를 나누어서 생각해 보자.

출발 모드
출발을 할 경우는 가솔린 엔진을 이용하여 차를 움직이게 된다. 이 시점에서는 전기 모터를 사용하지 않고, 가솔린 엔진만을 사용한다.

주행 모드

---

---

주행 모드에서는 가솔린 엔진으로부터의 동력을 전달 받아서 동력 분산 장치가 실제 차를 구동 시키면서 필요한 경우 발전기를 통해서 배터리를 충전할 수 있다. 그림 3처럼 가솔린 엔진이 동력 분산 장치를 통해서 실제 차를 구동 시키고 배터리의 충전이 필요한 경우는 동력을 발전기에 전달하여 배터리의 충전까지 하게 된다.

가속 모드

---

---

급격한 가속을 하거나 혹은 더 많은 동력을 필요로 하는 경우, 가솔린 엔진과 함께 전기 모터도 동력 분산 장치로 동력을 전해줘서 필요한 만큼의 동력을 얻게 된다. 그림 4를 보면 가솔린 엔진과 전기 모터가 함께 차축에 동력을 전달하는 것을 알 수 있다.

브레이크 모드

---

---

차량 운행중에 브레이크를 밟는 동작은 현재 동작중인 엔진으로부터의 동력을 끊고, 바퀴를 멈추기 위해서 실제로 에너지를 버려야 하며, 이러한 것들이 바로 마찰에너지등로 사라지게 된다. 그림 5처 럼 하이브리드 카는 이런 소멸되는 에너지를 다시 동력 분산 장치를 통해서 발전기를 통해서 배터리를 충전하는 방식으로 에너지를 어느 정도 재사용할 수 있게 해준다. 이렇게 충전된 배터리는 가속 모드에서 필요한 동력을 위해서 전기 모터를 동작 시킬 수 있게 된다.

정지 모드
정지 모드에서는 에너지를 소비하지 않기 위해서, 가솔린 엔진과 전기 모터 모두 자동으로 동작을 멈추게 된다. 이 때문에 일반적인 자동차 보다는 정지 이후에 출발시 약간 늦게 출발한다는 느낌을 받을 수 있다.

2.1.2  하이브리드 시스템을 위한 시물레이션 및 구현

이상과 같이 간단하게 설명된 원리 구현을 위해서는 하드웨어(가솔린 엔진, 전기 모터, 등등)와 함께 소프트웨어가 필요하다. 특정 시점에 맞춰서 동력 전달을 위한 결정도 해야 하며, 언제 전기 모터를 가솔린 엔진과 함께 사용하고, 가솔린 엔진만으로 구동하거나, 혹은 배터리를 주행중에는 언제 충전할 것인지등은 모두 소프트웨어적으로 결정되어야 한다.

전체 시스템 구성

---

---

그림 6는 그림으로만 설명했던 하드웨어적인 부분들을 전체적으로 배열하여 놓은 Simulink 모델이다. Simulink는 그림 6와 같이 블록을 연결하여 알고리즘을 구현하며, 하드웨어의 동작까지도 소프트웨어로 구현 가능하기 때문에 하드웨어의 제작전에 알고리즘이 적합한 것인지등을 테스트 하거나 혹은 요구 사항(여기서는 규제안에 맞는 연비와 효율 등)이 구현 가능한 것인지등을 미리 검증할 수 있기 때문에 다양한 엔지니어링 분야에서 사용되고 있다.

또한 시물레이션을 통해서 검증된 알고리즘에 대해서도 C 코드를 생성해 낼 수 있기 때문에, 모델의 재활용이며, 알고리즘을 검증한 후 C 코드를 직접 생성해 내는 것보다 훨씬 효율적임을 알 수 있다.

이런 시물레이션을 통한 알고리즘의 검증과 C 코드 생성을 활용하는 것은 제품 개발 시간의 단축 및 제품의 신뢰성에 큰 영향을 줄 수 있다. 이런 방식의 개발 방법을 Model-Based Design이라고 한다. 더 자세한 내용은 2007년 7월부터 10월까지 마소지에 연재된 기사를 참조하기 바란다.

컴포넌트 별 모델링
그림 6와 같이 전체 시스템을 분류별로 잘 나누어서 모델링을 한 이후에 각 컴포넌트를 좀더 실제 상황과 맞게 모델링을 하게 된다. 여기서는 예를 들어 하드웨어 부분과 소프트웨어 부분을 어떤 식으로 모델링되어 있는지 보도록 하자.

DC-DC Converter 모듈

그림 6에서 DC-DC Converter 모듈을 좀 더 자세하게 알아 보자. DC-DC Converter 모듈은 배터리에서의 나온 전압을 증폭하는 모듈이다. 그림 7를 보면 실제 회로도를 보는 것과 같이 모델링한 것을 알 수 있다. 이런 하드웨어적인 부분들을 자세하게 포함하면 할 수록 시물레이션에 걸리는 시간은 많이 걸린다. 그림 7와 같이 실제 하드웨어를 시물레이션하기 위해서는 수식을 작성하거나 해서 만들어야 하지만, 그림 7와 같이 실제 하드웨어의 구성품들을 연결하여 모델링을 하도록 도와 주는 제품들도 있다. 여기서 보여 지는 제품은 Simscape 이라고 하는 제품을 활용하여 만든 것이다.

---

그림 7: Simscape을 이용한 DC-DC Converter 모듈 모델링

---

테스트 케이스

시물레이션을 하게 되면, 당연히 테스트 케이스가 있어서 알고리즘을 테스트 하게 된다. 그림 6에서 ‘Driver Inputs’ 부분이 전체 알고리즘을 테스트 하는 부분이며, 내용을 보면 그림 8와 같다. 그림 8에서 빨간색 선으로 된 인풋은 가솔린 엔진의 페달을 어느 정도 밟았는지 표시하는 것이며, 파란색 선은 브레이크를 어느 정도 밟았는지 표시하는 것이다.

---

그림 8: 알고리즘을 테스트 하기 위한 테스트 케이스

---

운전 모드에 따른 모델링

각 운전 모드를 스테이트로 보고 스테이트 머신을 모델링하면 시물레이션을 해 볼 수 있다. 스테이트 머신의 경우 Stateflow 라는 소프트웨어를 활용하면 각 스테이트의 변경을 에니메이션으로 볼 수도 있으며(이는 디버깅시 상당히 편리하다), 알고리즘이 완성되면 Stateflow Coder라는 제품으로 코드를 생성할 수 있다.

그림 9는 Stateflow로 운전 모드를 스테이트 머신 형태로 모델링한 것이며, 파란색으로 보이는 박스가 현재 동작중인 스테이트를 나타낸다. 조건이나 이벤트에 의해서 스테이트간의 움직임을 볼 수 있는 이런 기능은 직접 코딩을 해서 디버거를 이용하는 방법 보다는 훨씬 쉽게 알고리즘을 파악할 수 있다. Stateflow에 관한 내용은 마소지 2008년 1월부터 4월까지 필자가 연재한 내용을 보면 어느 정도 정보를 얻을 수 있다.

---

그림 9: Stateflow로 만든 모드 로직

---

2.1.3  임베디드 소프트웨어와 활용

이상과 같이 하이브리드 카의 기본적인 작동 원리와 시물레이션을 위한 소프트웨어의 역할을 간단하게 보았다. 앞에서 보여준 것과 같이 간단한 모델에서 점차 각각의 모듈을 더욱 세부적으로 실제 시스템과 비슷하게 모델링하여 하드웨어의 제작과 별개로 알고리즘을 테스트 할 수 있다.

시물레이션을 한 후에 알고리즘을 다시 직접 C 코드를 작성하게 되면, 인력과 시간의 소모가 생길뿐이므로 가능한 자동 생성 코드를 사용해서 C 코드를 생성하여 제품 개발 시간 단축과 임베디드 소프트웨어의 신뢰도를 높일 수 있다. 이런 개발 방법을 Model-Based Design(MBD)라고 한다.

실제로 GM에서는 Simulink, Stateflow와 같은 모델링툴과 모델로부터의 코드 생성툴인 Real-Time Workshop Embedded Coder과 Stateflow Coder를 활용하여 하이브리드 카를 개발하였다³.

2.2  전기 자동차

전기 자동차는 기본적으로 전기 충전을 해서 배터리와 전기 모터만으로 차를 구동시키는 방법이다. 이 방법의 문제는 전기 충전을 위해서 주유소와 같이 전기 충전소가 필요하며, 충전시 걸리는 시간등이 문제가 되며, 또한 배터리의 효율성도 문제가 된다.

이런 전기 자동차에서 사용되는 배터리는 주로 연료 전지(Fuel Cell)를 이용한다. 전기 자동차에도 다양한 구성 요소가 있지만, 제일 중요한 요소가 바로 연료 전지이므로 연료 전지의 기본 원리와 함께 소프트웨어의 역할을 살펴 보자.

2.2.1  연료 전지 정의 및 구조

일반적인 내연 기관(예를 들어 가솔린 엔진)과 연료 전지의 가장 큰 차이점은 다음과 같다.

일반적인 내연 기관
가솔린 + 산소 →에너지 + 물 + CO₂ + CO

연료 전지
수소 + 산소 →에너지 + 물

연료 전지는 기본적으로 환경 친화적인 에너지 발생 장치임을 알 수 있다. 전기 에너지를 사용할 수 있도록 하는 대표적인 제품은 배터리인데, 연료 전지의 경우 그림 10에서 보는것처럼 외부에서 수소와 산소를 인풋으로 받아서 내부의 화학적 변화로 에너지와 물을 생성한다. 배터리의 경우 내부에 축적된 에너지를 사용하기 때문에 클로즈드 시스템이라고 하며, 연료 전지의 경우 오픈 시스템으로 본다.

---

---

일반적으로 한 개의 연료 전지는 자체적으로 0.7 볼트의 전압을 발생시킬 수 있기 때문에 실제로 사용하기 위해서는 그림 11와 같이 스택처럼 쌓아서 사용해야 한다.

---

---

2.2.2  연료 전지 시스템 시물레이션 및 구현

연료 전지 Stack의 경우 외부에서 수소와 산소가 제공되어야 하므로 그림 12처럼 수소의 양을 조절하여 생성되는 에너지인 전기의 세기를 조절하게 된다. 이런 수소의 양을 조절하기 위해서 제어 보드가 있어야 하며, 임베디드 소프트웨어가 필요하게 된다.

---

---

연료 전지 시스템 플랜트 모델링
그림 12에서 연료 전지 시스템의 플랜트 부분의 모델은 그림 13와 같이 Simulink 환경에서 사용 가능한 블록 형태로 제공되는 ThermoLib/FClib라는 제품이다. 이 제품은 Simulink 환경에서 연료 전지 시스템에서 플랜트 부분을 모델링하는 데 필요한 모든 블록을 제공한다.

---

---

Power Converter 모델링
그림 12에서 Power Converter 부분은 Simulink 환경에서 동작하며, 전력이나 발전에 관한 다양한 블록을 제공하는 SimPowerSystems를 이용하여 그림 14와 같이 모델링 할 수 있다.

---

---

전력 및 물에 대한 제어
제 어하고자 하는 대상인 플랜트에 대한 모델링을 하였으므로 이제 이 들을 제어할 부분을 고려해 보자. 간단하게 생각하면 전력에 대한 제어와 생성되는 물에 대한 제어가 필요하다. 전력에 대한 제어는 스위치를 활용할 수 있으며, 물에 대한 제어는 밸브를 이용해서 제어가 가능하다. 이러한 제어의 경우에도 특정한 조건이나 이벤트에 따라 동작해야 하므로, 그림 15와 같은 Stateflow로 모델링을 한다.

---

---

2.2.3  임베디드 소프트웨어와 연료 전지의 활용

이상과 같이 임베디드 소프트웨어를 작성하기 전에 하드웨어를 직접 만들기 전에 시스템을 PC상에서 구성하여 시물레이션을 할 수 있으며, 그에 대한 코드를 생성할 수 있다. 시스템상에서 코드를 생성할 수 있는 것은 다양한 장점이 있는데, 그 중 가장 큰 장점은 앞에서 설명한 알고리즘을 새로 C 코드를 작성할 필요가 없다는 점이다. 또 하나의 장점은 HIL(Hardware-In-the Loop) 시스템 구성이나 RCP(Rapid Control Prototype 혹은 줄여서 RP) 시스템으로 시스템을 테스트할 수 있다.

연료 전지의 활용은 차량에서만 사용할 수 있는 것이 아니고, 현재 배터리나 전기로 동작하는 제품에는 모두 연료 전지를 사용할 수 있다. 자전거, 휴대폰, 노트북, 청소기, 아파트 난방, 휴대용 연료전지,무인 항공기, 항공기, 인공위성, 군용 장비등 다양한 분야에 활용할 수 있다.

Ford Motor사와 Pi Technology사는 함께 MBD를 활용하여 연료전지 자동차를 이미 개발했으며, 다양한 성공 사례가 있다⁴.

제 3 절  철도 분야

자동차 분야에서 활발하게 친환경에 대한 활동이 있다는 얘기는 역으로 말하면 지금까지 친환경에 대해서는 많이 부족했다는 점이다. 개인용 차량이나 버스등에 대해서 개발이 활발한데, 사람 수송에 가장 큰 영향을 주는 철도에서도 이런 친환경에 대한 연구가 이루어 지고 있다. 대표적인 것이 바로 바이모달 트램이다.

3.1  바이모달 트램(Bimodal Tram)

일반적으로 철도는 정해진 궤도(철로)를 따라 달리는 교통 수단이지만, 바이모달 트램은 이름에서 뜻하는 것처럼 정해진 궤도나 혹은 일반 도로에서도 달리는 새로운 교통수단이다. 수도권이나 지방 대도시에서 볼 수 있는 지하철의 장점과 유연한 운행과 쉬운 접근성이 있는 버스의 장점을 합쳔 차세대 교통 수단으로 볼 수 있다.

전체 구성
바 이모달 트램의 경우 동력원으로 CNG-하이브리드와 연료 전지 등을 추진 시스템으로 사용하는 하므로 친환경적이라고 볼 수 있다. 또한 운전자의 조작 없이 시스템이 동작하며, 모든 바퀴의 방향을 조작할 수 있는 전체 차륜 조향 시스템을 사용하므로 정거장에 정차하는 위치를 정밀하게 제어 할 수 있어서 지하철과 같이 정밀한 정차가 가능하다. 그림 16⁵를 보면 바이모달 트램의 구성을 볼 수 있으며, 앞에서 이미 설명했던 다양한 하드웨어가 사용됨을 알 수 있다.

---

---

그림 16는 하드웨어적인 구성과 형태에 따른 바이모달 트램 시스템의 구성이며, 그림 17은 실제 시스템 개발시 소프트웨어 측면에서 본 구성이다. 이와 같은 구성을 보면 결국 다른 시스템에서 봤던 것과 같이 소프트웨어를 이용하여 시물레이션 하고 그 모델로부터 코드 생성해서 임베딩할 수 있는 MBD를 활용할 수 있음을 알 수 있다.

---

---

제 4 절  자연 에너지 발전소

친환경 에너지를 생각하면 발전소를 빠트릴 수가 없다. 화석 연료를 사용하는 발전소와 달리 자연 환경을 사용하는 발전소를 살펴보자.

4.1  풍력 발전소

현실적으로 가장 많이 사용되는 발전소는 풍력 발전이다. 다른 에너지원은 여러 가지 문제가 있어서 아직까지는 풍력이 가장 각광을 받고 있으며, 친환경적이다. 간단히 풍력 발전소의 원리를 보고, 소프트웨어가 왜 필요한지 알아 보자.

4.1.1  동작 원리

풍력 발전소는 다수의 풍력 터빈을 설치하여 기계적인 동력이나 전기를 발생시켜서 사용하는 시스템이다. 풍력 터빈은 바람의 힘인 운동 에너지를 기계적인 동력으로 변환하며, 컨버터 등을 사용해서 다시 전기로 변경시킬 수 있다. 그림 18⁶를 보면 풍력 터빈의 구조를 각 컴포넌트별로 표현한 것이다. 하드웨어가 복잡해질 수록 제어를 하기 위한 임베디드 소프트웨어의 복잡성은 당연한 사실이다.

---

---

그림 19는 풍력 터빈에 제어가 필요한 부분을 표시한 것이다. 이런 제어를 하기 위해서는 실제 하드웨어서 직접 할 수도 있지만, 시물레이션이 역시 필요한 것이다.

---

---

풍력 터빈에서 중요한 것은 바람에 의해서 동작하는 블레이드(Blade)가 항상 정상 속도로 회전하도록 만드는 것이다. 블레이드가 너무 빨리 회전하면 풍력 터빈에 손상을 가져 올 수 있으며, 너무 늦게 회전하면 필요한 만큼의 기계적 동력을 얻지 못한다. 블레이드가 일정한 속도로 회전하는 것은 블레이드의 핏치(Pitch)를 바꿈으로서 얻을 수 있다. 매스웍스 제품을 활용할 경우 풍력 발전에 필요한 모든 내용을 모델링, 시물레이션, 그리고 코드 생성까지 가능하며⁷, 여기서 중요한 블레이드 핏치 제어를 위해서 블레이드와 그 연결 부위를 모델링하는 것을 살펴 보자. 전체 시스템의 모델링은 http://www.mathworks.com/programs/wind_turbine_webinars/에서 볼 수 있다.

블레이드 및 연결 부위
블레이드 핏치를 제어 하기 위해서는 그림 20에서 모델링한 하드웨어를 시물레이션을 하기 위해서 구성해야 한다. 이렇게 모델링으로 구성하고 나면 마찬가지로 제어기를 구성하여 시물레이션을 해볼 수 있다. 그림 20에서 오른쪽에 있는 모델은 SimMechanics라는 제품을 활용한 것이다. 3D로 된 강체의 모델링을 수식을 세우지 않고 쉽게 모델링 할 수 있게 도와 주며, Simulink 환경에서 동작하기 때문에 제어기 설계등을 하나의 환경에서 쉽게 연결해서 할 수 있다.

---

---

4.2  GreenIT, 시물레이션, 그리고 임베디드 소프트웨어

지금까지 몇 가지 예를 들어 GreenIT에서 실제로 소프트웨어가 어떤 역할을 하는지 살펴 보았다. Green IT의 특징은 시스템이 점점 지능적이 되어 가면서 소프트웨어의 역할은 점점 더 커지고 있는 것이며, 하드웨어와 함께 동작하는 것을 알 수 있다. 보드에 임베딩되는 특성 때문에 항상 하드웨어가 제작되기 전에는 알고리즘을 확인하기 힘들기 때문에 시물레이션의 중요성이 커지면서, 소프트웨어로 하드웨어의 일부를 대체해서 테스트해 볼 수 있는 RCP와 HIL의 중요성이 커지고 있다.

또한 소프트웨어의 디펙트나 알고리즘의 문제점을 초기에 발견해서 고칠수록 비용과 시간이 절감되기 때문에 Model-Based Design과 같은 모델링 기법들을 사용해서 초기에 검증하고 그 모델들을 재사용하여 코드 생성까지 하는 것도 일종의 리소스를 재활용하는 것이다.

Notes

¹산업 연구원

²http://www.theautochannel.com/news/2009/03/11/453029.html

³http://www.mathworks.co.kr/company/user_stories/userstory19893.html?by=company

⁴http://www.mathworks.com/company/user_stories/userstory13369.html?by=company

⁵http://www.hydrail.org/docs/present3/chang.pdf

⁶http://www1.eere.energy.gov/windandhydro/wind_how.html

⁷http://www.mathworks.com/programs/wind_turbine_webinars/

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

아래 내용은 마이크로소프트웨어 2008년 4월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다. 잡지 기사를 pdf로 보실려면 iMaso 홈페이지에 가셔서 구매하실 수 있습니다.

Stateflow를 활용한 실전 예제

요 약

Embedded MATLAB을 소개하며, 지금까지 배운 State machine, flow graph등을 바탕으로 실제 예제를 만들어 보자. 복잡한 내용은 하기가 힘들겠지만, 간단한 내용을 가지고 Stateflow의 기능을 활용해 보자.

제 1 절  온도에 따른 팬 제어

이제 Stateflow에서 제공하는 대부분의 기능을 알았으니, 이런 기능들을 활용해서 하나의 예제를 모델링해보자.

1.1  두 개의 팬을 동작시키기 위한 요구 사항

두 개의 팬으로 케이스 내부의 온도를 유지하는 시스템이 있다. 여기서 온도에 따라서 한 개의 팬이 동작하던가 아니면 두 개의 팬이 동작 된다. 그리고 팬을 동작 시킬것인지에 대한 전체적인 On/Off 스위치가 있다. 자세한 요구 사항은 아래와 같다.

1. Stateflow로 들어 오는 인풋은 케이스 내부의 온도 이다.
2. Stateflow에 팬 전체를 On/Off 하는 이벤트가 들어 온다.
3. 제어는 1초 단위로 한다.
4. 온도가 50도 이상일 경우 전체 스위치가 On 상태이면 팬1을 On 시킨다.
5. 온도가 65도 이상일 경우 전체 스위치가 On 상태이면 팬1과 팬2를 On 시킨다.
6. 팬의 On/Off 여부는 Stateflow의 아웃풋 변수에 0, 1, 2로 표시한다. 즉 0이면 두 개의 팬 모두 Off 상태이다. 1이면 팬1이 On 상태이다. 2이면 두 개의 팬 모두 On 상태이다.

제 2 절  요구 사항에 따른 State Machine

먼저 요구 사항을 분석했을때 첫번째로 고려해야 할 사항이 팬의 전체적인 동작을 On/Off 시킬 수 있어야 한다. 이를 위해서 {PowerOn}, {PowerOff}두개의큰 state를 가진다. 두 state 사이의 transition은 SWITCH라는 이벤트에 의해서 동작하며, SWITCH 이벤트는 Stateflow에 인풋으로 들어 오며, either edge로 이벤트가 전달된다. 그림 1에서와 같이 Stateflow에서 모델링할 수 있으며, 그림 2와 같은 윈도우에서 SWITCH 이벤트에 대해서 셋팅할 수 있다. 여기서 trigger를 either로 했으므로 rising edge와 falling edge에서 이벤트가 발생하게 된다.

---

---

---

---

2.1  팬1과 팬2의 제어를 위한 State

팬1과 팬2의 제어를 위한 state의 경우 서로 독립적으로 On/Off가 가능해야 한다. 따라서 팬1과 팬2의 경우 parallel state로 모델링하면 된다. 그림 3와 같이 parallel state를 만들면 된다.

---

---

팬1과 팬2 각각의 state에는 팬의 On/Off가 되는 state를 모델링 해야 한다. 즉 온도가 50도 이상인 경우 팬1이 {On}이며, 50도 미만이면 {Off}로 transition이 발생하게 된다. 그리고 온도가 65도 이상이면, 팬2가 {On}이며, 65도 미만이면 {Off}로 transition이 발생한다. 이를 표시하면 그림 4와 같이 모델링할 수 있다.

---

---

2.2  팬1과 팬2의 동작 여부 모델링

그림 4는 팬 각각의 On/Off를 보여 주고 있다. 이를 체크하여 외부로 0, 1, 2를 내보내여야 하므로 이를 모델링을 해야 한다. 이때 사용하는 것이 Stateflow에서 제공하는 in() 함수이다. in() 함수의 인풋은 state 이름이며, 인폿으로 주어진 state가 활성화되어 있으면 리턴 값이 1이며, 비활성화되어 있으면 리턴 값이 0이다. 이러한 값을 계산하는 부분은 {FAN1}과{FAN2}의동작이완전히끝난후에계산해야하므로 parallel state를 하나 더 포함해야 한다. 그림 5를 보면 {FAN_Output}의 during action에서 in()함수를 이용하여 아웃풋 값인 control_fan에 {FAN1.On}과{FAN2.On}의활성화여부로값을대입하고있다.

---

---

2.3  모델의 문제점

그림 5를 보면 한 가지 문제가 있다. Parallel state인 {FAN1}, {FAN2}, {FAN_Output}들을보면우측 위에 숫자가적혀있다. 이 숫자가 각 parallel state의 실행 순서이다. {FAN1}의경우내부에{On}, {Off}가있으므로둘중에하나의 state가 활성화 되어야 하는데, 현재로서는 알 수가 없다. 따라서 지금 모델의 경우 문제가 있으므로 첫번째로 활성화되는 state를 표시하기 위해서 default transition으로 표시하게 된다. 그림 1에서도 마찬가지로 {PowerOn}과{PowerOff}두개의 state중에서 어느 state가 먼저 활성화가 되어야 하는지 알려 주는 default transition이 있어야 한다. 그림 6는 모든 것을 포함한 전체 모델이다. Stateflow로 모델링하다 보면 default transiton을 빠트리고 모델링하는 경우가 상당히 많다. 때문에 꼭 포함 시키기 바란다.

---

---

2.4  모델의 해석

그림 6이 전체 모델이므로 한번 해석을 해보자.

1. 처음 state chart가 업데이트 될때 default transition을 따라서 {PowerOff}가활성화된다.
2. SWITCH 이벤트가 발생하면 transition을 따라서 {PowerOn}이활성화되고, {FAN1}이활성화되며, default transition을 따라서 {Off}가활성화된다. 그 다음으로 parallel state인 {FAN2}가활성화되며, {Off}가활성화된다. 그 뒤 또 다른 {FAN_Output}이활성화된다.
3. 다시 차트가 업데이트 되었을때, {FAN1.Off}에서조건이맞으면{FAN1.On}으로 transition이 일어 난다. 그리고 {FAN2.Off}에서조건에따라 {FAN2.On}으로 transition이 일어 난다. {FAN_Output}은 during action이 있으므로 {FAN1.On}이 활성화 되었을 경우 in()함수에 의해서 1이 리턴되고, {FAN2.On}이 활성화 되었을 경우 in() 함수에 의해서 1이 리턴된다. 그러므로 control_fan의 값이 결정된다.

{PowerOn.FAN_Output}을보면{PowerOn.FAN1}과{PowerOn.FAN2}와 같은 parallel state이지만 순서가 세번째 인것을 알 수 있다. 이는 항상 차트가 한번 업데이트 됐을때 팬1과 팬2의 On/Off가 이미 결정된 이후에 그 결과를 계산하기 때문이다. 만약 parallel state의 실행 순서가 바뀌어서 {PowerOn.FAN_Output}가첫번째로실행되면팬의 On/Off가 현재 업데이트된 결과가 아니고, 바로 이전에 차트가 업데이트 됐을때 결정된 팬의 On/Off를 현재 시점에 결정하여 내보내는 것이다.

모델링한 것만 보면 알 수 없지만, state chart는 외부에서 이벤트가 들어 오게 되면 이벤트가 발생했을때만 차트가 업데이트되서 실행되게 된다. 지금까지 설명한 것으로만 보면 SWITCH 이벤트가 발생했을때에만 차트가 업데이트 되므로 처음 SWITCH ON 했을때와 SWITCH OFF 했을때, 즉 두번만 차트가 업데이트 된다. 요구 사항을 보면 1초 단위로 차트가 업데이트되어서 팬을 제어해야 하므로, 이럴 경우에는 외부에서 1초 단위로 이벤트를 발생시켜서 그 이벤트를 인풋으로 받으면 된다. 보통 이런 이벤트는 내부에서 사용하지 않을 경우도 많이 있다. 즉 단순히 차트를 업데이트 하는데만 사용하는 것이다.

2.5  시물레이션을 해보자

Simulink로 모델링된 외부 내용과 state chart를 합쳐서 실제로 원하는 방식으로 동작하는지 확인해 보도록 하자. 그림 7는 제어 로직을 테스트 하기 위한 Simulink 모델이며, 그림 8와 그림 9는 Signal Builder를 이용하여 인풋을 생성한 것이다. 그림 8에서와 같이 SWITCH 이벤트가 100초와 500초에 각각 한 번씩 발생하게 된다. 또한 CLOCK 이벤트를 좀 더 확대해서 보면 그림 9와 같이 1초에 한 번씩 rising edge가 있다. 그래서 차트에서 CLOCK 이벤트를 받을때 rising edge 로 이벤트를 받으면 차트가 1초에 한 번씩 업데이트 되게 된다.

---

---

---

---

---

---

그림 10는 앞에서 만든 차트로 제어를 했을 경우 온도 변화를 본 것이다. 결과를 보면 알겠듯이 50도를 거의 넘지 않게 잘 제어가 되고 있음을 알 수 있다.

---

---

2.6  Graphical function을 써 보자

팬의 On/Off 를 결정하는 조건문을 보면 비슷한 형태이므로 graphical function으로 변경이 가능하다. 물론 실제로 이 모델은 복잡한 모델이 아니므로 바꾸지 않아도 괜찮지만, 이때까지 배운 것을 활용한다는 입장에서 한번 바꾸어 보자. 그림 11를 보면 graphical function을 정의하고 활용하고 있는 부분을 알 수 있다.

---

---

2.7  Embedded MATLAB을 써 보자

Stateflow가 실행되기 위해서는 Simulink가 있어야 하며, Simulink를 실행 시키기 위해서는 MATLAB이 있어야 한다. MATLAB은 자체적인 프로그래밍 언어가 있으며, 수학적인 계산은 행렬 연산을 기본으로 한다. 즉 덧셈, 뺄셈, 곱셈, 나눗셈의 경우 행렬 연산을 기본으로 하므로 공학적인 계산을 할 때는 정말 편리하게 사용할 수 있다.

Stateflow 내에서 복잡한 action의 경우 flow graph등으로 하기가 어렵다. 조건이 많으면 flow graph의 패턴등을 이용할 수 있지만, 그래프의 크기가 많이 커지면 너무 복잡해 보일 수 있다. 이와 같이 복잡한 조건문, 반복문의 경우와 수학적인 계산을 많이 해야 할 경우 MATLAB의 기능을 쓰면 쉽게 구현할 수 있다. 하지만 MATLAB의 기능을 쓰게 되면 나중에 자동 코드 생성시에는 코드가 생성되지 않는다. 때문에 자동 코드 생성이 가능하면서 MATLAB의 기본적인 수학 함수를 사용할 수 있게 해주는 것이 Embedded MATLAB 함수이다.

그림 12를 보면 그림 11에서 graphical function으로 만든 부부을 Embedded MATLAB으로 만든 것이다. Embedded MATLAB으로 함수를 구현하기 위해서는 그림 11에서 왼쪽에 보이는 아이콘 중에서 Embedded MATLAB 아이콘을 클릭하고 차트 에디터의 공간에서 왼쪽 클릭을 하면 그림 12와 같이 함수 이름을 적을 수 있는 사각형 박스가 나온다. 여기에 함수 이름을 적고 마우스로 박스 내부를 더블 클릭하게 되면 그림 12에서와 같이 Embedded MATLAB Editor가 나와서 여기에 프로그래밍을 하게 된다.

Embedded MATLAB으로 함수를 구현하게 되면 에니메이션으로 어떤 경로로 움직이는지를 볼 수 없는 단점이 있지만, 프로그래밍에 익숙한 사람들에게는 편한 인터페이스이다.

---

---

2.8  팬의 On/Off에 대한 제약을 주는 모델

실제 팬을 그림 10와 같이 On/Off를 하게 되면 너무 빈번하게 On/Off가 이루어지므로 하드웨어에 좋지 않은 영향을 줄 수 있다. 이럴 경우 한번 Off가 되면 특정 시간만큼은 무조건 Off 상태로 있다가 특정 시간이 지난 이후에야 On으로 움직이도록 제약을 주는 경우가 많다. Stateflow에서는 이와 같이 횟수나 시간에 관련된 함수를 많이 제공하는 데 이를 Temporal Logic 이라고 한다. 아래는 대표적인 Temporal Logic 들이다.

after

after(n, E) 형태로 사용하며, 이벤트 E가 n번 일어난 후에 참이 되거나 이벤트가 발생하게 된다.

before

before(n, E) 형태로 사용하며, 이벤트 E가 n번 일어 나기 전에 참이 되거나 이벤트가 발생한다.

at

at(n, E) 형태로 사용하며, 이벤트 E가 n번 일어났을때 참이 되거나 이벤트가 발생한다.

every

every(n, E) 형태로 사용하며, 이벤트 E가 n번씩 일어 났을때 참이 되거나 이벤트가 발생한다.

이런 Teporal Logic은 조건문안에 들어 가도 되고 이벤트 처럼 활용할 수 있다. 무슨 말인가 하면, 위에 적은 것처럼 transiton 위에서 조건문인 […] 안에 Temporal Logic이 있으면 참과 거짓으로 결과를 넘겨 주고, transition 위에서 이벤트 위치에 Temporal Logic이 있으면 정확하게 이벤트가 발생한 것으로 알려 준다.

지금까지 팬 제어를 위한 모델을 일단 {PowerOn.FAN1.Off}이활성화되고나서최소 100초는 지나서 조건이 맞으면 {PowerOn.FAN1.On}으로 transition이 일어 나도록 모델링을 해보자. 앞에서 언급한 Temporal Logic중에서 after()를 사용하는게 제일 적합하므로 그림 13와 같이 {FAN1}에서는 after()를 이벤트로 사용하였고, {FAN2}에서는 after()를 조건문 안에 사용하였다. 어떤 방식을 사용해도 상관 없지만, 하나 고려해야 할 것은 이벤트이냐 조건문 안에 사용되었느냐에 따라서 transition의 우선 순위가 달라진다. 앞 연재에서 언급했듯이 이벤트로 사용할 경우가 우선 순위가 조건문 안에 사용할 때보다 높다는 것을 기억하자.

---

---

그림 14를 보면 그림 10와 다르게 팬의 On/Off가 그렇게 자주 일어 나지는 않는 것을 알 수 있다.

---

---

제 3 절  기존의 C코드를 사용하자

이미 검증된 c 코드가 있는데, 이를 Stateflow에서 쓰도록 다시 작성하는 것은 시간과 비용 측면에서 좋지 않기 때문에, Stateflow에서는 기존의 이미 검증되어진 C코드를 간단하게 불러 쓸 수 있게 되어 있다. 이런것을 셋팅할때 사용하는 메뉴가 Target에 관련된 메뉴이다. 즉 Simulation Target에 포함을 하면 되는 것이다. 앞에서와 마찬가지로 여기서도 지금까지의 모델을 수정하여 기존의 C코드로 작성한 함수를 부르게 만들어 보자.

온도 조건을 검사해서 transition이 발생하게 하는 부분을 아래와 같이 C로 작성했다고 생각하자. 이 파일의 이름은 custom_comp.c 라고 하면, custom_comp.h 파일은 함수의 선언만을 가지고 있다고 가정하자.

차트에디터에서 Tools → Open Simulation Target 메뉴를 선택하게 되면 그림 15와 같은 창이 뜨며, 여기서 “Include Code”와 “Source Files”에 각각 코드에 대한 내용을 적어 주면 된다. 즉 “Include Code”에는 C에서 헤더 파일 포함시킬때 처럼 하면 되고, “Source Files”에는 C 파일의 이름을 적어 주면 된다.

---

---

그림 15와 같은 윈도우에 셋팅을 하고 나서 실제로 사용은 일반적인 함수처럼 사용하면 된다. 그림 16에서 transition 부분을 주의 깊게 보면 isOK()라는 함수를 쓰고 있는 것을 알 수 있다.

---

---

3.1  기존 C 코드 사용의 주의점

앞에서 본 것처럼 기존의 C 코드를 함수 형태로 불러서 사용하는 것은 크게 힘들지 않지만, 몇 가지 주의 해야 할 점이 있다. 여기서 그 내용을 간략하게 살펴 보도록 하자.

3.1.1  C 수학 라이브러리 함수를 사용할 때

기본적으로 사용할 수 있는 수학 함수는 아래와 같으며, 한가지 특이한 점은 abs()함수가 Stateflow에서는 C와 다르게 동작한다. abs()함수의 경우 C에서는 abs, labs, fabs등 총 세 가지 형태가 있다. Stateflow내에서는 abs()함수 하나만 사용해도 abs()함수의 인풋 인자의 데이타 타입에 따라서 내부적으로 알맞은 함수가 불리운다.

또한 매크로 함수로 min()과 max() 함수가 Stateflow 내부에 존재하므로, 사용이 가능하다. 실제 매크로 함수는 아래와 같이 정의되어 있다.

3.1.2  기존 C 코드 사용상 주의점

• 문자열이 인풋 인자로 넘겨 줄때 C에서는 스트링 처리를 “…”로 감싸서 넘겨 주지만, Stateflow 내에서 이런 함수를 불러서 사용할 때는 ‘…’로 감싸서 넘겨 준다.
• C 함수에서는 call by value가 일반적인지만, call by reference가 필요할 경우가 있다. 이럴 경우 C에서와 같이 f(&c) 로 사용하면 된다.
• call by reference로 인풋 인자를 넘겨 줄때는 만약 함수의 인풋으로 들어 가는 변수가 차트의 인풋, 즉 Simulink로 부터 들어 오는 값이면 call by reference로 넘겨 줄 수 없다. 이럴 경우 차트의 내부 변수를 만들어서 값을 대입하고 내부 변수를 call by reference로 넘겨 주면 된다.
• 배열을 함수의 인풋 인자로 넘겨 줄 경우에는 무조건 f(&(x[0]))와 같이 써야 한다. C의 경우 f(x)만 해도 되지만 Stateflow 내에서는 이렇게 사용하면 안된다.

제 4 절  Stateflow 모델의 자동 C 코드 생성

이상으로 Stateflow를 활용하여 이벤트에 따라서 동작하도록 하는 모델을 시물레이션하는 방법을 보았다. Stateflow로 복잡한 모델등을 시물레이션으로 실제 하드웨어 없이 동작을 검증하고 나면, 실제로 실시간으로 테스트를 해야 한다. 실시간으로 테스트를 할 때는 C나 어셈블리 코드를 작성해야 하는데, 시물레이션을 한 모델을 다시 C로 재코딩하는 것은 많은 비용과 시간을 소모해야 한다. 이런 문제점을 해결하기 위해서 Stateflow Coder라는 것을 이용하면, 모델로부터 자동으로 C 코드를 생성할 수 있게 된다. 이렇게 C 코드를 자동으로 생성하게 되면, 모델로 시물레이션하고 다시 C로 코딩하고, 코딩된 프로그램이 모델과 같은지 테스트하는데 걸리는 시간등이 전혀 필요없게 된다. 이미 NASA나 Toyota 등과 같은 많은 회사들이 자동 코드 생성 기능을 사용하고 있다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

아래 내용은 마이크로소프트웨어 2008년 3월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다. 잡지 기사를 pdf로 보실려면 iMaso 홈페이지에 가셔서 구매하실 수 있습니다.

요 약 State machine을 모델링하는 기본적인 내용은 다 배웠다. 이번 연재에서는 복잡한 로직등을 action이나 조건식에 사용할 수 있게 해주는 flow graph와 truth table에 대해서 배워 보도록 하자.

제 1 절  Flow graph

Flow Graph는 복잡한 로직(주로 조건문과 반복문)을 Stateflow 내부에서 모델링할때 사용한다. 앞 연재에서 배웠던 junction과 transition을 이용하여 로직을 구성하게 된다. 아래와 같이 간단한 c 코드를 Flow Graph로 바꾸면 그림 1와 같다. 앞 연재를 잘 보았다면 그림 1를 충분히 이해할 수 있지만, 한번 더 확인해 보자.

Stateflow 내에서는 Junction에는 머무를 수가 없고 무조건 지나가야 하므로 state chart가 업데이트 될때마다 default transition을 따라서 들어 와서 각 junction에서 어떤 transition을 따라서 움직여야 하는지를 판단해서 terminating junction을 만날때까지 실행이 된다. terminating junction이란 junction중에서 transition이 들어 오기만 하고 나가는 transition이 없는 junction을 말한다.

---

---

Flow graph에는 한 개의 default transition과 최소 한 개 이상의 terminating junction이 필요하다. terminating junction은 여러 개 있을 수 있는데, C에서 함수를 작성할때 return 문이 여러 개 있으면 분석때 복잡한 것처럼 flow graph에서도 가능하면 한 개의 terminating junction을 두는게 좋다.

Chart가 업데이트 되었을때 첫 번째 junction에서 우선 순위에 따라서 [ u >0.5 ] 인 조건식을 먼저 검사하게 된다. 이 조건식이 참인 경우 transition을 따라서 다음 junction으로 움직이고, 그 뒤에 junction을 따라서 { y = 1;}이실행된다. 그리고 다시 junction으로 움직이고, 아무 것도 없는 transition을 따라서 terminating junction에서 실행이 멈추게 된다. 이상과 같이 flow graph는 junction에서 우선 순위에 따라서 조건 검사하고 transion 따라서 움직이는 것을 잘 찾아 다니면 쉽게 이해할 수 있다.

1.1  Flow Graph Pattern

Flow graph가 복잡해지면 transition과 junction이 많아져서 오히려 가독성이 떨어지게 된다. 이러한 가독성을 높게 하기 위해서 일반적으로 The MathWorks 사에서 제공하는 패턴 형태가 있다. 물론 현재까지 stateflow를 사용한 유저들의 의견이 충분히 반영되어 있으므로 가능한 지키는 것이 좋다. junction과 transition으로 정형화된 모양으로 형태만 보고도 조건문인지, 반복문인지 등을 구별할 수 있다. 그림 1의 경우 if-else 문을 표시한다.

---

---

그림 2의 경우 c 코드에서는 if-else if 문으로 아래와 같다.

그림 3는 c 코드에서 if 내부에 다시 if가 있는 것으로 아래에 코드가 있다.

---

---

그림 4는 for 구문을 표시하며, 그림 5는 while 구문이며, 그림 6는 do-while 구문을 나타낸다. 이와 같이 패턴 형태로 로직을 구성하게 되면 flow graph를 읽을때 가독성이 확실히 좋아 짐을 알 수 있다. 물론 이것이 법칙은 아니지만 대부분의 사용자가 사용하는 방식이므로 따라서 하는게 좋다.

---

---

---

---

---

---

1.2  Flow graph의 주의할 점

Flow graph를 사용할때 주의해야 할 점이 있다. 항상 junction에서 나와서 junction으로 transition이 발생하는데, transition에 조건문이 있을 경우 항상 조건이 없는 transition이 있어야 한다는 것이다. 예를 들어 그림 7의 flow graph를 보면 condition1이 참이고 condition2가 거짓인 경우 그림 7에 표시한 부분에서 backtracking이 발생하여 다시 돌아 가서 y=0;이 실행되게 된다. 이런 경우는 주로 사용자가 원하지 않는 경우이다. 이런 경우를 피하기 위해서는 backtracking이 발생한 junction에서 Junction 1 이라고 표시된 junction으로 transition이 있어야 한다. 이런 backtracking을 피하기 위해서는 조건이 있는 transition이 나가는 junction의 경우 항상 조건이 없는 transition을 추가하면 해결된다.

---

---

또 하나 주의 할 점은 반복문의 패턴을 만들때이다. 그림 4와 그림 8를 비교해 보면 내용 자체는 똑같다. 하지만 그림 4는 제대로 동작하고, 그림 8는 실행 자체가 되지를 않는다. 반복문을 flow graph로 구성할때는 무조건 아무 조건이 없는 transition이 반복문 바깥에 있는 junction으로 나가야 한다. 그림 8는 조건문이 반복문 바깥에 있는 junction으로 나가므로 제대로 실행이 되지 않는다. 의미상 flow graph에서는 같아보여도 실제로 실행이 되지 않는다. 이는 stateflow에서의 제약 사항 이다.

---

---

1.3  Graphical Function

일반적인 프로그래밍 언어를 보면 같은 일을 모아서 반복하거나 혹은 단위일을 하게 하는 경우에 함수 형태로 만들 수 있는 것처럼 flow graph도 함수 형태로 만들 수 있다. 이를 graphical function이라고 한다. graphical function을 만들때는 c에서 함수 만드는 것처럼 함수의 이름과 인풋, 아웃풋에 대해서 정의 하고 그 내부 구성을 flow graph로 만드는 것이다. c와는 다르게 인풋과 아웃풋의 데이타 타입을 함수명에 표시하지 않고 변수명만 적으면 된다. 그림 9에 서 점선으로 동그라미친 부분을 보면 공통되는 부분이라는 것을 알 수 있다. 물론 조건문의 값이 2와 1로 다르지만 이 부분을 함수의 인풋 형태로 만들면 동그라미 친 부분은 동일하다는 것을 알 수 있다. 이럴때 graphical function을 사용할 수 있는 것이다.

---

---

그림 10와 같이 왼쪽에 있는 아이콘중에 f()로 되어 있는 아이콘이 graphical function을 만들기 위한 아이콘이다. 이를 클릭해서 차트 에디터의 빈 공간이 클릭을 하면 function 이라고 적힌 빈 상자가 생긴다. function 다음에 함수의 형태를 쓰므로서 graphical function을 만들 수 있다. 빈 상자는 네 모서리를 움직여서 크기를 바꿀수 있으며, 그 안에 flow graph를 만들어서 graphical function을 만들 수 있다.

---

---

그림 11를 완성해서 원래 flow graph에 반영한 모습이다. 그림과 같이 상당히 단순화 되는 것을 알수 있다. 그리고 graphical function으로 만든 부분을 내용은 보여 주지 않고 함수의 이름 형태로만 보여 줄 수도 있다. 이렇게 하기 위해서는 graphical function 위에서 마우스 오른쪽 버튼을 클릭하여 ”Make Contents → Subcharted”를 선택하면 된다. 이 과정이 그림 12에 나와 있다. 이렇게 subchart화된 graphical function의 내용을 보기 위해서는 박스 안쪽을 더블 클릭하면 볼 수 있게 된다.

---

---

---

---

첫 연재에서 state chart를 만들고 시물레이션할 때 에니메이션으로 어떤 조건에 state가 어떻게 변하는지 볼 수 있다고 했듯이 마찬가지로 graphical function도 어떤 transition을 따라서 움직이는지를 에니메이션 형태로 볼 수 있다. 따라서 복잡한 로직의 경우 flow graph를 잘 활용해서 만들어 놓으면, 조건이나 인풋에 따라서 실제로 어떤 흐름으로 움직이는지 볼 수 있으므로 본인이 만든 알고리즘을 디버깅할때 실제 c코드를 보는 것보다 훨씬 쉽게 할 수 있다.

1.4  Inner Flow Graph

지금까지 설명한 것처럼 flow graph를 단독으로 사용할 수도 있지만, graphical function 형태로 만들어서 state chart의 condition/transition/state action등에 사용할 수도 있다. 또 한 state 내부에 flow graph를 사용할 수도 있는데, 이를 inner flow graph라고 한다. 그림 13를 보면서 그 활용도를 확인해 보자.

---

---

차트가 처음으로 업데이트된 상황에서 어떤 action이 실행되는지 확인해 보자.

1. default transition을 따라서 {S1}이활성화된다.
2. {S1}의 entry action인 action1이 실행된다.
3. {S1}내부에있는 innter graph의 default transition을 따라서 flow graph가 실행되므로 act1이 실행된다.
4. u1 > 1의 조건이 참이면 y = 1이 실행되고, 거짓이면 y = 0이 된다.

{S1}이활성화된상태에서다시차트가업데이트되고 e2 이벤트가 발생하게 되면 {S1}의 during action인 action2가 실행된다. 여기서 중요한 것은 inner flow graph가 실행되지 않는 다는 것이다. 그 다음으로 차트가 업데이트 될 때 e1 이벤트가 발생하게 되면 어떻게 될까? 한번 생각해 보자.

1. {S1}에서나가는 transition을 체크했을때 e1 이벤트가 발생했으므로 {S1}에서{S2}로 transition이 일어나게 된다.
2. {S1}의 exit action인 action3이 실행된다.
3. transition action이 없으므로 바로 {S2}가활성화된다.
4. {S2}가활성화되면서 entry action인 action4가 실행된다.
5. inner flow graph의 default transition을 따라서 실행되므로 act2가 실행된다.
6. u1 > 1의 조건에 따라서 y=1이거나 y=0이 된다.

{S2}가활성화된상태에서다시한번차트가업데이트되고아무런이벤트가발생하지않았을때의동작을살펴보자

1. {S2}에서나가는 transition이 아무것도 일어 나지 않으므로 during action인 action5가 실행된다.
2. {S2}의경계에서 inner flow graph로 transition이 있으므로 act3가 실행된다.
3. u1 > 1의 조건에 따라서 y=1 또는 y=0이 된다.

위에서 설명한 것처럼 innter flow graph의 경우 state의 경계에서 inner flow graph로 transition이 있는지 여부에 따라서 during action 다음에 inner flow graph가 실행되는지의 여부가 판가름 난다. 앞에서 본것처럼 inner flow graph의 경우 state의 entry/during action 처럼 동작을 하지만, 순서가 실제 state의 action보다는 뒤에 실행된다는 것을 명심해야 한다.

제 2 절  Truth Table

조건이 아주 많고 그런 조건의 조합으로 어떤 action을 실행할지 결정해야 하는 경우들이 있다. 물론 flow graph를 사용해서 조건문을 실제로 조합해서 모델링할 수도 있지만, 이런 경우는 stateflow에서 제공하는 truth table을 이용하는 것이 훨씬 수월하게 작업을 하도록 도와 준다.

Truth table의 경우 function 형태로만 제공되며 truth table을 위한 에디터가 따로 제공된다. 게다가 truth table만을 사용하기 위한 사용자를 위하여 truth table 블럭이 존재한다. 여기서는 truth table을 함수 형태로 사용하는 것을 보도록 하겠다.

세 개의 센서가 있는 시스템에서 아래와 같은 세 가지 조건이 있다고 가정해 보자.

1. 세 개의 센서는 정상 작동하면 0과 같거나 혹은 더 큰 값을 가진다.
2. 세 개의 센서의 값이 정상 작동하는 경우는 세 센서의 값을 다 더하고 3으로 나눈다. 즉 평균을 구한다.
3. 한 개의 센서만 음수의 값을 가질 경우, 즉 두 센서의 값은 정상적일 경우, 두 센서의 값 만을 더하고 2로 나누어 평균을 낸다.
4. 한 개의 센서만 정상 작동할 경우 시스템에 문제가 있다고 가정하고 -1을 가진다.
5. 모든 센서가 정상 작동하지 않을 경우 -1을 값으로 가진다..

2.1  Truth Table 에디터

위와 같은 경우 c로 어떻게 코딩하면 되는지 한번 생각해 보기 바란다. 프로그래머의 능력에 따라서 각각의 코드가 나오므로 독자에게 이 부분은 맡기겠다. 여기서는 truth table을 이용하여 모델링해 보도록 하겠다.

차트 에디터에서 왼쪽에 있는 아이콘 중에서 junction 아이콘 밑에 있는 아이콘을 클릭하면 된다. 이를 클릭하면 graphical function 처럼 박스가 생기는데 이번에는 function이 아니라 truthtable 이라고 적힌다. 그리고 박스의 중간에 함수의 이름과 인풋, 아웃풋을 적게 된다. 그리고 박스 안을 더블 클릭하면 그림 14가 나와서 모델링을 하게 된다.

---

---

조건식은 sensor_a >= 0, sensor_b >= 0, sensor_c >= 0 세 개의 조건식의 참/거짓여부로 판단할 수 있다. 이를 위해서 truthtable 에디터의 condition table에 행을 두개 더 추가 하고, 열의 경우 7개를 더 추가한다. 열을 7개 더 추가하는 이유는 truthtable을 만들 경우 가능한 모든 경우의 수를 만들어야 한다. 즉 3개의 조건이 참/거짓으로 만들 수 있는 최고의 경우의 수는 8이므로 7개를 더 만들어야 한다.

그림 15에 서처럼 condition table에 3개의 조건을 각각의 행에 두고 열에는 T/F로 조합을 만든다. 그리고 action table에는 y를 계산하는 각각의 action을 실제로 적는다. action table의 제일 왼쪽에 보면 숫자가 있는데, 이 숫자를 condition table의 각 열의 맨 마지막에 숫자로 적는다. 만약 두 개 이상의 숫자를 적어야 하면 ,로 구별하면 된다.

---

---

그림 15에서 D5와 D8을 삭제해 보자. truth table이 복잡하다보면 조건을 적다가 빠트리는 경우도 있을 수가 있다. 이럴 경우를 체크하기 위해서 그림 14에 있는 체크 아이콘을 클릭했을때 나오는 에러 윈도우가 그림 16이다. 그림 16를 보면 FFF(D8)와 FTT(D5) 조건이 빠졌다고 체크해주는 것을 알 수 있다.

---

---

2.2  Simulink와 연동한 알고리즘의 체크

모델링을 다 했으니, 제대로 모델링 했는지 체크를 해보기 위해서 Simulink와 연동하여 테스트해 보자. 그림 17는 테스트를 하기 위해서 Simulink로 전체 모델을 만든 것이다. sensor들의 값은 sine 인풋으로 값을 주었는데, phase를 약간 달리하므로 인풋 값에 차이가 날 것이다. 그림 18는 10초간 시물레이션했을때 그 결과를 보여 주는 것이다. c로 코딩했을때와 truth table로 모델링한 것과의 차이점 뿐만 아니라 알고리즘을 테스트 하기 위한 부분까지도 얼마나 쉬운지 알 수 있을 것이다.

---

---

---

---

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

아래 내용은 마이크로소프트웨어 2008년 2월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다. 잡지 기사를 pdf로 보실려면 iMaso 홈페이지에 가셔서 구매하실 수 있습니다.

요 약 State Machine을 Stateflow에서 모델링하는 기초적인 방법을 지난 시간에 배웠다. 이제는 좀 더 활용도를 높이기 위해서 Stateflow에서 제공하는 기능들을 살펴보고, Parallel State가 무엇인지, 어떻게 사용하는지에 대해서도 배워보자.

제 1 절  우선 순위에 대해서

Stateflow에서 각 state에 대한 transition을 만들다 보면 하나의 state에서 여러개의 transition이 생긴다. 이럴 경우 어떤 transition이 먼저 실행되는지가 중요한 경우들이 있을 수 있다. 그림 1에 서 {twoCoin}(state를 지칭할때는 {}를붙이겠다.)을 보면 insertCoin과 cancel 두 개의 이벤트가 발생할 때 실제로 어느 것을 먼저 비교할 것인가에 대한 기준이 있어야 한다. Stateflow의 경우 내부적인 기준을 가지고 이를 자동으로 결정하고, 그 결정 사항을 보여 주게 된다. {twoCoin}에서두개의 transition을 보면 숫자 1과 2가 적혀 있으며, 이 숫자가 실행될 transition을 체크하기 위한 우선 순위이다. 물론 숫자가 작을 수록 우선 순위가 크므로 그림 1와 같은 모델에서 {twoCoin}에있으면, 이벤트가 발생할때 마다 우선 순위가 높은 insertCoin 이벤트의 transition이 먼저 체크 된다.

---

---

1.1  디폴트로 생성되는 우선 순위

Stateflow 내부적으로 생성되는 우선 순위는 총 세 가지 경우를 기본으로 생성된다. 아래 세 가지 경우고 동시에 발생하는 경우에는 아래 순서로 우선 순위가 결정된다. 이에 대해서는 뒤에 나오는 Super state와 substate를 설명할 때 자세히 설명하도록 하겠다.

1.1.1  계층 구조에 따라서

State chart에서 계층 구조란 하나의 state안에 여러 개의 state를 포함하고 있을 수 있는 것을 말한다. 또 한 이럴 경우 transition을 체크하는 우선 순위가 가장 바깥에 있는 state가 다른 state(즉 자기가 포함하지 않은 state)로 transition이 일어날 경우가 가장 높다. 이 경우는 superstate와 substate를 뒤에서 설명하면서 자세하게 설명하도록 하겠다.

1.1.2  Transition 레이블에 따라서

transition 레이블이란, 그림 2처 럼 transition 위에 적을 수 있는 내용을 말한다. 여기서 기본적인 우선 순위는 transition이 일어날 확률이 적은 것일 수록 우선 순위가 높다. 이벤트와 조건식을 가지고 쉽게 이해해 보자. 이벤트의 경우 그 이벤트가 꼭 발생해야 하지만, 조건식의 경우 조건이 맞으면 된다. 그럼 이 둘의 경우 어떤 경우에 발생할 확률이 높을까? 당연히 조건식의 경우가 발생할 확률이 높다. 물론 조건식도 [a == 3]과 같은 조건식은 당연히 이벤트 처럼 발생하기 힘들 수 있지만, 여기서는 전체적인 것을 생각해 봤을 때 이다. 그러므로 이벤트가 있는 transition이 조건식만 있는 transition보다 당연히 우선 순위가 높다. 이를 바탕으로 생각해 보면 이벤트도 있고 조건식이 있는 경우가 우선 순위가 제일 높다는 것을 알 수 있다. 이와 같이 하나의 state에서 transition이 여러 개 있을 경우 transition이 발생되는 이벤트나 조건에 따라서 어느 것이 먼저 테스트 되는지 알 수 있게 된다. 그림 3를 보면 우선 순위가 e2[in1 > 20]이 제일 높고 그 다음이 e2, e1, 마지막으로 [in1 < 10] 이다.

---

---

---

---

1.1.3  Transition의 위치에 따라서

그림 3를 보면 위에 규칙에 의하면 우선 순위가 같은 e2와 e1이 있다. 레이블로 보면 둘 다 이벤트 이므로 위에 있는 규칙인 transition 레이블에 따라서 우선 순위를 매길 수가 없다. 이런 경우는 transision의 시작점을 기준으로 transition이 시계를 기준으로 12시에 가까울 수록 우선 순위가 높다. 즉 시계 방향으로 돌면서 우선 순위가 낮아 지게 된다. 그림 3를 보면 e2와 e1 둘 중에 시계 방향으로 봤을때 e1이 e2보다 나중에 있으므로, e2가 e1보다 우선 순위가 높다.

1.1.4  직접 지정하기

Stateflow가 우선 순위를 대부분 지정해 주고, 화면상에 표시하기 때문에 쉽게 우선 순위를 알 수 있지만, 우선 순위를 직접 지정하고 싶을때가 있다. 이럴 경우에도 사용자는 쉽게 이를 지정할 수 있다. 이를 지정하기 위해서는 먼저 File→Chart Properties 를 선택하면 사용자가 직접 우선 순위를 지정할 수 있게 할 것인지 여부를 체크할 수 있다. 여기에 체크를 한후, transition을 마우스 오른쪽 클릭을 하게되면 그림 4처럼 직접 지정할 수 있게 된다.

---

---

제 2 절  Junction에 대해서

transition이 일어 나는 것은 앞에서 본 우선 순위에 의해서 어떤 transition이 실행될 것인지가 결정되고 나서 이다. 그러면 e1 이벤트가 발생하고 조건에 따라서 다른 state로 가야 하는게 결정되면 어떻게 하면 될까? 물론 각각의 transition에 e1[c1], e1[c2], e1[c3] 등을 각각 만들면 되지만, 보기에도 좋아 보지는 않는다. 이럴 경우 junction을 사용하면 된다. 그림 5를 보면 {A}에서{B}로 transition이 e1[c1], e1[c2], e1[c3]에 의해서 일어 난다. 그림과 같이 독립적인 3개의 transition을 만들어서 사용해도 되지만, 이것보다는 {C}에서{D}로가는것처럼 junction을 이용해서 사용할 수 있다. 위와 아래를 비교해보면 junction을 이용하는 것이 훨씬 이해가기 쉽다. junction의 경우는 항상 지나가는 길을 여러개로 만들수 있는 것이라고 생각하면 된다.

---

---

또 하나의 사용은 앞 연재에서 봤던 condition action과 transition action을 구별 지을 수 있게 해준다. 그림 6에 서 e1 이벤트가 발생하고 그 다음에 있는 모든 조건이 맞지 않으면, 우선 순위 4번인 아무 조건이 없는 transition으로 다시 {C}로돌아간다. 이 때 out1 = 1 이라는 transition action은 실행되지 않지만, {out1 = 5;}라는 condition action은 실행된다. 즉 transition의 경우 항상 state가 바뀌는 경우에만 실행이 되지만, condition action은 조건이 만족되기만 하면 실행이 가능하다. junction은 잘 사용하면 모델을 읽는 사람에게 편하게 읽을 수 있도록 해주므로 주의 깊게 잘 사용하도록 하자.

---

---

제 3 절  Temporal Logic을 써보자

temporal logic이란 state chart가 업데이트 되는 수에 관련된 함수들을 말한다. 예를 들어 {on}에서 10번 업데이트 되는 동안에 있다가 11번째 업데이트때는 {off}로가야한다면어떻게모델링을해야할까? 이에 대한 해답이 바로 temporal logic을 쓰는 것이다. 대표적인 temporal logic 함수들은 아래와 같다.

after

after(n, E) 와 같이 사용하며, E는 이벤트이며, n은 0보다 큰 숫자이거나 0이나 혹은 더 큰 숫자를 리턴하는 함수를 사용하면 된다. 이름이 뜻하듯이 E가 n번 발생한 후에 true를 넘겨 주거나 혹은 이벤트를 생성한다.

before

before(n, E) 와 같이 사용한다. E가 주어진 n 이전에 발생했는지 여부를 알려 준다.

at

at(n, E) 와 같이 사용하며, E가 정확히 n 번째에 발생했을 경우 true를 넘겨 주거나 이벤트를 생성한다.

every

every(n, E) 와 같이 사용하며, E가 n번째 마다 발생했을 경우 true를 넘겨 주거나 이벤트를 생성한다. every(2, e1) 이면 e1 이벤트가 2번째 발생할때 마다 true를 넘겨 주거나 이벤트를 생성한다.

더 많은 temporal logic이 있지만, 대표적인 것만 설명했다. 이런 temporal logic은 대부분 이벤트로도 쓰이고, 조건문으로도 사용할 수 있다. 즉 그림 7처럼 이벤트나 조건문 모두에 사용할 수 있다. {E}에서{F}로 transition이 일어나는 경우는 timeClock 이라는 이벤트가 3번 발생한 후, 즉 4번째 발생했을 때이며, {F}에서 {E}로 transition이 일어나는 경우는 e1 이벤트가 5번 일어난후 즉 6번째 이다.

---

---

temporal logic을 잘 활용하면, 자신만의 스케줄러를 만들 수 있다. 즉 인풋 이벤트로 원하는 샘플링 시간인, 0.001초로 펄스를 만들어서 인풋 이벤트로 만들고 temporal logic 을 이용하면 자신만의 스케줄러를 만들어서 원하는 작업을 할 수 있게 만들 수 있다. 또한 버튼을 눌렀을때를 생각해 보자. 한개의 버튼이 있는데, 누르고 있는 시간에 따라서 다른 동작을 하게 만들어야 할 경우에도 temporal logic을 잘 활용하면 된다.

제 4 절  Action에 대하여

Stateflow를 활용하다 보면 여러 가지 action에 대해서 알게 된다. 여기서 action들에 대해서 정리하고 넘어 가도록 하자. 크게 봐서 action은 state에 연관된 action과 transition에 연관된 action으로 두 종류가 있다. state action은 다시 entry, during, exit 으로 구별되며, transition에 연관된 action은 condition action과 transition action으로 나누어 진다.

4.1  Action이 실행되는 순서

---

---

그림 8를 보면, 다양한 action들이 있는 것을 알 수 있다. 그림 8는 transition action과 state action이 다 포함된 모델이다. 여기서 알고자 하는 것은 각 action들의 순서를 확인하고자 하는 것이다. 먼저 몇 가지 가정을 하고 시작하자. out으로 시작하는 변수들은 아웃풋으로 가정하고, in으로 시작하는 변수들은 인풋으로 가정한다. e로 시작되는 변수들은 인풋 이벤트이며, timeClock은 0.001초 단위로 rising/falling edge가 반복되는 펄스 신호이다. 즉 그림 8의 모델은 0.001초 단위로 업데이트 되는 모델이다. 현재 시간이 0.001초이면 {A}가활성화되어서 entry action인 out1 = 1 이 실행된다. 이 상태에서 0.003초가 되면, 즉 timeClock 이벤트가 세 번 발생했을때 e1 이벤트가 발생하면 {A}에서{B}로 transition이 일어 나게 된다. 이 때 실행되는 action을 순서대로 고려해 보면 다음과 같다.

1. {A}에있는 exit action인 out1 = 3이 실행된다.
2. {A}에서{B}로실제로 transition이 일어 나므로 transition action인 out2 = 2가 실행된다.
3. {B}에 entry action인 out3 = 1이 실행된다.

위 순서를 보듯이 transition action은 항상 exit action과 entry action 사이에 발생한다. 좀 더 이해를 돕기 위해, 이번에도 {A}에있는상태에서 e2 이벤트가 발생했다고 생각해 보자. e2 이벤트가 발생했으면, transition을 따라가 보면 junction에 도달하게 된다. junction의 경우 무조건 분기해 주는 역할뿐이므로 junction에서 밖으로 나가는 세가지 분기가 있다. 이 중에 우선 순위가 가장 높은 경우가 [in1 > 10]{out2 = 2;}이다. 이 조건이 만약 참이면, 실행되는 action의 순서를 생각해 보자.

1. {A}에있는 exit action인 out1 = 3이 실행된다.
2. in1 > 10 이 참이므로, condition action인 out2 = 2가 실행된다.
3. {A}에서{B}로실제로 transition이 일어 나므로 transition action인 out2 = 0이 실행된다.
4. {B}에있는 entry action인 out3 = 1이 실행된다.

위와 같이 condition action은 condition이 참인 경우에는 transition이 안 일어 나도 condition이 참이면 실행이 되는 action이고, transition action의 경우 실제로 active state가 변경될 경우에 실행되는 action이다.

다음 연재에서 배우겠지만, action을 실행할때 함수 형태로도 실행할 수 있으므로 필요한 경우에 맞게 잘 선택해서 사용하면 된다.

제 5 절  Superstate와 Substate

State chart에서 각각의 state는 다른 state를 포함할 수 있다. 여기서 포함된 state를 substate라고 하며, 다른 state를 포함하고 있는 state를 superstate라고 한다. 상대적인 개념으로 항상 얘기하므로 잘 구별해서 얘기해야 한다. 또 superstate가 활성화 되면 그 안에 있는 substate중에 하나가 무조건 활성화 되어야 한다. 그래서 제일 안쪽에 있는 substate가 활성화 되어야 한다. 즉 superstate만 활성화 되고 substate가 하나도 활성화 되지 않는 상황은 존재하지 않는다.

---

---

5.1  Superstate와 substate 구별하기

그림 9는 superstate와 substate를 표시하며, 그 사이에 transition을 보여 주고 있다. {A}는{SubA1}, {SubsubA1}, {SubsubA2}, 그리고 {SubA2}의 superstate이며, {SubA1}은{SubsubA1}의 superstate이다. 물론 {SubsubA2}는{SubA1}의 substate이다. 이런 state를 나타낼때는 계층 구조적으로 나타낼수 있다. 즉 {A.SubA1}과같이나타낼수있다.

5.2  State활성화 및 Action이 실행되는 순서

앞에서 언급했던 transition을 테스트하는 우선 순위는 superstate와 substate 사이에서는 더욱 복잡해진다. 하지만 기본적인 사항을 잘 숙지하고 하나씩 체크하면 충분히 이해할 수 있다. 앞에서 우선 순위를 체크할때 가장 먼저 고려하는 것이 superstate에서 다른 state로 나가는 transition이다. 지금부터는 전부 설명이 그림 9를 기준으로 한다. 최초로 차트가 업데이트 될 때 활성화 되는 state는 아래와 같은 순서로 활성화 되면서 state action이 실행된다.

1. 차트가 업데이트가 되어서 디폴트 transition을 따라서 {A}가활성화된다. 그리고 entry action인 doEnA() 실행된다.
2. {A}가활성화되었으므로 substate인 {A.SubA1}이나{A.SubA2}가활성화되어야한다. 이 때 {A}안에있는디폴트 transition을 따라서 {A.SubA1}이활성화되게해준다. entry action인 doEnSubA1() 실행된다.
3. {A.SubA1}이활성화되었으므로 substate인 {A.SubA1.SubsubA2}가활성화된다.

이 상황에서 e10 이벤트가 발생했다고 하자. 그러면 어떤 transition이 제일 먼저 테스트가 될까? 가장 바깥에 있는 superstate인 {A}에서바깥으로나가는 transition이 제일 먼저 테스트 된다. 즉 {A}에서{B}와{B.SubB1}가는 transition이 제일 먼저 테스트될 대상이다. 이 둘중에서 e1 이벤트에 대한 transition이 먼저 테스트되는 이유는 같은 이벤트이므로 시계방향으로 봐서 12시에 가까운 쪽이 우선 순위가 높기 때문이다.

{A}에서직접적으로나가는 transition이 없으므로 during action인 doDuA()가 실행된다. 그리고 {A.SubA1}에서나가는 transition이 없으므로 during action인 doDuSubA1()이 실행된다. 그리고 현재 활성화 된 {A.SubA1.SubsubA2}에서{A.SubA2}로나가는({A.SubA1.SubsubA2}입장에서는자신의 superstate인{A.SubA1}을나가는것이므로) transition인 [in < 1]인 조건을 먼저 테스트한다. 그 다음으로 이벤트 e10이 있는 transition을 테스트한다. 여기서는 in이 1로 가정하면 {A.SubA1.SubsubA1}이활성화되게된다.

위와 같은 상황에서 이번에는 e1 이벤트가 발생하면 어떻게 되는지 생각해 보자. 가장 먼저 테스트되는 transition이므로 실제로 {A}에서{B}로 transition이 일어나게 된다. 활성화 되는 state와 state action들을 순서대로 정리하면 아래와 같다.

1. {A}에서{B}로가는 transition이 실제로 일어 나게 되므로 현재 활성화 되어 있는 {A.SubA1.SubsubA1}이비활성화되며, exit action이 없으므로 아무것도 실행하지않는다.
2. {A.SubA1}을비활성화시키면서 exit action인 doExSubA1()이 실행된다.
3. {A}를비활성화시키면서 exit action인 doExA()가 실행된다.
4. transition action이 없으므로 실행되지 않는다.
5. {B}를활성화하면서 entry action인 doEnB()를 실행한다.
6. {B.SubB1}이활성화된다.
7. {B.SubB1}에 entry action이 없으므로 아무것도 실행되지 않는다.

{A.SubA1.SubsubA1}이활성화된상태에서 e2 이벤트가 발생하면 어떻게 되는지 확인해 보면 {A}에서일어나는일은그대로이지만, {B}에서는 transition이 {B}의경계를가리키므로{B}내부의 state가 활성화 되는 것은 디폴트 transition에 따라서 {B.SubB1}이활성화된다. 바로 위와 결과는 같지만, 과정이 다른 것이다.

제 6 절  Parallel State를 활용하자

지금까지 본 state는 주의 깊게 살펴 보면 실제로 활성화된 state가 항상 한 개뿐이다.(물론 가장 안쪽에 있는 substate를 말한다.) 실제로 모델링을 하다보면 동시에 여러 개의 state가 활성화 되어야 할 필요가 있다.

예를 들어 FAN이 두 개 있는 상태에서 각각의 FAN의 ON/OFF 상태를 모델링 한다면 FAN1과 FAN2의 상태가 각각 활성화된 상태여야 한다. 그림 10는 이를 모델링하는 과정에서 {PowerOn.FAN1}과{PowerOn.FAN2}는어느한쪽만활성화되면 FAN이 두 개가 동시에 동작하지 않을 것이다. 이를 위해서 {PowerOn.FAN1}과{PowerOn.FAN2}를동시에활성화시키는방법이이두 state를 parallel state로 만드는 것이다. 이를 위해서 그림 10와 같이 parallel state로 만들고자 하는 state를 포함하고 있는 superstate에서 마우스 오른쪽 클릭을 하여 Decomposiont →Parallel (AND)를 선택하면 그림 11와 같이 state의 경계가 점선으로 변하게 된다. 또한 state 오른쪽 윗 부분을 보면 숫자 1,2 가 적혀 있는데, 이는 동시에 활성화 되기는 하지만 실제로 컴퓨터에서 계산할때는 어쨌든 먼저 활성화되는 순서가 있어야 하므로 그 순서를 나타낸다. 이 순서는 parallel state의 위쪽 경계선의 높이에 따라서 자동으로 생성된다. 물론 transition의 우선 순위를 지정할 수 있는것과 똑같이 사용자가 직접 지정할 수 있다.

---

---

---

---

주의할 것은 parallel state 사이에는 어떠한 transition도 있어서는 안되며, 그림 11에 서처럼 {PowerOn}에서 parallel state로 어떠한 디폴트 transition도 없음을 기억해야 한다. 왜냐하면 {PowerOn}이활성화되면 {PowerOn.FAN1}과{PowerOn.FAN2}모두활성화되기때문에디폴트 transition이 있을 수가 없다. 하지만 parallel state인 {PowerOn.FAN1}과 {PowerOn.FAN2}내부에 exclusive state(베타적인 state, 지금까지 배웠던 state)가 있을 경우에는 어떤 state가 처음에 시작되어야 하는지 알려 줘야 하기 때문에 반드시 디폴트 transition이 있어야 한다.

6.1  로컬 이벤트를 생성해 보자

지금까지 이벤트는 Simulink로부터 받아 오거나 Simulink로 내보냈었다. 하지만 parallel state를 사용할 경우 로컬 이벤트를 생성해서 다른 parallel state의 transition을 발생시킬 수 있다. 그림 12를 보면 {A}, {B}, {C}는서로 parallel state이다. 하지만 그 사이에도 우선 순위가 있어서 그림에서 보는데로 실행된다. 외부에서 들어오는 이벤트는 e1 밖에 없으며, local_e1과 local_e2는 로컬 이벤트이다.

---

---

현재 이벤트 e1이 발생했을때 차트가 업데이트되면서 {A.SubA1}, {B.SubB1}, {C.SubC1}이활성화되어있는경우이벤트 e1이 발생하면 {C.SubC1}에서{C.SubC2}로 transition이 발생하게 된다. 이 때 transition action으로 local_e1을 발생하게 되면 {C.SubC2}를활성화하기전에다른 parallel state가 다시 체크된다. 즉 {A.SubA1}에서{A.SubA2}로 transition이 실제로 일어나서 {A.SubA2}가활성화된다. 그리고 마찬가지로 {B.SubB2}가활성화되고, 그 다음에 {C.SubC2}가활성화된다.

{C.SubC2}가활성화된상태에서이벤트 e1이 발생하게 되면, send(local_e2, B)를 실행시킨다. send(Event, state) 형태로 사용하며, 위와 다르게 특정한 state 안에만 로컬 이벤트를 발생시킨다. 즉 이번에는 {B}에만로컬이벤트인 local_e2가 발생하므로 {B.SubB2}에서 {B.SubB1}으로 transition이 일어나며, {A}의경우는아무런 transition이 일어 나지 않는다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

아래 내용은 마이크로소프트웨어 2008년 1월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다. 잡지 기사를 pdf로 보실려면 iMaso 홈페이지에 가셔서 구매하실 수 있습니다.

요 약 임베디드 시스템의 경우 이벤트에 의해 동작을 하는 시스템이 많으며, 이런 경우 State Machine으로 모델링할 수 있는 경우가 많다. State Machine에 대한 개념을 알아 보고 이를 Stateflow에서 어떻게 모델링하는 지 기본적인 것에 대해서 알아 보자.

제 1 절  State Machine 이란?

State Machine이란 좀 더 정확하게 말하면 Finite State Machine을 뜻한다. 이름에서 알 수 있듯이 유한 개의 상태가 존재하여 시스템이 그 상태들 사이로 어떻게 옮겨 다니는지를 모델링하는게 State Machine을 모델링하는 것이다(앞으로 상태라는 말보다 원래 단어인 state라고 사용하도록 하겠다).

정의로만 보면 어려워 보이는데, 간단히 예를 들어 보면, 간단한 State Machine의 경우 On/Off 스위치를 생각하면 된다. 그림 1처럼 두 개의 state(On과 Off)가 존재하며, 실제 스위치를 On/Off 하는 행위에 의해서 동작을 하게 되는 것이다.

역으로 다시 한번 State Machine을 생각해보면 현재의 인풋에 대해서만 반응하는 것이 아니고 현재 어떤 상태에 있느냐와 현재 인풋에 따라서 시스템의 반응이 결정되는 시스템을 State Machine이라고 한다.

---

---

1.1  필요한 용어 정의

State Machine에서 몇 가지 사용하는 용어에 혼란 스럽지 않게 여기서 정의 하고 가도록 하자.

1.1.1  State

State는 앞에서 언급했듯이 모델링하고자 하는 시스템에 미리 정의된 상태를 의미한다. 자동차의 자동 변속기를 모델링한다고 생각해 보자. 자동 변속기의 경우 D에 두면 내부적으로 기어의 단이 속도에 따라서 변경되게 된다. 이때 각각의 단을 바로 state로 생각할 수 있다. 예를 들어 3단이 활성화 된 경우에는 다른 단은 비활성화되므로, State Machine은 항상 활성화된 state를 기준으로 동작을 하게 된다.

1.1.2  Transition

Transistion의 경우 각 state상의 움직임을 얘기한다. State Machine 전체에서 논리적인 흐름을 말하는 것이다. 그림 1을 봤을때 On state에서 Off state로 변경되어서 On state가 비활성화 되고 Off state가 활성화 되는 과정에서 transition이 일어 났다고 한다. 물론 이러한 transition이 일어나기 위해서는 이를 유발시키는 행위가 있어야 하는데, 조건이라던지 아니면 이벤트 등이 이에 해당한다. 일반적으로 State Machine에서는 항상 기준이 활성화된 state에서 비활성화된 state를 활성화 시킬때 transition이 일어 났다고 얘기한다. 물론 자기 자신에게 transition이 일어 날 수도 있다.

1.1.3  Action

Action이란 주어진 순간에 실행되는 행동을 말한다. 간단한것 같지만, action의 경우 아래와 같이 여러가지가 있으며, 각각의 경우에 대해서 더 자세한 내용은 뒤에 실제 모델링시에 설명하도록 하겠다.

Entry action

state가 활성화될 때 실행 되는 action

Exit action

state가 비활성화될 때 실행 되는 action

During action

state가 활성화된 상태로 계속 있을때 실행 되는 action

Input action

현재 state와 조건에 따라서 실행되는 action

Transition action

transition이 발생했을때 실행 되는 action

Conditional action

지정한 조건이 만족될 때 실행 되는 action

제 2 절  간단한 자판기를 모델링해보자

앞에서 설명한 State Machine을 실제로 모델하기 위한 툴은 여러 가지 있을 수 있다. State Machine만을 위한 전용툴로부터 심지어 파워 포인트를 이용해서도 모델링을 할 수 있다. 본 연재에서는 Stateflow라는 제품을 사용해서 State Machine을 모델링하고 디버깅하며, 또한 기존에 가지고 있는 C 코드와 연동하는 법, 마지막으로 자동 코드를 생성하여 실제로 임베딩할 수 있는 코드를 만들어 내는 것으로 연재를 끝낼 예정이다.

2.1  제약 조건을 가진 자판기

간단한 자판기란 이해의 편의를 돕기 위해서 아래와 같은 제약 조건을 가진 자판기이다.

1. 자판기가 받아 들이는 동전은 한 가지 종류 밖에 없다.
2. 동전 3개를 받고 나면 더 이상의 동전은 받아 들이지 않고 돌려 준다.
3. 언제든지 취소가 가능하며, 취소할 경우 동전을 반환해야 한다.
4. 동전 3개가 있는 경우에만 캔을 선택할 수 있으며, 이 경우 캔을 돌려 주고 동전은 돌려 주지 않는다.

위와 같은 제약 조건을 가진 자판기를 모델링한다면 다음과 같은 사항을 먼저 생각하고 결정해야 Stateflow로 모델링할 수 있다.

1. {empty, oneCoin, twoCoin, threeCoin}앞으로 state의 경우 {}로감싸겠다.으로 총 4개의 state가 있어야 한다.
2. 각 state에서 insertCoin이라는 이벤트가 발생할 경우 현재 state에서 다음 state로 옮겨 간다.
3. {empty}제외하고각경우에 cancel 이벤트가 발생할 경우 현재 state에 가지고 있는 동전을 전부 되돌려 주고 {empty}로 state가 옮겨 간다.
4. {threeCoin}에서는 order 이벤트가 발생할 경우 캔을 하나 내보내고 {empty}로간다.

2.2  Stateflow로 모델링하자

Stateflow는 독자적인 프로그램이 아니라 Simulink2007년 8월호 Simulink를 이용한 플랜트 모델링상에서 하나의 블럭(Chart블럭)으로 존재하게 된다. 다시 말하면 Simulink가 있어야만 실행 가능하다는 점이다. Simulink에서 다른 블럭들과 똑같이 다루어 지며, MATLAB 명령어 윈도우에서 sfnew라는 명령어로 그림 2와 같이 빈 모델에 Chart 블럭이 포함된 상태로 모델을 열 수도 있다.

---

---

---

---

Chart 블럭을 더블 클릭하면 그림 3가 열려서 State Machine을 모델링할 수 있게 된다.

2.2.1  실제 모델링을 해보자

1. 그림 3의 왼쪽에 있는 State 아이콘을 한번 클릭하고 에디터로 마우스를 움직이면 사각형 박스를 보여 준다. Stateflow에서 이 사각형 박스가 하나의 state를 나타낸다. 이 박스를 에디터의 원하는 위치로 옮겨서 마우스 왼쪽 클릭을 하면 그 위치에 state를 표시할 수 있다. State 아이콘을 더블 클릭하면 에디터에서 왼쪽 클릭을 해도 해제되지 않으므로 여러개의 state를 그릴 경우 편리하며, 오른쪽 버튼을 클릭할 경우 해제된다. 또 각각의 state에는 다른 state와 구별되는 이름을 주어야 한다. 이름의 경우 state 안에 있는 ? 표시를 클릭하면 텍스트를 쓸 수 있으며, state의 이름을 만들때는 C에서 변수 이름을 만들때의 규칙과 같다. 예제에서는 앞에서 결정 했던 4개의 state의 이름을 사용한다.
2. 각 state간의 transition은 그림 4와 같이 state의 테두리에서 만들어서 그림 5처 럼 다른 state의 테두리에서 끝나게 된다. transition의 경우 방형성이 있으므로 transition이 시작되는 state와 끝나는 state를 결정해서 선을 연결하면 된다. state의 테두리 근처로 마우스를 가져가면 그림 4처럼 마우스 표시가 십자 형태로 변하며 이때 왼쪽 클릭한 상태에서 드래깅하면 선의 끝 부분이 그림 5처럼 원을 보여 주며, 이 원이 state의 다른 테두리 위에 오도록하여 드래깅했던 버튼을 떼어내면 transition이 생성된다.

   ---

   그림 4: transition의 시작

   ---

   ---

   그림 5: transition의 끝

   ---

3. {empty} 에서{threeCoin}까지 insertCoin이라는 이벤트가 발생했을때 하나씩 transition이 발생하는 것이다. 또한 cancel 이벤트가 발생했을때 각 state에서 가지고 있는 동전을 돌려 주어야 하며, threeCoin에서는 order 이벤트가 발생할 경우 캔을 내주어야 하며, insertCoin이벤트가 발생하면 1개의 동전만 되돌려 줘야 한다. 이벤트에 따른 transition을 만들때는 transition 위에 그 이벤트 이름을 적어 주면 된다. 그림 6와 같이 transition을 마우스로 왼쪽 클릭하면 그 위치에 ? 가 나와서 마우스로 ?를 클릭하면 그 위치에 텍스트를 쓸 수 있다. 실제로 transition 위에 쓸 수 있는 것은 이벤트 뿐만 아니라 조건문과 action등을 적을 수 있다. 그림 7와 같은 순서로 적으면 된다. 그림과 같이 이벤트와 조건이 모두 있는 경우 이벤트가 발생하고 조건이 참일 경우에 실제로 transition이 일어 나게 된다.

   transition 에 보면 / 다음에 쓰인 것이 transition action인데, 이는 transition이 실제로 일어 났을때 실행되는 action을 적는 것이다. {와}사이에적는것은 condition action으로 [와] 사이에 있는 condition이 참일 경우에 실행되는 action이다. condition action과 transition action에 차이는 다음회에서 설명하도록 하겠다.

   ---

   그림 6: transition에 텍스트 쓰는 법

   ---

   ---

   그림 7: transition에 쓰는 문법

   ---

4. 그림 8를 보면 {empty}에서{threeCoin}까지 state가 있으며, 각각의 state에서 insertCoin 이벤트가 있을 경우 transition이 생기며, {threeCoin}에서 insertCoin 이벤트가 다시 발생할 경우 동전을 다시 되돌려 주는 것을 알 수 있다. 또 한 order 이벤트가 있을때 캔을 돌려 주는 것을 볼 수 있다. {empty}에보면위에서내려오는 transition이 있는데, 이는 그림 3에서 default transition을 선택한 것인데, 용도는 처음 전체 차트가 실행되었을때 어느 state가 활성화 될지 알 수 없으므로 이를 표시하는 transition이다. 즉 차트가 처음 실행될때 {empty}가처음으로활성화되는것으로표시하는것이다.

   ---

   그림 8: 간단한 자판기에 대한 모델

   ---

5. Chart내에서 모델링을 할때 사용하는 모든 이벤트와 데이타의 경우 실제로 시물레이션을 하기 전에는 선언을 해줘야 한다. 그림 8를 봤을때 여러 가지 이벤트가 있고, n_coin과 n_can 과 같은 결과를 저장하는 변수들이 있다. 시물레이션을 위해서는 이벤트를 외부로부터 받아 들여야 하며, 또한 결과를 직접 볼 수 있어야 한다. 이를 위해서는 Simulink와 연결을 해야 하며, Simulink에서는 그림 2와 같이 chart 전체를 하나의 블럭으로 여기므로 Simulink의 다른 블럭들과 시그널을 연결하기 위해서는 chart 블럭에 인풋과 아웃풋을 위한 포트가 존재해야 한다. 때문에 chart 내부에서 각각의 이벤트와 변수등을 선언해서 어떤것이 인풋이고 아웃풋인지를 알려 줘서 chart 블럭에 인풋과 아웃풋을 표시해야 한다.

   Chart내의 인풋과 아웃풋을 chart블럭에 표시하기 위해서는 그림 9와 10와 같은 메뉴를 사용해서 선언하게 된다. 그림 9와 같은 메뉴에서 ”Input from Simulink...”메뉴를 선택하면 그림 11와 같은 윈도우가 생긴다. 여기서 Name 부분에 insertCoin으로 바꾸고 Trigger 메뉴에서 ”Either”를 선택한다. cancel과 order도 똑같은 방법으로 선언한다.

   ---

   그림 9: event를 표시하기 위한 메뉴

   ---

   ---

   그림 10: data를 표시하기 위한 메뉴

   ---

   ---

   그림 11: Simulink로부터 이벤트를 받아 오는 것을 선언하는 윈도우

   ---

   그림 10에 있는 메뉴를 이용하여서 이번에는 데이타에 대해서 선언을 한다. 데이타의 경우 내부적으로 사용하고 있는 변수와 외부에서 인풋으로 들어 오는 값이 없으므로 아웃풋인 n_coin과 n_can을 만들게 된다. 이렇게 데이타를 선택하면 chart블럭 자체가 그림 12와 같이 바뀌게 된다. 주의해서 보면 아웃풋의 경우 실제 아웃풋 갯수인 2개의 포트가 생겼고, 블럭의 위쪽에 생긴 것이 이벤트를 외부에서 받아 들일 수 있는 포트인데, 3개의 이벤트를 받아 들임에도 불구하고 포트는 한개밖에 없다. 이는 Chart블럭 자체가 항상 이렇게 아웃풋의 경우 이벤트/데이타 모두 외부로 내보내기 위한 포트가 그 갯수 만큼 생기지만, 인풋 이벤트의 경우 항상 위쪽에 포트가 한개밖에 생기지 않는다. 인풋 데이타의 경우 블럭의 왼쪽에 인풋 갯수만큼 포트가 생성된다.

   ---

   그림 12: Chart블럭에 생긴 이벤트 인풋 포트와 아웃풋 포트

   ---

2.2.2  Simulink와 연계된 모델

State Machine에 대한 모델링은 다 했지만, 이를 시물레이션하기 위해서 필요한 것은 인풋과 아웃풋을 Simulink 블럭을 이용하는 것이다.

1. 예 제로 하고 있는 모델의 경우 한개 이상의 이벤트를 인풋으로 해야 하는데, chart블럭에는 이벤트를 인풋으로 할때 생기는 포트가 1개 밖에 없으므로 Simulink 기본 라이브러리에 있는 Mux 블럭을 사용해서 들어오는 시그널을 한개로 묶어서 chart 인풋으로 만들어야 한다. 그리고 나오는 아웃풋의 값을 보기 위해서 Display 블럭을 사용한다. 그림 13를 보면 완성된 자판기 모델을 보여 준다.

   ---

   그림 13: 완성된 자판기 모델

   ---

   이벤트의 경우 rising, falling, either edge가 있다. 이벤트가 생겼는지의 여부를 들어 오는 값의 edge 상태에 맞춰서 보는 것이다. 그림 14에서와 같이 들어 오는 인풋이 있을때 0에서 1로 올라 갈때 이 부분이 rising edge라고 하며 반대로 1에서 0으로 내려 갈때를 falling edge라고 한다. 이 두가지 경우를 다 포함하는 것이 either edge라고 한다. 즉 either edge로 이벤트를 설정하게 되면, 그림 14의 경우 4초에 한번 이벤트(rising edge)가 발생하며, 6초에 또 한번 이벤트(falling edge)가 발생한다.

   ---

   그림 14: 이벤트의 발생에 대한 내용

   ---

   이벤트를 Mux로 묶을 경우 Mux 블럭에 위에서부터 몇 번째로 들어 오는 것인지가 이벤트를 연결할때 사용되는 포트와 연관되어 있다. 그림 11에 서 이벤트 이름을 적는 칸 밑에 보이는 포트 번호이며, 여기서 1번이면 Mux 블럭에 첫 번째 포트로 들어 오는 시그널이 연결되는 것이다. 앞에서 셋팅할때 insertCoin을 포트 1번, cancel을 2번, order를 3번에 연결해 놨다.

   chart블럭에 인풋, 아웃풋을 표시하고 나서 제대로 되어 있는지를 포기 위해서는 모델 익스플로러라는 프로그램을 띄워서 볼 수 있다. 이는 Simulink 모델 에디터나 chart 에디터에서 View 메뉴 아래에 있는 Model Explorer 라는 메뉴를 실행 시키면 그림 15와 같이 볼 수 있다. 실제로 모델 익스플로러는 Simulink 모델에 대한 모든 셋팅이나 파라메타 변경등을 한 곳에서 할 수 있게 해주는 편리한 도구이다.

   ---

   그림 15: 모델 익스플로러

   ---

2.2.3  시물레이션을 해보자

자 이제 실제로 시물레이션을 해서 내가 원하는 동작으로 동작하는지 보는 일만 남았다. Stateflow로 State Machine을 만들면 또 하나의 장점이 이벤트나 인풋에 대해서 실제로 state가 어떻게 움직이는지 에니메이션으로 볼 수 있다는 장점도 있다. 이를 위해서 Stateflow에서 제공하는 디버거에서 셋팅을 하는데, 그림 16에서 보는 것처럼 에니메이션을 위해서 몇 초정도의 시간을 지연시킬지를 결정할 수 있다. 지연을 안 시키면 너무 순식간에 지나가는 경우에 이 시간을 지연할 수 있지만, 실제 전체 모델을 실행하는데 시간이 더 걸리므로 디버깅 시에만 사용하는게 좋다.

---

---

이제 실제로 시물레이션을 해보면 그림 17와 같이 {empty}가활성화되어서파란색으로표시가된다. 이 상태에서 insertCoin이벤트(그림 13에서 insertCoin 스위치 블럭을 더블 클릭)를 발생시키면 그림 18와 같이 {empty}는비활성화되고 transition을 따라서 {oneCoin}이활성화된다. 그림 19는 {twoCoin}에서 cancel 이벤트가 발생했을 경우 transition을 따라서 {empty}로가는과정을순간적으로캡쳐한것이다. 이와 같이 에니메이션으로 현재 어떤 state에 있고, 어떤 transition을 따라서 움직이는지를 알 수 있으므로 State Machine을 모델링해서 시물레이션하기 위한 최적의 조건을 제공한다.

---

---

---

---

---

---

여기까지는 기본적인 내용을 설명해서 State Machine을 모델링할때 시물레이션의 강력함을 제대로 느끼지 못했을수도 있다. 하지만, 앞으로 진행되는 연재를 보면 점점 더 시물레이션의 강력함을 느끼게 될 것이다. 그리고 시물레이션으로 모델을 검증된 상태에서 자동으로 코드를 생성해서 실제로 임베딩할 수 있는 코드를 가지게 될때의 장점도 아울러 알게 된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

요 약 지금까지는 시물레이션을 위해서 플랜트와 제어기를 모델링했다. 시물레이션은 말 그대로 PC 상에서 테스트 하는 것이니, 이제는 실제로 실시간 시스템에서 제어기의 성능을 테스트 해보자. 그러기 위해서 필요한 자동 코드 생성툴등을 살펴 보도록 하자.

제 1 절  자동 코드 생성

시뮬레이션으로 제어기 설계를 끝냈으면, 이제 실시간으로 성능을 테스트 해야 할 시간이 됐다. 실시간으로 성능을 테스트 하기 위해서는 먼저 실시간으로 테스트 하기 위한 C 코드가 있어야 한다. C++의 경우에도 임베딩하는 경우가 있지만, 여전히 C 언어가 임베디드 소프트웨어로 가장 많이 사용되고 있다. 제어기나 복잡한 알고리즘을 시뮬레이션으로 테스트를 끝내고 이를 바탕으로 다시 처음부터 C 코드를 작성하게 되면 엄청난 시간과 노력이 들게 된다. 이럴때 사용할 수 있는 코드 생성에 대해서 살펴 보도록 하자.

1.1  자동 코드 생성의 유용성과 효율성

자동 코드 생성 툴의 유용성에 대해서 예를 들어 설명하면, Flight Code라는 용어를 쓰는데, 이는 항공기에서 비행을 위해서 작성하게 되는 모든 소스 코드를 일컫는 말이다. 국방 항공쪽에서 세계적으로 유명한 Lockheed-Martin에 따르면 이런 Flight Code는 천5백만 LOC를 넘는다고 한다. 국방/항공쪽은 잘못되면 크나큰 인명의 손실을 입기 때문에 소스 코드를 작성할때 수도 없이 많은 테스트를 해야 한다. 그리고 개발 단계에서는 아직 하드웨어가 완성되어 있지 않으므로 시뮬레이션을 통해서 이런 작업을 하게 되는데, 자동 코드 생성 툴을 사용하지 않게 되면 시뮬레이션으로 테스트한 알고리즘을 다시 처음부터 C로 작성하는 것이므로 시간과 비용의 소모가 엄청나게 된다. 때문에 자동 코드 생성 툴을 쓰게 되면 이런 C 코드 생성에 필요한 시간과 비용을 절약하게 된다.

SAE(Society of Automotive Engineers)는 자동차나 비행기등 엔진등의 힘에 의해서 움직이는 것들 취급하는 엔지니어들을 위한 가장 큰 협회중에 하나이다. 2004년에 Visteon 이라는 회사가 자동 코드 생성된 코드와 직접 손으로 작성한 코드를 비교한 논문을 제출했는데, LOC 비교가 아니라 생성된 코드를 위해서 필요한 ROM과 RAM의 사이즈를 비교했다. 표 1에 그 결과가 나와 있듯이 손으로 작성한 코드 보다 낳은 결과를 보임을 알 수 있다. 대부분 다른 회사에서 자동 코드 생성 툴을 썼을때의 결과를 보면 실제로 직접 작성한 코드와 비슷하거나 혹은 조금 안 좋은 결과를 보여 주지만, 사용되는 비용과 시간을 생각해 보면 충분히 자동 코드 생성 툴들을 이용할 만하다.

1.2  자동 코드 생성 툴

Simulink 모델에 대한 자동 코드 생성툴의 대표적인 소프트웨어가 같은 회사인 MathWorks사 제품인 Real-TIme Workshop(RTW라 칭한다)이다. 또 다른 소프트웨어로서 dSpace사의 TargetLink가 있다. 작년부터 MathWorks사는 소프트웨어를 6개월에 한번씩 출시하고 있는데, RTW의 경우 Simulink의 버전이 변경됨과 동시에 변경된 버전을 지원하고 있지만, TargetLink의 경우 Simulink 버전의 변경을 같이 따라가지 못하고 지난 버전을 지원한다. TargetLink의 경우 생성되는 코드를 사용자가 원하는 형태로 어느 정도 수정할 수 있는 기능이 있는데, RTW의 경우 이런 사용자의 수정을 할 수가 없도록 되어있다. 이런 작업을 하기 위해서는 Real-Time Workshop Embedded Coder(RTW-EC라 칭한다.)를 따로 구매해야 한다. 본 기사에서는 필자가 익숙한 RTW와 RTW-EC를 이용하여 설명하도록 하겠다.

---

---

복잡한 모델을 이용하여 설명하면 전체 코드를 보여 주지 못하므로, 그림 1와 같은 간단한 사칙 연산을 하는 모델을 만들어서 RTW와 RTW-EC를 이용하여 코드를 생성해서 어떤 차이가 있는지를 확인해 보자.

1.3  Real-Time Workshop

---

---

---

---

RTW를 사용하기 위해서는 그림 2와 같이 선택하면 그림 3와 같은 윈도우가 보여 지므로, 화살표로 설명한 부분중에서 System target file 부분에 있는 grt.tlc 파일이 코드가 어떻게 생성되기를 바라는지에 대한 내용을 미리 셋팅한 것이다. 왼쪽에 있는 메뉴에서 Real-Time Workshop 메뉴 아래에 생성되어 있는 메뉴는 System target file을 선택함에 따라 다르게 나타날 수 있다. RTW-EC의 경우 더 많은 메뉴가 생성된다.

---

---

이제 Generate code 버튼을 클릭하면 그림 4와 같은 윈도우가 생성되면서 생성된 코드를 볼 수 있게 해준다. 코드를 생성하고자 하는 모델의 이름이 sc.mdl 파일이기 때문에 sc.c와 같이 모델의 이름이 붙은 파일들이 생성된다. 소스 코드는 sc_grt_rtw 라는 폴더 안에 포함되며, html 리포트는 html 디렉토리 밑에 sc_codegen_rpt.html 파일을 열면 된다. 여기서 sc.c 파일에 실제로 모델의 알고리즘이 들어 있는 함수가 있으며, 함수의 이름을 어느 정도 짐작할 수 있을 것이다. 리포트 윈도우에서 함수에 관련된 부분만 보게 되면 아래와 같다. 예상한것처럼 함수의 이름은 sc_output 이다. 생성된 코드에서 주석 부분은 Simulink 모델중에서 어떤 블럭과 연계되어 있는지를 보여 준다. 물론 옵션으로 이런 주석 부분을 없앨 수도 있다.

모델에서코드를생성하게되면, 옵션을 선택해서 간단하게 만들 수 있는 코드는 최대한 간단하게 만들수 있는데, 아래의 코드는 주석문을 넣지 않고, Block Reduction과 Signal Reuse등의 옵션을 체크해서 나온 결과를 보여 준다.

1.4  Real-Time Workshop Embedded Coder

지금까지 보여 준 것은 RTW를 이용해서 생성된 코드를 보여 줬는데, 실제로 RTW는 쉽게 이해하자면, Hardware-In-the-Loop(HIL)이나 Rapid Control Prototyping을 위한 코드를 생성해 준다. 실제로 임베딩하기 위해서 코드를 생성해야 하면, RTW-EC를 이용해야 한다. RTW-EC는 이름이 의미하는 것처럼 임베딩되기 위한 최적화된 코드를 생성해 준다. 아래 표 2는 그림 1에 있는 모델을 RTW와 RTW-EC로 코드를 생성했을때 생기는 파일들과 LOC(Line Of Code)이다. rtwtypes.h 파일이 RTW-EC에서 더 많은 LOC를 보여 주는 것은 RTW에서 생성된 파일은 다른 헤더 파일을 인클루드 하고 있기 때문이다. RTW-EC에서 생성된 파일은 다른 파일을 인클루드 하더라도 ANSI C 헤더 파일만을 인클루드 하기 때문에 LOC가 커지는 것이다.

RTW-EC는 기본적으로 다른 시스템에 C 코드와 합쳐서 실행되는 것을 목표로하는 코드를 생성하므로 인풋 인자를 가지는 함수 형태로 만들수 있다. 아래 코드는 인풋 3개와 아웃풋 1개를 가지고 게인값을 변경시킬수 있도록 함수의 인자로(총 5개) 받을 수 있도록 생성된 함수이다. 이와 같이 함수 형태로 만들어서 다른 환경, 즉 임베딩 시키고자 하는 환경에서 사용할 수 있도록 만들어 주는 제품이 RTW-EC이다.

그러면 RTW-EC로 생성된 코드는 어느 정도 정확성과 효율적일지가 궁금해진다. 이는 이미 수 많은 프로젝트에 사용되어서 그 효율성과 정확성은 어느 정도 입증되었다고 본다.

제 2 절  시뮬레이션과 실시간 테스트

앞 연재에서 시뮬레이션의 중요성을 강조했는데, 이제는 실제 하드웨어에서 실시간으로 플랜트를 제어할때도 같은 성능이 나오는지를 테스트 해야 한다. 이미 알고 있듯이 실시간으로 제어 하기 위해서는 윈도우 XP와 같은 범용 운영체제를 사용하지 않고, 실시간 성능을 지원하는 운영체제를 써야 한다. 가장 많이 쓰는 실시간 운영 체제는 윈드리버사의 VxWorks이다. 그 외에 리눅스에서 실시간 성능을 구현한 MontaVista도 있고, 교육용으로 많이 쓰는 uC-OSII 등 선택의 폭이 여러 가지 이다.

범용 운영체제와 다르게 이런 실시간 운영체제는 특정한 보드에 포팅하거나 혹은 입출력을 위한 보드에 대한 드라이버는 직접 작성하는 수고를 해야 한다. 이런 작업은 하드웨어 종속적인 작업이라서 항상 수작업이 필요한 작업이다. 시뮬레이션으로 제어기 설계를 완료하고 이제 실시간으로 성능을 테스트 하기 위해서 다시 수작업으로 이런 일들을 해야 하므로 역시나 시간 소모적인 작업이다.

그럼 Simulink로 만든 모델을 실시간으로 빠르게 테스트 해보고 싶은데, 어떻게 하면 될까? 여기서 Rapid Control Prototyping(RCP)가 나오는 것이다.

2.1  Rapid Control Prototyping

RCP는 엔지니어가 시뮬레이션을 통해서 테스트한 알고리즘을 쉽고 빠르게 실제 하드웨어와 연결하여, 실시간으로 알고리즴을 테스트할 수 있는 방법을 말한다. 여기서 쉽고 빠르게가 강조 되는 것으로 알 수 있듯이, 시뮬레이션시에 사용한 모델을 그대로 자동 코드 생성 툴로 코드를 생성하여, 실시간 운영체제와 IO를 위한 디바이스 드라이버까지를 제공받아서 사용하는 것이다. 즉 엔지니어가 개발한 알고리즘을 다시 C로 코딩하는 작업과 실시간으로 하드웨어를 돌리기 위한 실시간 운영체제의 포팅과 디바이스 드라이버 작업을 하지 않고, 하드웨어의 연결로 빠르고 쉽게 알고리즘을 테스트할 수 있도록 하는 것이다.

이와 같은 RCP의 경우 실제로 제공되는 제품들이 있다. 상용 제품과 오픈 소스 제품군으로 볼 수 있는데, 상용 제품군은 MathWorks사의 xPC Target, dSpace사의 AutoBox, National Instruments사의 LabView등이 있다. RCP 환경은 그 특성상 모델링 툴과 밀접한 연관을 가지고 있는데, NI사의 제품을 제외한 대부분의 RCP 상용 제품은 Simulink로 모델링하며, RTW로 생성된 코드를 자동으로 각 하드웨어에 맞는 디바이스와 실시간 운영체제와 인터페이싱하도록 구성된다. 오픈 소스는 Scilab/Scicos와 Linux RTAI를 활용한 방법등이 있으나, 전체가 패키지 형태로 묶여 있는 것은 아직 없는 실정이다.

2.2  Hardware-In-the-Loop

Hardware-In-the-Loop(HIL)은 간단하게 정의 하자면 실제 플랜트 대신에 수학적 모델링을 통해서 나온 모델을 실시간으로 실행시켜서 외부 인터페이스를 붙여서 플랜트 이외에 부분에 실제 하드웨어가 있는 것처럼 여기도록 하는 것이다. 즉 플랜트의 동역학 부분을 소프트웨어로 대체하는 것이 HIL의 개념이다.

HILS에서도 결국엔 RCP장비에 임베딩시켜서 실행되는 것이므로 앞에서 설명한 RCP장비를 HILS(Hardware-In-the-Loop System)에서 사용할 수도 있다. 단지 자동 코드 생성되는 모델이 제어기인지 아니면 플랜트인지에 따라서 다른 것이다. 예전에는 제어기도 하드웨어로 구성했었으므로, RCP는 HILS에 포함되는 개념으로 생각해도 된다.

---

그림 5를 보면 RCP의 경우 제어기 모델을 자동 코드 생성을 통해서 하드웨어에 임베딩해서 실제 플랜트를 실시간으로 제어하는 경우이고, HIL의 경우 수학적으로 모델링된 플랜트를 실시간으로 실행하여 제어를 위한 로직등은 실제 하드웨어에 임베딩된 제어기로 제어하는 것으로 실제 하드웨어 플랜트 없이 하는 경우이다.

2.3  MBD를 활용한 실제 하드웨어 제어

이제 실제 소프트웨어에서 RCP로 제어하는 것을 예로 들어 보자. 여기서 예로 들 예제는 그림 6와 같이 UAV(Unmanned Aerial Vehicle)의 전체 모델중에 Carnard라고 하는 부분을 모델링하여 제어기 설계하고, 시물레이션을 통해서 그 성능을 검증하고, RCP환경의 하나인 xPC Target을 이용하여 제어기의 성능을 확인할 것이다.

---

---

Carnard는 DC 모터를 이용하여 제어 되고 있으므로, 전체 시스템을 모델링할때 필요한 부분이 DC 모터에 대한 부분이 필요하며, DC 모터에 가해지는 힘은 대기중의 저항이 큰 영향을 주므로 UAV의 특성상 대기에 대한 모델링도 필요하다. 이러한 것들을 전부 Simulink와 그 외 다른 툴을 이용하여 모델링을 한다. 플랜트와 제어기를 전부 모델링한 후에 시뮬레이션으로 제어기의 게인 값들을 선정하고, xPC Target을 이용하여 시뮬레이션 했을때의 결과와 실시간으로 하드웨어를 제어 했을때의 결과를 비교해 보도록 하겠다.

2.3.1  DC 모터 모델링

DC 모터는 그림 7와 같이 단순화 할 수 있으며, 이를 수학적 모델링을 하지 않고, Simulink의 add-on제품중에 플랜트 모델링을 쉽게 할 수 있도록 도와주는 Physical Modeling Tool을 이용하여 모델링을 하게 되면 그림 8와 같다. Aerodynamic Load는 DC 모터에 저항처럼 작용을 하지만, UAV의 고도에 따라서 달라 지는 점이 있다. 이런 대기의 모델을 미리 정해 놓은 것이 있어서 여기서 모델링은 ISA Atmosphere 모델을 이용하였다. 이 부분을 C로 직접 작성할 수도 있지만, 역시나 Simulink의 add-on중에 하나를 이용하면 그림 9와 같이 간단하게 하나의 블럭으로 표시할 수 있다.

---

---

---

---

---

2.3.2  증폭기 모델링

실제로 하드웨어를 구성하게 되면 모터를 구동할때 증폭기를 사용하게 된다. 증폭기의 특성을 직접 실험으로 테스트 해보면 그림 10와 같이 steady state 일때는 원하는 만큼 증폭이 되지만, transient state 일때는 오버슛도 보이고 하기 때문에 안정화 되기전에는 시스템에 원치 않는 영향을 미친다. 따라서 시뮬레이션할때도 이 부분이 고려되어야 한다. 증폭기를 수학적 모델링하는 것은 힘들기 때문에 이미 테스트한 입력값과 측정된 출력값을 이용하여 모델링을 한다. System Identification Toolbox를 이용하면 이런 과정을 좀 더 단순하고 간단하게 해준다.

---

---

2.3.3  Open-loop System

이런 모델링을 다 모아서 Simulink 모델로 합치고, 같은 역할을 하는 부분끼리 서브 시스템으로 묶으면 그림 11와 같이 나타난다. 이런 Open-loop 모텔이 제어 하고자 하는 플랜트가 되는 것이다. 이와 동등한 하드웨어 사진을 보면 그림 12

---

---

---

---

2.3.4  제어기 설계 및 RCP

이제 실제로 알고리즘 개발자가 개발해야 하는 제어기를 설계 하는 것이다. 당연히 Closed-loop으로 해야 하므로, Closed-loop 시스템으로 만들고 제어기를 개발할때는 지난 연재에서 설명한 툴들을 이용하여 설계 하게 된다. Simulation으로 원하는 각도로 입력값을 줬을때 그와 같은 출력값이 나오도록 제어기가 설계되었으면, 이제 실시간으로 테스트 해야 한다.

실시간 테스트는 xPC Target이라는 툴을 이용하여 하게 되는데, 일반적인 PC에서 운영될 수 있는 xPC Target Real-Time Kernel이라는 실시간 운영체제를 제공한다. 실시간으로 외부 하드웨어와 인터페이스해야 하므로 A/D보드등이 필요한데, xPC Target에서 지정한 보드를 이용하면 이 보드에 대한 모든 소스 코드를 제공하므로 사용자가 이런 디바이스 드라이버 작성에 대한 고민도 할 필요가 없다. xPC Target이 다른 RCP 툴과의 차이점은 일반 PC를 사용하므로 만약 xPC Target에서 지정한 보드이외의 보드를 써야할 경우 드라이버 직접 작성해서 계속 재 사용할 수 있다는 장점이 있다. 즉 회사에서 직접 만든 보드의 경우 한번은 드라이버를 작성해야 하지만, 그 뒤로 그 보드를 쓸데는 계속해서 재 사용이 가능한 것이다. 다른 RCP를 지원하는 소프트웨어는 이런 개방적인 형태로 되어 있지 않은게 대부분이다. 즉, 자신들 만의 하드웨어만을 써야 하는 것이다.

Simulink로 만든 모델을 RTW를 이용하여 코드 생성하며, Microsoft Visual C++ 컴파일러를 이용하여, 실행 파일을 만들어서 Target PC에서 실행할 수 있도록 다운로드 한다. 즉 모델을 만드는 호스트 PC(Windows XP 이상)가 있으며, 실시간으로 실행되는 타겟 PC(xPC Target Real-Time Kernel)가 있어야 한다. 두 PC는 서로 TCP/IP 로 연결된다. 타겟 PC의 조종은 전부 호스트 PC에서 Simulink와 MATLAB 환경에서 하게 되며, 타겟 PC를 조정하기 위한 xpcexplr 라는 GUI 환경을 제공한다.

그림 13를 보면 시뮬레이션 결과 실제 하드웨어 테스트한 결과가 거의 유사함을 알 수 있다. 이와 같이 MBD를 이용하여 최대한의 시뮬레이션을 일반적인 PC 상에서 수행하고, 어느 정도 만족할 만한 결과가 나왔을때 RCP로 실시간에서의 성능을 테스트 하며, 실제로 보드와 같은 환경에 임베딩할때는 RTW-EC로 C코드를 생성해서 사용하면 된다.

---

---

이상과 같이 총 4회에 걸쳐 MBD에 대한 내용을 소개했는데, MBD를 제품 개발시에 도입하게 되면 시간과 비용의 절감을 가져 올 수 있으며, 개발자의 입장에서도 개발을 하기 위한 여러 가지 툴을 사용해서 최대한 편리한 환경에서 개발할 수 있으므로 한번쯤은 도입을 생각해 보기 바란다. 각 연재에서 설명한 툴등은 훨씬 더 많은 기능들이 있으므로 궁금한 내용이 있으면, 각 회사에 연락하거나 필자에게 연락하면 최대한 자세히 알려 주겠다. MBD를 이용한 개발은 국내 소프트웨어 개발자들에게는 생소할 수 있지만, 구글과 같은 써치 엔진에서 MBD를 검색해 보면 얼마나 많은 곳에서 사용하는지 알 수 있을 것이다.

RTW와 RTW-EC를 위한 모델과 소스 코드는 이달의 디스켓에 포함되어 있으니 생성된 코드가 어떤지 궁금하면 소스 코드를 열어 보기 바란다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

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

Simulink를 이용한 제어기 설계

요약

실제로 임베디드 소프트웨어를 설계할 때가 왔다. 앞 연재까지에서는 임베디드 소프트웨어를 컴퓨터 상에서 설계하고 테스트 하기 위해서 필요한 환경을 만들었으니, 이제 실제로 임베딩할 알고리즘을 설계 하는 것이다. 기본적인 제어기에 대한 내용과 Simulink를 활용할 경우에 이를 위한 add-on 툴이 있으므로 이에 대한 간략한 소개를 하고자 한다.

제 1 절  제어기란?

제어기는 이름이 말하는 그대로 뭔가를 제어하는 장치를 말한다. 임베디드 소프트웨어의 경우 간단한 하드웨어인 핸드폰부터 우주로 나가는 위성등에도 포함되어서 플랜트를 제어하는 장치/소프트웨어를 말한다. 초기에 제어기가 나왔을때는 하드웨어적인 장치가 대부분이었지만, 요즘은 대부분 임베딩되는 소프트웨어를 이용해서 하게 된다. 이런 임베딩되는 제어기 소프트웨어는 구현해서 테스트 하기 위해서는 제어하고자 하는 플랜트가 있어야 하며, 이 플랜트에 직접적으로 연결되어 있는 인터페이스가 있어서 임베딩되는 소프트웨어가 플랜트를 어떻게 제어 하는지를 테스트 하게 된다. 앞 시간의 기사에서 소개했던 플랜트의 모델링의 경우 이런 하드웨어 없이 컴퓨터상에서 소프트웨어적으로 시뮬레이션할 수 있는 환경을 제공해 준다.

1.1  알아야 할 용어들

제어기에 대한 내용을 진행하기 전에 몇 가지 꼭 알아야할 내용이 있다. 일반적으로 쓰이는 인풋과 그 인풋에 대한 결과를 해석할때 사용하는 용어등을 먼저 알아 보자.

1.1.1  Standard Input

일반적으로 제어기를 설계했을때 제대로 설계되었는지를 체크하기 위해서 사용하는 인풋 값들이 있으며, 이를 표준 인풋이라고 한다.

Step Input

스 텝 인풋의 경우 제어에서만 사용되는 것이 아니고, 거의 모든 엔지니어링 측면에서 사용되고 있다. 시스템에 스텝 인풋을 인풋으로 줬을때 나오는 아웃풋을 step response 라고 한다. 단위 스텝 인풋에 대해 수학적으로 표기하면 식 1와 같이 표현된다.

(1)

Ramp Input

램프 인풋의 경우 식 2와 같이 단위 스텝 인풋을 포함한 수식으로 표현할 수 있다. 식에서 보는것 같이 램프 인풋의 경우는 단위 스텝 인풋의 적분을 한 경우이다.

(2)

1.1.2  System Metrics

시스템의 특성을 나타내는 방법은 여러 가지 있지만, 그중에서 제일 많이 쓰이는 것들을 살펴 보면 다음과 같다. 아래에 나와 있는 특성은 시스템에 인풋을 단위 스텝 인풋으로 주었을때 의미를 가진다.

Steady State(정상 상태)

시스템에 인풋으로 단위 스텝 인풋을 주었을때 시간 t = ∞인경우, 시스템의 아웃풋을 나타낸다. 실제로 t = ∞라는게있을수가없으므로수학적으로시스템의아웃풋을계산한다.

Rising Time(상승 시간)

시스템의 아웃풋이 0으로부터 특정한 값까지 도달하는데 걸리는 시간을 의미하는 것으로 보통 초기 값에서 타겟 값의 90%까지 도달하는 시간을 말한다.

Overshoot(오버슛)

시스템의 아웃풋중에서 원하는 아웃풋인 타겟 값보다 크게 나온 값들을 말한다.

Percent Overshoot

시스템의 아웃풋중에서 가장 큰 값(y_p)과 정상 상태일때의 값(y_ss)을 이용하여 식 3와 같이 나타낸다.

(3)

Steady-State Error(정상 상태 에러)

일반적으로 시스템은 원하는 타겟 값으로 100% 맞게 동작하지 않는다. 때문에 정상 상태에 도달하게 되면 보통 원하는 타겟 값과 오차가 생기며, 이를 정상 상태 에러 라고 한다.

Settling Time(정착 시간)

시스템의 아웃풋은 일반적으로 정상 상태에 도달하기 전에는 진동하는 경향이 있다. 시스템이 정상 상태까지 도달하기 까지 걸린 시간을 정착 시간이라고 한다.

지금까지 설명한 내용을 그림 1에 표시하였다.

---

---

1.2  Open-loop과 Closed-loop 제어기

---

---

---

---

제어기를 구성할때는 크게 두가지 경우로 구성할 수 있다. 그림 2와 같이 플랜트의 아웃풋을 측정하지 않고 제어기의 인풋을 결정하는 경우(Open-loop 제어기)가 있으며, 그림 3와 같이 플랜트의 아웃풋을 측정해서 원하는 결과 값인지를 체크해서 새롭게 제어기의 인풋을 결정하는 경우(Closed-loop 제어기)가 있다.

1.2.1  Open-loop 제어기

Open-loop 제어기의 경우 외부의 신호를 측정해서 원하는 값에 도달했는지에 대한 체크를 하지 않는다. 이와 같이 제어의 정밀도가 중요하지 않거나, 플랜트의 특성이 매우 잘 알려져 있어서 플랜트에 특정한 인풋을 줬을때 그 아웃풋을 충분히 예측할 수 있을 경우에 사용하게 된다. Open-loop 제어 시스템은 시스템이 간단히 구성되므로 가격 면에서 있어서도 유리하게 구성할 수 있어서, 아직까지도 사용되고 있는 제어 시스템이다.

1.2.2  Closed-loop 제어기

Open-loop 제어기의 경우 플랜트가 원하는 아웃풋을 내는지 확인을 하지 않기 때문에 정밀한 제어등에는 사용할 수가 없다. 실제로 존재하는 플랜트의 경우는 외부의 잡음등이 포함되기 때문에 항상 우리가 원하는 데로 제어가 되지를 않는다. 때문에 이런 아웃풋을 피드백해서 제어기에서 필요한 만큼 제어기의 아웃풋을 수정해서 플랜트로 보내게 되며, 이러한 작업을 하는 제어기가 Closed-loop 제어기 이다.

제 2 절  제어기에 대한 소개

하드웨어를 제어하는 일반적인 제어기는 필요한 정밀도에 의해서 제어기를 선택하게 된다. 일반적으로 Closed-loop 시스템에서 가장 많이 사용하는 제어기는 PID 제어기이다. 또한 최적 제어(Optimal Control), 강인 제어(Robust Control), 뉴럴 네트웍(Neural Network)등 아주 많은 제어기가 있다. 다른 제어기에 대한 내용보다 여기서는 PID 제어기에 대한 소개와 간단한 모델에 적용하여 그 특성을 알아보자.

2.1  PID 제어기

일반적으로 Closed-loop 시스템에서 가장 많이 사용하는 제어기는 PID 제어기이다. PID제어기에서 PID란 Proportional-Integral-Derivative 를 뜻하는 것으로 세 부분으로 나누어서 생각할 수 있는 제어기이다. 그림 3 에서 플랜트의 인풋으로 들어 가는 값을 식 4라고 하면, Closed-loop의 제어기는 이 e(t)의 값을 이용하여 플랜트를 제어 하게 된다.

(4)

2.1.1  P 제어기

Proportional(비례) 제어기를 뜻하는 P 제어기는 현재 원하는 인풋과 측정된 아웃풋의 차이에 게인이라고 하는 값을 곱하는 제어기이다. 즉 e(t)에 필요한 값을 곱하는 제어기 이다. 이 제어기를 생각할때는 사람이 자동차 속도를 맞춘다고 생각하면 된다. 시속 100 km를 맞춰서 움직인다고 생각해 보면 현재 속도가 100 km 보다 얼마나 빠른지 혹은 느린지를 사용자가 보고 필요한 만큼 가속 페달을 밟는 양을 조절한다. 현재 속도가 60 km 이면 원하는 속도 100 - 60 = 40인 40 km에 달하도록 가속 페달을 밟아야 한다. 여기서 제어 게인을 얼마로 하느냐에 따라서 실제로 플랜트로 들어 가는 값이 결정이 된다. P 제어기는 이와 같이 원하는 결과 값에 못 미칠때 그 차이에 비례하여 값을 곱하는 제어기이다. P 제어기의 특성을 보면, 에러가 클 수록 더 큰 값이 플랜트에 들어 가므로 때문에 시스템에 진동을 야기할 수 있다. P 제어기에 대한 수학식은 다음과 같다.

(5)

2.1.2  I 제어기

Integral(적분) 제어기는 I 제어기라고 하며, 식 6에 수학적 표현이 있다. 식 6를 보면 적분이 있는데, 수학적으로 현재 시점이전에 있었던 에러들의 합을 계산하여 적분 제어기의 게인을 곱하므로 현재의 에러뿐만 아니라 과거의 에러까지 고려할 수 있는 제어기이다.

(6)

2.1.3  D 제어기

Derivative(미분) 제어기는 D 제어기라고 불리며, 식 7와 같이 에러의 시간에 대한 변화에 게인을 곱하므로 급작스런 에러의 변화에 대응할 수 있는 제어기이다. 특히나 오버슛이 갑작스럽게 커질 경우에 큰 효과를 발휘하는 제어기이다.

(7)

2.1.4  PD, PI, PID 제어기

실제 제어기의 경우 앞에서 설명한 각각의 제어기를 사용하지는 않는다. 각 제어기의 경우 단점과 장점이 혼합되어 있어서 주로 두 개 이상을 조합해서 제어기를 구성하게 된다. P 제어기의 경우 간단한 제어기로 사용하기도 하지만, I 제어기나 D 제어기의 경우 단독으로 사용하지 않는다.

PD 제어기를 생각해 보면 P 제어기의 게인을 크게 할수록 오버슛을 크게 하거나 시스템을 불안하게 할 수 있다. 에러의 크기에 게인값이 곱해지므로 오버슛이 커지거나 시스템이 불안해 질 수 있는데, 이런 점을 보안하기 위해서 D 제어기를 사용한다. P 제어기 때문에 생기는 오버슛이나 시스템의 불안정을 시간에 대한 에러의 비율에 따라서 동작하는 D 제어기를 같이 포함하면, 오버슛을 줄이고 불안정함을 줄일 수 있다. PD 제어기의 문제점중에 하나는 플랜트의 아웃풋을 측정하는 센서등에 노이즈가 생길수 있는데, 이럴 경우 신호가 급작스럽게 변할 수 있으며 이렇게 생긴 급작스런 변화에 D 제어기가 반응하여 문제가 생길수 있다.

또 다른 제어기 중에 하나인 PI 제어기의 경우 P 제어기에서 발생할 수 있는 정상 상태에서의 오차를 줄일 수 있도록 도와 준다. 또한 시간에 대한 급작스런 변화보다 과거에 오차가 누적되어서 거기에 맞추어서 제어를 할 수 있게 해주므로 노이즈등에 좀 더 견고한 제어기를 구성할 수 있다.

PID 제어기의 경우 세 가지 제어기를 모두 포함하는 제어기로서 위에서 설명한 각각의 단점을 보충할 수 있는 제어기이다. 식 8와 같이 수학적으로 구성할 수 있다.

(8)

2.2  질량-스프링-댐퍼 시스템 모델

---

---

(9)

그림 4와 같이 질량-스프링-댐퍼 시스템 모델을 수학적 모델링을 하게 되면 식 9와 같으며, Simulink에서 식 9를 모델링하면 그림 5와 같다. 시뮬레이션을 하기 위해서 필요한 질량(M=1kg), 댐핑 상수(b=10N s/m), 그리고 스프링 상수(k=20N/m)등의 값을 주고, 단위 스텝 인풋 값을 주게 되면 그림 6와 같이 질량의 위치가 변함을 알 수 있다.

---

---

---

---

그림 6를 보면, 인풋으로 준 값이 단위 스텝이므로 1이 되어야 하는데, 0.05 이므로 정상 상태 에러는 0.95이다. 또한 상승 시간을 보면 약 1초 정도되며, 정착 시간은 약 1.5초 정도되는 것을 알 수 있다. 이 모델에 P, PI, PD, PID 제어기를 구성하여 상승 시간과 정착 시간을 줄이고 정상 상태 에러를 최소화 할 수 있도록 해보자. 그럼으로써 각 제어기의 특성을 이해할 수 있을 것이다.¹

---

---

---

---

2.2.1  P 제어기

그림 7에서 K_d = K_i = 0으로 한 경우가 P 제어기를 나타내며, K_p의 값을 50, 100, 300을 주었을때의 결과가 그림 8에서 (a)에 있다. 그림에서 보는 바와 같이 K_p의 값이 커질 수록 원하는 아웃풋인 1에 근접하지만, 그 만큼 오버슛이 많이 나타난다. 때문에 초기에 원치 않는 큰 움직임이 생기며, P 제어기만을 쓸 경우 이 현상을 없앨 수가 없다.

2.2.2  PD 제어기

그림 7에서 K_i = 0로 두었을때 PD 제어기를 포함한 모델이며, K_p의 값은 300으로 고정하고 K_d의 값을 1, 5, 10을 했을때의 결과를 그림 8의 (b)에 나타냈다. K_d의 값이 증가할 수록 오버슛이 줄어들지만 정상 상태 오차에는 영향을 미치지 못해서 여전히 정상 상태 오차가 존재 함을 알 수 있다.

2.2.3  PI 제어기

I 제어기의 경우 과거의 에러를 고려해서 계산을 하므로 정상 상태 에러를 줄일 수 있지만, 현재의 에러도 고려하므로 P 제어기의 역할도 하기 때문에 PI 제어기를 포함(K_d = 0)한 그림 7에서 K_p의 값을 30으로 두고 K_i의 값을 70, 30, 5로 하여 결과를 그림 8(c)에 나타내었다. 보는 바와 같이 정상 상태 에러가 없어 졌음을 알 수 있다.

2.2.4  PID 제어기

I 제어기는 P 제어기의 역할을 어느 정도 하므로, 오버슛을 없앨 수가 없다. 따라서 최대 오버슛을 줄이기 위해서는 D 제어기를 포함해야 한다. 그러므로 지금까지 본 제어기를 다 모아서 PID 제어기를 구성해 보면 그림 7와 같으며, 그 결과를 보면 그림 8(d)에서 볼 수 있다. 결과를 보면, D 제어기가 포함되면서 오버슛이 줄어 들게 되어서 Kp와 Ki의 값을 크게 주었다. 최대 오버슛도 거의 없으며, 정상 상태 오차도 없어졌음을 알 수 있다.

제 3 절  제어기를 설계해 보자

제어 이론을 바탕으로한 제어기는 PID 제어기 말고도 아주 많다. 이중에서 가장 오래됐으면서, 가장 많이 쓰이는 제어기가 PID 제어기이다. 하지만, 이 방법은 각각의 게인값을 찾는게 문제이다. 이렇게 게인 값을 찾는 과정을 튜닝한다고 얘기하며, 튜닝하는 방법은 크게 보면 3가지 정도 밖에 없다. 감에 의한 방법, Ziegler-Nichols 방법, 마지막으로 전용 소프트웨어를 이용하는 방법등이다. 이런 방법등을 살펴보기전에 제어 이론에 대해서 간략히 살펴보도록 하자.

3.1  선형 시스템과 비선형 시스템

플랜트를 모델링하다보면 선형 시스템과 비선형 시스템으로 크게 나눌 수 있다. 비선형 시스템의 경우 PID 제어기로 제어가 제대로 되지가 않기 때문에 대부분 비선형 시스템을 선형화 해서 제어기를 설계하게 된다. 선형화 하는 방법은 여러 가지가 있고, 수학적인 내용이 많아서 여기서 소개하기가 힘들므로 관심이 있으면 구글이나 관련 도서를 참고 하기 바란다.

3.1.1  고전적 제어 기법과 현대적 제어 기법

선형 시스템은 두가지로 다시 나눌 수 있는데, 선형 시변(Linear Time Varying)과 선형 시불변(Linear Time Invariant, LTI) 시스템으로 나눈다. LTI 시스템을 미분 방정식 형태로 모델링을 하면 주로 라플라스 변환을 이용해서 분석을 하게 된다. 라플라스 변환을 하여서 모델을 분석하고 제어기를 설계하는 방식을 고전적인 제어 기법(Classical Control Method)이라고 한다. 모델을 행렬 형태로 변환해서 분석하고 제어기를 설계하는 경우는 현대적인 제어 기법(Modern Control Method)이라고 한다.

3.1.2  고전적 제어 기법

고전적 제어 기법에 따라 모델을 분석할때 가장 중요한 개념중에 하나가 전달 함수와 극점(pole)과 영점(zero)이다. 전달 함수란 LTI 시스템을 라플라스 변환을 통해서 식을 변환하고 초기 값을 0으로 두며, 식을 인풋/아웃풋 의 형태로 만드는 것이다. 앞에서 예로 들었던 질량-스프링-댐퍼 모델에 대한 전달 함수를 구해 보면 식 10와 같다. 여기서 극점과 영점을 구해보면, 극점은 전달 함수의 분모를 0으로 했을때의 해를 말하며, 영점은 분자를 0으로 했을때의 해를 말한다. 따라서 식 10에서 분자를 0으로 하는 식은 Ms² + bs + k = 0이므로 M,b,k에 따라서 s가 실수 또는 복소수가 될수도 있지만, 갯수는 최대 두 개이다.

(10)

극점과 영점이 중요한 이유는 여러가지 이유가 있지만, 그 중에 가장 중요한 특징은 극점이나 영점이 x축의 오른쪽에 위치할 경우 시스템이 불안정한 시스템이며, 최소한 y축 위, 즉 x = 0인 위치보다 왼쪽에 있어야 시스템이 안정한 시스템이라는 점이다.

여기에 제어기를 붙이면, 시스템의 전달 함수가 변하며, 전체적인 극점과 영점이 변하게 된다. 다시 말하면, 제어기를 설계한다는 것은 시스템의 극점과 영점의 위치를 원하는 곳으로 변경시키는 것과 같은 것이다. 식 11는 PID 제어기를 질량-스프링-댐퍼 모델에 포함시켰을때의 전달함수로서 극점과 영점이 변한것을 알 수 있다.

(11)

시스템 게인을 변경시켰을때 극점의 위치 변화를 보는 것을 근궤적이라고 하며, 제어기 설계할때 중요한 역할을 한다. 시스템이 복잡해 지면 이런 근 궤적선도를 그리기가 어려워지므로 소프트웨어의 도움을 받아야 한다.그림 9와 그림 10에 근 궤적 선도를 그렸다. 근 궤적 선도에서 근의 움직임은 x표시에서 o표시로 움직인다.

---

---

---

---

근 궤적뿐만 아니라 주파수에 따른 시스템 분석 방법이 있는데, Bode Plot, Nyquist Plot, Nichols Chart 등을 그려서 분석하는 방법이 있다. 여기서는 정말 간단하게 설명해서 근 궤적 선도에 대해서만 간략하게 소개했는데, 실제로 고전적인 제어 기법을 배우는 것만 해도 학교에서 한 학기 과정이다. 깊이 있는 내용에 대해서는 직접 책을 구해서 공부하는게 좋다.

3.2  감에 의한 방법

앞에서 보여 준 각각의 게인 값은 특별한 공식이나 방식 없이 감으로 잡는 것이다. 그러므로 각 제어기의 특성을 숙지하여, 여러번 시도해서 결과를 보는수 밖에 없다. 무수히 반복해서 본인이 원하는 결과를 얻을때까지 반복만이 길이다.

3.3  Ziegler-Nichols 방법

가장 널리 알려져 있는 것으로 Ziegler-Nichols 방법이라는게 있다. 먼저 I와 D의 게인 값들을 0으로 두고, 시스템이 진동(oscillation) 할때까지 P 게인 값을 증가시킨다. 이렇게 증가시킨 게인 값과 진동 주기를 이용하여 각 제어기에 대한 대략적인 값을 계산할 수 있다. 이 경우 말 그대로 대략적인 값이므로 제어기의 게인 값들을 찾기 위한 시작점이라고 생각하면 된다. 그래서 원하는 아웃풋이 나올때까지 반복해서 해야 한다.

3.4  소프트웨어를 활용하는 방법

PID를 튜닝하는 소프트웨어는 여러가지가 있을 수 있다. 접근 방법 자체도 각 회사마다 따로 있기 때문에 어느 소프트웨어가 가장 좋다라는 얘기는 할수가 없다. 여기서는 필자가 사용하는 The MathWorks사의 제품을 소개하도록 하겠다.

3.4.1  Control System Toolbox

MATLAB 환경에서 제어기를 설계하는 방법은 MATLAB의 프로그래밍 환경을 이용해서 직접 작성할 수 있지만, 그보다는 Control System Toolbox를 이용해서 제어기 설계에 필요한 대부분의 함수를 제공하므로 편리하게 사용할 수 있다.

앞에서 본 근 궤적 선도(그림 910)도 Control System Toolbox에 있는 rlocus()라는 함수를 이용해서 그린 것이다. 그리고 앞에서 언급했던 비선형 시스템의 선형화를 위한 함수도 제공하며, SISO(Single Input, Single Output) Design Tool(그림 11) 이라는 것을 제공하여 화면상에서 직접 극점과 영점을 포함할 수 있으며, 직접 극점과 영점을 마우스로 움직였을때 게인의 값의 변화에 따라 즉각적으로 단위 스텝 인풋에 대한 아웃풋을 볼수 있으므로, 그래픽적으로 제어기를 설계할 수 있도록 도와 준다.

---

---

3.4.2  Simulink Control Design

질량-스프링-댐퍼 모델을 Simulink에서 개발한 것처럼 제어기를 설계할때 Control System Toolbox에 있는 SISO Design Tool을 Simulink 모델에 적용할 수 있게 하는 제품이다. 또한 Simulink로 모델링한 모델이 비선형 시스템일 경우 선형화된 Simulink 모델로 변환할 수 있도록 하는 기능도 포함되어 있다.

3.4.3  Simulink Response Optimization

Simulink Control Design으로 튜닝할 때는 일단 모델을 선형화 해야 한다. SISO Design Tool 자체가 LTI 시스템에만 적용할 수 있기 때문에 항상 비선형 시스템의 경우 선형화를 꼭 해주어야 한다. 지금 소개하고자 하는 Simulink Response Optimization의 경우는 시스템이 선형/비선형 여부에 상관 없이 사용할 수 있는 제품이다. Simulink로 모델을 만든 후 원하는 아웃풋이 되도록 범위를 지정해서 범위안에 아웃풋이 되도록 선택된 파라메타를 변경하는 제품이다.

그림 7에 있는 모델을 Simulink Response Optimization을 이용할 경우 PID 제어기에 게인으로 셋팅한 K_p,K_d,K_i의 값들을 변경하고자 하는 파라메타로 셋팅할 수 있다.

파라메타 선택을 하고 나면 그림 12과 같이 원하는 아웃풋의 범위를 지정하고 어떤 방식으로 파라메타 값들을 변경할 것인지에 대한 수학적인 알고리즘을 결정한다.

---

---

그림 13를 보면 초기값으로 K_p = 150,K_d = 1,K_i = 15으로 주었을때 그림 12에서 지정한 범위내로 아웃풋이 되도록 총 5번을 실행해서 최종 결과로 K_p = 256.5661,K_i = 209.8900,K_d = 10.5070이라는 값을 얻었음을 알 수 있다. 이와 같이 제어기를 튜닝할때 자동화 해주는 기능이 있으므로 제어에 대한 깊은 지식이 없어도 충분히 제어기를 설계할 수 있도록 해준다.

---

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

요 약 제어기 설계를 위해서 필수적으로 필요한 플랜트의 수학적 모델을 Simulink에서 설계하는 방법을 배우며, System Identification을 통해서 수학적 모델링 없이 실제 플랜트의 인풋값과 아웃풋값을 이용하여 플랜트 모델링하는 방법을 보도록 하자. 설계한 플랜트를 VRML을 이용하여 나타내는 모델을 보고, 3D로 시각화 했을때의 장점을 보도록 한다.

제 1 절  플랜트와 제어기의 관계를 이해하자

임베디드 시스템은 항상 하드웨어와 소프트웨어로 나누어 진다. 소프트웨어는 운영체제, 디바이스 드라이버, 그리고 어플리케이션으로 다시 세분화 된다. 임베디드 소프트웨어의 어플리케이션의 경우 윈도우즈 XP와 같은 일반 데스크탑 환경에서의 프로그래밍과는 다르게 하드웨어 제조 업체를 제외하고는 개발하기가 힘들다. 특히나 시스템이 안전성과 관련이 되어 있으면 통상 하드웨어 제조 업체가 임베디드 소프트웨어의 어플리케이션을 직접 개발한다. 이런 어플리케이션은 운영체제와 깊은 연관성을 가지고 있어서 운영체제와 같이 크로스 컴파일링하여 임베딩 시키는 경우도 많이 있다.

1.1  시뮬레이션이란?

---