임베디드시스템개발 Part2
Upcoming SlideShare
Loading in...5
×
 

임베디드시스템개발 Part2

on

  • 635 views

 

Statistics

Views

Total Views
635
Views on SlideShare
635
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

임베디드시스템개발 Part2 임베디드시스템개발 Part2 Presentation Transcript

  • 임베디드 시스템 개발 (2)이 민 석minsuk@nhn.com
  • 오늘의 목표• 간단 복습• 임베디드 시스템? 개발의 목표?• 임베디드 시스템 개발에 대한 이해• 일반 소프트웨어와 개발의 차이• 무엇을 개발한다는 것인가 ?• 그 기본과 절차• 인력• 디버깅, 테스팅, 보안 이슈
  • 임베디드 시스템의 특징• 전통적인 임베디드 시스템의 특징• 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 Engineering)• 개발비 등 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/WSizePerformancePowerNRE 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 ReplaySourceInspection전문TesterTestingTools
  • 임베디드 시스템 보안• 보안 문제의 중요성 인식 필요• Nothing is 100% Secure !• 임베디드 시스템에서의 중요성• Attacker가 제품 자체를 소유 : 물리적 접근 가능• 많은 임베디드 시스템이 이제 On-Line• 공격 목표• 이전의 모든 목표 (내부 정보 획득, 서비스 중지, …)• Competition (Cloning) : 지적 재산권 탈취• Free Ride : 서비스의 무료 이용• 대책• 하드웨어 보안 : Interface, Tamper Proof 하드웨어• 소프트웨어 보안 : Firmware 보안, TPM, …• No “Security by Obscurity” Policy !!
  • Q & A