Embedded System 개발 문서화

임베디드 시스템은 일반적으로 큰 시스템의 일부로 통합된 전문화된 컴퓨터 시스템이다. 임베디드 시스템은 특정 기능을 수행하는 컴퓨터 엔진을 형성하기 위해 하드웨어와 소프트웨어 컴포넌트 조합으로 구성된다.

최근 공부 중인 도서에서 임베디드 시스템에 대한 정의를 인상적으로 표현하였는데 다음과 같다.

" 최종 기능이 컴퓨터가 되지 않는 컴퓨터 " -  임베디드 시스템을 위한 소프트웨어 공학 총론 -

 

"개발(Develop)" 이라는 것은 단순히 정해진 것 들을 프로그래밍 하는 것 만을 요구하지 않는다. 프로그래밍은 개발을 위한 도구이자 수단에 불과하며 "개발자의 역할은 단순한 코드 작성자 아닌 다양한 IT 기술들을 융합" 하여 새로운 것을 창조해내는 역할을 수행한다.

임베디드 시스템 개발에서는 하드웨어와 소프트웨어가 긴밀하게 결합되며, 개발 과정에서 요구사항 정의, 회로 설계, 펌웨어 구현, 테스트 및 검증, 최적화까지 폭넓은 기술적 고려가 필요하다. 이 과정에서 체계적인 문서화는 필수적인 요소다.

명확한 문서화는 단순한 기록이 아니라, 프로젝트의 명확한 방향성을 설정하고, 협업의 효율성을 높이며, 유지보수성을 극대화하는 핵심 요소다. "핀 매핑, 통신 프로토콜, 메모리 구성, 전원 관리, 인터페이스 설계" 등 각종 기술적 요소를 문서로 체계화하면, 개발자는 보다 창의적인 문제 해결에 집중할 수 있으며, 퀄리티가 높은 제품을 창출해낼 수 있다.

"계획이 없다는 것은 실패를 계획하는 것이다." - 벤저민 플랭클린 -

 

1. 개발 프로세스 (어떻게 개발을 수행 할 지 대한 큰 틀)

(1) 다양한 형태의 개발 프로세스 모델

역사 깊은 개발 프로세스 모델 "나선형", "폭포수", "V 모델"

개발을 진행하는 데 있어서 정답은 없다. 주어진 환경과 조건으로 최적의 결과물을 만들어내기만 하면 된다. 그러나 개발 진행에 있어 효율성의 차이는 분명 존재 한다. 체계적인 개발 프로세스를 이해하고 적용하는 개발자는 시행착오를 줄이고, 문제 해결 속도를 높이며, 최종적인 제품의 완성도를 높일 수 있다. 반면, 명확한 계획 없이 진행하는 개발은 불필요한 수정과 시간 낭비를 초래할 가능성이 크다. 체계적인 개발 프로세스를 이해하고 적용하는 개발자는 시행착오를 줄이고, 문제 해결 속도를 높이며, 최종적인 제품의 완성도를 높일 수 있다. 반면, 명확한 계획 없이 진행하는 개발은 불필요한 수정과 시간 낭비를 초래할 가능성이 크다. 즉, 개발은 단순한 기능 구현이 아니라, 문제 해결을 위한 최적의 방법을 찾아가는 과정이며, 이를 체계적으로 접근할수록 더욱 강력한 결과물을 만들어낼 수 있다.

(2) 임베디드 시스템 " V 모델링 "

임베디드 시스템에서는 신뢰성과 안정성(검증)이 중요한 항목이기 때문에 V 모델을 선호한다.

전통적인 폭포수 모델(Waterfall Model)을 확장한 형태의 V 모델은 개발과 검증을 병렬적으로 진행하는 구조를 가진다.

핵심적인 특징으로서는 개발자가 정의한 개발 단계와 테스트 단계가 1:1로 매칭 된다. 즉, 개발된 모든 요소는 반드시 검증과정을 거쳐야하는 형태이다. 개발과 테스트를 강조한 V 모델은 문제를 최소화 하고 제품의 완성도를 높일 수 있다.

물론 신속한 개발에 유리한 접근은 아니고 (문서 유지에 곤란함등의 결점이 존재한다.) 자동차, 항공우주, 국방, 산업 등의 신뢰성 및 안정성을 요구하는 개발에 요구되는 개발 프로세스 모델이다.

개발 프로세스를 반드시 수행하는 것에 의미있는 것이 아니라, 이미 효율적이라고 증명된 개발 프로세스 모델들을 숙지하고 개발에 임하는 습관을 들이는 것이 중요하다고 생각된다!

2. 요구사항 정의 (Requirements Definition)

(1) 정답이 없는 요구사항 정의 단계, 그래서 더 어렵게 느껴진다.

요구사항 정의 단계에서 이뤄지는 사항들은 정해진바 없다. 회사 양식에 맞춰 작성할 수도 있지만 1인 개발자의 경우 다양한 방법으로 구체화 한다.

 

어떤 개발 프로세스 모델을 사용하든지, 개발 초기에는 전체 시스템의 요구 사항을 반드시 고려해야 한다. 무엇을 개발 할 지에 대한 문서라고 생각하면된다. 이 과정이 구체화되고 명확할 수록 개발 속도가 빨라지고 시행착오를 줄일 수 있다. 요구사항 정의에는 정답이 없다. 개인적으로는 기술적인 접근으로 개발 계획을 표현하는 예술적인 과정이라고도 생각된다. 특히나 임베디드 시스템의 경우 하드웨어적인 변경이 어렵기 때문에, 요구사항 정의 단계에서 철저한 검토가 필수적이다. 아래에는 내가 자주 사용하는 요구사항 정의 단계의 수행 방법에 대해서 소개한다.

(2) 핀 매핑 정의서 (Pin Mapping)

MCU, I2C 및 SPI 장치에서 사용할 핀에 기능들을 작성하고 INPUT, OUTPUT 등을 표기하였다.

MCU를 사용하지 않는 임베디드 개발자에게 해당되는 내용은 아니지만, 어떤 핀을 어떻게 사용할 지에 대한 "핀 매핑 정의서"는 구체화에 큰 도움을 준다. 회로도, PCB 등을 설계할 때 뿐만 아니라 임베디드 소프트웨어 (펌웨어) 코드를 작성할 

때도 문서로 매핑이 명확하게 정리되어 있어 직관적으로 이해가 가능하다. I2C에서에서 각 장치의 I2C 주소를 작성해 두면 개발자가 I2C를 활용할때 충돌과 같은 버그들을 방지 할 수가 있다. SPI의 경우는 Chip Select 핀을 간단히 작성해 두면 코드 개발시 매우 용이하다.

(3) 아키텍처 (Architecture) 다이어그램

아키텍처도 표현일 뿐이다. 너무 명확하게 나타내려고 고생하지 않아도 된다.

구체화하면 구체화 할 수록 어려운게 아키텍처 (Architecture)이다. 아키텍처는 단지 결과물에 대한 설계도를 최대한 시각적으로 나타낸 다이어그램이다. 나의 경우에는 하드웨어(PCB)를 설계할 때 자주 아키텍처를 그려보는 데 회로도 설계시에 확실히 큰 도움이 많이된다. MCU를 기준으로 주변 인터페이스를 최대한 분류하여 핵심 기능들을 표현 해보자.

(4) 사양서 (Specification)

임베디드 개발 결과물의 스펙을 미리 작성해두면 하드웨어 개발 시 큰 도움이 된다.

전자제품을 보면 항상 기능들과 스펙을 표기한 사양서가 존재하는데, 이를 임베디드 시스템의 개발 요구사항에 활용하면 매우 효과적이다. 사양서는 단순한 정보가 아니라 성능, 기능, 하드웨어 제약, 인터페이스 등을 명확하게 정의하는 문서로써 하드웨어 개발의 기준점이 된다. 특히 하드웨어와 소프트웨어가 유기적으로 연결된 임베디드 시스템에서 성능적 요구사항을 미리 정의한 문서를 작성한다면 개발 속도를 높일 수 있다.