임베디드시스템개발 part2
TRANSCRIPT
오늘의 목표
• 간단 복습• 임베디드 시스템 ? 개발의 목표 ?
• 임베디드 시스템 개발에 대한 이해• 일반 소프트웨어와 개발의 차이• 무엇을 개발한다는 것인가 ?
• 그 기본과 절차• 인력
• 디버깅 , 테스팅 , 보안 이슈
임베디드 시스템의 특징
• 전통적인 임베디드 시스템의 특징• Single functioned
• 하나의 프로그램이 반복 수행• Tightly constrained
• 재료비 , 전력 , 물리적인 크기 , 특정 기능의 속도 , 메모리 등• Reactive and real-time
• 시스템의 환경 변화에 지속적으로 반응• 예측 가능한 응답으로 , 어떤 이벤트가 가지는 시간 제약성을 만족
• 최근 임베디드 시스템의 특징• Digitally converged
• 멀티미디어 , 유비쿼터스 , …• More tightly constrained (except memory)• Scalable and feature-rich
• 더 많은 기능을 수용할 수 있는 소프트웨어 구조
앞으로의 임베디드 시스템 시장
• 전통 임베디드 시장의 건재함은 그대로 유지• 항공우주 , 자동차 , 의료 , 공장 , 전통가전 , 게임
• 기술적 발전에 따른 시장 변화• 통신 인프라의 발전 : 유비쿼터스 , 컨버젼스 응용 창출• 반도체 기술의 발전 : 제품의 기술적 구현 가능성 증가• BT, NT 의 발전 : 새로운 소재 , 센서의 등장
• 미래형 임베디드 시스템 시장은 대부분 인간 주변에…• 콘텐츠 중심의 임베디드 시스템 시장• 서비스와 연계 ( 수익 모델의 변경 )
• 미디어 ( 정보에 접근하는 채널 ) 의 변화• SNS, Mobile, Location Based xxx
• 사회 구조 , 제도 , 환경의 변화에 따른 시장 변화• 노령화 , 주 5 일 근무 , 사교육 , 저출산 , 온라인 미디어
지구 온난화 , 지속 가능 에너지 , …
하드웨어에서소프트웨어로
가치창출동력이 바뀜그 중심엔
역시 사람 !!!
임베디드 시스템 개발의 목표
기술적 목표• Correctness
• 사용자 관점의 기능 충실도• Availability
• 시스템 가용 시간의 확보• Technical Requirements
• Power Consumption• Space Limitation• Legal Stuffs ( 특허 , 전자파 , …)• …
• Security• 논리적 , 기계적 보안• 사용자 보호 , 기술 보호
• Flexibility• Testability
시장적 목표• Marketing driven requirements
• 수요자 그룹을 위한 디자인• 사회적 요구 ( 윤리적 , 환경적 , …)
• Price+ NRE (Non-Recurring Engineer-
ing)• 개발비 등 1 회성 비용
+ Unit (BOM) Cost+ 중간쯤 있는 비용
• 장비 , 광고 , 땅 , …
• Time• to Prototype• to Market
• Maintainability• or NOT
설계의 핵심 : 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
플랫폼 기반 / 모델 기반 개발
• 플랫폼 기반 개발• Platform : 서로 연관되어 상승 효과를 낼 수 있는 공통 서비스들의 추상화
• 다양한 요구 사항을 해석하여 그들을 수용하는 architecture 를 제시한 것
• 잘 정의된 공통 서비스를 바탕으로 “필요 기술 요소”의 확인 / 조달을 빠르게 함 ( 각 요소 서비스 제공자들을 나열한 solutions-map 과 함께 )
• 모델 기반 프로그래밍의 장점• 플랫폼 독립적인 소프트웨어 모듈의 재사용성 증가• 새로운 하드웨어 플랫폼에의 적응성 향상• 사용자 요구 변화에 대한 빠른 대응
• 쉽게 말하면 , 모두가 이해할 수 있는 ‘틀’ 을 기반으로 뭔가를 만들자 ! 소프트웨어 개발 생산성 증가
임베디드 소프트웨어 개발 : 조금 다르다 !
• 보통 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 에서의 디버깅
일반 SW vs. 임베디드 SW 차이
구분 일반 소프트웨어 임베디드 소프트웨어
특징
• 사용자의 기능 요구 사항의 만족• 개인 및 기업을 위한 정보 처리 • MS 와 같은 몇몇 기업이 주로 독점 • 실시간성이 거의 요구되지 않으며• 자원 제한이 거의 없음
• 특정 하드웨어를 제어 , 특정 제품에서 동작• 제한적인 사용자 인터페이스 제공• 특정 제품에서 동작하는 소프트웨어 • 경성 , 연성 실시간성이 요구됨• 각종 자원에 제한이 있음
사용자
측면
• 사용자의 필요에 따라 선택• 하드디스크에 프로그램 저장 • 별도의 매체를 이용하여 배포 • 그래픽 사용자 인터페이스
• 시스템이 켜지면 바로 실행됨 • 롬이나 플래시 메모리에 내장• 소프트웨어가 하드웨어와 함께 배포 • 스위치 , LCD 등 제한된 인터페이스
개발자
측면
• 소프트웨어만을 개발 • 프로그래밍 기술 및 비즈니스 로직에 관한 지식이 필요 • 개발 대상 하드웨어 , 운영체제의 종류가 다양하지 않음• 개발 환경과 실행 환경이 같음
• 하드웨어와 함께 개발하므로 하드웨어에 대한 지식 및 경험도 필요 • 시스템 소프트웨어 기술이 많이 필요 • 같은 기능이라도 다양한 하드웨어 , 다양한 운영체제에 이식됨• 호스트 시스템과 타겟으로 구성된 교차 개발 환경
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
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 에도 사용
임베디드 시스템 개발 절차
• 기획• 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 는 모든 개발 단계에서 !!• 요구사항 , 설계 , 구현 , 통합 , …
• 가능한 모든 디버깅 방법 활용 !!
임베디드 시스템 개발 인력
• 하나의 임베디드 시스템을 출시하기 위한 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)
• 그리고…• 지원 인력 ( 인사 , 재무 , ...)
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 이 있을 때
디버깅 방법 / 도구
• 모니터링 / 디버깅 방법이 확보되어야 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 에 수행
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
등이 가능
임베디드 시스템 개발의 왕도
• 임베디드 시스템의 이해• 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 를 더 심하게
임베디드 시스템의 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
SourceInspection
전문Tester
TestingTools
임베디드 시스템 보안
• 보안 문제의 중요성 인식 필요• Nothing is 100% Secure !
• 임베디드 시스템에서의 중요성• Attacker 가 제품 자체를 소유 : 물리적 접근 가능• 많은 임베디드 시스템이 이제 On-Line
• 공격 목표• 이전의 모든 목표 (내부 정보 획득 , 서비스 중지 , …)• Competition (Cloning) : 지적 재산권 탈취• Free Ride : 서비스의 무료 이용
• 대책• 하드웨어 보안 : Interface, Tamper Proof 하드웨어• 소프트웨어 보안 : Firmware 보안 , TPM, …• No “Security by Obscurity” Policy !!
Q & A