1. 임베디드 시스템의 라이프사이클
임베디드 시스템의 가장 큰 특징은 하드웨어라는 실물이 존재하고, 거기에 컴퓨터가 탑재되어 있다는 점이다.
이러한 임베디드 제품 및 시스템 설계에는 크게 두 가지 특징이 있다:
- 제품이나 시스템의 시장 공급을 가능한 한 빨리 실현하기 위해 각종 설계를 동시에 실행하는 동시 개발(concurrent development)
- 테스트 및 생산, 유지보수 등 상정했던 사항에 대해 이를 사전에 고려해서 설계하는 프런트 로딩(Design for X, Dfx)
2. 임베디드 시스템의 개발 방법
- 1. 동시 개발
동시 개발에서는 제품이나 시스템의 시장 공급을 가능한 한 빨리 실현하기 위해 각종 설계를 동시에 실시한다. 하드웨어 설계가 완료되지 않은 단계에서 동작하는 임베디드 소프트웨어 설계를 진행한다. 하드웨어의 상태를 읽어 낼 인터페이스가 정해져 있지 않은 단계에서 소프트웨어가 하드웨어에 어떻게 접근하는지에 대한 디자인도 진행한다.
동시 개발은 하드웨어와 소프트웨어의 설계를 동시에 진행할뿐만 아니라 외장 케이스 등의 디자인이나 메커니즘에 대해서도 동시에 진행한다. 또한, 제조에 시간이 필요한 LSI(Large-Scale Integrated circuit)의 설계도 동시에 진행하는 경우가 있다. LSI 는 인터페이스의 변경 등 변동에 따른 재작업이 발생하면 많은 시간과 비용이 소요되므로 가능한 한 선행 단계에서 인터페이스 등의 조건을 결정해야 한다.
- 2. 프런트 로딩
프런트 로딩은 제품이나 시스템의 전체 라이프사이클에서 고려해야 할 사항을 상위 단계의 설계에서 고려하고, 각 기능별로 구비하는 등 대책을 마련하는 개발 방법이다. (개발 초기에 발생 가능한 잠재적 문제를 사전에 파악하고 이에 따른 솔루션을 미리 마련하는 것)
환경에 대한 대응으로 환경 적응도에 대한 평가 기준을 마련하여 리뷰 및 평가에 의한 데이터를 수집해 개선하려는 DfE(Design for Environment) 프런트 로딩도 이뤄지고 있다.
검사 및 조정 작업의 효율화는 제품이나 시스템의 비용과 리드 타임(lead time)에 큰 효과가 있다. 임베디드 시스템은 양산되는 생산 수가 수 천에서 수 만에 이르는 매우 많은 경우도 있기 때문에 검사 및 조정 시간의 단축이 양산 효율을 높일 수 있고 이러한 생산 및 검사에 관한 프런트 로딩은 DfM(Design for Manufacturability) 이나 DfT(Design for Testability) 라고 부른다.
- 3. 임베디드 소프트웨어 개발 프로세스의 V 자 모델
임베디드 소프트웨어 개발 프로세스는 V 자 모델로 표현되는 경우가 많다. 기본적으로는 기업용 소프트웨어 개발과 같은 프로세스라고 해도 특별히 문제가 없다.
| 제품 기획 | 제품 심사 | ||
|---|---|---|---|
| 임베디드 시스템 개발 프로세스 | 시스템 요구 정의 ------------------------- | --------------------> 시스템 테스트 | |
| - | ㄴ 소프트웨어 요구 정의 --------------- | ---------------> / 소프트웨어 결합 테스트 | |
| 임베디드 소프트웨어 개발 프로세스 | ㄴ 소프트웨어 방식 설계 ---------- | ----------> / 소프트웨어 단위 테스트 | |
| - | ㄴ 소프트웨어 상세 설계 ----- | -----> / 하드웨어 개발 프로세스 등 | 하드웨어 개발 프로세스 |
| - | ㄴ 실 | 천 / | - |
- 4. 임베디드 소프트웨어 개발 프로세스
제품의 하드웨어를 포함한 설계는 이 임베디드 시스템 개발 프로세스에서 구체화된다. 기획서에 기재된 정보를 바탕으로 개발 대상인 제품에 관한 정보를 시스템 요구 사양서나 시스템 아키텍처 설계서로 구체화해 나간다. 그리고 그 문서들을 기반으로 테스트나 타당성 확인의 작업을 실시하여 개발한 제품이나 시스템을 생산 공정에 전달한다.
3. 임베디드 소프트웨어용 개발 프로세스 가이드 (ESPR)
다음의 개발 프로세스는 IPA 가 작성한 임베디드 소프트웨어용 개발 프로세스 가이드(Embedded System development Process Reference guide, ESPR) 을 바탕으로 한다.
- 1. 시스템 요구 정의
임베디드 시스템 개발 프로세스의 첫 단계인 시스템 요구 정의 에서는 기획서 등의 정보를 바탕으로 정보를 확인, 정리해 제품에 요구되는 요구사항을 요약 정리한 시스템 요구 사양서 를 만든다:
기능 요구: 시스템 요구 사양서에는 제품에 구비해야 할 기능비기능 요구: 제품에 요구되는 각종 품질 등(기능성, 신뢰성, 사용성, 효율성, 보수성, 이식성)제한 사항: 위 사항들을 처리할 때의 한계기능 요청: 각 시스템 간이나 사용자와의 인터페이스를 정의하고 제품의 입력에 대해 출력을 구체화한다. 사용자 시나리오 및 유스 케이스, 액티비티 다이어그램, 인터페이스 다이어그램 등 각종 문서도 작성한다.
* 사용자 시나리오: 사용자가 어떤 상황이나 환경에서 자신의 목표를 이루기 위해 어떻게 행동할 것인지를 적어보는 것.
* 액티비티 다이어그램: 일련의 Activity 들로 어떤 프로세스를 표현하는 다이어그램으로, 모든 종류의 프로세스를 표현.
임베디드 시스템에서는 제품별로 혹은 이용자별로 원하는 요구의 우선순위가 다르다. 의료 기기에서는 신뢰성과 보수성이 중요시되지만, 일반 소비자용 기긱에서는 사용성과 효율성이 중시된다. 단, 이것은 가장 우선적인 요구가 바뀌는 것만을 의미하기 때문에 다른 것이 요구되지 않는다는 의미가 아니다.
- 2. 시스템 아키텍쳐 설계
시스템 아키텍쳐 설계 에서는 시스템 요구 정의에서 작성된 시스템 요구 사양서를 바탕으로 하드웨어를 포함한 시스템 아키텍쳐 설계서를 작성한다. 먼저 하드웨어 및 소프트웨어 등의 역할 및 기능 분담을 고려하고, 각각의 구성 및 동작을 구체화한다.
각 기능 간의 인터페이스나 제한 사항을 명확히 하고, 이후의 하드웨어나 소프트웨어가 개별적으로 설계 가능하도록 한다.
예시) 핵심은 시스템 요구를 어떻게 실현할 것인지를 주안으로 둔다.
- 하드웨어의 경우,
LSI로 실현할 것인가FPGA(Field-Programmable Gate Array)로 실현할 것인가? - 소프트웨어의 경우, 공장 출하 시에 ROM 이나 플래시 ROM 에 기록해서 탑재할 것인가?
또 소프트웨어 업데이트 또한 가능하게 할 것인가? - 기존 제품의 재사용할 것인가 상업용 부품의 활용할 것인가? (make or buy)
이러한 시스템 요구 사양서에 기재된 QCD(Quality, Cost, Delivery; 비용, 품질, 납기) 를 고려해 최적의 실현 방법을 선택한다.
이처럼 시스템으로서 요구되는 기능 요구 및 비기능 요구를 QCD 등의 제약을 고려하면서 시스템의 구조와 동작을 검토하는 것이 시스템 아키텍쳐 설계 다. (따라서 아키텍터가 가진 지식과 경험이 매우 중요)
- 3. 소프트웨어 요구 정의
소프트웨어 요구 정의 는 임베디드 소프트웨어 개발 프로세스의 첫 번째 단계다. 시스템 요구 사양서 (1. 시스템 요구 정의) 및 하드웨어 사양서 (2. 시스템 아키텍쳐 설계; 시스템 아키텍쳐 설계서) 를 바탕으로 임베디드 소프트웨어에 관한 요구사항을 검토 및 구체화한다.
소프트웨어 개발에서 요구는 개발 프로세스의 시작 단계인 상위 공정에서 실시하는 중요한 작업이다. 요구를 제대로 정의할 수 없으면 소프트웨어의 완성도가 높아지고 납기가 다가오는 상황에서 앞 공정으로 되돌아가 버리는 경우가 많아진다.
소프트웨어 공학에서는 요구사항 공학이 체계화되어 있다. 요구사항 공학은 요구사항 개발과 요구사항 관리로 크게 나뉘며 요구사항 개발은 다음과 같은 흐름이다:
- 요구사항을 추출 및 획득한다.
- 요구사항을 분석한다.
- 요구사항을 사양으로 정의한다.
- 정의한 요구사항에 대한 사양의 타당성을 확보한다.
- 4. 소프트웨어 아키텍쳐 설계
소프트웨어 아키텍쳐 설계 는 소프트웨어 요구 사양서나 하드웨어 사양서를 바탕으로 임베디드 소프트웨어에 대한 아키텍쳐를 검토 및 구체화하는 공정이다. 이 공정에서는 시스템 아키텍쳐 설계와 마찬가지로 각종 제약을 고려하여 소프트웨어의 구조와 동작을 구체화한다.
유사한 제품의 소프트웨어를 재사용하거나 상업용 소프트웨어 부품 (Commercial Off-The-Shelf, COTS) 의 활용을 포함해 소프트웨어 아키텍쳐 설계서 를 작성해나간다.
임베디드 소프트웨어가 실현하는 기능을 정리한 것을 기능 유닛 이라고 부르며, 기능 유닛을 구성하는 프로그램의 최소 단위를 프로그램 유닛 이라고 한다. 이 프로그램 유닛은 컴파일과 테스트를 실시하는 단위(이후 6. 구현 단위 테스트 에서 자세히)이며 소프트웨어 아키텍쳐 설계에서는 이 기능 유닛을 어떻게 구성할지, 그리고 그것들이 어떤 인터페이스인지를 설계한다.
이 공정에서 중요한 설계로는 예외 와 공통 상수의 정의 가 있다. 특히, 신뢰성이 요구되는 기기는 예외 처리 쪽이 정상적인 기본 처리보다도 많을 때가 많다.
- 5. 소프트웨어 상세 설계
소프트웨어 아키텍쳐 설계서(4. 소프트웨어 아키텍쳐 설계) 를 바탕으로 기능 유닛 에 포함된 각 프로그램 유닛 의 논리 조건과 처리 항목을 구체화해 나가는 공정이 소프트웨어 상세 설계 이다. (아직 코딩 안함)
소프트웨어 상세 설계에서는 다음 공정인 구현 공정에서 각 담당자가 프로그램 유닛을 코딩할 때에 필요한 정보를 구체화한다. 어떠한 함수(모듈)의 구조 및 조합에 대해 구체화하고 프로그램의 내부 구조(함수 및 모듈의 호출 관계) 를 설계한다. 동적인 동작은 모듈의 호출 방법(동기/비동기식)과 모듈 내부의 상태 제어로 설계한다.
- 6. 구현, 단위 테스트
소프트웨어 상세 설계서 (5. 소프트웨어 상세 설계) 를 바탕으로 프로그램 유닛을 프로그래밍해 나가는 과정이 구현 이다. 공통적으로 사용하는 프로그램 유닛을 선택하고 개발환경을 확인한 후 작업을 시작한다.
단위 테스트 는 프로그램 유닛이 설계대로 구현되어 있는지 확인한다. 단위 테스트에서 체크하는 것은 프로그램 유닛이 사양에서 규정한 동작을 하는 것과 사양에서 규정하지 않은 데이터를 받아도 비정상적인 동작을 하지 않는 것이다.
테스트의 목적은 버그를 찾아내는 것이지 버그의 원인을 찾는 것이 아니다. 버그의 원인을 찾아서 수정하는 것을 디버깅 (debugging) 이라고 한다. 단위 테스트는 프로그램 유닛의 버그를 찾아내는 것이 목적이며 따라서 구석구석을 파고들어 집요하게 테스트 항목을 설계하고, 버그가 없음을 증명해야 한다.
- 7. 소프트웨어 결합, 통합 테스트
소프트웨어 결합 테스트 에서는 프로그램 유닛을 결합(연결)하여 기능 유닛과 임베디드 소프트웨어가 설계대로 구현되어 있는지 확인한다. 이 테스트는 소프트웨어 아키텍쳐 설계서 (4. 소프트웨어 아키텍쳐 설계) 에 기재된 설계 정보대로 임베디드 소프트웨어가 동작하는지 확인하는 공정이다.
소프트웨어 통합 테스트 는 기능 유닛 등 임베디드 소프트웨어를 모두 통합한 상태에서 사양대로 제대로 동작하는지 확인한다. 소프트웨어 요구 사양서 (3. 소프트웨어 요구 정의) 에 기재된 사양대로 임베디드 소프트웨어가 동작하는지 확인한다.
소프트웨어 공학을 체계적으로 정리하고 있는 SWEBOK (Software Engineering Body Of Knowledge) 에서는 소프트웨어 테스팅(Software Testing) 을 다음과 같이 정의한다:
일반적으로 무한한 경우의 수가 존재하는 실행 공간으로부터 적절하게 선정한 유한한 수의 테스트 케이스를 해당 프로그램에 적용해서 동적으로 그 동작을 미리 사양화된 기대 행동과 비교, 확인하는 작업으로 구성된다.
위의 적절하게 선정한 테스트 케이스 를 추출하기 위해서 사양화된 기대 행동 인 사양서 및 설계서에서 테스트 조건을 정의한다. 테스트 조건을 통해 추출하는 테스트 케이스는 적절한 테스트 설계 기법을 선택해서 작성한다. 그리고 테스트 케이스를 동적으로 검증하기 위한 테스트 절차를 작성한다:
- 테스트 조건의 확인
- 테스트 케이스의 작성
- 테스트 절차의 작성 (테스트 데이터의 작성)
테스트 케이스의 작성에서는 테스트 조건을 기반으로 테스트 기법을 사용하여 구체적인 조건을 작성한다. 테스트 기법의 분류로는 블랙박스와 화이트박스 가 있다:
- 블랙박스의 경우, 내부 구조는 대상으로 하지 않고, 사양서 및 설계서를 토대로 테스트 조건과 테스트 케이스를 작성 및 선택한다. 블랙박스에는 동치 분할, 경계값 분석, 의사 결정 테이블 테스트, 상태 전이 테스트 등의 기법이 존재한다.
- 화이트박스의 경우, 프로그램 유닛 및 기능 유닛, 하드웨어의 내부 구조를 정리해 테스트 설계를 한다. 테스트 망라 비율 기준에는 명령 망라(C0 기준), 분기 망라(C1 기준), 복합 조건 망라(C2 기준) 등이 있다.
- 8. 소프트웨어 타당성 확인 테스트
소프트웨어 타당성 확인 테스트는 소프트웨어 요구 사양을 충족하고 있는지 확인한다. 대규모나 안전성이 요구되는 대규모 임베디드 소프트웨어를 개발하는 일부 기업에는 타당성을 확인하는 조직이 있으며, 개발 팀에서의 테스트 후, 발주자나 이용자의 관점에서 다시 타당성 확인을 실시하는 곳도 있다.
- 9. 시스템 결합, 통합 테스트와 시스템 타당성 확인 테스트
시스템 결합 및 통합 테스트 는 소프트웨어나 하드웨어 등 별도로 개발된 구성 요소를 결합하여 제대로 동작하는지 검증한다. 소프트웨어 결합 및 통합 테스트에서도 하드웨어에 탑재해 테스트를 진행했지만, 여기에서는 시스템 전체에서 검증한다.
시스템 타당성 확인 테스트 에서는 제품으로 시스템 요구 사양을 충족하는지 확인한다. 실제로 사용되는 환경에서 확인 작업이 이루어지는데, 사양에 명시된 범위(또는 범위 이상)라는 엄격한 환경에서의 확인 작업도 동시에 실시한다.
- 10. 제품 출하
개발 부문에서 시스템 타당성 확인 테스트를 완료한 후에는 제품을 출하하는 공정으로 나아간다. 양산 설계를 거쳐 양산되고, 비로소 제품이 출하된다. 단, 양산 설계 단계에서 임베디드 소프트웨어의 변경, 특히 비용과 품질을 고려한 설계 변경이 발생할 수도 있다.
임베디드 소프트웨어 개발 프로세스의 V 자 모델에 따라 개발이 진행되는 과정을 풀어서 썼는데 임베디드 시스템의 설계와 개발 프로세스 분야에서 많은 연구가 이뤄졌음을 알 수 있었다. 일본정보처리추진기구(IPA, Information-technology Agency),에서 발표한 가이드인데 체계화가 정말 잘 되어 있음을 알 수 있다.
출처
[책] 임베디드 엔지니어 교과서 (와타나베 노보루, 마키노 신지 지음, 정인식 옮김)
[사이트] https://brunch.co.kr/@b30afb04c9f54dc/20
[사이트] https://invincibletyphoon.tistory.com/60
