실시간 운영체제와 임베디드 시스템

목 차

 실시간 운영체제

 실시간 시스템 개요

 실시간 시스템과 임베디드 시스템

 실시간 운영체제 적용기술과 사례

 실시간 운영체제 현황

 상용 실시간 시스템 현황

 임베디드 Linux 

 RT-Linux

 실시간 운영체제 기술 동향

실시간 운영체제와 임베디드 시스템

Real-Time OS and Embedded System

운영체제

 운영체제란?

 자원 관리자 (Resource Manager)

 응용에게 자원에 대한 서비스 제공 (Computing Environment)

 자원의 종류

 물리적인 자원 : 처리기, 메모리, 디스크, 터미널, 네트웍, ...

 추상적인 자원 : 태스크, 세그먼트/페이지, 파일, 드라이버, 통신 프로토콜, 패킷, 보안, ...

운영체제 종류

 RTOS(Real-Time OS)

 VxWorks, pSOS, LEX, uITRON, EPOCH, Nucleus 

 UNIX

 SVR4, Solaris

 BSD, HP-UX

 Linux

 Embedded Linux

 RT-Linux

 Windows System

 Windows XP

 Windows CE.NET

실시간 시스템 (Real-Time System)

 실시간 시스템이란?

 사전적 의미 : “실 시간적 요소가 포함되어 있는 기능을 하기위해 어떠한 법칙에 따라 조합된 집합체” 

 “ 특정 입력에 대해 주어진 시간 내에 반드시 정해진 결과를 보장해야 해야 하는 시스템” - www.foldoc.org , www.jargon.org

 특정 반응에 대해 정해진 시간 내에 행동할 수 없을 때 문제가 발생하는 시스템. 그 결과가 산출되어야 하는 시간에도 적시성(timeliness)을 가지며 외부 자극에도 예측 가능한(predictable)  방식으로 반응.

 timeliness? 열악한 환경 하에서도 데드라인(deadline) 이내에 논리적으로도 정확한 출력 값을 산출해 내는 것 .

 deadline이란 반응에 요구되는 시간의 한계 값 

 분류

 Hard 실시간 시스템 - 제어작업이 deadline을 어기는 경우 시스템에 심각한 영향을 주는 time-critical 속성을 지닌 시스템 

예) 항공기, 우주 왕복선, 자동차 등

 Soft 실시간 시스템 - Deadline을 어긴 단위 제어 작업의 무효화로 시스템의 평균적 성능에 미세한 영향을 주는 시스템

예) 컴퓨터, 정보기기, 네트워크 관련기기 등

실시간 시스템 개요 

 용어 설명(car and driver)

 driver : real-time controller

 car : controlled process

 other cars : operating environment

 main actuators : wheels, engine, brakes

 controls : accelerator, steering wheel, brake-pedal, etc.

 sensors : eyes, ears, body itself

 성능(performance)

 마감시간을 어기는 태스크가 없도록

 태스크 데드라인

실시간 시스템 개요 (2)

 실시간 시스템의 설계

 적대적인 운영환경을 가정

• 전자기장의 영향, 소립자의 방사

• 계산부하가 급격히 변화

• 비교) 항온항습 되는 전산실

 항공기 제어 컴퓨터

• 자세제어 태스크가 최고 우선순위

• 웍스테이션 설계 대 엔진 제어 컴퓨터 설계

* 엔진제어 태스크의 경우 마감시간 넘길 때 폭발할 수도

* 웍스테이션의 경우 단순한 성능 감소만

실시간 시스템 개요 (3)

실시간 시스템 개요 (4)

 태스크의 분류

 the predictability of their arrival.

 the consequences of their not being executed on time.

 Periodic and aperiodic tasks

 periodic tasks can be prescheduled.

 Aperiodic tasks with a bounded interarrival time are called sporadic tasks.

 Critical and noncritical tasks

 critical tasks are those whose timely execution is critical.

 Noncritical tasks are not critical to the application

실시간 스케쥴링

 태스크 스케쥴링

 매우 많은 스케쥴링 연구들

• 공학분야, 경영분야, 산업공학분야 등

• 공학분야 논문의 30%

 실시간 태스크 스케쥴링

• Feasible schedule

* 모든 태스크가 마감시간을 준수하는 스케쥴

• 입력

* 태스크 시간 특성, 마감시간, 자원요구

• 출력

* Feasible chedule

실시간 스케쥴링 (2)

 실시간 스케쥴링 (3)

 임베디드 (실시간) OS의 주요 개념 

 태스크

 수행중인 프로그램 (an instance of a running program)

 프로그램의 수행 환경 (an execution environment of a program)

 스케줄링 단위 (scheduling entity)

 제어 흐름과 주소 공간의 집합 (a control flow and address space)

 멀티 태스킹

 여러 개의 태스크를 동시에 실행시키는 것

 일반 OS 에서의 태스크

• 각 태스크들은 대분분 무관한 프로그램임

 임베디드 시스템에서의 태스크

• 하나의 큰 응용 프로그램을 논리적으로 나눈 것 

* 기능상 매우 밀접한 관계 

* 태스크 사이에 이루어지는 작업들이 많다.

• 응용 프로그램을 실행을 위해 여러 기능들이 동시 실행 요구 

* 순차적이 아닌 동시 실행의 필요성이 있다.

 임베디드 (실시간) OS의 주요 개념

 스케쥴러(Scheduler)

 OS의 핵심기능

 다음 번에 어떤 태스크를 실행해야 하는 지를 결정하는 코드 부분

 태스크 선택 정책 : 우선순위 기반의 스케쥴링

• FIFO(First In First Out), Round-robin 등

 선점(Preemptive)

• 어떤 태스크가 수행되고 있을 때 커널이 중간에 그 태스크의 수행을 중지 시키고 다른 태스크의 기능을 수행시키는 기능

• 선점형 커널 / 비선점형 커널

 다른 태스크로 실행이 넘어갈 때 문맥전환(context switching) 발생

 Context switching

 일단 현재 수행 중인 태스크 상황 하에서의 시스템 상태(문맥)를 TCB(Task Control Block)이라는 특정한 자료구조에 저장하고, 다음에 새로운 태스크의 문맥을 가져와 시스템 상태를 복원한 후에 실행하는 것

 Context switching은 overhead이기 때문에 짧을 수록 효율적 임

• thread의 개념을 통해 이를 보완하는 방법

 임베디드 (실시간) OS의 주요 개념

 Mutual exclusion

 두개의 태스크가 동시에 하나의 공유자원에 접근하려고 할 때 한 태스크에게 자원 사용에 대한 배타적 권리를 보장하는 것

 Critical section : 공유자원을 access하는 일련의 코드부분

• 다른 태스크에 의해서 중단되어서는 안 되는 일련의 명령 혹은 코드 블록

 상호배제 기법 

• 인터럽트 발생을 방지

* Critical section에 들어가기 전에 인터럽트를 disable시키고 (CLI) 빠져 나오면서 인터럽트를 다시 enable 시키는 방법 (STI)

* 단일 CPU의 경우 단순하게 사용 가능

• semaphore 이용

* semaphore를 얻지 못하면 공유자원을 얻을 수 없으며 일단 semaphore를 얻으면 공유자원을 마음 놓고 쓸 수 있다.

* 다른 태스크를 위해서 공유자원을 다 쓰면 semaphore를 풀어야 한다.

* Semaphore가 0 이면 waiting한다.

 임베디드 (실시간) OS의 주요 개념

 Semaphore

 공유변수 사용

 mutual exclusion을 만들어 공유자원을 제어

 태스크 사이의 동기화에 사용 가능

 사용 방법

• 공유자원에 해당하는 semaphore를 만든다.

• 공유자원을 사용하기 직전에  해당 semaphore 얻는다.

* 변수 값이 0이 아닌 경우 그 변수 값을 1 감소 시킨다.

* 0이면 양수가 될 때까지 기다린다. (SLEEP상태)

• 공유자원을 다 쓰면 그 값을 1 증가 시킨다.

 종류

• Binary semaphore : 공유자원의 변수가 0,1인 경우

• Counting semaphore : 1이상의 값

 임베디드 (실시간) OS의 주요 개념

 Task communication

 태스크간에 통신하는 방법

• Global variable을 쓰는 방법 / message passing 방법

 Global variable   

• exclusive access를 해야 하며, ISR이 포함된 인터럽트를 disable해야 한다.

• Task 사이에서는 인터럽트를 disable하는 방법 외에 semaphore를 사용할 수 있다.

 message passing

• Mailbox, queue, pipe – message의 크기에 따라 결정됨

 Task synchronization

 태스크 간의 동기화 기능

 Semaphore/event flag/signal 등을 사용

 임베디드 (실시간) OS의 주요 개념

 Interrupt service

 Asynchronous event를 CPU에 알리는 방법

 Interrupt는 외부에서 들어오는 중요한 신호로서 시간에 민감한 경우가 있기 때문에 interrupt latency가 짧은 것이 좋음.

 ISR자체도 짧은 것이 좋은데 그 이유는 ISR 자체가 길어지면 interrupt nesting이 되기 쉽기 때문.

 ISR에서는 보통 그에 상응하는 태스크 수준의 service routine을 부르고(HISR) 끝나도록 구성.

 HISR에서는 마치 태스크처럼 존재해서 수행이 된다.

 임베디드 (실시간) OS의 주요 개념

 Reentrancy code

 인터럽트, 선점의 개념과 연관

 하나의 함수를 여러 태스크가 동시에 수행 가능

 ‘Reentrant하다’ 

• 태스크 1에서 함수 1을 수행하다가 도중에 태스크 2로 제어권이 넘어가고 이 함수를 다시 호출해도 함수 1이 제대로 동작하는 것

• 전역변수를 사용하지 말 것

* 전역 변수는 shared resource이기 때문에 mutual exclusive 하도록 만들어 주지 못하는 문제가 생긴다.

• Reentrant하지 못한 code는 공유하지 않거나, 공유해야 하는 경우에는 semaphore를 쓴다거나 동일 우선 순위를 갖는 태스크 사이에서 round-robin을 하지 않아야 한다.

임베디드 운영체제

 실시간 시스템에서의 S/W

 간단하고 단순한 순차적인 작업에 관련

 순차적인 프로그램으로 충분하였음

 8bit, 16bit 마이크로프로세서 및 마이크로콘트롤러 사용

 임베디드 시스템에서의 운영체제

 시스템의 규모가 커짐에 따른 Multi Tasking 기능 요구

 Network이나 multimedia가 시스템의 기본으로 자리 잡음

• Networking, GUI, Audio, Video

 임베디드 시스템의 특성상 실시간이라는 요소를 만족해야 함

 지능성이 부가되고 기능이 많아지고 복잡해짐

 순차적인 프로그램 작성이 불가능하여 운영체제가 도입됨

 임베디드 운영체제

 기존의 상용 RTOS(Real-Time OS)

 윈도우 CE

 임베디드 Linux

 임베디드 JAVA

상용 RT-OS와 특징

 상용 실시간 운영체제 들과 특징 

Windriver – VxWorks, pSOS

 VxWorks의 특징

 pSOSystem과 마찬가지로 VxWorks의 커널은 선점형 멀티미디어 태스킹이다. 

 총 256개의 태스크 우선순위를 갖는다. 

 두 개 이상의 태스크가 같은 우선순위를 가진다면 라운드 로빈 방식의 스케줄링을 이용한다. 

 통합 개발환경으로 토네이도(Tornado)가 제공된다. 

 약 200개 가량의 소프트웨어 모듈로 구성되어 개발자가 이들 모듈들 중에서 목표 시스템에 필요한 모듈을 선택하여 운영체제를 구성할 수 있다. 

 세마포어와 메시지 큐, 공유 메모리, 소켓, 시그널 등이 제공된다. 

 표준 TCP/IP를 이용한 네트워크 통신이 가능하며 ROM이나 로컬 디스크 등 다양한 부팅이 가능하다. 

 또한 MS-DOS와 RT-11등의 파일 시스템을 지원한다. 

 VxWorks의 구조는 크게 하드웨어에 의존하지 않는 BSP(Board Support Package)와 디바이스 드라이버, 커널과 그에 따른 모듈, 응용프로그램으로 나누어진다. 

Windriver – VxWorks, pSOS

 Windriver 플랫폼 구조

Nucleus

 Nucleus 는 Accelerated Technology사의 실시간 운영체제로서 저작권 없는(Royalty Free)정책 때문에 널리 사용되어지는 실시간 운영체제

 인공위성 및 엘리베이터, 휴대전화, 기지국, 네트워크 분야에서 강세

 국내의 휴대폰 개발 업체들이 로얄티 부담을 줄이기 위해서 많이 채택하고 있음

 Nucleus의 특징

 Nucleus는 ARM, MIPS, PPC, M68K, SH 등 마이크로프로세서를 비롯하여, Analog와 TI  그리고, Hitachi사의 DSP등을 지원하고 있다. 

 ATI에서 제공하는 Nucleus  Web Browser는 HTTP 1.0을 준수하며, HTML 3.2와 프레임을 지원한다. 

 Nucleus GRAFIX와 결합하면 아주 작은 스크린에 Nucleus Web Browser를 최적화할 수 있다. 

Nucleus

 Nucleus RTS 솔루션 구조도 

WinCE.NET

 Windows CE .NET은 Microsoft사에서 실시간 운영체제 시장 및 임베디드 시스템 시장을 위하여 개발, 제공하는 Windows CE 3.0의 후속 버전 

 WinCE.NT 의 특징

 Windows CE .NET에는 모바일 장치가 기존의 인프라에 유연하게 접속할 수 있도록 하기위한 Bluetooth, 802.1x/Zero Configuration, OBEX(Object Exchange) 프로토콜,  MediaSense , 실시간 공동 작업 및 통신(RTC/SIP)과 같은 무선 기술을 지원한다.

 적은 메모리 점유율, 엔터프라이즈 수준의 보안, 다양한 CPU 지원.

 실시간성 지원: 256개의 우선 순위 수준과 중첩 인터럽트 지원을 통해 시스템 자원 사용량이 많은 주요 응용 프로그램에 대한 실시간 처리를 지원 

 에뮬레이션 기술, 다양한 플랫폼 마법사 

 관리되는 코드 및 원시 코드 지원 

 기존의 MS Windows 시스템 및 애플리케이션과 호환성이 우수 

WinCE.NET

 WinCE.NET 적용분야

  임베디드 리눅스

 임베디드 리눅스

 일반 리눅스 – 일반 테스크 탑 환경인 고성능 프로세서와 대용량 메모리 환경에서 동작 하는 범용 컴퓨터 용 리눅스

 임베디드 리눅스 – 저성능의 마이크로 프로세서 와 제한된 메모리 환경에서 동작하는 임베디드 시스템 용 리눅스

 임베디드 리눅스 출현 배경

 H/W의 발전: 32/64bit 고성능 CPU

 S/W의 많은 기능 요구: OS의 기능이 중요, 안정된 운영체제의 제공

                                (멀티 태스킹의 제공)

 강력하고 다양한 네트워크 환경의 제공

 다양한 형태의 파일시스템과 실행파일 포맷 지원

 확장성의 다양함과 용이함의 제공

 Free Software

임베디드 리눅스(2)

 임베디드 리눅스 장점

 기능성과 확장성이 우수 (리눅스 이용에 따른 장점)

 PowerPC, ARM, MIPS 등 다양한 CPU Platform지원함

 로열티가 없으므로 가격 경쟁력이 우수

 사용자 층이 넓어 오류 수정이 빠르고 안정성이 우수

 기존의 데스크 탑 개발 환경과 동일하여 개발이 용이함

 임베디드 리눅스 단점

 기존의 RTOS보다 많은 메모리를 요구함

 범용 OS로 설계되어 Real-Time을 지원하지 못함

 개발 환경이 Text 기반의 환경임으로 개발에 어려움이 있음

 GUI 환경을 개발하기 어려움

 제품화하기 위한 솔루션 구성이 어려움

 많은 업체들과 개발자들이 독자적으로 개발하고 있어 표준화가 어려움

  임베디드 리눅스(3)

 임베디드 리눅스 개발환경 개념도

  임베디드 리눅스(4)

 임베디드 리눅스 구조

  임베디드 리눅스(5)

 임베디드 리눅스 커널 구조

RT-Linux  - Real-Time Linux의 개요

 RT-Linux 출현 배경

 정확한 타이밍 제어가 가능한 Linux 운영체제

 수 십 Micro-Second까지 제어 가능

 Embedded System과 결합

 RT-Linux - 일반 Linux의 문제점

 Critical Section에서의 긴 Blocking 시간

 우선 순위 보다는 기아(Starvation)문제 해결에 집중

 낮은 우선 순위의 Tread도 상위 대기 큐에 있을 수 있음

 공정한 자원 분배

 Exhaustive, Fairness based Scheduling

 Fairy-Shared Scheduler의 문제

 특정 Thread의 정확한 동작 보다는 모든 Thread의 공평한 동작에 초점

 Fairy-Shared Scheduler의 문제

 Linear List로 Task 관리

 우선 순위의 정확한 반영이 어려움

 우선 순위 역전의 가능성 존재

 Soft-Interrupt 발생 시점에서 Handling 함수에 도달 할 때까지의 타이밍 예측 불가능

 정확한 시간 간격으로 Task가 동작하도록 보장 할 수 없음

 타이밍에 엄격한 시스템에서는 일반 Linux는 사용 불가능

 RT-Linux - Dual Kernel 구조

 RT-Scheduler와 None RT-Scheduler가 존재

RT-Linux - Real Time Task의 구조(1)

 Device Driver와 같은 형태로 Kernel의 모듈로 동작하는 RT-Task

 Hardware Interrupt Emulation

 Character Device Emulation

 사용 가능한 라이브러리의 제한

 실질적인 실시간 동작 담당

 RT-Task와 FIFO, Shared Memory를 이용해 정보를 교환하는 User Task

 RT-Task의 제어

 RT-Task의 출력 정보 처리

RT-Linux - Real Time Task의 구조(2)

RTOS 기술동향

 RTOS 구조

RTOS 기술동향 (2)

 커널 발전 과정

RTOS 기술동향 (3)

 RTOS 구조

 Monolithic OS

 Layered OS

 Client-server OS

• microkernel: basic OS functions(scheduler, synchronization, etc.)

• Server tasks: responsible for different functions

• Clients: applications

• Scalable, easy to debug, robust, flexible

RTOS 기술동향 (4)

 hardware abstraction layer(HAL)

 Smooth and efficient porting to different platform

 Scale- down kernel version

 modular

 dynamic extensions and upgrades to provide new features to meet market requirements

 portable architectures

 dynamic and adaptable systems

 small memory footprint(code+workspace)

RTOS 기술동향 (5)

 Process-thread-task model

 a process is an application subdivided in tasks or threads

 scheduling, priority, interrupts

 preemptive priority scheduling

 deadline driven scheduling policy

 handling priority inversion

 interrupt handling following different simultaneous interrupts in a pre-emptive way

 minimum interrupt latency

RTOS 기술동향 (6)

 라이브러리 발전 과정

RTOS 기술동향 (7)

 표준화

 POSIX, ISO, ANSIC

 Flash, FAT

 C library(POSIX)

 Graphic/ Windows

 GUI support

 X-Windows, Motif

 GTK

 Java, CORBA support

 network (Internet-ready)

 telnet, ftp, tftp, TCP/IP,SNMP,STREAM, ATM, x.25, OSI, htto server, PPP

 Security

 File system

 Multiprocessing support

RTOS 기술동향 (8)

 개발도구의 발전 과정

RTOS 기술동향 (9)

 개발 도구

 Object-oriented notations and methods

 design, implementation, debugging, test등 전 개발 과정에서 이용

 3GL 대신 Graphical design model(notation) 이용

• UML, FSM, SDL notation 등

• reduce time to market, improve quality

 graphical design editor, model compiler, graphical symbolic debugger

 Cross 개발 환경 지원

 Emulator, debuggers, memory analyzers, and profilers등을 포함

 memory analyzer

• test point 삽입: allocated된 지점이나 free된 지점

• 어플리케이션의 메모리 자원 활용의 정보 수집

• memory leak 여부 조사

 Profiler

• task나 semaphore등을 사용

• OS의 성능을 모니터

• task나 function의 실행시간의 분석을 위한 도구 지원

RTOS 기술동향 (10)

 Debugger

 Design-level

• model based design: concentrate on the problem rather than code

 Source-level

• C/C++source level debugging, based on GNU

• setting break point and single stepping, stack debugging

 Kernel-level

• low-level embedded target debugging

• memory inspection/modification

 kernel configuration tool

 manage components and services available to the application