양산 코드를 생성하는 데 모델기반 설계(Model-Based Design) 기법이 활용되면서 오늘날 전자제어장치(Electronic Control Unit, ECU)들은 하루가 다르게 발전을 거듭하고 있다. 실제로 시스템/소프트웨어 엔지니어들은 이러한 첨단 기법을 통해 블록 다이어그램과 상태 기계(state machines) 그리고 데이터 사전(data dictionaries)을 이용하여 알고리즘을 모델링하고 시뮬레이션 할 수 있게 됐다. 또 이 과정에서 코드는 모델들로부터 자동 생성이 이루어져 래피드 프로토타이핑이나 양산 마이크로프로세서에 바로 적용이 가능하다.
모델 구조와 코드 생성의 배열(환경 설정) 옵션들은 디자인과 결과 코드의 효율성 및 명확성에 중대한 영향을 미친다. 고성능의 컴퓨터 환경에서는 통상 효율성과 명확성이 초기 래피드 프로토타이핑 평가에 그리 큰 영향을 미치지 않는다. 하지만, 비용절감을 목표로 한 소프트웨어 개발과정이나 저성능의 대량 양산 ECU 부문에서는 매우 중요한 이슈인 것이다. 이에 필자는 모델 스타일 가이드라인과 최적화된 고정소수점 및 부동소수점 코드의 자동적인 설계와 생성사례들을 통해 효율적인 대안을 제시해 보고자 한다.
필자는 본지를 통해 양산 조직 모델(production organizations model)과 임베디드 소프트웨어를 개발할 때 효율성과 명확성을 향상시킬 수 있는 기술과 기법을 제시하고자 한다. ‘양산 코드 생성을 위한 모델링 스타일’은 잘 알려진 주제로 이와 관련한 많은 연구사례 및 논문들이 이미 발표된 바 있다. 또 어떤 경우에는 툴의 지원 또한 가능한 것으로 알고 있다. 이에 필자는 새로운 팁과 조언을 제공하는 것은 물론 전문적인 모델기반 설계 개발자들도 모를 수 있는 이미 존재하는 자료를 참고하여 시스템?소프트웨어 엔지니어들에게 보다 실질적인 도움을 제공하고자 한다.
시뮬레이션에 사용되는 모델에서 코드를 생성하는 과정은 간단하다. 첫 번째 단계는 코드가 배치될 적합한 타깃 환경을 설정하는 것이며, 두 번째 단계는 코드 생성 프로그램을 불러오는 것이다. 그러나 이 두 단계의 프로세스는 최적화된 디자인이나 코드를 생성시키기에는 충분하지 않다. 한 단계 더 나아가는 프로세스는 모델 가이드라인을 개발하는 것과 수동 검열과 자동 검사를 사용하여 모델 가이드라인을 적용하는 것이다.
본지에서는 매스웍스의 제품들인 매트랩(MATLAB), 시뮬링크(Simulink), 스테이트플로우(Stateflow), 리얼타임 워크샵 임베디드 코더(Real-Time Workshop? Embedded Coder)^[1-5] 등을 특정 모델링과 코드 생성 환경으로 설정한 사례들을 인용, 실질적인 모델 가이드라인 실행법을 소개하고자 한다.

가이드라인 개발
ECU 개발에 앞서 모델 스타일 가이드라인과 자동 검사기(automated checker)를 고려하는 것이 중요하다. 모델 스타일 가이드라인은 구체적인 동작 사양을 양산 코드에 직접 영향을 줌으로써 개발자에게 도움을 준다. 코딩 표준을 기반으로 양산 조직은 일반적으로 임베디드 코드 생성을 위한 고유한 모델 가이드라인과 모델 작성 접근법을 구축하고 있다.
이 표준들을 증명할 때는 다음과 같은 기관들의 모델과 코드에 대한 이미 정립된 가이드라인이나 표준을 확인하는 것이 유용하다.

● MathWorks Automotive Advisory Board (MAAB)
● Japan MathWorks Automotive Advisory Board (J-MAAB)
● Motor Industry Software Reliability Association (MISRA)

MAAB 스타일 가이드라인
MAAB는 1998년에 포드, 다임러 벤츠(현재는 다임러 크라이슬러), 도요타와 같은 고객사가 매스웍스에 요구하는 제품의 특성들을 조율하기 위해 설립됐다. 이 위원회는 꾸준한 성장을 거듭하며 현재는 전세계의 주요 OEM과 공급자들을 포함하고 있다. 이러한 발전과정 속에 MAAB는 공개적으로 이용할 수 있는 모델링 스타일 가이드라인⁶ 세트를 마련할 수 있었다.
MAAB 가이드라인이 만들어지게 된 배경은 다음과 같다.
 


MAAB 가이드라인은 프로젝트의 성공과 팀웍을 위한 중요한 기반이 된다. 이는 단지 자사뿐만 아니라 협력사 및 하청업체와 일할 때도 마찬가지이다.
스테이트플로우(Stateflow) 가이드라인은 Simulink에 포함된다. 가이드라인은 그림 1에서 보는 바와 같다.
MAAB 가이드라인을 사용하는 회사들은 예외사항과 추가사항 혹은 민감한 차이점을 각기 적용하고 있다. 이 가이드라인은 최근의 제품 출시와 성능을 반영하여 2007년에 수정될 예정이다.

J-MAAB Simulink 스타일 가이드
MAAB의 지역 커뮤니티들은 최근 계속 발전해 왔으며, 이는 일본의 경우도 마찬가지이다. 커뮤니티의 헌장에 다음과 같이 언급되어 있다.
J-MAAB은 모델기반설계를 향상시키고 MATLAB과 Simulink를 기반으로 한 개발환경을 사용하고자 설립됐다.



이후 도요타, 닛산, 혼다, 마즈다, 덴소, 히타치, 히타치 유니시아, 아이신 및 자트코를 포함한 J-MAAB Simulink 시스템 워킹 그룹(J-MAAB Simulink System Working Group)이 창립됐다. 이 그룹은 2003년 3월에 Simulink 스타일 가이드⁷를 만들었다. 이 문서는 모델 구조와 설계에 대한 가이드라인, 신호와 블록 레이아웃에 대한 정보를 담고 있다.
Section 3.1.2에 따른 J-MAAB 모델 설계 트리거 레이어를 위한 가이드라인은 다음과 같다.
트리거 레이어는 그림 2의 예와 같이 사용돼야 한다. 그러나 트리거 레이어와 함께 계산 시점을 지정할 때에는 아래와 같이 포맷 B 과정의 시점 설명을 사용해서는 안된다.
J-MAAB Section 4에 따른 신호를 그리는 것의 예들은 다음과 같다.

● 연속적인 신호를 그리지 않는다.
● 가능한 한 선을 교차하는 것을 피해야 한다.
● 신호 선은 수직이나 수평으로 그려야 한다(기울어지면 안됨).
● 신호는 다른 것이 지정되지 않을 경우에는 왼쪽에서 오른쪽으로 흘러야 한다.
● 되도록이면 Goto and From tag을 사용하면 안된다. 이 태그를 쓰면 로컬 신호만이 Goto Block의 Tag Visibility에 적용된다. 그러나 단지 모니터링이 목적인 시뮬레이션 결과를 보는데 사용된다면 태그는 포괄적으로 설정될 수 있다.
● Goto and From tag을 사용할 때는 서브시스템들 간의 프로세스 순서를 볼 수 있도록 적어도 한 개 선 이상이 연결되어야 한다.
● 각 층의 서브시스템들의 입력신호(input)와 출력신호(output)를 설명하는 방식은 가능한 분명히 해야 한다.
● algebra 루프를 사용해서는 안된다.

MISRA-C 가이드라인
MISRA는 1998년 4월 “소프트웨어 기반 운송 수단에서의 C언어 사용에 대한 가이드라인(Guildlines For The Use Of The C Language In Vehicle Based Software)⁸”을 최초로 공표했다. 일반적으로 알려진 바와 같이 MISRA-C는 자동차 임베디드 시스템의 안정성과 연관된 C 언어 프로그래밍에 대한 가이드라인을 제공한다. 이 가이드라인의 상당 부분은 C 언어 기반 전자제어장치를 개발하는 자동차 산업 개발자들에 의해 만들어졌다.
C언어가 임베디드 시스템 개발을 위해 폭넓게 사용되고 있기 때문에 MISRA-C 또한 항공이나 국방 등 폭넓은 산업분야에서 활용이 가능하다. MISRA-C의 버전 2(MISRA-C:2004로 알려져 있음)가 2004년에 발표되었다.
MISRA-C는 모델기반설계를 따르는 양산 코드 생성에서는 그 가이드라인을 맞추지 않는다. 이 점과 관련하여 업계에서는 회사가 코드보다는 모델 기준에 대한 개발시간과 검사에 더욱 초점을 맞추는 것에 대해 논쟁이 있다. 이러한 프로세스의 전개는 어셈블리에서 C로 옮겨온 경우의 사람들에게는 잘 알려진 것이다. 그러나 많은 사람들은 수동이나 자동으로 코드를 만드는 것과는 관계없이 C 컴파일러의 이식성(portability)과 변환성(interpretation)에 초점을 두고 있는 MISRA 규칙이 매우 중요하다는 것에 공감할 것이다. 다음과 같은 예가 이러한 사실을 입증해 준다.

MISRA 규칙 11(필수): 식별자(Identifiers, 내부 및 외부)는 31개 이상의 문자의 의미에 의존해서는 안된다. 이에 더하여 컴파일러/링커는 외부 식별자를 지원하는 31개 문자의 의미와 대소문자 구별을 안전하게 하는 지 점검할 수 있어야 한다.




이 규칙은 이름이 긴 식별자와 이름이 충돌하는 것을 방지해 주므로 중요하다. 또한 이 규칙은 코드를 보다 안정적으로 만드는데, 이는 대부분의 컴파일러와 링커가 적어도 31개 문자를 지원하고 있기 때문이다.
양산 코드 생성을 위해 식별자는 모델 안에 지정된다. MISRA-C가 코드 스타일 가이드라인이라 할지라도, 모델이 코드 생성자의 입력신호이기 때문에 이는 모델 스타일 가이드라인 안에 그와 연관되는 규칙들을 포함 하는 것이 일반적이다. 매스웍스는 리얼타임 워크샵 임베디드 코더를 위해 MISRA-C 컴플라이언스 패키지를 제공한다.

컴플라이언스 체커
회사가 잘 정의된 가이드라인과 표준을 개발하는데 시간과 노력을 쏟아야 하는 이유는, 그래야 그 가이드라인과 표준에 맞는지를 시스템적으로 검사하는 프로그램이나 스크립트를 만들 수 있기 때문이다. Simulink는 거의 모든 그래픽적인 특성이 스크립트를 통해서 액세스할 수 있는 상응하는 API를 가지고 있다는 데서 이러한 과정을 매우 효과적으로 수행할 수 있다.
예를 들어, MISRA 규칙 11이 가이드라인에 필요하다고 가정하자. 리얼타임 워크샵 임베디드 코더는 그림 3에서 보는 바와 같이 최대 식별자의 길이를 유저 지정값으로 제한하는 옵션을 가지고 있다.
이것은 Simulink 환경에서 최대 식별자 길이를 31 문자 이하로 만드는 지를 점검하는 스크립트를 개발하는 간단한 처리과정이다. 모델을 점검하는 스크립트를 개발할 때 중요한 점은 MATLAB 다이제스트 기사⁹에 설명되어 있다. MAAB 스타일 가이드라인을 위한 자동 검사자는 매스웍스에서 구입할 수 있다¹⁰.



지금까지 공표된 대부분의 가이드라인과 검사 도구는 안전성, 균등성, 명확성에 초점을 맞추고 있다. 최근 매스웍스는 Simulink Verification & Validation 제품의 기능 중의 하나인 ‘모델 어드바이저(Model Advisor)’라는 모델 분석 툴을 출시했는데, 이는 시뮬레이션 및 코드를 생성하기 위해 양산에 적용하는 것을 저해하거나 코드 능률을 제한시키는 모델의 양상을 규명하는 데 쓰인다. 모델 어드바이저는 모델 개발자들이 양산 코드를 만들기 위해 모델과 블록 레벨의 환경설정을 분석하여 그 결과를 기록하고 각 영역에서의 향상 방안을 제안한다. 이것은 초기 디자인 사이클에서 매우 유용하다. 모델 어드바이저 리포트에 대한 예는 그림 4에서 보는 바와 같다.
이상 회사 스타일 가이드라인과 자동 검사자가 준비되었으면 ECU를 개발할 차례다. ECU를 개발하는 초기 과정에서 모델은 연구 단계에서 벗어나 정식으로 소프트웨어를 개발하는 데 쓰이게 된다. 지면 관계 상 ECU 개발부터는 다음 호에 소개하기로 한다.


[참조문헌]
1. The MathWorks, Inc. Natick, MA., www.mathworks.com
2. MATLAB, Software Package, Ver. 7.4.0, The MathWorks, Inc., Natick, MA.
3. Simulink, Software Package, Ver. 6.1, The MathWorks, Inc., Natick, MA.
4. Stateflow, Software Package, Ver. 6.1, The MathWorks, Inc., Natick, MA.
5. Real-Time Workshop Embedded Coder, Software Package, Ver. 4.6.1, The MathWorks, Inc., Natick, MA.
6. “Controller Style Guidelines for Production Intent Using MATLAB?, Simulink? and Stateflow?,” MathWorks Automotive Advisory Board (MAAB), dated April 2001, (Update in progress) www.mathworks.com/industries/auto/maab.html
7. “Simulink Style Guide”, Version 1.0, Japan MathWorks Automotive Advisory Board (J-MAAB), dated March 2003, j-maab.cybernet.jp
8. "Guidelines for the Use of the C Language in Vehicle Based Software", Motor Industry Software Reliability Association, ISBN 0 9524156 9 0, April 1998, www.misra.org.uk
9. “Checking Code and Models in Production Environments”, Tom Erkkinen and Damon Hachmeister, MATLAB Digest, dated July 2003, www.mathworks.com/company/newsletters/digest/july03/checking_code.html
10. Simulink Verification and Validation,  Software Package,  Ver. 2.2.1., The MathWorks, Inc., Natick, MA
11. “Logic Design Using Stateflow Truth Tables”, by Rob Aberg, MATLAB News & Notes, June 2004, www.mathworks.com/company/newsletters/news_notes/june04
12. “Strategy for Successful Enterprise-Wide Modeling and Simulation Using COTS”, by Rob Aberg and Stacey Gage, American Institute of Aeronautic and Astronautics GN&Cl Conference, dated August 2004.
13. “Multi-Target Modeling for Embedded Software Development for Automotive Applications”, by Grantley Hodge, et al, Visteon Corp, SAE Technical Paper No. 2004-01-0269, March 2004, www.visteon.com/whitepapers/2004_01_0269.pdf
14. “Fixed-Point Modeling and Code Generation Tips”, by Siva Nadarajah and George Beals, MATLAB Central, dated 2002, www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=2632&objectType=file
15. Link for TASKING, Software Package, Ver. 1.1, The MathWorks, Inc., Natick, MA.