1. 우리 주변에 있는 임베디드 시스템 찾기
2. 목차
3.지문인식 출퇴근 기록기 - 사용자의 지문을 센서에 가져다 대면 센서가 지문을 캡쳐하여 내부메모리에 저장 및 확인 가능하고 내부메모리에 저장된 데이터들은 회사 데이터베이스와 연동하여 출퇴근 확인 가능
4. 추가로 출입문은 인증후 DoorLock과 DoorSensor로 출입문을 제어하며 근무 시간대 등록, 지각,조퇴,외출 집계 기본,연장,야간시간 설정 등 많은 기능이 시스템에 존재
5. 왜 소프트웨어로 만드는 것이 좋았을까? - 기존 아날로그 방식은 종이에 출퇴근 기록을 입력하는 방식이고 달마다 종이를 새루 바꾸어서 출퇴근 기록을 입력 해야하고 실수로 분실 가능성이 있다. 그로인해 지문인식 출퇴근 단말기 사용시 매달마다 종이를 바꿀 필요가 없으며 지문입력한번으로 쉽게 등록가능, 출퇴근시 지문인식으로 자동으로 회사 데이터베이스에 저장된다.
6. 발견된 버그 - 출퇴근기에 지문 입력시 퇴근을 찍어도 출근이라고 뜨는경우, 시스템 기록엔 정상적으로 퇴근처리 되어있음
7 회사엔 3개의 입출근 기록기 존재, 확인결과 3개의 기록기중 하나만 버그가 보임, 시스템 재부팅시 퇴근시간을 출력해주는 프로그램 설정만 초기화된것 같음
8 순서도 - 지문인식을 하면 디지털화된 지문정보를 전송할것인지 판별(자세하게 스캔이 되지않으면 다시 입력하게 만듬) 제대로 스캔이 되면 디지털화된 지문정보를 사내 DB에 전송 회원정보가 DB내 회원정보와 일치하면 문을 열고 일치하지않으면 다시 대기상태로 들어감
9. 출입문 동작 모듈 - 고객이 지문을 인식하면 판별된 정보를 제어시스템에 보내고 제어시스템은 출입문 상태를 확인하고 출입문에 제어명령을 열어주어서 출입문 동작
10. 지문인식 판별 - 고객이 지문을 스캔하면 지문정보를 DB에 정보를 전송 디지털화된 정보를 DB에 넘기고 지문정보를 판별해 판별정보를 제어시스템에 제공한다.
11. The End
개발을 업으로 한다는 것. 즉 선수 개발자가 되려면 스스로 개발에 자신이 있어야 하고 동시에 남들에게도 인정받는 훌륭한 개발자여야 합니다. 자신있다는 것과 훌륭하다는 것은 어떤 차이가 있을까? 이 발표는 이제 개발에 입문하려는 사람들, 이제 뭐든 만들 수는 있을 것 같은 개발자들, 뭔가 개발 '꺼리'를 보면 솟아나는 열정에 가슴이 뛰는 개발자님들을 위하여 훌륭한 개발자가 되기 위한 마음가짐과 준비해야하는 것들에 대하여 이야기를 합니다.
1. 우리 주변에 있는 임베디드 시스템 찾기
2. 목차
3.지문인식 출퇴근 기록기 - 사용자의 지문을 센서에 가져다 대면 센서가 지문을 캡쳐하여 내부메모리에 저장 및 확인 가능하고 내부메모리에 저장된 데이터들은 회사 데이터베이스와 연동하여 출퇴근 확인 가능
4. 추가로 출입문은 인증후 DoorLock과 DoorSensor로 출입문을 제어하며 근무 시간대 등록, 지각,조퇴,외출 집계 기본,연장,야간시간 설정 등 많은 기능이 시스템에 존재
5. 왜 소프트웨어로 만드는 것이 좋았을까? - 기존 아날로그 방식은 종이에 출퇴근 기록을 입력하는 방식이고 달마다 종이를 새루 바꾸어서 출퇴근 기록을 입력 해야하고 실수로 분실 가능성이 있다. 그로인해 지문인식 출퇴근 단말기 사용시 매달마다 종이를 바꿀 필요가 없으며 지문입력한번으로 쉽게 등록가능, 출퇴근시 지문인식으로 자동으로 회사 데이터베이스에 저장된다.
6. 발견된 버그 - 출퇴근기에 지문 입력시 퇴근을 찍어도 출근이라고 뜨는경우, 시스템 기록엔 정상적으로 퇴근처리 되어있음
7 회사엔 3개의 입출근 기록기 존재, 확인결과 3개의 기록기중 하나만 버그가 보임, 시스템 재부팅시 퇴근시간을 출력해주는 프로그램 설정만 초기화된것 같음
8 순서도 - 지문인식을 하면 디지털화된 지문정보를 전송할것인지 판별(자세하게 스캔이 되지않으면 다시 입력하게 만듬) 제대로 스캔이 되면 디지털화된 지문정보를 사내 DB에 전송 회원정보가 DB내 회원정보와 일치하면 문을 열고 일치하지않으면 다시 대기상태로 들어감
9. 출입문 동작 모듈 - 고객이 지문을 인식하면 판별된 정보를 제어시스템에 보내고 제어시스템은 출입문 상태를 확인하고 출입문에 제어명령을 열어주어서 출입문 동작
10. 지문인식 판별 - 고객이 지문을 스캔하면 지문정보를 DB에 정보를 전송 디지털화된 정보를 DB에 넘기고 지문정보를 판별해 판별정보를 제어시스템에 제공한다.
11. The End
개발을 업으로 한다는 것. 즉 선수 개발자가 되려면 스스로 개발에 자신이 있어야 하고 동시에 남들에게도 인정받는 훌륭한 개발자여야 합니다. 자신있다는 것과 훌륭하다는 것은 어떤 차이가 있을까? 이 발표는 이제 개발에 입문하려는 사람들, 이제 뭐든 만들 수는 있을 것 같은 개발자들, 뭔가 개발 '꺼리'를 보면 솟아나는 열정에 가슴이 뛰는 개발자님들을 위하여 훌륭한 개발자가 되기 위한 마음가짐과 준비해야하는 것들에 대하여 이야기를 합니다.
2016년 11월 모 대학에서 IT 계열 전공 재학생들을 대상으로 진행했던 진로 특강 자료입니다.
앞쪽의 제반 내용들은 다양한 자료들을 정리하면서 제 생각을 담았습니다.
이 자료의 가장 핵심적인 내용은 5가지 유형의 현직 선배들을 대상으로 설문을 실시하여 후배들에게 들려주고 싶은 현실적이고 진솔한 이야기를 정리한 부분입니다.
IT 분야 그리고 소프트웨어 개발자의 삶의 모색하는 분들에게 조금이나마 도움이 되길 바라는 마음에 자료를 공개합니다.
The Complete Roadmap Workbook Final Usepaulageorge
"The Complete Roadmap to Your Business Success”
Interactive workbook for Business Owners who want to transform their Busiiness and make more Profit
Work Book
2016년 11월 모 대학에서 IT 계열 전공 재학생들을 대상으로 진행했던 진로 특강 자료입니다.
앞쪽의 제반 내용들은 다양한 자료들을 정리하면서 제 생각을 담았습니다.
이 자료의 가장 핵심적인 내용은 5가지 유형의 현직 선배들을 대상으로 설문을 실시하여 후배들에게 들려주고 싶은 현실적이고 진솔한 이야기를 정리한 부분입니다.
IT 분야 그리고 소프트웨어 개발자의 삶의 모색하는 분들에게 조금이나마 도움이 되길 바라는 마음에 자료를 공개합니다.
The Complete Roadmap Workbook Final Usepaulageorge
"The Complete Roadmap to Your Business Success”
Interactive workbook for Business Owners who want to transform their Busiiness and make more Profit
Work Book
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
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 !!