아래 내용은 마이크로소프트웨어 2008년 1월호에 기사로 나간 내용입니다. 물론 초안이라서 책에 나간 내용과는 약간 차이가 있습니다. 저작권 문제가 있을 수 있으므로, 복사하시지는 말고 링크만 걸어 주시기 바랍니다. 잡지 기사를 pdf로 보실려면 iMaso
홈페이지에 가셔서 구매하실 수 있습니다.
State Machine의 개념과 Stateflow에서의 기본적인 모델링 방법 1
|
요 약 |
제 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 제약 조건을 가진 자판기
간단한 자판기란 이해의 편의를 돕기 위해서 아래와 같은 제약 조건을 가진 자판기이다.
- 자판기가 받아 들이는 동전은 한 가지 종류 밖에 없다.
- 동전 3개를 받고 나면 더 이상의 동전은 받아 들이지 않고 돌려 준다.
- 언제든지 취소가 가능하며, 취소할 경우 동전을 반환해야 한다.
- 동전 3개가 있는 경우에만 캔을 선택할 수 있으며, 이 경우 캔을 돌려 주고 동전은 돌려 주지 않는다.
위와 같은 제약 조건을 가진 자판기를 모델링한다면 다음과 같은 사항을 먼저 생각하고 결정해야 Stateflow로 모델링할 수 있다.
- {empty, oneCoin, twoCoin, threeCoin}앞으로 state의 경우 {}로감싸겠다.으로 총 4개의 state가 있어야 한다.
- 각 state에서 insertCoin이라는 이벤트가 발생할 경우 현재 state에서 다음 state로 옮겨 간다.
- {empty}제외하고각경우에 cancel 이벤트가 발생할 경우 현재 state에 가지고 있는 동전을 전부 되돌려 주고 {empty}로 state가 옮겨 간다.
- {threeCoin}에서는 order 이벤트가 발생할 경우 캔을 하나 내보내고 {empty}로간다.
2.2 Stateflow로 모델링하자
Stateflow는 독자적인 프로그램이 아니라 Simulink2007년 8월호 Simulink를 이용한 플랜트 모델링상에서 하나의 블럭(Chart블럭)으로 존재하게 된다. 다시 말하면 Simulink가 있어야만 실행 가능하다는 점이다. Simulink에서 다른 블럭들과 똑같이 다루어 지며, MATLAB 명령어 윈도우에서 sfnew라는 명령어로 그림 2와 같이 빈 모델에 Chart 블럭이 포함된 상태로 모델을 열 수도 있다.
![]()
|
![]()
|
Chart 블럭을 더블 클릭하면 그림 3가 열려서 State Machine을 모델링할 수 있게 된다.
2.2.1 실제 모델링을 해보자
- 그림 3의 왼쪽에 있는 State 아이콘을 한번 클릭하고 에디터로 마우스를 움직이면 사각형 박스를 보여 준다. Stateflow에서 이 사각형 박스가 하나의 state를 나타낸다. 이 박스를 에디터의 원하는 위치로 옮겨서 마우스 왼쪽 클릭을 하면 그 위치에 state를 표시할 수 있다. State 아이콘을 더블 클릭하면 에디터에서 왼쪽 클릭을 해도 해제되지 않으므로 여러개의 state를 그릴 경우 편리하며, 오른쪽 버튼을 클릭할 경우 해제된다. 또 각각의 state에는 다른 state와 구별되는 이름을 주어야 한다. 이름의 경우 state 안에 있는 ? 표시를 클릭하면 텍스트를 쓸 수 있으며, state의 이름을 만들때는 C에서 변수 이름을 만들때의 규칙과 같다. 예제에서는 앞에서 결정 했던 4개의 state의 이름을 사용한다.
- 각 state간의 transition은 그림 4와 같이 state의 테두리에서 만들어서 그림 5처
럼 다른 state의 테두리에서 끝나게 된다. transition의 경우 방형성이 있으므로 transition이 시작되는
state와 끝나는 state를 결정해서 선을 연결하면 된다. state의 테두리 근처로 마우스를 가져가면 그림 4처럼
마우스 표시가 십자 형태로 변하며 이때 왼쪽 클릭한 상태에서 드래깅하면 선의 끝 부분이 그림 5처럼 원을 보여 주며, 이 원이 state의 다른 테두리 위에 오도록하여 드래깅했던 버튼을 떼어내면 transition이 생성된다.

그림 4: transition의 시작

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

그림 8: 간단한 자판기에 대한 모델
- 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 블럭을 이용하는 것이다.- 예
제로 하고 있는 모델의 경우 한개 이상의 이벤트를 인풋으로 해야 하는데, 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을 모델링할때 시물레이션의 강력함을 제대로 느끼지 못했을수도 있다. 하지만, 앞으로 진행되는 연재를 보면 점점 더 시물레이션의 강력함을 느끼게 될 것이다. 그리고 시물레이션으로 모델을 검증된 상태에서 자동으로 코드를 생성해서 실제로 임베딩할 수 있는 코드를 가지게 될때의 장점도 아울러 알게 된다.











댓글을 달아 주세요