안전 우선 자동차 애플리케이션에서 임베디드 소프트웨어의 역할과 책임이 지속적으로 커지고 있다. 이것은 기능성의 추가 요구와 함께 시장 출시 기간의 단축, 전체 비용 저감의 요구와 관련되어 있다. 자동 코드 생성(auto-matic code generation)은 이러한 요구를 만족시킬 수 있는 하나의 대안이며, 설계표현식(design representation)에서 곧바로 목적하는 특정 코드를 생성하는 데 이용할 수 있다. 자동 코드 생성은 어디서나 구할 수 있는 프리웨어로 구현할 수 있다는 표면적인 이점 때문에 매우 강력하다고 여겨질 수 있다. 그러나 안전 우선 시스템은 높은 무결성의 코드 생성을 요구한다. 소스와 대상 언어는 정식으로 잘 정의된 구문론(syntax)과 의미론(semantics)을 갖추고 있어야 한다. 또한 번역기나 생성된 코드는 엄격하게 검증되어야 한다.
자동 코드 생성은 또한 설계 사양을 대상 코드로 변환시키기 위한 소프트웨어 엔지니어가 더 이상 필요 없기 때문에 개발과정에서 추가적인 수작업 점검을 없앤다. 그러나 안전 우선 개발 프로세스 환경에서 이 방법론이 빠뜨릴 수 있는 일부 함정이 존재한다.

소프트웨어 개발 프로세스
안전 우선 시스템의 설계 프로세스는 대부분의 생산 품질(production quality) 소프트웨어의 개발과 같이 일반적으로 전통적인 V-모델 구조의 소프트웨어 개발 프로세스에 기반을 두고 있다. 이 프로세스 라이프사이클은 산업계에서 수년 간 경험하고 개발해오면서 그 가치가 증명되었다.
이 라이프사이클을 구현하기 위한 일반적인 두 가지 방법은 명세-기반(specification-based) 개발과 모델-기반(model-based) 개발이 있다. 명세-기반 개발 방법은 전통적으로 수작업에 의한 문서를 작성하고 수작업 코딩을 수반한다.
모델-기반 설계 방법론은 명세 기반 프로세스에 비해 이런 라이프사이클 과정에서 중요한 시간과 노동력 절감을 제공하므로 권장되고 있다. 이것은 많은 프로세스를 자동화시킬 수 있는 잠재적 기회와 각 단계간에 더 용이한 정보전달 수단을 제공한다. 이것은 하나의 모델이 연속적인 과정으로 개발될 수 있다는 의미인데, 즉 여러 단계들을 모으는 초기 작업에서 버튼을 한 번만 누르면 생산품질 코드가 생성되는 상황까지 곧바로 이루어져 하나의 모델이 만들어진다.
그러나 안전 우선 시스템에 도입하기 위한 적절한 라이프사이클을 고려할 때, 각 개발 단계의 목적을 보증하기 위해 주의할 점은 이용하는 모델-기반 개발 방법을 이용하면서 어떤 이익을 보려고 타협해서는 안된다는 것이다.
모델 - 기반 개발

요구사항 수집
자동으로 생성된 어떤 코드이든지 최초 의뢰인의 요구사항들을 추적할 수 있어야 한다. 전통적으로 요구사항 수집(Requirement Gathering)과 소프트웨어 요구사항 명세 단계는 텍스트 기반으로 이루어지고 있는데, 이 요구사항들은 나중에 추적의 용이성을 위해 쉽게 참조할 수 있는 문서에 개별번호가 기입된 항목으로 분류된다.
어떤 경우이든 텍스트로 설명되어 있는 경우에는 문서가 개발팀 간에 전달되는 과정에서 모호하게 전달될 수 있기 때문에 오해와 오역이 개입될 수 있다. 그러나 모델-기반 요구사항 명세는 모호함이 덜하다. 즉, 그것을 해석하는 사람에 관계없이 정의된 거동(behaviour) 모델을 제시한다. 주어진 어떤 입력 세트이든지 모델은 항상 같은 결과를 출력한다.
그러나 이것은 운용 영역선도(operational envelope)의 응답이 주어진 입력을 고려한 요구사항을 효과적으로 포착하지 못해 모호함을 완전히 제거하지는 못한다.
이 초기 단계에서 요구사항을 알아내기 위해 모델-기반 기법을 순수하게 적용하는 데 따른 또 다른 결점이 있다. 즉, 모델의 어떤 부분이 하나의 개별적인 요구사항을 나타내는 지 추적하기 어렵다는 점이다.
계층 모델(hie-rarchical model)에서 요구사항들은 서브시스템 계층 내에 숨어 있을 수 있다. 또한 이미 결정된 설계 선택이라도 모델만을 보고서 효과적으로 이해될 수 없다. 이런 모든 점에서 모델-기반 방법을 적용한다면 여전히 백업 문서가 필요하다.

설계
V-모델의 효용성이 떨어지는 경우가 있는데, 즉 모델 기반 체계를 이용하면 시스템 설계와는 전혀 다른 소프트웨어 설계가 여전히 필요하다는 사실을 자동 코드 생성 제안자들이 종종 간과해 버린다. 시스템 설계 단계와 소프트웨어 설계 단계의 목표는 분명히 다르다.
시스템 설계 레벨에서의 설계 전략은 차량에서 주변 시스템들과의 거동적 상호작용을 고려한 높은 레벨의 관점에서만 세워진다. 소프트웨어 설계 단계에서는 수많은 하드웨어의 특별한 제한 요소가 고려된다. 예를 들면, 프로세서 유형(고정 또는 부동 소수점), 속도, ROM·RAM 용량, I/O 수, 인터페이스 등을 고려해야 한다. 이 두 단계 모두는 시스템 설계가 소프트웨어 설계로 어떻게 해석되는 지에 대해 영향을 미치게 된다. 이 두 단계를 통해 하나의 모델 기반 설계를 하려는 시도는 한 쪽과 타협하든지 아니면 다른 쪽과 타협하게 될 것이다.

코딩
이 과정의 목적은 코드 모듈을 생성하는 것으로서, 이 코드 모듈은 목표 언어(target language)로 설계에 의해 정의된 거동과 구조를 구현한다. 수동 프로세스가 사용되는 곳에서의 코드 작성은 엄격한 절차를 따르게 되며 표준과 가이드라인을 꼭 준수한다. 코드 모듈들은 그래서 설계의 무결성을 보증하기 위해 자세한 검토가 있어야 하고, 또 그렇게 해야 승인을 받을 수 있다. 만약 코드가 자동으로 생성되었을 경우에는 사람이 설계에서 코드를 실현하거나 설계와는 별개로 코드를 재검토하는 정상성 점검(sanity checking)은 필요 없다.
일반적으로 모델 기반 자동 코드 생성 툴들은 완전한 의미론적(semantic) 정의가 부족한 면이 있다. 이것은 어떤 두 버전의 자동 코드 생성기가 정확히 똑같은 방법으로 주어진 모델링 구조를 반드시 실현할 수 있을 지 확신할 수 없다는 것을 의미한다.
MISRA-C 서브셋의 결과로서 C의 점진적인 수용에 있어서 비교는 매우 효과적이다. MISRA-C는 자동차 산업 소프트웨어 신뢰성 협회(Motor Industry Software Reliability Association)에서 개발한 자동차 산업용 C의 안전한 서브셋으로 많은 코드가 신뢰성과 안전성이 우수하다.
즉, C 언어의 버그와 문제점 등을 정확하게 짚어내어 그 정확도 등을 높여 놓은 C 언어라고 할 수 있다. 모델링 언어를 다루는 데 있어서 똑같은 일을 하는 그룹은 없다.
따라서 자동 코드 생성 모델은 모델이 무엇을 하려고 설계되는 지, 그리고 어떤 코드 구성이 생성되는 지를 모두 확실하게 아는 총괄적인 기술 소유자에 의해 설계되고 구현되어야 한다.

테스팅
모델은 정적 또는 동적으로 모두 테스트될 수 있다. 자동 코드 생성 모델의 정적 검사는 생성된 코드가 수용 가능한 표준을 만족하도록 보증하고 모델링 언어에 어떤 알려진 문제 구조를 피할 수 있도록 돕니다. 정적 분석이 오랫동안 소프트웨어 공학 분야에서 폭넓게 사용되어 왔음에도 불구하고 모델 검사에서의 사용은 최근에 이용할 수 있게 된 이런 툴과 더불어 비교적 새로운 개념이다.
동적 테스트는 원하는 거동을 충분히 자극하기 위해 테스트 벡터를 사용할 것을 요구한다. 모델 기반 환경에서는 V-라이프사이클 모델 좌측의 모든 단계에서 테스트 벡터를 만들 수 있다.
이상적으로는 요구사항 수집 단계로 바로 되돌아가 시작할 수 있고, 시스템의 모든 거동 특성이 자극받는 다는 것을 보증할 수 있도록 그 자체가 자동 코드 생성 모델과 나란히 설계된다. 모든 거동을 포착하고 있는 모델의 개념은 두 엔지니어가 같은 곳을 보고 있다면 둘 간에 통신 도구로서만 유용하다. 모델은 그것이 완전한 테스트 벡터 세트와 함께 제공될 경우에만 유용하다. 이것들은 최초의 설계/요구사항과의 비교를 위해 언제든지 재사용될 수 있다. 좋은 엔지니어링 실천을 위한 일반적인 충고는 여전히 테스트를 일찍부터 자주 할수록 좋다(test early and test often)는 것이다. 테스트 초기에는 여러 가지 설계, 개발 단계, 그리고 HIL(hardware-in-loop) 테스트 링의 사용을 통한 물리적 세계와의 사이에 모델-기반 방법론이 더 수월하며 테스트를 미루는 것도 더 쉽다. 모델-기반 명세를 위해, 그리고 모델 범위 및 경계 값 테스트를 위해 테스트 케이스 제너레이션을 추가하기 위한 툴이 제공되고 있다. 이 테스트의 수동 검토는 여전히 필요한 테스트 모드가 적절하게 이뤄지는 지를 보증하도록 권고하고 있으나, 자동 테스트 케이스 제너레이션은 태스크로부터 일부 힘든 일을 제거할 수 있다.
모델 기반 설계 프로세스는 적절히 구현될 경우에 시간과 비용을 절약할 수 있지만, 그것이 만병통치약은 아니며 여전히 숙련된 엔지니어를 요구한다. 안전 관련 프로젝트에 자동 코드 생성의 광범위한 수용을 가로막는 주된 장해물은 산업계의 넓은 정의 및 모델링 표준의 부족이다.
따라서 ‘안전’ 서브셋에 대해 동의가 있을 때까지는 수작업에 의한 코드 작성이 안전 관련 시스템을 위한 기준으로 남아 있게 될 것이다. 그 때까지는 모델 거동이 그것을 해석하는 사람과 떨어져 있으므로 모델 기반 요구 사양의 애매함을 줄일 수 있는 프로젝트의 초기 단계에 노력을 집중해야 할 필요가 있다.