1장 임베디드와 실시간 시스템을 위한 소프트웨어 공학<br/><br/>__소프트웨어 공학<br/><br/>__임베디드 시스템<br/><br/>____임베디드 시스템은 반응 시스템이다<br/><br/>__실시간 시스템<br/><br/>____실시간 시스템의 유형: 소프트와 하드<br/><br/>____하드 실시간 시스템의 사례<br/><br/>____실시간 이벤트의 특성<br/><br/>____효율적 실행과 실행 환경<br/><br/>__실시간 시스템 설계에서의 도전<br/><br/>____반응 시간<br/><br/>____장애로부터 복구<br/><br/>____임베디드 시스템 소프트웨어 구축 프로세스<br/><br/>__분산과 멀티프로세서 아키텍처<br/><br/>__임베디드 시스템을 위한 소프트웨어<br/><br/>____슈퍼 루프 아키텍처<br/><br/>__임베디드 시스템을 위한 하드웨어 추상화 계층(HAL)<br/><br/>__정리<br/><br/> <br/><br/>2장 임베디드 시스템 하드웨어/소프트웨어 공동 개발<br/><br/>__오늘날의 임베디드 시스템: 사례<br/><br/>__HW/SW 프로토타이핑 사용자<br/><br/>__HW/SW 프로토타이핑 선택 사항<br/><br/>__프로토타이핑 결정 기준<br/><br/>__올바른 프로토타입 선택<br/><br/>__산업 설계 사슬<br/><br/>__설계 흐름의 변경 필요성<br/><br/>__가상 프로토타입의 다양한 유형<br/><br/>__가상 프로토타입의 간략한 역사<br/><br/>__독점 오퍼에 대한 제한 사항<br/><br/>__가상 프로토타입을 빠르게 만드는 것<br/><br/>__표준화: SystemC TLM-2.0 시대<br/><br/>____SystemC TLM-2.0 추상화 레벨<br/><br/>__아키텍처 가상 프로토타입<br/><br/>__소프트웨어 가상 프로토타입<br/><br/>__정리: 가상화 중요성의 증가<br/><br/> <br/><br/>3장 임베디드 시스템을 위한 소프트웨어 모델링<br/><br/>__언제 그리고 왜 임베디드 시스템을 모델로 만들려고 하는가?<br/><br/>__모델링<br/><br/>__모델링 언어는 무엇인가?<br/><br/>__모델링 언어의 사례<br/><br/>__V 다이어그램의 약속<br/><br/>__왜 임베디드 시스템을 모델로 만들려고 하는가?<br/><br/>__언제 임베디드 시스템을 모델로 만들려고 하는가?<br/><br/>____임무와 안전 필수 애플리케이션<br/><br/>____고도로 복잡한 애플리케이션과 시스템<br/><br/>__운용의 복잡성<br/><br/>__결함 비용과 검출 시간<br/><br/>__규모가 큰 개발 팀은 모델링을 요구한다<br/><br/>__모델링은 종종 유일한 선택이다<br/><br/>__모델링은 훌륭하지만, 모든 모델이 틀리지는 않는가?<br/><br/>__자신의 프로토타입을 가져야 한다: 이제 어떻게 해야 하는가?<br/><br/>__정리<br/><br/>__다음 단계: 시도하라!<br/><br/>____DC 모터를 이용한 폐회로 제어<br/><br/>____다운로드 가능 킷을 이용한 프로토타이핑 더 배우기<br/><br/>____NI 상태 차트 모듈을 이용한 애플리케이션 설계<br/><br/>____브러시를 갖는 DC 모터의 H 브리지 회로의 설계와 시뮬레이션<br/><br/>____모델리카 모델을 이용한 다중 도메인의 물리적 모델링<br/><br/>__참고 문헌<br/><br/> <br/><br/>4장 임베디드 시스템을 위한 소프트웨어 설치 아키텍처와 패턴<br/><br/>__아키텍처와 설계 개요<br/><br/>____아키텍처는 시스템 전역 최적화에 관한 것이다<br/><br/>__세 가지 설계 레벨<br/><br/>__설계 패턴이란?<br/><br/>____설계 패턴을 이용하기 위해 객체지향 기법을 이용해야만 하는가?<br/><br/>____아키텍처 사례<br/><br/>____패턴 사용<br/><br/>____트레이드오프 결정<br/><br/>__소프트웨어 아키텍처 범주와 뷰<br/><br/>____주 아키텍처 뷰<br/><br/>____2차 관점<br/><br/>__정리<br/><br/>__참고 문헌<br/><br/> <br/><br/>5장 실시간 빌딩 블록: 이벤트와 트리거<br/><br/>__이벤트와 트리거<br/><br/>__실내 온도 구성단위<br/><br/>__이벤트 시스템<br/><br/>__이벤트 처리<br/><br/>__이벤트 메소드<br/><br/>__이벤트 데이터 구조<br/><br/>__재진입<br/><br/>____인터럽트 불능과 가능<br/><br/>____EnterCritical과 ExitCritical<br/><br/>____세마포어<br/><br/>____Enter/ExitCritical을 이용한 구현<br/><br/>__이벤트 처리<br/><br/>__통합<br/><br/>__트리거<br/><br/>__LED 깜박이기<br/><br/>__설계 아이디어<br/><br/>__틱 타이머<br/><br/>__트리거 인터페이스<br/><br/>__트리거 디스크립터<br/><br/>__데이터 할당<br/><br/>__SetTrigger<br/><br/>__IncTicks<br/><br/>__재진입 만들기<br/><br/>__초기화<br/><br/>__깜박이기!<br/><br/>__삐 소리 내기!<br/><br/>__실시간 양상<br/><br/>__정리와 소스코드<br/><br/> <br/><br/>6장 임베디드 소프트웨어에 대한 하드웨어 인터페이스<br/><br/>소개<br/><br/>하드웨어 팀과의 협업<br/><br/>____능동적 협업<br/><br/>____앰버서더<br/><br/>____레지스터 설계 툴<br/><br/>____공동 개발 활동<br/><br/>____시스템 통합<br/><br/>__유용한 하드웨어 설계 양상<br/><br/>____하드웨어 이벤트 통지<br/><br/>____하드웨어에서의 작업 시작<br/><br/>____비트 필드 정렬<br/><br/>____고정 비트 위치<br/><br/>____블록 버전 번호 <br/><br/>____디버그 후크<br/><br/>__다중 하드웨어 버전 지원<br/><br/>____컴파일 시간 스위치<br/><br/>____빌드 시간 스위치<br/><br/>____실행 시간 스위치<br/><br/>__자가 적응 스위치<br/><br/>__어려운 하드웨어 상호작용<br/><br/>____정확한 레지스터 접근<br/><br/>____동일 레지스터에서의 혼합 비트 유형<br/><br/>____에지와 레벨 인터럽트<br/><br/>__테스팅과 문제 해결<br/><br/>__일시적 후크<br/><br/>____영구적 후크<br/><br/>__정리<br/><br/>__성공 사례<br/><br/> <br/><br/>7장 임베디드 소프트웨어 프로그래밍과 구현 가이드라인<br/><br/>__소개<br/><br/>____고품질 프로그래밍의 원칙<br/><br/>____임베디드 프로그래밍이 일반 프로그래밍과 다른 점<br/><br/>__임베디드 소프트웨어 프로젝트 시작<br/><br/>____하드웨어 플랫폼 입력<br/><br/>____프로젝트 파일/구성<br/><br/>____팀 프로그래밍 가이드라인<br/><br/>____구문 표준<br/><br/>____소스코드에서의 안전성 요구 사항<br/><br/>__변수 구조<br/><br/>____변수 선언<br/><br/>____데이터 유형<br/><br/>____정의<br/><br/> <br/><br/>8장 임베디드 운영체제<br/><br/>__포어그라운드/백그라운드 시스템<br/><br/>__실시간 커널<br/><br/>____실시간 운영체제(RTOS)<br/><br/>____임계 구간<br/><br/>____태스크 관리<br/><br/>____태스크 우선순위 할당<br/><br/>____스택 크기 결정<br/><br/>____유휴 태스크<br/><br/>__우선순위 레벨<br/><br/>__준비 목록<br/><br/>____선점형 스케줄링<br/><br/>__스케줄링 시점<br/><br/>____라운드로빈 스케줄링<br/><br/>__문맥 스위칭 <br/><br/>__인터럽트 관리<br/><br/>____CPU 인터럽트 처리<br/><br/>____비커널 인식 인터럽트 서비스 루틴(ISR)<br/><br/>____다중 인터럽트 우선순위를 가진 프로세서<br/><br/>____공통 장소에 대한 모든 인터럽트 벡터<br/><br/>____유일 장소에 대한 모든 인터럽트 벡터<br/><br/>__클록 틱(또는 시스템 틱)<br/><br/>__대기 목록<br/><br/>__시간 관리<br/><br/>__자원 관리<br/><br/>____자원 관리, 불능/가능 인터럽트<br/><br/>____자원 관리, 세마포어<br/><br/>____자원 관리, 우선순위 전환<br/><br/>____자원 관리, 상호 배제 세마포어(뮤텍스)<br/><br/>____자원 관리, 교착상태(또는 죽음의 포옹)<br/><br/>__동기화<br/><br/>____동기화, 세마포어<br/><br/>____동기화, 크레딧 트래킹<br/><br/>____쌍방 랑데부<br/><br/>__메시지 패싱<br/><br/>____메시지<br/><br/>____메시지 큐<br/><br/>____제어 흐름<br/><br/>____클라이언트와 서버<br/><br/>__메모리 관리<br/><br/>__정리<br/><br/> <br/><br/>9장 임베디드 시스템에서 설계에 의한 소프트웨어 재사용<br/><br/>__소프트웨어 재사용이 문제가 되는 이유<br/><br/>__소프트웨어 재사용의 제한 사항<br/><br/>__소프트웨어 재사용의 종류<br/><br/>__계층에 의한 재사용 구현<br/><br/>__다음 레벨로 이동<br/><br/>__컴포넌트 팩토리 소개<br/><br/>__팩토리 하드웨어 구성<br/><br/>__팩토리 소프트웨어 구성<br/><br/>__팩토리가 재사용성을 지원하는 방법<br/><br/>__RTOS 불가지론<br/><br/>__임의 확장성<br/><br/>__정리<br/><br/>__참고 문헌<br/><br/> <br/><br/>10장 임베디드 시스템을 위한 소프트웨어 성능 공학<br/><br/>__사례: eNodeB 애플리케이션에서 지연과 처리량<br/><br/>__성능 패턴과 안티패턴<br/><br/>__참고 문헌<br/><br/> <br/><br/>11장 임베디드 소프트웨어의 성능 최적화<br/><br/>__코드 최적화 프로세스<br/><br/>__개발 툴 이용<br/><br/>____컴파일러 최적화<br/><br/>____기본 컴파일러 구성<br/><br/>____최적화 보장 활동<br/><br/>____추가 최적화 구성<br/><br/>____프로파일러 이용<br/><br/>__배경: 임베디드 아키텍처 이해<br/><br/>____자원<br/><br/>__기본 C 최적화 기법<br/><br/>____올바른 데이터 유형 선택<br/><br/>____함수 호출 관례<br/><br/>____포인터와 메모리 접근<br/><br/>____제한과 포인터 대역<br/><br/>____루프<br/><br/>____추가 팁과 비법<br/><br/>__일반 루프 변환<br/><br/>____루프 언롤링<br/><br/>____다중 샘플링<br/><br/>____부분 합<br/><br/>____소프트웨어 파이프라이닝<br/><br/>__최적화 기법 애플리케이션 사례: 교차 상관관계<br/><br/>____준비<br/><br/>____최초 구현<br/><br/>____1단계: 분수 연산을 위한 인트린식 사용과 루프 카운트 명시<br/><br/>____2단계: 데이터 정렬 명시와 다중 샘플링 알고리즘 수정<br/><br/>____3단계: 어셈블리 언어 최적화<br/><br/> <br/><br/>12장 임베디드 소프트웨어의 메모리 최적화<br/><br/>__소개<br/><br/>__코드 크기 최적화<br/><br/>____컴파일러 플래그와 플래그 마이닝<br/><br/>____크기와 성능 트레이드오프를 위한 타깃 ISA<br/><br/>____코드 크기를 위한 ABI 튜닝<br/><br/>____캐비앳 엠프토르: 코드 크기에 직교적인 컴파일러 최적화!<br/><br/>__메모리 레이아웃 최적화<br/><br/>____메모리 최적화 개요<br/><br/>____최적화 노력에 집중<br/><br/>____벡터화와 동적 코드: 비율 계산<br/><br/>____C의 포인터 에일리어싱<br/><br/>__데이터 구조, 데이터 구조 배열, 합산<br/><br/>__메모리 성능을 위한 루프 최적화<br/><br/>____데이터 정렬 파급 효과<br/><br/>____큰 성과를 위한 데이터 유형 선정<br/><br/> <br/><br/>13장 임베디드 소프트웨어의 전력 최적화<br/><br/>__소개<br/><br/>__전력 소비의 이해<br/><br/>____전력 소비 기초<br/><br/>____정적과 동적 전력 소비<br/><br/>____최대, 평균, 최악, 일반 전력<br/><br/>__전력 소비 측정<br/><br/>____전류계를 이용한 전력 측정<br/><br/>____홀 센서 유형 IC를 이용한 전력 측정<br/><br/>____VRM(전압 조정기 모듈 전력 공급 장치 IC)<br/><br/>____정적 전력 측정<br/><br/>____동적 전력 측정<br/><br/>____애플리케이션의 전력 소비 프로파일링<br/><br/>__전력 소비 최소화<br/><br/>____하드웨어 지원<br/><br/>____클록과 전압 제어<br/><br/>____저전력 사례<br/><br/>__데이터 흐름 최적화<br/><br/>____메모리 접근을 위한 전력 소비 줄이기<br/><br/>____DDR 개요<br/><br/>____전력용 DDR 데이터 흐름 최적화<br/><br/>____타이밍에 의한 전력 최적화<br/><br/>____인터리빙을 이용한 최적화<br/><br/>____메모리 소프트웨어 데이터 구성 최적화<br/><br/>____일반 DDR 구성 최적화<br/><br/>____DDR 버스트 접근 최적화<br/><br/>__전력을 위한 SRAM과 캐시 데이터 흐름의 최적화<br/><br/>____SRAM(모든 메모리)과 코드 크기<br/><br/>____SRAM 전력 소비와 병렬화<br/><br/>____데이터 전이와 전력 소비<br/><br/>____캐시 활용과 SoC 메모리 레이아웃<br/><br/>____지역성 설명<br/><br/>____집합 연관도 설명<br/><br/>____캐시를 위한 메모리 레이아웃<br/><br/>____후기입과 연속 기입 캐시<br/><br/>____캐시 일관성 기능<br/><br/>____컴파일러 캐시 최적화<br/><br/>__주변기기/통신 활용<br/><br/>____데이터 DMA와 CPU<br/><br/>____코프로세서<br/><br/>____시스템 버스 구성<br/><br/>____주변기기 속도 등급과 버스 폭<br/><br/>____핵심 통신에 대한 주변기기<br/><br/>__알고리즘<br/><br/>____컴파일러 최적화 레벨<br/><br/>____명령 패킹<br/><br/>____루프 언롤링 재고<br/><br/>____소프트웨어 파이프라이닝<br/><br/>____반복 제거<br/><br/>____정확성 줄이기<br/><br/>____저전력 코드 시퀀스와 데이터 패턴<br/><br/>__정리<br/><br/> <br/><br/>14장 임베디드 시스템을 위한 인간 요소와 사용자 인터페이스 설계<br/><br/>__사용자 인터페이스 설계의 분석 단계<br/><br/>____첫 번째 설계 반복<br/><br/>____두 번째 프로토타입 개발(고성능 툴로 작성된 실물 모형)<br/><br/>____필수 유스케이스<br/><br/>____사용자 분석 시나리오<br/><br/>____계층적 태스크 분석<br/><br/>____사용자의 인지, 지각, 학습의 제한사항 극복을 위한 설계 접근법<br/><br/>____오류 메시지<br/><br/>__가상 윈도우<br/><br/>__엔티티 관계 다이어그램(ERD)을 이용한 데이터 모델<br/><br/>__CREDO 매트릭스를 이용한 가상 윈도우 분석<br/><br/>__발견적(휴리스틱) 평가<br/><br/>__형태(게슈탈트)<br/><br/>__MVC 아키텍처를 이용한 사용자 인터페이스 설계<br/><br/>____MVC 소프트웨어 아키텍처의 상황<br/><br/>____MVC 소프트웨어 아키텍처의 문제와 영향력<br/><br/>____MVC를 이용한 해결책<br/><br/>__안전 필수 사용자 인터페이스<br/><br/>____안전한 HMI 설계 프로세스<br/><br/>____안전한 인간-기계 인터페이스 설계 가이드라인<br/><br/>__참고 문헌<br/><br/>__관련 문헌<br/><br/> <br/><br/>15장 임베디드 시스템 품질, 통합, 테스팅 기법<br/><br/>__소프트웨어 테스트란?<br/><br/>____소프트웨어를 테스트해야 하는 이유<br/><br/>____테스팅에 충분한 양<br/><br/>____테스팅 시점<br/><br/>____누가 결정하는가?<br/><br/>__이용 가능한 기법<br/><br/>____정적과 동적 분석<br/><br/>____요구 사항 추적성<br/><br/>____코딩 표준에 엄격한 정적 분석<br/><br/>____필수 노트와 필수 순환 복잡도 사례연구<br/><br/>____동적 분석의 이해<br/><br/>____고집적 시스템의 유물<br/><br/>____단위, 모듈, 통합 테스트 정의<br/><br/>____구조적 커버리지 분석 정의<br/><br/>____탠덤에서 단위 테스트와 시스템 테스트에 의해 코드 커버리지 성취<br/><br/>____회귀 테스트를 통한 기능성 유지<br/><br/>____단위 테스트와 테스트 주도 개발<br/><br/>____테스트 케이스 자동 생성<br/><br/>__표준 설정<br/><br/>____표준 용어<br/><br/>____공인 프로세스 표준의 진화<br/><br/>____적절한 표준 선택의 자유<br/><br/>__특이 상황 처리<br/><br/>____자동 생성 코드 작업<br/><br/>____레거시 코드와 작업<br/><br/>____목적 코드 베리피케이션(OCV)을 통한 요구 사항 추적<br/><br/>__테스트 솔루션 환경 구현<br/><br/>____실용적 고려 사항<br/><br/>____대안 고려<br/><br/>__정리<br/><br/> <br/><br/>16장 임베디드 시스템용 소프트웨어 개발 툴<br/><br/>__디버깅 툴 소개<br/><br/>__GDB 디버깅<br/><br/>____GDB 디버거 구성<br/><br/>____GDB 시작<br/><br/>____애플리케이션 컴파일<br/><br/>____애플리케이션 디버깅<br/><br/>____데이터 검사<br/><br/>____중단점 이용<br/><br/>____스텝으로 만들기<br/><br/>____프로그램 변경<br/><br/>____코어 덤프 분석<br/><br/>__디버그 에이전트 설계<br/><br/>____사용 예<br/><br/>____디버그 에이전트 개요<br/><br/>____애플리케이션 시작<br/><br/>____문맥 스위치<br/><br/>____위치 독립 실행 가능자<br/><br/>____애플리케이션으로부터 나온 디버그 이벤트<br/><br/>____다중 코어<br/><br/>____디버그 에이전트 시작<br/><br/>__JTAG를 이용한 디버깅<br/><br/>____JTAG 이용의 이점<br/><br/>____JTAG를 이용한 보드 브링업<br/><br/>____디버그 에이전트와의 비교<br/><br/>____GDB와 JTAG<br/><br/>__이클립스와 GDB를 이용한 디버깅 툴<br/><br/>____GDB를 이용한 리눅스 애플리케이션 디버그<br/><br/>____KGDB를 이용한 리눅스 커널 디버그<br/><br/>__계측 코드<br/><br/>____실제 사례<br/><br/>__분석 툴<br/><br/>____Strace<br/><br/>____Mtrace<br/><br/>____Valgrind<br/><br/>__하드웨어 능력<br/><br/>____하드웨어 중단점<br/><br/>____하드웨어 감시점<br/><br/>__디버깅 비법과 요령<br/><br/> <br/><br/>17장 임베디드 시스템용 다중 코어 소프트웨어 개발<br/><br/>__1부: 분석과 고수준 설계<br/><br/>__분석<br/><br/>____직렬 성능 향상<br/><br/>____애플리케이션의 이해<br/><br/>__고수준 설계<br/><br/>____병렬 분해<br/><br/>____데이터 종속성<br/><br/>____통신과 동기화<br/><br/>____부하 균형<br/><br/>____알고리즘 선택<br/><br/>____분해 접근법<br/><br/>__1부 정리<br/><br/>__2부: 구현과 저수준 설계<br/><br/>__스레드 기반 구현<br/><br/>____커널 스케줄링<br/><br/>____POSIX 스레드(Pthreads)<br/><br/>____PPthreads 이용<br/><br/>____스레드 안전성 처리<br/><br/>____동기화와 상호 배제 구현<br/><br/>__뮤텍스, 잠금장치, 중첩 잠금장치<br/><br/>____뮤텍스<br/><br/>____조건 변수<br/><br/>__입상도<br/><br/>____작은 범위<br/><br/>____큰 범위<br/><br/>____접근법<br/><br/>__태스크 병행성 구현<br/><br/>____생성과 연결<br/><br/>____병렬 파이프라인 계산<br/><br/>____분할 정복 스키마<br/><br/>____태스크 스케줄링 고려 사항<br/><br/>____스레드 풀링<br/><br/>____친화력 스케줄링<br/><br/>____이벤트 기반 병렬 프로그램<br/><br/>____루프 병행성 구현<br/><br/>____계산과 집약성 정렬<br/><br/>__메시지 전달 구현<br/><br/>____MCAPI<br/><br/>____MRAPI<br/><br/>____다중 코어 시스템의 MCAPI와 MRAPI<br/><br/>____플레잉 카드 인식과 분류 사례<br/><br/>__하이브리드 접근법 이용<br/><br/>__참고 문헌<br/><br/> <br/><br/>18장 안전 필수 소프트웨어 개발<br/><br/>__소개<br/><br/>__어떤 안전 요구 사항인가?<br/><br/>____인증 킬러<br/><br/>__프로젝트 기획 전략<br/><br/>____전략 1: 초기에 프로젝트의 인증 범위 결정<br/><br/>____전략 2: 인증의 타당성 결정<br/><br/>____전략 3: (사용한다면) 독립적 평가자 선정<br/><br/>____전략 4: (사용한다면) 평가자의 역할 이해<br/><br/>____전략 5: 평가 의사소통이 핵심<br/><br/>____전략 6: 인증의 베이시스 정립<br/><br/>____전략 7: 제품의 ‘적합성과 목적’정립<br/><br/>____전략 8: 인증의 블록 다이어그램 정립<br/><br/>____전략 9: 의사소통의 통합 목표 정립<br/><br/>____전략 10: 인증 경계의 모든 인터페이스 식별<br/><br/>____전략 11: 핵심 안전 방어 전략 식별<br/><br/>____전략 12: 빌트인 테스트(BIT) 능력 정의<br/><br/>____전략 13: 결점 경보 커버리지 정의<br/><br/>____전략 14: 운용자/사용자의 의지와 기대 정의<br/><br/>____전략 15: 적절한 통합 레벨에서의 소프트웨어 개발 계획 정의<br/><br/>____전략 16: 규정 준수의 증거로서 사용될 인공물 정의<br/><br/>____전략 17: 노동 집약 분석 계획<br/><br/>____전략 18: 사용자 레벨 문서 생성<br/><br/>____전략 19: 잔여 활동 계획<br/><br/>____전략 20: 명확한 인증 계획 발간<br/><br/>__결점, 장애, 위험, 리스크 분석<br/><br/>____결점, 오류, 장애<br/><br/>____가용성과 신뢰성<br/><br/>____결점 처리<br/><br/>____위험 분석<br/><br/>____리스크 분석<br/><br/>__안전 필수 아키텍처<br/><br/>____행위자(Do-er)/검사자(check-er)<br/><br/>____두 개의 프로세서<br/><br/>____투표자<br/><br/>__소프트웨어 구현 전략<br/><br/>____전략 1: 명확하고 반복적인 동료 검토 프로세스가 있는가<br/><br/>____전략 2: 기존의 안전 코딩 표준에 대한 이용 고려<br/><br/>____전략 3: 입력 데이터의 모든 조합 처리<br/><br/>____전략 4: 특정 변수 값 검사<br/><br/>____전략 5: 안전 필수 코드 구역 표시<br/><br/>____전략 6: 타이밍 실행 검사<br/><br/>____전략 7: 진부한 데이터<br/><br/>____전략 8: 출력 비교<br/><br/>____전략 9: 최소 허용 상태로 데이터 초기화<br/><br/>____전략 10: 실행 순서<br/><br/>____전략 11: 휘발성 데이터 검사<br/><br/>____전략 12: 비휘발성 데이터 검사<br/><br/>____전략 13: 전체 시스템이 동작할 수 있는지 확인<br/><br/>____전략 14: ‘불필요’ 코드 제거<br/><br/>____전략 15: 비사용 메모리 작성<br/><br/>____전략 16: 정적 코드 분석<br/><br/>__참고 문헌<br/><br/> <br/><br/>19장 지적 재산<br/><br/>__배경<br/><br/>__소프트웨어가 자신의 것인 경우<br/><br/>____소프트웨어 획득<br/><br/>____저작권 보호<br/><br/>____저작권 얻기<br/><br/>__특허<br/><br/>____특허는 무엇인가?<br/><br/>____특허는 왜 존재하는가?<br/><br/>____특허 결정<br/><br/>____특허 신청<br/><br/>____특허에는 무엇이 있는가?<br/><br/>____특허 허가<br/><br/>__문제<br/><br/>____오픈소스 소프트웨어<br/><br/>____소프트웨어 허가와 판매<br/><br/>____특허 확보<br/><br/>____침해 발견<br/><br/>____저작권 침해 회피<br/><br/>____특허 침해 회피<br/><br/> <br/><br/>20장 임베디드 소프트웨어 개발 관리<br/><br/>__능력 성숙도 모델 통합<br/><br/>__OSI 모델<br/><br/>__소프트웨어 관리<br/><br/>____V 모델<br/><br/>____폭포수 모델<br/><br/>____애자일 모델<br/><br/>__구조<br/><br/>__프로그램 헌장<br/><br/>__이해관계자와 핵심 팀<br/><br/>__제품 수명주기 관리<br/><br/>__포트폴리오 관리<br/><br/>__프로젝트 관리 수명주기<br/><br/>__프로젝트 수명주기<br/><br/>__문제 해결<br/><br/>__의사소통<br/><br/>__약어, 기호, 두문자어<br/><br/>__저작권 감사의 글<br/><br/>__참고 문헌<br/><br/> <br/><br/>21장 임베디드 시스템을 위한 애자일 개발<br/><br/>__소개<br/><br/>__임베디드 시스템의 특별한 점<br/><br/>____소프트웨어가 유일하고 요구 사항이 다양한 공학 분야에 걸쳐있는 시스템에 적합하다<br/><br/>____특정 하드웨어를 사용한다<br/><br/>____종종 하드웨어와 공동 개발된다<br/><br/>____프로그래밍 언어와 툴의 선정에 제약이 있다<br/><br/>____더 도전적인 테스팅 환경을 갖는다<br/><br/>____종종 고도로 예측 가능해야 한다<br/><br/>____종종 엄격한 시간 제약을 받는다<br/><br/>____종종 (메모리 같은) 심각한 자원의 제약이 있다<br/><br/>____종종 대단히 고신뢰적이고 안전 필수적이 돼야 한다<br/><br/>____종종 엄격한 외부 규정에 제약을 받는다<br/><br/>____단일 제품으로 출하, 납품된다<br/><br/>____종종 고정 가격 입찰의 대상이 된다<br/><br/>__임베디드 소프트웨어를 위한 애자일 프로젝트 기획<br/><br/>____프로젝트 비전<br/><br/>____초기 안전성/신뢰성 리스크 평가<br/><br/>____초기 프로젝트 리스크 평가 <br/><br/>____추정<br/><br/>____스케줄링<br/><br/>__임베디드 소프트웨어를 위한 프로젝트 거버넌스<br/><br/>____스탠드 업!(회의)<br/><br/>____성과 메트릭<br/><br/>____반복 회고(파티 단계)<br/><br/>__임베디드용 애자일 개발 관행<br/><br/>____점증적 개발<br/><br/>____고충실도 모델링<br/><br/>____실행 가능한 요구 사항<br/><br/>____테스트 주도 개발(TDD)<br/><br/>____연속적 통합<br/><br/>____변경 관리<br/><br/>____동적 기획<br/><br/>____리스크 관리<br/><br/>__애자일 척도 인자<br/><br/>__애자일 방법이 표준 고수에 도움을 줄 수 있는가?<br/><br/>__정리<br/><br/>__참고 문헌<br/><br/>__참고 목록<br/><br/> <br/><br/>22장 자동차 애플리케이션용 임베디드 소프트웨어<br/><br/>__배경 설명을 위한 역사<br/><br/>____자동차 전자 기술: 1911-2000<br/><br/>____전자 콘텐츠의 성장 동력<br/><br/>____임베디드 SW의 성장<br/><br/>____자동차 프로그래밍 언어 <br/><br/>____영향에 대한 요약<br/><br/>__자동차 세그먼트와 차이점<br/><br/>____차체<br/><br/>____차대와 안전성<br/><br/>____운전자 보조<br/><br/>____구동과 변속<br/><br/>____인포테인먼트와 텔레매틱스<br/><br/>____자동차 하부 세그먼트 요약<br/><br/>__자동차 품질<br/><br/>____머피의 법칙을 위한 기획<br/><br/>____결점 허용 통신<br/><br/>____결점 허용 소프트웨어<br/><br/>____제로 결함 소프트웨어<br/><br/>____리스크 관리와 장애 모드<br/><br/>____장애 모드와 영향 분석<br/><br/>__개발과 테스트<br/><br/>____서브시스템의 상호 운용성<br/><br/>____소프트웨어 명세서<br/><br/>____소프트웨어 아키텍처<br/><br/>____모델링<br/><br/>____자동 코딩과 드라이버<br/><br/>____벤치 테스팅<br/><br/>____추적과 디버그<br/><br/>____최종 단계 테스팅<br/><br/>____보정<br/><br/>____유지 보수/제품 생애 지원<br/><br/>__자동차 진단<br/><br/>____MIL<br/><br/>____데이터 로거<br/><br/>____OBD II<br/><br/>__자동차 표준<br/><br/>____MISRA<br/><br/>____AUTOSAR<br/><br/>____AEC<br/><br/>__자동차 안전성<br/><br/>____ISO 26262<br/><br/>____ASIL<br/><br/>__자동차 보안<br/><br/>____사용 수단: 차 경보장치 등<br/><br/>____현재의 수단: 해킹<br/><br/>____미래의 수단: 위조<br/><br/>__자동차 시장의 가까운 미래<br/><br/>____성능<br/><br/>____다중 코어의 출현 <br/><br/>____커넥티드 차량<br/><br/>____자동 차량<br/><br/>__정리<br/><br/> <br/><br/>23장 입출력과 스토리지 프로그래밍<br/><br/>__I/O 디바이스와 I/O 컨트롤러<br/><br/>____I/O 디바이스 범주<br/><br/>____I/O 컨트롤러<br/><br/>____메모리 맵 I/O와 DMA<br/><br/>____플래시, SD/SDHC, 디스크 드라이브 <br/><br/>____네트워크 부착 스토리지<br/><br/>__I/O 프로그래밍<br/><br/>____I/O 소프트웨어의 목적<br/><br/>____I/O 소프트웨어 계층<br/><br/>____사례연구: 리눅스 디바이스 드라이브<br/><br/>__스토리지 프로그래밍<br/><br/>____블록 디바이스용 I/O<br/><br/>____플래시 디바이스 프로그래밍<br/><br/>____SATA 디바이스 드라이버<br/><br/>__스토리지 시스템의 성능 개선<br/><br/>____사례연구 1: SDHC의 성능 최적화<br/><br/>____사례연구 2: NAS의 성능 최적화<br/><br/>__정리<br/><br/>__참고 문헌<br/><br/> <br/><br/>24장 네트워킹 애플리케이션용 임베디드 소프트웨어<br/><br/>__소개<br/><br/>__네트워크 디바이스용 시스템 아키텍처<br/><br/>____데이터면, 제어면, 서비스면, 관리면<br/><br/>__네트워킹용 다중 코어 SoC<br/><br/>____코어<br/><br/>____패킷 엔진 하드웨어(PEH) 블록<br/><br/>__네트워크 프로그래밍 모델<br/><br/>____파이프라인 프로그래밍 모델<br/><br/>____동작 완료 프로그래밍<br/><br/>__패킷 프로세싱 소프트웨어의 구조<br/><br/>____데이터면 기반 구조(DP 인프라)<br/><br/>____포워딩 엔진 구조<br/><br/>____패킷 프로세싱 애플리케이션 요구 사항<br/><br/>__네트워크 애플리케이션 프로그래밍 기법<br/><br/>____네크워크 애플리케이션 프로그래머용 다중 코어 성능 기법<br/><br/>____흐름 문맥 탐구 동안 락 회피<br/><br/>____참조 계수 회피<br/><br/>____안전 참조 메커니즘<br/><br/>____흐름 병렬화<br/><br/>____최신 통계와 연관된 캐시 스레싱 감소<br/><br/>____통계 가속<br/><br/>__네트워크 애플리케이션 프로그래머를 위한 일반 성능 기법<br/><br/>____효과적 캐시 이용<br/><br/>____소프트웨어 지시 프리패칭<br/><br/>____likely/unlikely 컴파일러 빌트인 이용<br/><br/>____캐시의 핵심 코드 조각 락킹<br/><br/>____일반 코딩 가이드라인<br/><br/>__임베디드 네트워크 디바이스용 리눅스 운영체제<br/><br/>____사용자 공간 프로그래밍과 연관된 변환 색인 버퍼(TLB)의 실수<br/><br/>____하드웨어 주변장치와 하드웨어 가속기에 대한 접근<br/><br/>____결정론적 성능<br/><br/>__정리<br/><br/> <br/><br/>25장 임베디드 시스템용 리눅스<br/><br/>__소개<br/><br/>____임베디드에 리눅스인 이유<br/><br/>____리눅스 배포<br/><br/>____리눅스 적합 임베디드 플랫폼<br/><br/>____라이선싱<br/><br/>__임베디드 리눅스 시작<br/><br/>____메모리 관리 유닛<br/><br/>____부트스트래퍼<br/><br/>____부트로더<br/><br/>____커널<br/><br/>____애플리케이션<br/><br/>__참조 보드상의 리눅스 동작<br/><br/>____참조 플랫폼<br/><br/>____BeagleBone으로 시작<br/><br/> <br/><br/>부록 1 C 문법 코딩 표준: 소스코드 개발<br/><br/>부록 2 임베디드 소프트웨어, 시스템, 템플릿을 위한 C++ 프로그래밍 언어<br/><br/>사례연구 1 소프트웨어 성능 공학<br/><br/>사례연구 2 사용자 인터페이스: 경찰 지휘 통제 시스템<br/><br/>사례연구 3 다중 코어로의 전이<br/><br/>사례연구 4 임베디드 시스템 품질과 메트릭 프로그램을 위한 소프트웨어 공학

★ 이 책에서 다루는 내용 ★<br/><br/> <br/><br/>■ 임베디드 시스템을 위한 훌륭한 아키텍처 원칙<br/><br/>■ 임베디드 프로젝트를 성공적으로 만드는 데 도움을 주는 설계 관례<br/><br/>■ 디지털 신호 처리, 안전 필수 원칙, 개발 프로세스를 비롯해 임베디드 시스템의 일부분을 이루는 세부 원칙<br/><br/>■ 임베디드 시스템을 위한 사용자 인터페이스 개발 방법<br/><br/>■ 임베디드 시스템 테스팅과 배포 전략, 품질 개발 프로세스 보장 전략<br/><br/>■ 성능, 메모리, 전력에 대한 임베디드 소프트웨어 최적화 실무 기술 <br/><br/>■ 임베디드 시스템을 위한 다중 코어 소프트웨어 개발 고급 가이드라인<br/><br/>■ 네트워킹, 스토리지, 자동차 세그먼트를 위한 임베디드 소프트웨어 개발 방법<br/><br/>■ 임베디드 개발 프로세스 관리 방법<br/><br/>■ 핵심 문제/이슈 로드맵과 본문 솔루션에 대한 참고 문헌<br/><br/>■ 적용 방안이라는 맥락에서의 핵심 방법들에 대한 리뷰<br/><br/>■ 시대를 뛰어 넘는 구현 세부 사항들을 보여주는 사례<br/><br/>■ 핵심 아이디어 구현 방법, 결정된 선택 근거, 설계 가이드라인과 트레이드오프를 보여주는 짧고 간결한 사례 연구<br/><br/> <br/><br/>★ 이 책의 구성 ★<br/><br/> <br/><br/>1장, '임베디드와 실시간 시스템을 위한 소프트웨어 공학' 임베디드 시스템은 대규모 시스템의 특정 기능을 수행하기 위해 설계된 컴퓨터 시스템으로, 종종 하나 이상의 실시간 컴퓨팅 제약 사항을 갖는다. 이는 하드웨어와 기계적 부분을 포함하는 큰 장치의 부분으로서 내장된다. 이 시스템은 최종 사용자의 다양한 요구에 부응하면서 유연한 범용 컴퓨터와는 극명하게 비교된다. 범용 시스템에 성공적으로 적용됐던 소프트웨어 시스템의 개발 방법과 기법, 툴은 더 이상 임베디드 시스템에는 쉽게 적용되지 못한다. 모바일 임베디드 장치에서 동작하는 소프트웨어 시스템은 근접 최적 성능, 강건성, 분산, 역동성, 이동성 같은 더 전통적인 시스템에서 는 요구되지 않는 특징을 가져야 한다. 1장은 임베디드, 자원 제약, 모바일, 고도로 분산된 세계에 존재하는 소프트웨어 시스템의 핵심 특징을 조사한다. 그리고 이 분야의 맥락 속에서 소프트웨어 공학 방법의 핵심 부분에 대한 적용 가능성을 평가하고 기법(예를 들어 소프트웨어 설계, 컴포넌트 기반 개발, 소프트웨어 아키텍처, 시스템 통합, 테스트)도 다룬다. 1장은 임베디드와 실시간 소프트웨어를 개관적으로 설명한다.<br/><br/>2장, '임베디드 시스템 하드웨어/소프트웨어 공동 개발' 최신 임베디드 시스템에 대한 개발을 기획할 때 하드웨어와 소프트웨어를 독립적으로 고려하지 않는다. 지난 20여 년간 전용 하드웨어 구현에서 범용 임베디드 프로세스를 실행하는 소프트웨어로 시스템의 기능성이 이동된 반면, 칩과 시스템의 복잡성은 엄청날 정도의 성장률을 보였다. 2010년까지 소프트웨어를 개발하려는 노력이 하드웨어를 개발하려는 노력보다 더 커졌으며, 복잡성은 소프트웨어에 비례해 계속 증가하는 추세였다. 독립적인 하드웨어와 소프트웨어 설계 같은 전통적인 설계 기법은 칩 위에 복잡한 시스템을 만들기 위해 통합되는 이기종의 모델과 애플리케이션 때문에 도전이 되고 있다. 설계자는 하드웨어와 소프트웨어의 공동 설계에 사용되는 적절한 기법을 이용해 시스템의 특정 행위와 주어진 성능 목표, 기술이 드러날 수 있도록 시스템의 하드웨어와 소프트웨어 컴포넌트를 함께 작업하는 방법을 고려해야 한다.<br/><br/>3장, '임베디드 시스템을 위한 소프트웨어 모델링' 임베디드 시스템을 위해 모델을 생성하는 것은 아주 간단하거나 믿을 수 없을 정도로 복잡한 동적인 제어 시스템에 대한 시간과 비용 측면에서의 효과적인 접근법을 제공하며, 이 모든 것은 밀접하게 통합된 소프트웨어 집합에서 유지되는 단일 모델을 기반으로 한다. 최신 모델링 소프트웨어 툴을 이용하면 오프라인 시뮬레이션에서 초기 밸리데이션(validation)을 설계하고 수행할 수 있다. 이러한 모델은 차후 수행되는 모든 개발 단계의 기초를 형성한다. 임베디드 설계를 위해 모델을 생성하는 것은 전통적인 설계 접근법보다 더 다양한 이점을 제공한다. 하드웨어 프로토타이핑과 결합된 접근법을 이용하면 베리피케이션(verification)과 밸리데이션이 최종 테스팅 단계에서만 수행되는 것이 아니라 개발 전 기간에 걸쳐 수행되기 때문에 실수할 리스크가 줄어들고 개발 수명주기도 짧아진다. 시스템 모델을 베이시스(basis)로서 이용하면 훨씬 더 빠르고 신뢰성 있는 설계 평가와 예측을 만들어낼 수 있다. 반복적인 접근법은 성능과 신뢰성 관점에서 설계를 향상시키는 결과를 가져온다. 그리고 설계 팀과 설계 단계, 다양한 프로젝트 사이에서 모델을 재사용할 수 있기 때문에 자원에 들어가는 비용이 줄어들며, 물리적 프로토타입에 대한 종속성도 줄어든다. 자동 코드 생성 기법을 이용하면 개발 오류와 부담도 줄일 수 있다. 이러한 이점은 더 정확하고 강인한 제어 설계와 더 짧아진 시장 적시성, 설계 비용에 대한 감소로 이어진다.<br/><br/>4장, '임베디드 시스템을 위한 소프트웨어 설치 아키텍처와 패턴' 임베디드 컴퓨팅 시스템의 소프트웨어 아키텍처는 시스템이 어떻게 동작할 것인지 추론하거나 이해하는 것을 도와주는 시스템의 구조로 묘사할 수 있다. 소프트웨어 아키텍처는 시스템 개발 프로젝트뿐만 아니라 시스템을 위한 청사진으로 동작한다. 아키텍처는 성능, 변경 가능성, 보안성 같은 임베디드 시스템의 주요 품질에 대한 기본적인 프레임워크이며, 아키텍처 비전을 통합하지 않고는 시스템의 어떠한 품질도 획득할 수 없다. 아키텍처는 설계 접근법이 적절한 시스템의 개발로 이어진다는 것을 보장하는 초기 분석에서 만들어지는 산물이다. 4장은 임베디드 소프트웨어 아키텍처의 여러 양상에 대한 세부 사항을 다룬다.<br/><br/>5장, '실시간 빌딩 블록: 이벤트와 트리거' 4장까지는 임베디드 시스템을 개발하기 위한 높은 수준의 추상화와 시스템 설계 아키텍처, 구현 단계에서의 설계 패턴 적용 같은 접근법을 설명했다. 5장에서는 실시간 시스템의 두 가지 기본 개념과 설계 패턴을 소개한다. 여기서 두 가지 기본 개념은 비동기 이벤트(Event) 플래그를 설정하는 능력과 적절한 시기에 어떤 상황을 트리거(Trigger)하는 능력이다. 이들 두 가지 개념은 실시간 운영체제(RTOS)를 이용하지 않는 시스템뿐만 아니라 RTOS를 이용하는 시스템에도 모두 사용된다. 5장은 유스케이스로 시작해서 이벤트와 트리거를 구현하는 서로 다른 방식을 개발한다. 그리고 이들 각각에 대한 세부 구현 내용도 제시하며, 이들에 대한 장단점도 다룬다. 이벤트와 트리거 구현을 위한 소스는 이 장의 끝 부분에서 제공한다.<br/><br/>6장, '임베디드 소프트웨어에 대한 하드웨어 인터페이스' 임베디드 소프트웨어에 제공되는 하드웨어 인터페이스에 대해 다룬다. 그리고 하드웨어 인터페이스를 제공하는 레지스터와 인터럽트에 대해서도 다룬다. 그 외 프로젝트에서 하드웨어 팀과 임베디드 소프트웨어 팀 간 협력을 위한 인간적인 측면에 대해서도 논의한다. 협력은 설계 단계, 공동 개발 단계, 통합 단계, 디버깅 단계 동안 필요하며, 6장에서는 이들 각 단계에서 요구되는 협력의 개념에 대해 알아본다. 그리고 제품의 품질을 향상시키는 다양한 하드웨어 설계 양상과 하드웨어 버전을 지원하는데 도움을 주는 소프트웨어 설계 양상에 대해서도 다룬다.<br/><br/>7장, '임베디드 소프트웨어 프로그래밍과 구현 가이드라인' 임베디드 소프트웨어 개발에 일반적으로 사용되는 몇 가지 가이드라인을 제공한다. 프로그래밍 원칙에서 시작해 가독성, 테스트용이성, 유지 보수성을 포함한다. 7장은 하드웨어 고려 사항, 파일 구조, 개발 가이드라인을 비롯해 임베디드 소프트웨어 프로젝트를 어떻게 시작하는지 대한 논의를 계속 이어간다. 그런 다음 문법 코딩 표준의 중요성을 비롯해 소프트웨어 개발 프로젝트에서 매우 중요한 프로그래밍 가이드라인으로 초점을 바꿔 논의한다. 7장은 변수와 정의에 대한 설명과 이들이 어떻게 임베디드 소프트웨어 프로젝트에 사용되는지 대한 논의로 마무리한다.<br/><br/>8장, '임베디드 운영체제' 실시간 운영체제(RTOS)는 임베디드 시스템 어디에나 존재한다. 8장은 실시간 커널이 무엇인지, 운영체제가 제품 개발자에게 제공하는 서비스가 무엇인지 설명하고, 커널 내부 일부에 대해 설명한다. 커널은 RTOS의 컴포넌트다. 8장에서는 작업 관리, 인터럽트 핸들링, 스케줄링, 문맥 스위칭, 시간 관리, 자원 관리, 메시지 패싱, 우선순위 변환 등 많은 부분을 살펴본다.<br/><br/>9장, '임베디드 시스템에서 설계에 의한 소프트웨어 재사용' 임베디드 시스템에서 재사용을 제한하는 과제와 이의 극복 전략을 알아본다. 이러한 탐구에는 재사용의 제한 사항이 무엇인지, 하드웨어 추상화 계층이나 RTOS 포팅(porting) 계층과 같은 제한 사항을 극복하는 전통적인 접근법이 무엇인지를 포함한다. 그러나 여기서 그치지 않는다. 계층화된 소프트웨어가 가진 단점은 고도로 최적화되고 재사용이 가능한 소프트웨어 컴포넌트를 사용할 수 있게 만들어준다. 9장은 하드웨어와 RTOS에 상관없이 전문가 시스템에 의해 생성된 재구성과 재사용이 가능한 컴포넌트를 만드는 메커니즘인 컴포넌트 팩토리(factory)에 대한 개념을 소개한다.<br/><br/>10장, '임베디드 시스템을 위한 소프트웨어 성능 공학' 임베디드 시스템은 보통 하나 이상의 실시간 요구 사항을 갖는다. 최근 임베디드 소프트웨어 시스템의 복잡성으로 인해 이들 시스템의 성능 목표를 성취하기 위해서는 체계적인 접근법이 요구된다. 애드혹(ad hoc) 프로세스는 마감 시간을 놓치게 할 수 있고, 시스템의 성능을 빈약하게 만들 수 있으며, 프로젝트를 취소하게 만들 수도 있다. 다중 실시간 성능 요구 사항을 정의하고 관리하며 전달하기 위해서는 성숙도(maturity)가 필요하다. 소프트웨어 성능 공학(SPE)은 성능 공학 프로세스의 성숙도를 향상시킬 수 있는 시스템 공학의 범주에 속해 있는 교과목이다. SPE는 성능 목표를 만족하는 소프트웨어 시스템의 구축에 필요한 체계적이고 정량적인 접근법이다. SPE는 아키텍처, 설계, 구현에 초점을 둔 소프트웨어 지향 접근법으로, 임베디드 소프트웨어 개발 수명주기의 모든 단계에 적용되는 활동이나 기법, 산출물에 초점을 둔다. 특히 소프트웨어가 시스템의 성능 관련 요구 사항을 만족시키기 위해 설계되고 구현된다는 것을 보장하기 위해 민감성과 확장성에 초점을 둔다.<br/><br/>11장, '임베디드 소프트웨어의 성능 최적화' 코드 최적화는 개발 프로세스에서 시스템의 능력에 직접 영향을 미치는 핵심 단계다. 코드가 더 빠르게 실행된다는 것은 채널이 더 넓다는 것과 수행되는 것이 더 많다는 것, 더 경쟁적인 이점을 가진다는 것을 의미한다. 코드가 더 적은 메모리에서 실행된다는 것은 휴대폰에 더 적합한 애플리케이션 특징을 가질 수 있음을 의미한다. 그리고 코드가 실행 시 더 적은 전력을 소비한다는 것은 배터리의 수명을 증가시키거나 전력 기지국에서 소비되는 비용을 줄여줄 수 있음을 의미한다. 11장은 프로그래머에게 코드를 효과적으로 작성할 수 있게 도움을 줄 목적으로 작성됐다. 먼저 툴 체인의 이용법에 대한 소개부터 시작해, 최적화 이전에 임베디드 아키텍처를 아는 것이 중요하다는 점을 설명하고, 그런 다음 넓은 범위의 최적화 기법에 대해 설명한다. 11장에서 제시하는 기법은 C 언어 최적화 기법과 범용 루프 변환 같은 프로그램이 가능한 모든 아키텍처에 유효한 기법이다. 실세계에 대한 사례는 이 장 전체에 걸쳐 제시한다.<br/><br/>12장, '임베디드 소프트웨어의 메모리 최적화' 목표 아키텍처에서 클록 주기의 실행 결과로 인해 컴파일 코드에 대한 최적화 메트릭이 항상 측정되는 것은 아니다. 무선 네트워크 연결 또는 백홀(backhaul) 기반 구조에서 다운로드로 실행 가능한 휴대폰이나 무선 장치를 고려한다. 이러한 경우 보통 이점을 갖거나 무선 장치로 다운로드해야만 하는 컴파일 코드의 크기를 컴파일러가 줄여준다. 다운로드될 필요가 있는 코드의 크기를 줄임으로써, 다운로드되는 각 무선 지점에 요구되는 대역폭의 관점에서 비용이 줄어드는 결과를 얻는다. 컴파일 코드의 메모리 시스템 성능과 같은 최적화 메트릭은 개발자에게는 흔하게 중요한 또 다른 메트릭이다. 이들 메트릭은 목표 프로세서상의 컴파일 코드뿐만 아니라 기본이 되는 메모리 시스템, 캐시, DRAM, 버스 등과 같은 동적 실시간 동작과 긴밀히 연관돼 있다. 애플리케이션 내 데이터 또는 더 특별하게 실시간에서 동적으로 평가되는 데이터와 이에 대응되는 데이터 구조의 순서를 효율적으로 조정함으로써 메모리 시스템 레벨에서 중요한 성능 개선을 얻을 수 있다. 이에 추가해 SIMD 명령 집합이 제시되고 다양한 메모리 시스템의 정렬 조건이 만족되면 데이터의 공간적 위치로 인해 벡터화 컴파일러도 시스템의 성능을 개선할 수 있다.<br/><br/>13장, '임베디드 소프트웨어의 전력 최적화' 임베디드 프로젝트의 제품 수명주기에서 가장 중요한 고려 사항 중 하나가 장치에 대한 전력 소모를 이해하고 최적화하는 것이다. 재충전 동안 최소 사용 시간과 유휴 시간을 보장할 수 있는 정도의 배터리 전력을 요구하는 휴대용 단말기에서는 전력 소모가 아주 잘 드러난다. 그 외의 주요 임베디드 애플리케이션, 즉 의료장비, 테스트, 측정, 미디어, 무선 기지국 등도 전력에 매우 민감하다. 증가되고 있는 강력한 프로세서의 열 손실과 전원 공급장치에 들어가는 비용, 에너지 소비로 인한 비용을 관리해야 할 필요가 있기 때문이며, 특히 전력 소모는 간과될 수 없는 사실이다. 전력 요구 사항을 정하고 유지하는 책임은 보통 하드웨어 설계자의 몫으로 돌아가지만, 소프트웨어 프로그래머도 전력 최적화에 큰 기여를 제공할 수 있는 능력이 있다. 보통 소프트웨어 공학자가 이러한 장치들의 전력 소모에 큰 영향을 미친다는 사실은 간과되거나 저평가되고 있다. 13장의 목적은 전력 소모를 최적화하기 위해 소프트웨어가 어떻게 사용될 수 있는지에 대해 알아보는 것이다. 이를 위해 먼저 기본적인 전력 소모의 구성부터 시작해서 전력 소모에 대한 적절한 측정 방법, 알고리즘 레벨과 하드웨어 레벨, 데이터 흐름에서 소프트웨어로 전력 소모를 최소화하는 기법을 알아본다. 또한 특정 방법이 전력을 줄이는 데 어떻게 왜 효과적인지 이의 다양한 기법에 대한 데모와 설명을 포함하며, 이에 따라 독자는 자신의 애플리케이션에 이 방법을 즉시 선택해 적용할 수 있다.<br/><br/>14장, '임베디드 시스템을 위한 인간 요소와 사용자 인터페이스 설계' 임베디드 시스템을 설계할 때, 특히 사용자 인터페이스를 설계할 때는 특별한 주의가 요구된다. 간단한 장치에 대해서는 단순 텍스트, 명령 버튼, LED가 적절하다. 더 복잡한 시스템에 대해서는 완전한 그래픽 사용자 인터페이스GUI와 터치 패널이 요구된다. 사용자 인터페이스 설계는 a) 서로 다른 소프트웨어 컴포넌트 간 인터페이스 설계, b) 소프트웨어와 인간이 아닌 정보 생산자와 소비자 간 인터페이스 설계, c) 인간과 컴퓨터 간 인터페이스 설계 같은 핵심 영역에 초점을 맞춰야 한다. 14장은 효과적인 사용자 인터페이스 설계에 요구되는 프로세스, 가이드라인, 인간 요소, 기술에 초점을 맞춘다.<br/><br/>15장, '임베디드 시스템 품질, 통합, 테스팅 기법' 임베디드 소프트웨어 개발에서 실용적 결정이 이뤄져야 하는 가용한 테스트 시간과 예산 요구에 대한 효과성을 최적화할 필요가 있을 때 최신 기법과 모범 사례는 (항공기의 비행제어기, 자동차의 브레이크 시스템 또는 의료 장치와 같은) 고신뢰성 장치뿐만 아니라 신뢰성이 떨어지는 애플리케이션에도 적용된다. 이러한 다중 소프트웨어테스트 기법을 보완하기 위해, 기법을 자동화한 유사한 테스트 툴이 많다. 이들 툴은 안전 필수 애플리케이션의 개발에서는 아주 흔하게 사용되지만, 모든 툴을 구입하거나 심지어 이들 툴의 일부라도 구입할 만한 예산을 가진 사람은 별로 없을 것이다. 물론 이들 툴의 제공자는 툴 각각이나 그렇지 않으면 툴 모두에 대한 구입을 지지할 것이다. 그렇다면 제한된 예산을 어떻게 적절하게 할당할 것인가? 그리고 예산이 없다면 최종 제품이 적절한 품질을 가질 것이라는 확신을 사람들에게 믿게 만드는 그러한 툴도 없이 어떻게 유사한 원칙을 적용할 것인가? 이러한 이슈를 다루기 위해 15장에서는 제시된 기법 뒤에 숨어있는 개념뿐만 아니라 실제 어떻게 구현했는지를 설명하는 소프트웨어 코드에 대한 몇 가지 사례연구도 함께 제시한다.<br/><br/>16장, '임베디드 시스템용 소프트웨어 개발 툴' 임베디드 시스템의 소프트웨어 개발 툴, 특히 디버깅과 조사 툴에 초점을 둔다. 16장은 현재의 실행 시점에서 개발자에게 프로그램의 내부에 무엇이 있는지, 또는 프로그램이 언제 충돌하는지 그 시점을 알려주는 소스코드 디버거 툴의 능력 제시부터 시작한다. 디버거의 특징은 가장 대중적이고 많이 사용되는 디버거 중 하나인 GDB, 즉 프리소프트웨어 재단(FSF)에서 제공하는 GNU 디버거의 사례를 이용해 설명한다. 임베디드 시스템의 모든 요구 사항을 다루기 위해 16장은 간단한 디버거 루틴부터 시작해 디버거의 완전한 특징을 포함하는 특별한 대상 요구 사항에 적합한 디버거 에이전트를 어떻게 설계하는지 제시한다. 또한 전형적인 사용 사례와 문맥 전환, 위치 독립적 실행 파일, 디버거 이벤트 핸들링과 다중 코어 같은 설계에 대한 핵심 내용을 제시한다. 그런 다음 JTAG을 이용하는 이점과 디버거를 대상에 직접 연결하는 데 사용되는 외부 장치를 제시한다. 이때 디버거는 대상과 자기 자신의 자원을 완전히 제어하는 기능을 갖는다. 이 장의 끝부분에서는 이클립스(Eclipse)와 GDB 같은 무료 공개 소프트웨어를 기반으로 하는 통합 개발 툴, 측정 코드, 분석 툴과 같이 디버깅 프로세스에 도움을 줄 수 있는 기타 툴도 소개한다.<br/><br/>17장, '임베디드 시스템용 다중 코어 소프트웨어 개발' 다중 코어 소프트웨어 개발은 자동차부터 네트워킹과 무선 기지국까지 임베디드 시스템의 많은 영역에서 그 중요성과 적용 가능성이 점점 더 커지는 분야다. 17장은 다중 코어 연합(MCA)에서 최근 발표한 다중 코어 프로그래밍 사례(MPP)의 핵심 부분을 요약해서 보여준다. 모범 사례 가이드라인을 표준화한 MPP는 다중 코어 프로세서를 비롯한 개발 프로젝트를 고려하거나 구현하려는 회사와 기존 다중 코어 기술의 사용을 선호하는 회사의 공학자와 공학 관리자를 위해 특별하게 작성된 문서다. 다중 코어 준비를 위해 오늘날의 C/C++ 코드가 어떻게 작성됐는지를 더 잘 이해하는 것이 중요한데, 이것은 MPP 워킹 그룹의 영향하에서 성취됐다. 이 가이드라인을 이용하면 a) 더 높은 성능을 가진 소프트웨어를 만들 수 있고, b) 다중 코어 소프트웨어 이슈로 인해 버그 비율을 줄일 수 있으며, c) 다중 플랫폼에서 목표가 될 수 있는 휴대용 다중 코어 코드를 개발할 수 있고, d) 다중 코어 프로그래밍의 학습 커브를 줄이면서 개발 시간은 증가시킬 수 있으며, e) 다중 코어 연합의 API 기반 구조의 현 구조와 로드맵을 함께 묶을 수 있다.<br/><br/>18장, '안전 필수 소프트웨어 개발' 안전 필수 소프트웨어 개발의 여러 양상에 대해 다룬다. 18장의 첫 번째 부분은 프로젝트 기획 부분으로, 이는 프로젝트의 첫 시작 부분이자 공수(effort)의 범위를 정하는 중요한 단계다. 이는 안전 필수 요구 사항에 대한 관리와 개발 도중 대처 방법에 대한 통찰력을 제공한다. 또한 프로젝트 관리의 핵심 전략도 제공한다. 두 번째 부분은 결점, 장애, 위험에 대한 분석을 설명한다. 그리고 리스크 분석에 대한 서술도 역시 포함한다. 다음으로 임베디드 시스템에 사용될 수 있는 몇 가지 안전 필수 아키텍처를 다룬다. 마지막 부분은 안전 필수 소프트웨어를 개발하기 위한 소프트웨어 구현 가이드라인을 다룬다.<br/><br/>19장, '지적 재산' 지적 재산권은 보통 사람들의 발명품이나 설계 자체를 보호하기 위해 축적한 특허권 또는 기타 법적 보호조치의 두 가지 사항을 의미한다. 그래서 사람들은 지적 재산권과 관련된 라이선싱에 대해 많은 얘기를 하고 있는데, 이는 특허로 등록된 아이디어를 다른 사람 이 사용할 수 있도록 누군가에게 라이선스를 팔거나 프로세서와 기타 설계 사항을 가진 ARM이나 컴파일러와 운영체제 제품을 가진 툴처럼 제품을 만들어 배포하며, 또는 사용하기 위해 라이선스를 파는 것을 의미한다. 19장에서는 사람들의 일에 연관된 법적 보호조치를 처리하는 첫 번째 의미에 더 집중하며, 다음과 같은 두 가지 주요 영역에 대한 기본적인 사항을 다룬다. 첫째, 사람들이 썼거나 또는 구입했던 소프트웨어가 실제로 자신의 것이라는 것을 보장하기 위해 필요한 것이 무엇인지, 공개 소프트웨어에 대한 역할을 비롯해 그러한 소프트웨어를 팔 때나 다른 사람에게 라이선싱할 때 필요한 것이 무엇인지에 관련된 이슈를 다룬다. 둘째, 사람들이 가진 소프트웨어와 그 외의 가치 있는 발명품에 대해 획득될 수 있는 다양한 보호조치에 대해 다룬다.<br/><br/>20장, '임베디드 소프트웨어 개발 관리' 어떠한 임베디드 소프트웨어 프로젝트나 프로그램에 대해서든 성공적으로 구성하고 관리할 수 있는 정보를 제공한다. 20장은 시스템의 품질, 소프트웨어를 스택으로 구성하는 OSI 모델, 다양한 소프트웨어 개발 모델, 팀 구성 방식, 의사소통에 대한 개요를 소개한다. 자원이나 품질, 고객의 만족을 포함하는 프로젝트나 프로그램의 범위와 스케줄, 비용에 대한 제약 사항을 관리하는 것은 프로젝트나 프로그램이 가진 작업과 활동 모두를 다루는 것과 마찬가지다. 20장은 소프트웨어를 배포할 때까지 소요되는 수명주 기의 전 단계에 걸쳐 소프트웨어 개발에 대한 정상적인 진행 방법을 알아본다. 그리고 소프트웨어 명세를 테스트하기 위해 요구 사항부터 각각의 공학적 대응 방법까지 확장시킨 자원 관리, 리스크 관리, 문제 해결과 작업 추적성을 성공적으로 기획하고 실행하기 위한 툴도 함께 제시한다.<br/><br/>21장, '임베디드 시스템을 위한 애자일 개발' 애자일 소프트웨어 개발은 반복 개발을 기반으로 하는 소프트웨어 개발 기법을 집합시켜 놓은 개발 방법이다. 요구 사항과 소프트웨어 시스템은 자기 구성과 교차 기능 팀 간의 협력을 통해 발전한다. 애자일 개발은 적응적 기획, 진화적 개발과 배포, 타임박스(timebox)를 갖는 반복 접근법을 지원한다. 애자일의 목적은 변화에 대해 신속하고 유연한 대응을 하는 것이다. 애자일은 개념적 프레임워크로서 개발 주기를 통해 상호작용을 촉진한다. 애자일을 임베디드 소프트웨어 프로젝트에 적용하기 위해 소프트웨어 특징을 발전시키는 더 어렵고 효과적인 테스팅과 같은 몇 가지 특별한 도전을 소개한다. 이는 하드웨어 구성이 기획과 설계 단계에서 더 솔직한 스타일을 요구한다는 점을 고려해 대응 하드웨어의 변경이 수용하기에는 비용이 너무 높다거나 시간이 지날수록 학습하는 능력이 떨어질지도 모른다는 사실로 인해 대응 하드웨어가 적시에 가용하지 못하거나 변경에 대해서도 덜 자유로울 수 있기 때문이다. 21장은 애자일 소프트웨어에 대한 개발 기법을 소개하고 이들 기법이 어떻게 임베디드 시스템에 적용되는지 보여준다.<br/><br/>22장, '자동차 애플리케이션용 임베디드 소프트웨어' 다른 애플리케이션과는 달리 엄격한 기획, 아키텍처 개발, 테스팅, 밸리데이션과 베리피케이션이라는 특징을 갖는 자동차 시스템을 소개한다. 다른 애플리케이션 영역과 대비해 자동차 애플리케이션용 임베디드 소프트웨어를 작성하는 물리적인 작업은 다른 임베디드 시스템과 비교해 그리 크게 다르지 않지만, 개발과 테스트 프로젝트에 반드시 수반돼야 하는 품질 표준이 핵심 차이라 할 수 있다. 자동차 소프트웨어를 작성하기 위해 공학자는 자동차 시스템이 오늘날 어떻게 왜 복잡한 환경으로 발전됐는지 이해할 필요가 있다. 공학자는 자동차 하위 시장 간의 차이점과 공통점을 인식해야만 한다. 또한 적용 가능한 품질 표준에 대해서도 잘 알아야 하고, 품질이 어떻게 테스트되고 측정되는지도 알아야 하며, 이에 덧붙여 그러한 엄격한 품질 제어가 왜 있어야 하는지에 대해서도 잘 알아야 한다. 22장에서는 이러한 모든 내용에 대해 가장 흔한 모범 사례를 이용해 설명한다. AEC, OBD-II, MISRA와 같은 더 전통적인 표준뿐만 아니라 최근에 등장한 AUTOSAR와 ISO26262 표준으로 지원되는 모델링, 자동 코드 작성, 첨단 추적과 디버그 같은 높은 품질과 결함 허용, 상호작용 코드를 소프트웨어 공학자가 잘 작성할 수 있게 도움을 주는 다양한 프로세스를 소개한다.<br/><br/>23장, '입출력과 스토리지 프로그래밍' 임베디드 시스템에서 입출력(I/O)과 저장 장치는 매우 중요한 컴포넌트다. 임베디드 시스템에서 I/O의 다양성은 I/O 관리를 매우 복잡한 프로세스로 만든다. 임베디드 운영체제 시스템의 가장 기본적인 기능 중 하나가 모든 I/O 장치를 제어하고 관리하는 것이며, I/O 장치를 동시에 접속하는 다중 프로세스를 조정하는 것이다. 여기서 CPU와 장치 간 I/O 구현을 제어하는 것이 장치 관리의 핵심 기능이다. 운영체제는 인터럽트에 대응하고 장치에 대한 예외 사항을 다루기 위해 명령을 장치에 보낸다. 또한 장치와 시스템의 다른 부분 사이의 인터페이스를 간단하고 쉽게 사용하는 방법을 제공한다. 따라서 I/O 장치 사이뿐만 아니라 CPU와 I/O 간의 병렬 프로세싱 능력을 향상시키기 위해서도 I/O 관리 모듈은 필요하다. 그리고 시스템 자원에 대한 최적의 이용 효율성을 얻기 위해 I/O 관리 모듈은 통합되고, 명확하며 독립적이고 확장 가능한 I/O 인터페이스를 제공해야 한다. 이 책에서 스토리지는 임베디드 시스템에서 많이 사용되는 NOR/NAND 플래시, eSDHC, U-Disk, HDD, SSD 같은 외부 저장장치를 참조한다. 최근 클라우드 컴퓨팅의 개발에 따라 스토리지 기술은 시스템에서 아주 중요한 역할을 담당한다. 23장은 CPU와 I/O 장치, 인터럽트 기술, I/O 제어 프로세스, 대응되는 장치 드라이버의 구현 프로세스 간 데이터 변환 모드에 대해 알아본다. 스토리지 장치의 프로그래밍 모델도 다루는데, 여기에는 특징 지원과 성능 최적화가 포함된다.<br/><br/>24장, '네트워킹 애플리케이션용 임베디드 소프트웨어' 임베디드 네트워킹 애플리케이션은 급격히 변화되고 발전되는 분야다. 예를 들어 임베디드 다중 코어 기술은 고급 네트워킹 애플리케이션뿐만 아니라 중간 및 저급 네트워킹 애플리케이션에도 나타나고 있다. 네트워킹 성능을 성취하기 위해서는 소프트웨어가 다중 코어의 이점을 가져야만 가능하다. 다중 코어 프로그래밍은 단일 코어 프로그래밍처럼 간단하지 않다. 아키텍처를 만들고 설계하는 것부터 코드 작성까지 새로운 사고방식이 요구된다. 다중 코어 SoC에서 네트워킹 애플리케이션 개발은 확장 가능한 성능 확보에 초점을 둬야 할뿐만 아니라 개발의 용이성과 오랜 시간 동안 유지 보수가 가능한 개발에도 초점을 둬야 한다. 24장에서 목록화된 일부 프로그래밍 기법이 이러한 목적을 달성하는 데 도움이 된다.<br/><br/>25장, '임베디드 시스템용 리눅스' 리눅스(Linux)는 네트워킹과 무선, 기지국과 같이 많은 임베디드 시스템에서 선택받고 있는 지속적으로 성장하는 운영체제다. 25장은 임베디드 시스템에서 리눅스의 사용 가능성에 대해 알아본다. 리눅스 커널 설치 방법, 자신의 리눅스 베이스라인 생성 방법, 플랫폼에서 동작하는 애플리케이션 획득을 위한 초기 단계에 대해 다룬다. 이전에 임베디드 시스템에서 리눅스를 사용하지 않았다면 25장은 리눅스를 사용하는 모든 기초적인 과정을 다룬다.<br/><br/>부록 1, 'C 문법 코딩 표준: 소스코드 개발' 임베디드 프로젝트에서 고려될 수 있는 문법 표준을 설명한다. 이에는 변수와 선언문을 위한 스타일 가이드와 네이밍(naming) 규약을 포함한다. 또한 개발 중에 있는 특별한 애플리케이션에 적합하게 사용되거나 수정할 수도 있다. 코딩 표준을 이용하면 코드의 베이스라인에 균일성을 제공하는 데 도움을 준다. 이는 개발자 모두에게 가독성과 유지 보수성을 제공하는 데 도움을 준다. 또한 코드에서 버그를 줄이는 데 도움을 주는 초기화 순서와 규약과 같은 모범 사례를 제안한다.<br/><br/>부록 2, '임베디드 소프트웨어, 시스템, 템플릿을 위한 C++ 프로그래밍 언어' C++는 임베디드 시스템의 개발에 도움을 주는, 더 구체적으로는 주어진 제품이나 플랫폼에 대한 애플리케이션과 시스템 레벨 소프트웨어에 도움을 주는 몇 가지 특징을 제공한다. 부록 2에서는 임베디드 소프트웨어 개발을 위한 C++ 이용의 다양한 측면을 비용에 따른 세 가지 종류로 구분해서 설명한다. 상대적으로 저렴한 임베디드용 C++의 특징으로는 정적 상수, 선언과 문장 순서, 함수 오버로딩, 네임스페이스 이용, 컨스트럭터와 디스트럭터의 이용을 다루며, 다소 값비싼 임베디드용 C++의 특징으로 함수 인라이닝, 컨스트럭터/디스트럭터/자료형 전환, C++ 템플릿 이용, 다중 상속, 캡슐화를 소개한다. 마지막으로 일반적으로 값비싼 임베디드용 C++의 특징으로 런타임 유형 식별과 예외 처리를 설명한다.<br/><br/>사례연구 1, '소프트웨어 성능 공학' 소프트웨어 성능 공학SPE을 실제 산업용 프로젝트에 적용시킨 애플리케이션에 대해 알아본다. SPE는 데이터를 수집하고, 시스템 성능 모델을 구축하며, 성능 모델을 평가하고, 불확실성 리스크를 관리하며, 대안을 평가하고, 모델과 그 결과를 검증하는 기법들을 모아 놓은 집합이다. SPE는 또한 이들 기법을 효과적으로 사용하기 위한 전략을 포함한다. 소프트웨어 개발 수명주기에서 시스템의 성능 평가를 상대적으로 초기에 사용할 수 있다면 프로젝트의 실패를 면할 수 있다. 시스템을 구현하기 이전에 대안 설계가 평가된다면 애플리케이션은 보통 더 나은 성능을 가질 것이다.<br/><br/>사례연구 2, '사용자 인터페이스: 경찰 지휘 통제 시스템' 저충실도의 프로토타입 개발에 사용되는 경찰 지휘 통제 시스템의 사용자 인터페이스 프로토타입에 대한 사례를 고찰한다. 이 사례 연구는 인간 요소와 사용자 인터페이스 설계라는 바탕 위에서 10장에서 소개한 프로세스와 기법을 포함한다. 사용자 인터페이스 설계는 서로 다른 소프트웨어 컴포넌트 간 인터페이스 설계, 소프트웨어와 인간이 아닌 정보 생산자와 소비자 간 인터페이스 설계, 인간과 컴퓨터간 인터페이스 설계와 같은 핵심 영역에 주안점을 둔다.<br/><br/>사례연구 3, '다중 코어로의 전이' 다중 코어 프로그래밍에 대한 모범 사례를 실세계 산업용 애플리케이션에 적용한다. 단일 코어 애플리케이션에서 다중 코어 애플리케이션으로 임베디 드 소프트웨어 애플리케이션을 이동시키기 위해서는 소프트웨어 프로그래밍 모델, 소프트웨어 스케줄링 시스템, 시스템 분할 접근법, 최적화 전략을 변경해야 한다. 그리고 이러한 이행을 효과적으로 수행하기 위해 소프트웨어 최적화 방안뿐만 아니라 애플리케이션 도메인에 대한 지식, 핵심이 포함된 SoC의 세부 사항, 오프로드 블록, 주변장치, 상호연결 세부 사항도 결정해야 한다. 이 사례연구에서는 네트워킹 소프트웨어 애플리케이션을 단일 코어 구현에서 고도로 최적화된 다중 코어 구현으로 이동시키기 위한 여러 단계를 알아본다.<br/><br/>사례연구 4, '임베디드 시스템 품질과 메트릭 프로그램을 위한 소프트웨어 공학' 펨토(femto) 임베디드 시스템에 대한 소프트웨어 개발과 시스템 통합 메트릭에 대해 고찰한다. 펨토 셀(Femtocell)은 저전력의 짧은 전송 범위를 가진 독립 기지국이다. 펨토 셀은 기본적으로 가정이나 소규모 사무실을 위한 소형 기지국이다. 펨토 셀의 핵심 속성은 IP 백홀(backhaul) 음성 트래픽이 인터넷으로 전송된다), 자가 최적화, 저전력 소비, 쉬운 배포를 포함한다. 이 사례연구에서 다루는 많은 기법을 보강하기 위해 실제 산업용 데이터를 사용한다.<br/><br/> <br/><br/>★ 지은이의 말 ★<br/><br/> <br/><br/>이 책의 편집을 위해 각 전문 지식 분야에서 기여가 가능한 임베디드 분야 선도 공학자들에게 기고를 요청했다. 그리고 이 책의 각 장이 자체로서 완전한 장이 될 수 있도록 집필 방향을 결정했다. 이는 저자가 하나의 장에서 주어진 목적을 완료할 수 있게 자신이 필요한 만큼의 정보를 모을 수 있음을 의미한다. 일부의 경우 여러 장에서 중복된 정보가 나타날 수도 있지만, 이것도 편집자가 의도적으로 만든 부분이다.<br/><br/>이 책의 목적은 여러 영역 간 자신의 입장을 번복하지 않고 다양한 주제를 상의할 수 있는 소프트웨어 공학 핸드북을 만드는 것이었다. 각 장의 집필을 맡은 저자들은 각자의 지식이 해당 주제에 잘 들어갈 수 있도록 자유로움과 유연성을 제공받았다. 각 장은 실용적이 되도록 설계 됐으며, 저자의 실세계 경험을 기반으로 집필됐다. 이 책은 300년 이상의 임베디드 시스템에 대한 경험을 포함하고 있다.<br/><br/>지난 10여 년간 컴퓨팅 세계는 큰 기계에서 작은 기계로, 고정식 기계에서 모바일 기계로, 데스크톱 기계에서 임베디드 장치로 이동했다. 데스크톱 시스템에 성공적으로 적용됐던 소프트웨어 시스템을 개발하는 방법과 기법, 툴은 더 이상 임베디드 애플리케이션에는 쉽게 적용되지 못한다. 모바일 임베디드 장치에서 동작하는 소프트웨어 시스템은 더 전통적인 시스템에서는 요구되지 않는 다음과 같은 특징을 가져야 한다.<br/><br/>- 근접 최적 성능<br/><br/>- 강건성<br/><br/>- 분산<br/><br/>- 역동성<br/><br/>- 이동성<br/><br/>이 책은 임베디드, 자원 제약, 모바일, 네트워크 세계에 존재하는 소프트웨어 시스템의 핵심 특징을 조사한다. 그리고 이들 도메인에서 소프트웨어 공학 방법과 기법의 핵심 부분(예를 들어 소프트웨어 설계, 컴포넌트 기반 개발, 소프트웨어 아키텍처, 시스템 통합, 테스트)에 대한 적용 가능성을 평가한다.<br/><br/>★ 옮긴이의 말 ★<br/><br/> <br/><br/>정말 기나긴 시간이었다. 2년 전 4월 말, 우연히 아마존을 탐색하던 중 이 책이 곧 발간된다는 사실을 발견하곤 바로 에이콘출판사에 번역 요청을 드렸고, 곧 바로 출판사 사장님의 승인이 떨어져 번역이 시작됐다. 임베디드 소프트웨어 분야에서 10여 년 동안 강의와 연구를 해왔고, 2012년에는 『임베디드 소프트웨어 개론』이라는 책을 펴내고 이 책으로 국방대, 서강대, 고려대 등 여러 대학에서 강의도 했지만, 하드웨어를 이해시키면서 임베디드 소프트웨어를 강의하고 싶었다. 내 마음 한구석에 늘 자리 잡고 있었던 아쉬운 마음을 한 번에 사로잡았던 책이 바로 이 책이었다.<br/><br/>그만큼 이 책은 하드웨어와 소프트웨어의 공동 설계를 비롯해 임베디드 시스템 개발의 전 수명주기에 걸쳐 필요한 모든 내용을 담고 있다고 해도 과언이 아니다. 특히 각계각층 독자들의 요구를 충족시키기 위해 임베디드 시스템 개발을 위한 5계층 체계와 임베디드 시스템의 6단계 하드웨어/소프트웨어 공동 설계 모델을 정립하고, 5계층과 6단계 공동 설계 모델을 네 가지의 최신 사례연구와 결합시켜 책의 구조를 제시한 것은, 이 책만이 가진 장점 중의 장점이다. 또한 책의 완성도와 이해도를 높이기 위해 임베디드 소프트웨어 산업 분야에서 수십 년 이상 경험을 쌓으면서 세계적으로 명성을 떨치는 두 명의 전문 편집자가 책 구성부터 편집, 발간까지 책임을 맡았으며, 책의 전문성과 신뢰성을 높이기 위해 개요부터 사례 연구까지 각 해당 분야에서 왕성히 활동하고 있던 세계적인 선도공학자 16명이 저자로 참여했다.<br/><br/>이 책은 임베디드 소프트웨어 분야의 전문가가 되길 원하는 모든 사람에게 개념부터 사례 연구까지, 더 나아가 미래 추세까지 제공하는 임베디드 시스템을 위한 소프트웨어 공학 분야의 전문 백과사전이라 할 수 있다. 특히 그 동안 임베디드 하드웨어와 소프트웨어 분야에 각각 종사하던 독자들이 늘 아쉽게 생각하면서 접해보고 싶었던 임베디드 시스템의 하드웨어/소프트웨어 공동 설계, 소프트웨어 성능 공학, 임베디드 소프트웨어의 성능/메모리/전력 최적화, 임베디드 시스템의 애자일 개발 등을 함께 다루고 있어, 해당 분야에 종사하는 개발자뿐만 아니라 이 분야에 관심을 가진 모든 사람에게도 큰 도움을 제공하는 귀중한 안내서가 될 것이다.<br/>

이 책의 추천사를 작성한다는 것은 기념비적인 일이다. 이 책은 임베디드 시스템에 관해 현재까지 가장 포괄적인 내용을 담고 있는 책일 것이다. 그리고 이러한 작업은 정말 필요한 일이다.

펌웨어(firmware) 시장이 점점 커지고 있다. 일부 사람들은 현대 제품을 만드는 데 드는 개발 비용의 80%까지가 페그(peg) 펌웨어일 것으로 추정한다. 불과 몇 년 전까지만 해도 수십만 라인의 코드를 가진 시스템을 아주 크다고 생각했던 것에 비해, 오늘날은 수 메가 라인의 코드를 시스템에서 발견하는 일이 다반사가 됐다. 스마트폰은 현재 수천만 라인을 사용하며, 굉장히 복잡해졌다. 소비자는 자동차 가치의 70%가 전자 기술로부터 온 것으로 이해하고 있으며, 자동차의 엔진이나 핸들보다는 코드를 더 구입하고 있다.

40년 전, 첫 번째 마이크로프로세서가 소개된 이래로 펌웨어를 구축하는 표준 방식은 영웅적인 일이 됐다. 몇 명의 스마트한 사람과 너무 많은 초과 근무 방식, 훈련 담당 상급자의 고함소리 등이 제품을 만들어 내보내긴 했다. 그러나 이러한 접근법은 더 이상 사업 규모를 확장시키지 못했고, 오늘날의 대규모 시스템에는 맞지 않는 방식이었다. 따라서 잘 훈련된 접근법이 필요하다. 이 책은 이러한 분야의 정보 전달에 아주 훌륭한 책이다.

예를 들어 통합과 테스팅을 제시하는 15장은 이러한 목표에 적합하게 아주 올바른 방식을 제공한다. 요구 사항으로 시작해서 제시된 요구 사항에 일치하는 테스트로 마무리된다. 이 책의 저자 마크 크랠링은 테스트가 완전한지를 보장하기 위해 사람들이 어떻게 제어 흐름 그래프를 이용하는지 보여준다. 오늘날 대부분의 개발자는 자신이 만든 테스트 스위트가 프로그램 로직 흐름의 10%를 커버하는지, 또는 90%나 100%를 커버하는지 알 수 없다. 공학자는 제품이 올바른지 증명하기 위해 자신이 서술한 내용을 분석할 필요가 있다. 이상하게 들리겠지만, 테스트 케이스를 구축하고, 요구 사항을 관리하며, 완전한 테스트 커버리지를 보장하는 다양한 벤더의 충분한 툴들이 있다.

4장은 임베디드 시스템을 위한 설계 패턴을 다룬다. 패턴은 잘 훈련된 방식에서 재사용되며, 보통 IT 프로젝트에서 재사용된다. 임베디드 세계에서는 재사용이 가능한지 오직 그 위치를 발견하는 일이 될 것이다. 소프트웨어 재사용을 다루는 9장은 소프트웨어 컴포넌트를 재활용하는 더 전통적인 양상에 대한 통찰력을 제공한다.

이것이 과도한 최상위 설계(BUFD)를 의미한다고 사람들이 생각하지 않도록 저자는 애자일 프로그래밍과 임베디드 시스템에 제시된 특별한 과제를 다룬다. 그러나 공학의 추악한 현실에 대해서도 다룬다. 하드웨어와 소프트웨어의 공동 설계를 다루는 2장에서는 완전하지 않으면서 전통적인 전략을 이용해서는 테스트될 수 없다는 명확한 문제가 있음에도 불구하고 하드웨어와 소프트웨어 둘 모두를 어떻게 병렬로 가져오는지 독자들에게 보여준다.

무엇이 임베디드를 그렇게 특별하게 만들었는가? 자원의 희소성이 가장 큰 이유다. 제한된 메모리와 CPU 주기로 인해 개발자는 테스트에 상당한 신경을 기울인다. 배터리로 동작하는 많은 시스템이 있을 것으로 예상되므로, 오늘날 전력 소비는 시스템 개발에 큰 영향을 끼친다. 이 책의 여러 장에서 이러한 이슈를 다루며, 심지어 배터리에서 모든 마이크로 와트를 짜내는 소프트웨어 기법도 보여준다.

펌웨어에서의 독특한 또 다른 양상이 바로 하드웨어와의 강결합이다. 이 부분 역시 이 책의 여러 장에서 깊이 있게 다룬다.

그 외의 주제로는 자동차 코드에 대한 특별한 필요성을 제시한다. 물론 리눅스와 안드로이드도 포함된다. 안전 필수 시스템의 구축도 포함된다. 여기서 안전 필수 시스템은 사람들이 기대하는 것보다 더 많이 존재하고 있으며, 안전 필수가 임무 중심으로 변경되고 있고, 자신의 제품이 어떻게 안전 관련 커뮤니티의 관심사를 포용하는지 알면 놀랄 것이다.

이 책은 임베디드 소프트웨어가 가진 어떠한 양상이든 모두 다룬다.

이러한 분야에서 변함없이 지속되는 것은 바로 변경이라는 분야다. 2012년 11월 〈인디아 타임스〉 지에 실린 기사는 소프트웨어 개발자가 나이 40에 이르면 퇴물이 된다고 주장했다. 개발자의 나이 40세는 새로운 경력을 시작하기에 너무 늦은 나이라는 의미다. 이 책을 읽고 프로젝트를 더 효과적인 방식으로 수행하는 방식을 배우기 바란다. 이 책은 나이가 40이 넘은 공학자가 자신의 위치에 머무르면서 불행으로 빠지는 것을 피할 수 있도록 도움을 줄 것이다.

잭 갠슬(Jack Ganssle)(『임베디드 시스템 대사전』(에이콘출판) 저자)