1. 임베디드 시스템 개발 (2)
이 민 석
minsuk@nhn.com

2. 오늘의 목표
• 간단 복습
• 임베디드 시스템? 개발의 목표?
• 임베디드 시스템 개발에 대한 이해
• 일반 소프트웨어와 개발의 차이
• 무엇을 개발한다는 것인가 ?
• 그 기본과 절차
• 인력
• 디버깅, 테스팅, 보안 이슈

3. 임베디드 시스템의 특징
• 전통적인 임베디드 시스템의 특징
• Single functioned
• 하나의 프로그램이 반복 수행
• Tightly constrained
• 재료비, 전력, 물리적인 크기, 특정 기능의 속도, 메모리 등
• Reactive and real-time
• 시스템의 환경 변화에 지속적으로 반응
• 예측 가능한 응답으로, 어떤 이벤트가 가지는 시간 제약성을 만족
• 최근 임베디드 시스템의 특징
• Digitally converged
• 멀티미디어, 유비쿼터스, …
• More tightly constrained (except memory)
• Scalable and feature-rich
• 더 많은 기능을 수용할 수 있는 소프트웨어 구조

4. 앞으로의 임베디드 시스템 시장
• 전통 임베디드 시장의 건재함은 그대로 유지
• 항공우주, 자동차, 의료, 공장, 전통가전, 게임
• 기술적 발전에 따른 시장 변화
• 통신 인프라의 발전 : 유비쿼터스, 컨버젼스 응용 창출
• 반도체 기술의 발전 : 제품의 기술적 구현 가능성 증가
• BT, NT 의 발전 : 새로운 소재, 센서의 등장
• 미래형 임베디드 시스템 시장은 대부분 인간 주변에…
• 콘텐츠 중심의 임베디드 시스템 시장
• 서비스와 연계 (수익 모델의 변경)
• 미디어(정보에 접근하는 채널)의 변화
• SNS, Mobile, Location Based xxx
• 사회 구조, 제도, 환경의 변화에 따른 시장 변화
• 노령화, 주5일 근무, 사교육, 저출산, 온라인 미디어
지구 온난화, 지속 가능 에너지, …
하드웨어에서
소프트웨어로
가치창출동력이 바뀜
그 중심엔
역시 사람 !!!

5. 임베디드 시스템 개발의 목표
기술적 목표
• Correctness
• 사용자 관점의 기능 충실도
• Availability
• 시스템 가용 시간의 확보
• Technical Requirements
• Power Consumption
• Space Limitation
• Legal Stuffs (특허, 전자파, …)
• …
• Security
• 논리적, 기계적 보안
• 사용자 보호, 기술 보호
• Flexibility
• Testability
시장적 목표
• Marketing driven requirements
• 수요자 그룹을 위한 디자인
• 사회적 요구 (윤리적, 환경적, …)
• Price
+ NRE (Non-Recurring Engineering)
• 개발비 등 1회성 비용
+ Unit (BOM) Cost
+ 중간쯤 있는 비용
• 장비, 광고, 땅, …
• Time
• to Prototype
• to Market
• Maintainability
• or NOT

6. 설계의 핵심 : Trade-Offs
• Unit Size
• Cost
• Power
• Battery Type
• Processor Speed
• Distance
• Hardware Architecture
• Encoding Schemes
• Dynamic Loading over RF
• Antenna Size
• RF Frequency
• Development Tools
• Functionality
• Algorithm complexity
• Sampling Rate
• Routing Algorithms
• Redundancy
• Reliability
• Security
• Encryption
• Mobility
• Real-Time Guarantees
• Number of Nodes
• …
Sensor 중심의 CPS Device
설계 시의 Trade-Off 항목의 일부
• 정답은 없다.
• 모든 것을 일반화 할 수도 없다.
Design for Trade-Offs !!!
• WYNIWYG
– What You Need is What You Get
– No more, No Less!
+ Configurable and Reusable S/W
SizePerformance
Power
NRE cost

7. 플랫폼 기반 / 모델 기반 개발
• 플랫폼 기반 개발
• Platform : 서로 연관되어 상승 효과를 낼 수 있는 공통 서비스들의 추상화
• 다양한 요구 사항을 해석하여 그들을 수용하는 architecture를 제시한 것
• 잘 정의된 공통 서비스를 바탕으로 “필요 기술 요소”의 확인/조달을 빠르게 함
(각 요소 서비스 제공자들을 나열한 solutions-map과 함께)
• 모델 기반 프로그래밍의 장점
• 플랫폼 독립적인 소프트웨어 모듈의 재사용성 증가
• 새로운 하드웨어 플랫폼에의 적응성 향상
• 사용자 요구 변화에 대한 빠른 대응
• 쉽게 말하면,
모두가 이해할 수 있는 ‘틀’ 을 기반으로 뭔가를 만들자 !
 소프트웨어 개발 생산성 증가

8. 임베디드 소프트웨어 개발: 조금 다르다 !
• 보통 PC나 서버 응용 소프트웨어 개발
• 개발 시스템과 목적 시스템이 같다.
• 응용 프로그램 환경(O/S, CPU)이 개발 환경과 같다.
• 달라지면, 소스를 가져다 Porting (이식)을 한다
• 임베디드 소프트웨어 개발
• 개발 시스템과 목적 시스템이 다르다.
• 개발 환경에서 실행이 되지 않는다.
교차 개발 (Cross Development)
• 용어 정리
• Host (Development) System : 개발 도구가 실행되는 시스템
• Target System : 개발 대상 목적 시스템 (SUT, system under test)
• 대개 Host System과는 Serial(또는 USB, LAN)으로 연결됨
• Embedded System이라면 보통 Keyboard, Monitor 등이 없는 환경
• Remote Debugging : Target의 프로그램에 대한 Host에서의 디버깅

9. 일반 SW vs. 임베디드 SW 차이
구분 일반 소프트웨어 임베디드 소프트웨어
특징
• 사용자의 기능 요구 사항의 만족
• 개인 및 기업을 위한 정보 처리
• MS와 같은 몇몇 기업이 주로 독점
• 실시간성이 거의 요구되지 않으며
• 자원 제한이 거의 없음
• 특정 하드웨어를 제어, 특정 제품에서 동작
• 제한적인 사용자 인터페이스 제공
• 특정 제품에서 동작하는 소프트웨어
• 경성, 연성 실시간성이 요구됨
• 각종 자원에 제한이 있음
사용자
측면
• 사용자의 필요에 따라 선택
• 하드디스크에 프로그램 저장
• 별도의 매체를 이용하여 배포
• 그래픽 사용자 인터페이스
• 시스템이 켜지면 바로 실행됨
• 롬이나 플래시 메모리에 내장
• 소프트웨어가 하드웨어와 함께 배포
• 스위치, LCD 등 제한된 인터페이스
개발자
측면
• 소프트웨어만을 개발
• 프로그래밍 기술 및
비즈니스 로직에 관한 지식이 필요
• 개발 대상 하드웨어,
운영체제의 종류가 다양하지 않음
• 개발 환경과 실행 환경이 같음
• 하드웨어와 함께 개발하므로
하드웨어에 대한 지식 및 경험도 필요
• 시스템 소프트웨어 기술이 많이 필요
• 같은 기능이라도 다양한 하드웨어,
다양한 운영체제에 이식됨
• 호스트 시스템과 타겟으로 구성된 교차 개발 환경

10. Target System ?
• 개발하려는 목적 시스템 (Target Board, Embedded Board)
• 자체적인 개발 환경이 없음
• 개발 도구가 실행될 수 있는 운영체제, 개발 도구를 이식할 수 없거나
• 성능이 낮거나, 저장장치가 없거나, …
• 많은 경우 사용되는 PC나 서버와 Target 시스템은 CPU가 다름
• Host CPU : 보통은 x86
• Target CPU : 8/16 bit MCU (micro controller unit),
16/32 bit DSP (digital signal processor),
또는 ARM, MIPS, PowerPC 기반 SOC (System On a Chip)
• 대개 모니터/키보드가 없으며, 시리얼 포트와 같은 최소한의 통신만 제공
• 시리얼 포트로 메시지 출력/입력, 디버깅이 가능 („Debug Console‟)
• 실행 이미지를 다운로드 가능하다면 부트로더 (다운로더)를 활용이 가능
• Flash, RAM 등 실행 가능한 메모리에 이미지를 받아서, 실행
• Ethernet – tftp, nfs client,
• USB, Serial – X/Y/Zmodem protocol
• Hardware wired – JTAG

11. Debugging (Monitoring)을 위한 연결
• Serial Connection
• 거의 모든 MCU에 Serial Port 하드웨어가 이미 있음
• 이제는 반대로 PC (laptop) 쪽에 Serial Port가 없음 (serial <-> USB 동글 사용)
• 최대 전송 속도의 제한이 있음 (max 115200bps)
• 디버깅과 Console 메시지를 표시를 같이 할 수도 있음
• USB (Universal Serial BUS)
• 벌크 전송 모드를 이용하여 고속 전송이 가능
• 최근의 대부분 MCU에는 USB가 기본으로 들어있음 (SW 스택이 다소 복잡)
• 최근의 작은 MCU들은 MCU 내부의 Flash burning / 통신을 위해 사용
• High speed network interface (LAN)
• Ethernet 상에서 TCP/IP (or UDP/IP)으로 빠르게
• 하나의 LAN 상에서 논리적인 여러 channel을 구성하여 동시 이용 가능
• JTAG (Joint Test Action Group) 연결
• MCU chip 테스트를 위한 인터페이스이지만,
• MCU의 모든 pin를 직접 제어할 수 있고, MCU 내부의 모든 것을 읽을 수 있고
• MCU 내의 In-circuit-Emulator 기능에 접근할 수 있는 강력한 debugging 연결
• Flash Burning에도 사용

12. 임베디드 시스템 개발 절차
• 기획
• Goal 설정 (What, Why, Who, Cost ?)
• S/W, H/W Trade-Off (어디까지 H/W ?)
• H/W - 부품값 상승, 보수 유지 어려움
• S/W - 개발비 상승, flexible (A/S)
• Constraints 고려 - 법률, 환경, 윤리, 특허...
• 제품 Specification, Manual, 작성
• Hardware 개발
• 부품 선택
• CPU 및 기타 주요 부품, MEM, I/O, 기타
• H/W, S/W 개발 도구 고려
• 전체 비용, 성능(속도, 전력, 크기),
• FPGA등 유연한 부품 사용 고려
• multiple source !
• 기구(껍데기) Design, Mock-up, 금형, 사출
부품 공부 (HW, SW 제어방법) !
• schematic design
• test 방법 고려 (ICE, scope 꽂을 자리)
• PCB artwork, sample PCB, assembly
• Test (최소한 Test S/W 작성)
• Oscilloscope, Logic, Protocol, Spectrum, Analyzer
• 실패하면 “부품 공부”부터 다시
• Software 개발 (하드웨어와 동시 작업)
• 소프트웨어 Platform 선택
• OS (full-fledged OS, RTOS), Non-OS
• Out-Sourced Component 선택
• Protocol, Middleware, Libraries, …
• Software 구조 설계
• 계층 구조 (H/W 드라이버, OS, Lib, App)
• Platform 기반, Model 기반 설계
• 모듈 간의 I/F, Application 동작
• TEST 작전 마련
• 모듈 별 구현, Source Read, Test
• 통합 Test (소규모  대규모, H/W)
• Simulator 이용 Test (H/W가 덜 된 경우)
• (통합) Test
• All or nothing(„도느냐 마느냐‟)는 안됨
• 반드시 Test Plan 미리 준비
• TEST는 모든 개발 단계에서 !!
• 요구사항, 설계, 구현, 통합, …
• 가능한 모든 디버깅 방법 활용 !!

13. 임베디드 시스템 개발 인력
• 하나의 임베디드 시스템을 출시하기 위한 R&R
• Marketing / Sales
• 시장 조사, 제품 기획 (Target 시장, 가격, 주요 기능, 법률/지재권 검토)
• 광고, 판매망, 고객 관리, …
• 개발
• 하드웨어 (회로 설계/Test, PCB Design, 기계-기구)
• Design (외관, UX/UI)
• 소프트웨어 (Board Support, System Software, Application)
• TEST !!!
• Technical/User Document
• 생산 / AS
• 부품 조달 (+Inbound QC)
• 조립, 생산, 그리고 제품 Test  공장
• Technical Support, Customer Service (AS)
• 그리고…
• 지원 인력 (인사, 재무, ...)

14. Target S/W의 실행을 위해서…
• 우리가 임베디드 뭔가를 만든다면...
• CPU, ROM, RAM, I/O이 필요
• 처음 전원을 켜면 ? ROM이 필요
• Test, Booting, Application
• 즉, 뭔가를 개발한다는 것은
• ROM 용 프로그램을 만든다는 것
• 개발이 끝나면
• Masked ROM으로
• CPU 내부의 ROM 또는 외부 ROM
• (예전엔, PROM, EPROM)
• Flash - 잦은 Upgrade가 예상될 때
• Online Upgrade도 가능
• 재료비가 비싸진다
• 대부분의 임베디드 MCU
• 내부 ROM: Mask, Flash 버전 제공
• 요즘 32bit SOC는 부트로더 제공
(NAND flash에서 부팅)
• 초기: Flash, 안정되면 Masked MCU
• Masking 비용 : 수백만원
• 초기 개발 방법
• Flash (ROM) 굽기 (via USB, JTAG)
• 전원이 켜지면 실행될 ROM 준비
• Boot-loader 또는 실제 실행 프로그램
• ROM Emulator (최근에는 거의 사용 안함)
• ROM 자리에 꼽는 host와 연결된 RAM
• Target system에서는 ROM으로 보임
• ICE의 사용
• 고기능 ICE (저렴한 JTAG ICE 말고)는
CPU, 메모리를 대체…
• RAM에 download 하여 실행
• Serial, USB, LAN이 필요
• Downloader (boot-loader)를 먼저 개발
• 위 초기 개발 방법 사용
• Build 후 download하여 RAM에서 실행
• MCU가 RAM 실행을 지원하고
• 실행 코드를 수용하는 충분한 RAM이 있을 때

15. 디버깅 방법 / 도구
• 모니터링/디버깅 방법이 확보되어야 SW를 수정할 수 있다. !!!
 임베디드 시스템엔 대개 화면과 Keyboard가 없는 것이 함정
• 제대로 된 디버거 (HW, SW)가 있다면 반드시 사용
• LED, Buzzer, printf (via serial, usb, LAN..) 라도
• Target 시스템을 위한 Debugging 기능의 제공
• Target 시스템의 모니터/BIOS/Downloader/Bootloader에 디버그 기능 포함
• single step, break point
• ICE, JTAG ICE, Serial port / USB / LAN을 이용한 remote debugging
• printf() : 디버깅 도구가 절대 아님, 모니터링 용으로만 사용
• Printf ? (LCD 또는 serial port를 통해 host에서)
• 복잡하다 !!
 Target 없이 할 수 있는 모든 Test는 HOST에 수행

16. Debugger
• 디버거의 주요 기능
• Breakpoint (Code, Data),
• Stack Trace
• Data (global, local, register) Watch
• 다양한 방법의 Step Execution
• multiple condition, profiling, coverage 분석
• S/W debugging
• Illegal operation and/or PSW(flag)의 trace bit 이용하여 디버깅
• 제한적 기능 (실시간 디버깅 불가, 속도 느림)
• Hardware Debugging
• ICE (In-Circuit Emulator) or BDM (Background Mode Debugger) 사용
• JTAG-ICE, 싼 8, 4 bit ICE (Programmer 포함)도 있음
• 요즘의 거의 모든 CPU는 JTAG 디버깅이 가능하도록 만들어짐
• 고급 ICE는 Hardware 자체를 Debug (CPU, 메모리를 대체함)
• 실시간 Debug (ISR), Data Breakpoint, complex condition의 breakpoint 등이 가능

17. 임베디드 시스템 개발의 왕도
• 임베디드 시스템의 이해
• CPU, 하드웨어 (Data Sheets), 입출력 장치의 동작
• 전원 시스템, 하드웨어에 의한 제약 사항
• 그리고는 원래 소프트웨어 개발의 왕도와 같음
• 가방끈.. 기본이 중요
• 좋은 설계
• 플랫폼의 적절한 활용, 모델 기반 설계, 모듈화, 문서화, Test를 위한 설계
• 올바른 코딩
• Coding Convention 지키기 : 읽기 쉬운 코드 만들기
• 모든 compiler warning 없애기 – warning은 미래의 bug
• 뭐든지 Review and Source reading
• 자기와 팀이 만든 문서/소스를 “반드시” 뽑아서 읽음
• 모든 level에서의 TEST, daily/weekly Build, Version Control, (주기적 Backup)
• 안 되는 (error가 나는) case에 대한 test를 더 심하게

18. 임베디드 시스템의 Testing
• 임베디드 시스템 Testing 이슈
• 모든 일반 S/W의 Testing 이슈
+ 비동기적 Event에 대한 시간 제약성
+ 다양한 하드웨어, 소프트웨어 플랫폼
+ H/W, 개발 도구 자체의 오류
+ Intrusive Testing 이슈
• Test 모듈이 시스템의 일부가 되는 문제
• Testing 방법
• 일반 S/W Testing 도구의 사용
• Black box test (외주 모듈, closed source)
• White box test
• 정적 Test : Syntax, Semantics Check
• 동적 Test : Test Case에 의한 Test
• Emulator를 이용한 Test
• Target Testing 모듈을 이용한
• Event Capture (or Record) and Replay
Source
Inspection
전문
Tester
Testing
Tools

19. 임베디드 시스템 보안
• 보안 문제의 중요성 인식 필요
• Nothing is 100% Secure !
• 임베디드 시스템에서의 중요성
• Attacker가 제품 자체를 소유 : 물리적 접근 가능
• 많은 임베디드 시스템이 이제 On-Line
• 공격 목표
• 이전의 모든 목표 (내부 정보 획득, 서비스 중지, …)
• Competition (Cloning) : 지적 재산권 탈취
• Free Ride : 서비스의 무료 이용
• 대책
• 하드웨어 보안 : Interface, Tamper Proof 하드웨어
• 소프트웨어 보안 : Firmware 보안, TPM, …
• No “Security by Obscurity” Policy !!

20. Q & A