工學碩 士學位 請求論 文

리눅스 운용체계의 시뮬레이터 플랫폼 연구

Re s e arc h of a s im u lat or plat f orm on L inu x

Operat in g S y s t e m

200 1年 2月

仁荷大學校 大學院

航空工學科

韓 東 勳

工學碩 士學位 請求論 文

리눅스 운용체계의 시뮬레이터 플랫폼 연구

Re s e arc h of a s im u lat or plat f orm on L inu x

Operat in g S y s t e m

200 1年 2月

指導敎授 朴 瑃 培

이 論文을 工學碩士學位 論文으로 提出함

仁荷大學校 大學院

航空工學科

韓 東 勳

이 論文을 韓東勳의 碩士學位 論文으로 認定함

200 1年 2月

主審 (印 )

副審 (印 )

委員 (印 )

요 약

시뮬레이터란 위험하거나 절차가 복잡한 조작방법을 숙지하는 가상현실 기기이다.

이러한 시뮬레이터 플랫폼의 운영체제로 기존에는 윈도우즈 계열을 많이 사용하였

다. 하지만, 윈도우즈 운영체제의 복잡성과 소스의 비공개로 인하여 이를 이용한 개

발은 한계를 가지게 된다. 이에 자유로운 소스의 공개와 통신에 강점을 가진 리눅스

를 기반으로 한 시뮬레이터 플랫폼을 개발하였다.

본 연구에서는 리눅스 환경 하에서 다양한 시뮬레이터 시스템 구성 방법을 제공하

기 위해서, 방송모드와 T cp모드로의 통신방법을 구성하고 이의 성능을 분석하였다.

리눅스환경 하에서의 디스플레이 구현의 방법으로 OpenGL을 제시하였으며, 리눅스

자체의 시간함수를 이용한 실시간 구현방법, 리눅스 기반에서의 사운드 구현 가능성

을 제시하였다. 또한, 리눅스 운영체제의 특징중의 하나인 클러스터링 기법의 시뮬레

이터에의 적용 가능성을 제시하였다.

ABSTRACT

A simulator is a virtual reality machine which offers a chances to acquire

most of the current complex operation skills in dangerous missions .

Most of the current simulator platforms are based on Window s operating

system . But due to the complexity of using the Window s operating system

and the unavailability of the source code, there is a limit in using that . With

this, developed the simulator platform based on linux operating system

which has the merit of an open to public source and a easy communication .

T his research use multi- casting mode and T cp mode in communication to

offer a various simulator configuration and bench mark . Under a linux

environment show a Open GL use in display , a T ime functions use in

Real- time, some capability of playing sounds on linux operating system and

the possibility of application the clustering which is one of the features of

linux .

목 차

요 약

ABST RACT

목 차

그 림 목 차

표 목 차

1. 서론 1

2. 리눅스 운영체계 4

2.1 리눅스 시스템 4

2.2 커널의 구성 5

2.3 부팅 9

2.4 리눅스 개발 도구 11

2.4.1 C의 개발환경 11

2.5 리눅스 네트워크 12

3. 시뮬레이터 플랫폼 17

3.1 설계 요구 사항 17

3.2 시스템 구성 18

3.3 그래픽 시스템 21

3.4 사운드 시스템 24

3.5 입출력 시스템 26

3.6 통합 개발도구 27

3.6.1 diskless 개발 도구 28

3.6.2 각 Node마다 HDD가 있는 시스템 개발 도구 29

4. 시뮬레이터 소프트웨어 30

4.1 계산 흐름 30

4.2 프로그램 배분 및 데이터베이스 31

4.3 실시간 관리 31

5. 시제 개발 33

5.1 하드웨어 33

5.2 소프트웨어 35

5.2.1 운동방정식 35

5.2.2 데이터 베이스 및 실시간 관리 37

5.2.3 시뮬레이션 프로그램 38

5.3 성능평가 40

6. 결론 42

참고문헌 43

부록: 리눅스 운용체계의 함수 사용법 44

L i s t o f F ig u re s

그림 2- 1 커널 구조

그림 2- 2 소켓의 역할

그림 3- 1 시뮬레이터 시스템

그림 3- 2 그래픽 프로그램 순서도

그림 3- 3 I/ O port 프로그래밍 방법

그림 3- 4 시뮬레이터 플랫폼

그림 4- 1 계산 흐름

그림 5- 1 시제품 구성

그림 5- 2 시제품

그림 5- 3 공의 운동

그림 5- 4 시제프로그램 흐름도

L i s t o f T ab le s

표 3- 1 display mode

표 3- 2 사운드 변환 방법

표 5- 1 각 Node들의 사양

표 5- 2 데이터 크기에 따른 시간 변화(방송모드)

표 5- 3 데이터 크기에 따른 시간 변화(tcp모드)

표 5- 4 설계요구조건에 따른 성능 분석

1. 서론

시뮬레이터란 위험하거나 절차가 복잡한 조작방법을 숙지하는 가상현실 기기이다.

현재 항공분야에서 운용되는 시뮬레이터는 크게 두 분야로 나눌 수 있다. 항공기

설계시 공력 성능평가나 비행제어계통의 검증 등에 활용되는 엔지니어링 시뮬레이터

와 조종사들의 실제 비행훈련을 가상의 그래픽으로 대체 훈련하는 모의비행훈련 시

뮬레이터이다. 연구용 시뮬레이터는 크게 비행제어계통 개발 및 항공기의 조종성 평

가, 유도, 항법 및 무장계통의 제어장치 및 시현장치 개발 그리고, 조종사의 조종능력

및 조종 부하에 대한 인간공학 연구 등의 분야에서 사용되고 있다. 또한, 모의 비행

훈련용 비행 시뮬레이터는 조종훈련시 재현 불가능한 돌발상황에서의 훈련이나 이착

륙의 비행 기초훈련, 고도의 비행전술 연마 및 훈련비용 절감 등을 목적으로 사용되

고 있다.

시뮬레이터 구성은 용도와 성능수준에 따라 몇 가지의 방법이 있다. 첫 번째 방법

으로는 워크스테이션과 같은 고성능 장비를 사용하는 것이다. 이 경우 성능면에서는

월등하지만 워크스테이션의 대당 가격이 고가이다. 또한 한 대의 시뮬레이터가 제작

되기 위해서는 여러 대의 워크스테이션이 필요하고, 그로 인해 비용이 증가하기 때문

에 이는 연구용 시뮬레이터로 주로 사용되거나 고가의 고급 시뮬레이터에 적합하다.

두 번째로는 PC를 이용하는 방법이다. 예전에는 PC를 사용하여 시뮬레이터를 제작

할 경우 저가로는 제작할 수 있지만 실제 조종훈련용도로서의 성능이 부족하여 주로

일반 레저 오락용으로 많이 활용되었다. 하지만 근래에는 PC의 성능이 급속도로 향

상됨에 따라 PC기반의 시뮬레이터도 워크스테이션 기반의 시뮬레이터에 준하는 성

능을 기대할 수 있다.

- 1 -

기존의 PC기반 시뮬레이터의 경우 운영체제가 윈도우였다. 하지만, 윈도우 운영체

제 자체가 점점 복잡해지고, 크기가 커짐에 따라 이를 이용해서 시스템을 구성할 경

우, 실시간을 맞추기 어렵고, 시스템의 안정성이 보장되지 않는 등의 문제점들이 있

다.

본 논문에서는 리눅스를 이용하여 PC기반의 시뮬레이터의 플랫폼을 구성하는 방

법을 제시한다. 리눅스 환경은 개방적이기 때문에 개발자의 입장에서는 용이하게 개

발 할 수가 있다. 또한 시뮬레이터 자체가 여러 대의 PC로 구성되는 시스템이기 때

문에 통신에 강점을 가지고 있는 리눅스를 사용 할 경우 시스템 구성이 쉬워진다. 그

리고, 운영체제를 사용자의 용도에 따라 재컴파일 할 수 있으므로, 시스템의 크기 면

에서뿐만 아니라 시스템의 목적에 최적화된 운영체제를 만들 수 있다. 마지막으로 무

료로 배포되는 운영체제이므로 비용면에서도 강점을 가진다.

이러한 리눅스 운영체계를 기반으로한 학술적인 연구들은 병렬처리, 제어용 시스

템등에 주로 집중되고 있다. 리눅스 시스템을 사용한 병렬처리 기법은 국내외적으로

이미 활발하게 연구되고 있다. 미국 Los Alamos국립 연구소에서는 70개의 리눅스

박스로 구성된 Avalon Beowulf시스템을 직접 만들어 T op 500 Supercomputer

List에 315위로 등록되었다. 국내에서는 삼성종합기술원에서 알파CPU128개를 사용

하여 170.75 GFlops성능의 슈퍼 컴퓨터를 구성하였다. 제어용 시스템에서도 리눅스

운영체계를 사용해서 많은 시스템이 연구 개발중에 있다. 하지만, 리눅스 운영체계를

사용해서 시뮬레이터 시스템을 구축하려는 노력은 전무한 상태이다.

본 연구에서는 리눅스 운용체계에서 시뮬레이터 플랫폼이 구현되기 위해서 필요한

사운드, 그래픽, I/ O등에 대한 방법을 제시하였다. PC간의 통신은 소켓 인터페이스

를 사용하였으며, 이를 이용해 전체적인 시뮬레이터 플랫폼을 구축하였다. 또한, 구

축된 시뮬레이터 플랫폼에 시제를 탑 하여 성능 평가를 하여 가능성을 검증하였다.

본 논문은 제 2장에서 리눅스 운영체계에 대해서 언급하였고, 제 3장에서는 리눅

스 운영체계를 통하여 시뮬레이터 플랫폼을 구성하기 위한 설계요구사항을 설명한

- 2 -

다. 제 4장에서는 시뮬레이터 소프트웨어의 일반적인 구성요소를 설명하고, 제 5장에

서는 본 연구에서 예로써 구성한 시제 시뮬레이터 플랫폼을 설명한다. 그리고, 제 6

장에서 결론을 맺는다

- 3 -

2 . 리눅스 운영체계

2.1 리눅스 시스템

처음의 리눅스는 핀란드 대학생이었던 리누스 토발즈에 의해서 만들어진 PC하에

서 UNIX시스템과 비슷하게 돌아가도록 만든 운영체제(OS)이다. 리눅스(LINUX)란

이름도 리누스라는 개발자의 이름에서 나온 것이다.

1991년 10월에 리눅스 최초의 공식버전 0.02를 세상에 알리게 되었다. 그후 리눅

스에 대하여 관심있어한 유닉스 개발자들과 자발적인 프로그래머들이 이 소스를 수

정하고 자신의 기능을 추가하며 7년이 지난 현재 전세계 500만대 이상의 시스템에서

사용되고 있으며 32비트 유닉스 호환 운영체제로의 모습을 갖추게 되었다.

리눅스의 강점은 소스가 공개되어 있기 때문에 사용자의 능력과 요구에 따라 소스

를 고칠수 있다는 것이다. 또한 무료로 배포가 되기 때문에 운영체제에 대한 과비용

을 막을 수 있으며 강력한 네트웍 기능을 발휘해 윈도우 NT 의 대안으로 여겨지고

있다.

현재 리눅스라고 한다면 운영체제의 핵심 부분인 커널과 그외의 많은 공개 소프트

웨어와의 결합된 형태를 말한다. 일반적으로 배포본 형태로 나오는 것이 일반적이다.

배포본이란 리누스가 공개한 리눅스 커널에 각종 유틸리티와 응용프로그램을 추가해

서 시스템 구축을 용이하게 해주는 일종의 패키지를 말한다. 배포본의 경우 상업적인

것과 공개적인 것 두가지 형태가 있으며 이 두가지를 병행하는 것도 있다. 가장 많이

사용되는 배포본은 레드핫, 데비안, 슬렉웨어 등이 있다. 이 모두 FT P 사이트에서

무료로 받아서 설치할 수 있는 것들이다.

리눅스 시스템은 멀티 태스킹을 지원한다. 시스템에서 다양한 작업을 동시에 실행

할 수 있게 하는 멀티태스킹 기능은 GUI환경이 보편화되면서 운영체제의 기본 기능

이 되었다. 리눅스도 멀티태스킹은 완벽하게 지원된다. GUI환경은 물론 콘솔 환경에

서의 백그라운드 작업 처리가 용이하며, 한 프로세스가 무한 루프에 들어가거나 다운

- 4 -

되어도 그 프로세스만 죽으면 원상 복구되므로 안정된 환경에서 프로그램을 수행할

수 있다.

또한, 멀티유저 네트웍 환경이 잘 구축된 곳에서 멀티유저 운영체제는 서버라는 개

념을 구축할 수 있게 해주는 기본 기능이다. 심지어 리눅스에는 한 리눅스에는 한 시

스템에서 다른 사용자가 로그 아웃하지 않은 상태에서 다른 사용자가 로그인해 사용

할 수 있는 가상 콘솔 기능이 내장되어 있다.

GUI 환경 리눅스에서는 X윈도우를 사용한 GUI환경을 지원한다. X윈도우는

MIT 에서 개발한 그래픽 기반의 조작환경이며 소스 코드가 무료로 배포되고 있다.

MS 윈도우가 한 가지 윈도우 매니저만 제공하는 것과 달리 X윈도우에서는 twm이

라는 기본 윈도우 매니저를 비롯하여 mwm, dowm, fvwm, fvwm95, afterstep,

dtwm등 수많은 윈도우 매니저가 존재하며 취향에 맞취 선택, 사용할 수 있다. 또한

X윈도우의 강력한 기능 중에 하나는 네트웍에서 윈도우를 띄워 사용할 수 있다는 장

점이 있다. 클라이언트/ 서버 개념으로 리모트에 있는 시스템에 띄울 수도 있다. 소유

권만 허락되고 LAN으로 연결되어 있다면 자신의 시스템 A에서 시스템 B에 있는 X

윈도우 프로그램을 실행해 시스템 C의 모니터에 띄울 수 있다는 것이다.

다양한 파일 시스템 리눅스 표준 파일 시스템인 ext2fs를 비롯하여 VFAT ,

FAT 32, NFS, NT FS 등 거의 모든 파일 시스템을 지원한다

무료 배포 리눅스는 완전한 공개, 무료 소프트웨어이다. 리눅스를 구할 수만 있다

면 누구든지 무상으로 사용할 수 있다. 또한 커널이 공개되어 있기 때문에 누구든지

자신의 목적에 맞게 능력만 된다면 수정 개조 할 수 있다. 또한 대부분의 응용프로그

램들이 GPL 규약을 따르고 있어 자신의 원하는 프로그램을 무상으로 쓸 수 있다는

장점이 있다.

2.2 커널의 구성

UNIX계열의 운영체제는 커널(kernel)과 여러가지 시스템 프로그램(system

- 5 -

programs) 들로 이루어져 있는데, 여기에는 업무수행을 위한 몇 가지 응용 프로그램

(application programs) 들도 덧붙여져 있다. 이 중에서도, 특히 커널은 운영체제의

심장부라고 할 수 있는 부분이다. 커널은 파일들을 디스크에 적절히 배치시키거나,

프로그램을 시동시켜 작업을 수행하게 하고, 메모리와 같은 시스템의 자원

(resource)을 각각의 프로세스에 할당하며, 네트워크를 통해 패킷(packet )을 주고받

을 수 있게 해준다. 그러나 커널이 모든 일들을 혼자서 처리하는 것은 아니며, 실제

로 커널이 혼자서 처리하는 부분은 매우 적다. 대신에 커널은 기반 설비(tools )들을

제공함으로써 모든 작업을 가능하도록 하는데, 이 설비들을 통하지 않고서는 어떤 것

도 직접 하드웨어를 다루지 못하게 한다. 이런 방식으로, 하드웨어를 동시에 사용하

려는 각각의 사용자들이 서로 충돌하는 일을 막을 수 있다. 커널이 갖추고 있는 설비

들을 사용하는 일은 시스템 콜(system call)을 통해서 이루어진다.[1]

시스템 프로그램들은 운영체제를 위해 다양한 역할을 수행해 주어야 하는데, 이를

구현하기 위해 역시 커널의 기반 설비들을 사용한다. 이 상태를 사용자 모드(user

mode)라고 부른다. 사용자 모드에서 시스템 프로그램과 기타 프로그램은 결국 그 궁

극적인 역할에 차이가 있을 뿐이다. 즉, 사용자의 업무에 필요한 역할을 하도록 되어

있는 것이 응용 프로그램이라면, 시스템 프로그램은 시스템이 동작하는데 필요한 역

할을 하게 되어 있는 것이다.

리눅스 커널에는 몇가지 핵심적인 부분들이 있는데 그것은 프로세스 관리자

(process management ), 메모리 관리자(memory management ), 하드웨어 장치 드

라이버(hardware device drivers ), 파일시스템 드라이버(filesystem driver s), 네트

워크 관리자 (network management )등이며, 그 외에도 다양한 구성요소가 있다. 이

중 일부를 그림 2- 1 에 나타내었다.

아마도 커널에서 가장 중요한 구성요소는 메모리관리자와 프로세스 관리자일 것이

다. 메모리 관리자는 프로세스, 커널 일부분, 버퍼 캐쉬를 메모리 영역과 스왑 공간에

적절히 할당하는 역할을 한다. 프로세스 관리자는 새로운 프로세스를 생성하고 멀티

- 6 -

태스킹을 구현하는데, 멀티태스킹은 프로세서상의 프로세스를 계속 바꿔치기

(switching)하는 기법으로 이루어진다.

그림 2.1 커널 구조

커널의 가장 밑바탕은 갖가지 종류의 하드웨어 장치 드라이버들로 이루어진다. 하

드웨어는 그 종류가 워낙 다양해서, 하드웨어 장치 드라이버도 그 수가 무척 많다.

흔히, 비슷한 기능이면서도 소프트웨어에 의해 구동되는 방식이 다른 하드웨어가 많

은데, 이런 유사성은 비슷한 기능을 통틀어 구동시키는 일반적인 드라이버 클래스를

- 7 -

갖출 수 있게 해준다. 즉, 같은 클래스에 속하는 멤버 드라이버들은 자신을 제외한

커널의 나머지 부분에 대해선 같은 인터페이스를 갖는다. 그러나 각각의 드라이버들

이 기능을 실제로 구현하는 방법은 서로 다르다. 예로, 모든 디스크 드라이버들은 커

널의 나머지 부분에 대해 비슷한 인터페이스를 갖는데, 실제로 디스크 드라이버들은

"드라이브 초기화", "N번째 섹터 읽기", "N번째 섹터 쓰기"와 같은 조작방법을 모두

갖추고 있다.

커널이 독립적으로 제공하는 소프트웨어 서비스들 중에도 유사성을 가진 것들이

있어서, 역시 클래스란 것으로 추상화 될 수 있다. 예를 들자면, 수많은 네트웍 프로

토콜들은 BSD 소켓 라이브러리라는 하나의 프로그래밍 인터페이스로 추상화되어

왔다. 또 다른 예로, 가상 파일시스템 계층(virtual filesystem (VFS) layer ) 이란

것이 있는데, 이것은 파일시스템 조작방법을 실제 구현방법에서 떼어내 추상화한 것

이다. 파일시스템을 사용하려는 요청은 VFS에 전해지고, VFS는 요청에 알맞은 파

일시스템 드라이버를 골라 준다. 각각의 파일 시스템 드라이버는 그에 해당하는 파일

시스템 조작방법을 실제로 구현해 낸다.

유닉스와 마찬가지로, 리눅스에서도 시스템이 사용할 수 있는 구분된 파일 시스템

에 접근하는데 장치 식별자를 사용하지 않는다. 대신 파일 시스템 전체를 하나의 계

층적인 트리 구조로 연결하여 하나의 개체로 보여준다. 리눅스는 각각의 새로운 파일

시스템을 / mnt/ cdrom같은 마운트 디렉토리에 마운트하여, 파일 시스템 트리 구조에

추가한다. 예를 들면 CD- ROM을 / mnt/ cdrom으로 마운트하는 것이다. 이러한 방식

으로 리눅스는 여러 가지 파일 시스템을 지원할 수 있다. 리눅스에서 가장 많이 사용

하는 파일 시스템은 EXT 2 파일시스템으로, 대부분의 리눅스 배포판이 EXT 2를 지

원한다.

파일 시스템에 의해 사용자는 파일 시스템의 형태나 그 하부의 물리적인 장치의

특징에 상관없이 시스템의 하드디스크에 있는 파일이나 디렉토리를 인식할 수 있게

된다. 리눅스는 MS- DOS나 EXT 2 등의 많은 다른 파일 시스템을 투명하게 지원하

- 8 -

며, 마운트되어 있는 모든 파일과 파일 시스템을 하나의 통합된 가상 파일 시스템

(Virtual File System, VFS)으로 제공한다. 따라서, 사용자와 프로세스는 일반적으

로 어떤 파일이 무슨 파일 시스템에 속해 있는지 알 필요 없이 사용하기만 하면 된

다. [2]

2.3 부팅

모든 PC 시스템들은 롬(정확히는 BIOS)내의 코드를 실행시키는 것으로 부팅을

시작한다. 이 코드는 부트 드라이브의 섹터 0, 실린더 0 부분을 읽어들인다. 부트드라

이브는 보통 첫번째 드라이브(도스로 말하자면 A :, 리눅스로 말하자면 / dev/ fd0)를

지칭한다. 그 다음, 바이오스는 읽어들인 이 섹터의 내용을 실행한다. 대부분의 부트

가능한 디스크들은 섹터 0, 실린더 0 영역에 다음 내용 중 하나를 담고 있다.

LILO 등과 같은 부트로더(boot loader )의 코드, 즉 LILO 라는 부트로더는 커널을

찾아 메모리에 로드한 후 실행시키는 방식으로 부트를 시작한다.

만일 리눅스 커널이 디스켓에 직접 복사된 경우(raw copy )라면 디스크의 첫번째

섹터는 리눅스 커널 그 자체의 첫번째 섹터가 된다. 이 첫번째 섹터는 부트 디바이스

로부터 커널의 나머지 부분을 계속 읽어들임으로써 부트 프로세스를 진행한다.

일단 커널이 완전히 로드되면, 이제 기본적인 디바이스들을 초기화시키게된다. 그

다음, 특정 디바이스에서 루트 파일시스템을 찾아 루트에 마운트하려고 시도한다. 이

때 커널은 어디에서 루트 파일시스템을 찾아야 하는지를 미리 지정받아 알고있어야

만 한다. 만일 커널이 그 위치에서 로드 가능한 이미지를 찾지 못한다면 시스템은 멈

춰버린다.

어떤 부트방법은 (주로 디스켓에서 부팅하는 경우) 루트 파일시스템을 램디스크로

로드하기도 한다. 램디스크란 시스템의 RAM 의 일부를 마치 디스크처럼 취급하는

것이다. 시스템을 램디스크로 로드하는 것은 다음 두가지 장점이 있다. 첫째, 램은 플

- 9 -

로피디스크보다 수천배 이상 빠르기 때문에 시스템 구동이 빠르다. 둘째, 루트 파일

시스템을 압축시켜 플로피에 담은 경우, 커널은 이 압축을 풀면서 램디스크로 로드할

수 있다. 따라서 좀 더 많은 파일들을 디스켓 상에 압축시켜 둘 수 있는 장점이 있다.

일단 루트 파일시스템이 로드되어 마운트되면 다음과 같은 메시지를 볼 수 있을

것이다.

- VFS : Mounted root (ext2 filesystem) readonly .

이 시점에 이르면 시스템은 루트 파일시스템에 있는 init 프로그램을 찾아서 실행

시킨다. init 는 설정파일인 / etc/ inittab 에서 sysinit 라인을 찾아 그에 해당하는 이

름의 스크립트를 실행시킨다. 이 스크립트는 쉘 명령어로 짜여진 것으로서 아래와

같은 기본적인 시스템 서비스를 제공한다.

- 모든 디스크에 fsck 를 실행한다.

- 필요한 커널 모듈을 로드한다.

- 스왑핑(swapping)을 시작한다.

- 네트웍을 초기화시킨다.

- fstab 에 적힌 디스크들을 마운트한다.

이 스크립트는 대개 다른 여러가지 스크립트들을 또 동작시킨다. 즉, 초기화 과정

을 모듈화시킨 것이다. 예를 들면 일반적인 SysVinit 구조에서는 / etc/ rc.d/ 디렉토

리 밑에 복잡한 구조의 하위디렉토리가 있고 각각의 하위디렉토리에는 수많은 시스

템 서비스들을 어떻게 온오프 시키는지를 정해놓은 파일들이 있다. 하지만 부트디스

크에서 사용하는 sysinit 스크립트는 보통 매우 간단한 것이다.

sysinit 스크립트의 실행이 끝나면 다시 init 프로세스로 조종권이 돌아오고, 이번

에는 default runlevel 단계로 들어간다. default runlevel 은 inittab 파일내에

initdefault 키워드로 지정되어 있다. runlevel 라인은 주로 콘솔이나 tty 를 통한 통

신을 책임지는 getty 같은 프로그램을 지정한다. 우리에게 익숙한 ' ' login :' ' 프롬프

트 따위를 출력해 주는 것이 바로 getty 프로그램이다. 이제 getty 프로그램은 로그

- 10 -

인인증을 처리하는 login 프로그램을 구동시킨 후 user 세션을 마련한다.

리눅스는 운영체제는 네트워크를 통한 disk- less 부팅을 지원한다. disk- less부팅

방법은 네트워크를 통해 부팅 커널 이미지를 받아서 시스템을 부팅시키는 방법이다.

시뮬레이터 시스템에서는 운동방정식 계산 시스템과 화면 처리 시스템 같은 각 시

스템간의 연결에 이러한 네트워킹 부팅 방법을 일부 도입해 구성할 수 있다. 또한,

시뮬레이터호스트와 그래픽 부를 담당하는 시스템으로 구성된 간단한 시뮬레이터 시

스템의 경우에는 네트워크 부팅을 통한 disk- less시스템을 사용함으로써, 가격적인

면에서나 시스템 구성의 크기면에서 보다 효율적인 시스템을 구성할 수 있다.

2.4 리눅스 개발 도구

유닉스 자체가 C로 짜여 있기 때문에, 대부분의 유닉스 응용프로그램도 C로 짜여

져 있다. 하지만, 유닉스 프로그래밍에서 C만 사용하는 것은 아니고, 다음과 같은 많

은 프로그래밍 언어들을 지원한다. [3]

C C++ Objective C Fortran Pascal

sh (UNIX Bourne Shell) T cl/ T k Python Perl

Java PostScript HT ML SQL

이 중에서 본 연구에서는 C언어와 sh를 사용하여 개발하였다.

2.4.1 C의 개발환경

리눅스에서 사용하는 C 언어는 gcc이다. GNU 컴파일러 시스템의 핵심 운영 프

로그램인 gcc는 / usr/ bin 또는 / usr/ local/ bin에 있지만, 다른 위치에 있는 다양한

컴파일러 지원 프로그램을 수행 할 수 있다. C나 다른 언어로 프로그래밍을 하려면,

상수가 정의되어 있으며 시스템을 위한 라이브러리 함수 호출이 선언되어 있는 헤더

- 11 -

파일이 필요하다. C에서 필요한 대부분의 헤더파일은 / usr/ include/에 위치한다. 특

정 유닉스나 리눅스에 의존적인 헤더파일은 / usr/ include/ sys와 / usr/ include/ linux

에서 찾을 수 있다.

다른 프로그래밍 시스템에 필요한 헤더 파일은 보통 컴파일러가 자동으로 검색 가

능한 디렉토리에 저장되어 있다. 예를 들자면, X 윈도우의 헤더파일디렉토리는

/ usr/ include/ X11이며, GNU C++의 헤더파일 디렉토리는 / usr/ include/ g++이다.

하위 디렉토리나 표준이 아닌 디렉토리에 있는 헤더 파일은 C 컴파일러에 - I 옵션

을 사용한다.

C에서는 헤더파일 외에도 라이브러리 파일도 필요하게 된다. 라이브러리란 재사용

가능하게 작성된 함수들을 미리 컴파일하여 모아 놓은 것이며, 일반적으로 연관된 작

업을 수행하기 위한 함수들로 구성되어 있다.

표준 시스템 라이브러리는 보통 / lib와 / usr/ lib에 저장되어 있다. C컴파일러는 어

떤 라이브러리를 찾을 것인지 알려주기를 원하며, 기본적으로는 표준 C 라이브러리

만을 검색한다. 이 이외의 라이브러리는 - l 플래그를 사용하거나 또는 라이브러리의

전체 이름을 적어서 컴파일러가 라이브러리를 찾도록 알려주어야 한다.

라이브러리 이름은 항상 lib로 시작한다. 그리고, 각 부분별로 무슨 라이브러리인지

를 표시한다. 예를 들면, c는 C 라이브러리, m은 수학라이브러리를 표시한다. 마지막

부분은 . 으로 시작되는데, 이 뒷부분에서는 라이브러리의 형태를 지정한다. .a 는

전통적인 정적라이브러리를 나타내고, .so .sa는 공유라이브러리를 나타낸다.

C 프로그램은 vi나 emacs와 같은 리눅스 자체의 편집기를 사용하여 소스파일을

코딩 한 후에 gcc로 컴파일하여 사용한다.

2.5 리눅스 네트워크

리눅스 시스템에서 네트워킹은 서버-클라이언트 모델을 사용해서 구현할 수 있다.

서버-클라이언트는 PC, 워크스테이션등 주로 소형컴퓨터를 네트워크로 접속하여 데

- 12 -

이터를 분산 처리하는 시스템의 방식을 일컫는다. 서버는 데이터베이스와 프린터를

네트워크상에서 공유하기 위한 관리기능을 갖고, 클라이언트는 이 같은 기능을 사용

자가 이용하기 위한 단말기를 일컫는다. 일반적으로 서버에 워크스테이션, 클라이언

트 PC를 사용하는 경우가 많다. 하지만 최근 들어 성능이 날로 향상되고 있는 PC를

서버로 사용하는 예가 늘어나고 있다.

시뮬레이터의 시스템의 경우 Simulator Host에 Control Loading System,

Visual System, Sound/ Audio System, Input System 등 여러 시스템이 연결되어

있다. 따라서, PC기반에서 시뮬레이터 시스템을 구성하려할 경우에는 서버-클라이언

트 모델을 사용한다.

그림 2 - 2 소켓의 역할

리눅스 기반의 서버- 클라이언트의 통신에서 사용하는 통신 도구는 소켓 인터페이

스이다. 소켓은 하나의 지역적인 시스템이나 네트워크에 연결된 기계상에서 클라이

- 13 -

언트/서버 시스템을 개발할 수 있는 하나의 통신 메커니즘이다.

소켓이 만들어지면 서로 다른 방향으로 파이프를 통해 사용되는데, 그 이유는 서버

와 클라이언트간에 투명한 구별이 가능하기 때문이다. 소켓 메커니즘은 자연스럽게

하나의 서버에 여러 클라이언트를 접속하여 효율을 증대시킨다.

소켓은 도메인(domain), 형(type), 프로토콜(protocol)의 세가지 속성을 갖는다.

소켓은 또한 이름대용으로 하나의 주소(address )를 갖는다. 주소의 형식은 프로토콜

패밀리(protocol family )'라고 알려진 도메인(domain )'에 따라 다르다. 각각의 프로

토콜 패밀리는 주소 형식을 정의하기 위해 하나 이상의 주소패밀리를 사용할 수 있

다.

- 소켓 도메인

도메인은 본질적으로 소켓 통신이 사용하는 네트워킹 방법을 말한다. 대부분의 경

우에 소켓 도메인은 인터넷 네트워킹을 지칭하는 AF_INET 이 되는데, 이 도메인은

많은 유닉스 지역 네트워크와 인터넷상에서 사용된다. 기본이 되는 프로토콜인 인터

넷 프로토콜(Internet Protocol- IP )'은 단지 하나의 주소 패밀리를 가지며, 네트워크

상의 컴퓨터를 지칭하는 특별한 방법을 부여하는데 이것이 IP address이다.

인터넷상에 연결된 머신을 참조하는데 일반적으로 사용하는 이름은, 먼저 저 수준

IP 주소로 변환된다. 모든 IP 주소는 4개의 숫자로 표시하며, 각각의 숫자는 256보다

작다. 네트워크에서 소켓을 통해 연결될 때, 클라이언트는 서버 컴퓨터의 IP 주소를

알아야 할 필요성이 있다.

서버 컴퓨터에서 서비스를 할 수 있는 번호(포트)가 있을 것이다. 클라이언트는 네

트워크에 연결된 기계상의 IP 포트를 사용하여 특별한 서비스를 지칭할 수 있다. 포

트는 중복되지 않는 유일한 16비트 정수로 시스템 상에서 식별되며, IP어드레스와

포트 번호는 결합된다. 쌍방간에 통신을 하기 위해서는 포트를 지정하여야 하는데,

여기에서 소켓은 이 포트의 범위를 한정하여야 하는 통신에서의 마지막 지점이다.

서버는 보통 특정한 포트 상에서 접속 요청을 기다린다. 일반적으로 잘 알려진 서

- 14 -

비스들은 모든 유닉스 머신에서 사용되는 특정한 포트 번호를 할당받는다. 항상 그런

것은 아니지만 대부분의 경우에는 포트 번호는 1024보다 작다. 몇 가지 예를 들어보

면 프린터 스풀러(515), rlogin (513), ftp(21), httpd(80)등이 있다. httpd는 웹서버이

다. 보통 1024보다 작은 포트 번호는 시스템 서비스를 위해 예약되어 있으며, 슈퍼유

저 권한을 가지는 프로세스에 의해 사용될 것이다. X/ Open은 netdb .h에서

IPPORT _RESERVED를 정의하는데 이것은 예약된 최상위 포트 번호를 지정한다.

표준화된 서비스를 제공하기 위한 표준 포트 번호 집합이 이미 선택되어져 있기 때

문에, 컴퓨터는 서로 상대방의 시스템에 명확한 포트를 지정하지 않고서도 연결할 수

있다. 로컬 서비스는 비표준 포트 주소를 사용할 것이다.

다른 도메인으로는 AF_ISO와 AF_NS가 있는데, AF_ISO는 ISO 표준 프로토콜

에 기반한 네트워크이고 AF_NS는 제록스 네트워크 시스템을 말한다.

- 소켓 형

소켓 도메인은 서로 다른 통신 방법을 가질 수 있는데, 이들 각각은 쌍방간에 독특

한 특징을 가지고 있다. 소켓의 형(type)은 믿을만한 양방향 통신을 제공하는

AF_UNIX도메인 소켓 같은 것을 말하는 것은 아니다. 그러나 네트워크 도메인에서

네트워크의 기본적인 특색에 주의해야 할 필요성이 있다.

인터넷 프로토콜은 두 가지의 서로 다른 서비스 계층을 제공한다. streams '와

datagrams '가 그것이다.

스트림(streams)은 표준 입출력 스트림과 유사하며, 연속적이며 믿을만한 쌍방향

바이트 스트림을 제공한다. 이 말의 뜻은 전송되는 데이터는 잃어버리지 않으며, 에

러 발생에 상관없이 복사되거나 정돈될 수 있다. 용량이 큰 메시지는 작은 블록으로

쪼개어서 전송하며 이후에 다시 조립된다. 큰 용량은 데이터를 받아들이고, 저 수준

의 디스크에서 작은 블록에 쓰여진 데이터들을 정돈한다는 면에서 파일 스트림과 비

슷하다. 스트림 소켓은 행동양식을 예측할 수 있다.

스트림 소켓은 SOCKET _ST REAM으로 표시되며, T CP/ IP 연결의 AF_INET

- 15 -

도메인에서 사용된다. 물론 AF_UNIX 도메인에서도 이런 방법을 사용할 수 있다.

이 장에서는 네트워크 프로그래밍에서 공통적으로 한번 이상 사용되는

SOCK_ST REAM을 사용할 것이다.

이와는 대조적으로 데이터그램(datagram) 소켓은 SOCK_DGRAM으로 표시되

며, 접속을 보증하지도 않으며 신뢰성도 떨어진다. 또한 데이터그램에서는 한번에 보

낼 수 있는 크기에도 제한이 있으며, 잃어버리거나 복사될 수도 있는 단일 네트워크

메시지로 전송된다.

데이터그램 소켓은 UDP/ IP 접속에서 AF_INET 도메인상에서 사용되며 비 순차

화를 제공하며 서비스를 신뢰하기는 힘들다. 그러나 네트워크 연결을 유지할 필요성

이 없다는 점에서 자원을 비교적 많이 사용하지는 않는다. 데이터 그램 소켓은 접속

에 필요한 설정시간이 필요 없다는 점에서 속도가 빠르다.

데이터그램은 정보서비스를 받기 위한 일회성의 요청이나, 정규적인 상태 정보를

제공하거나 낮은 순위 로그인을 수행하는데 유용하다. 서버가 다운되었다 하더라도

클라이언트를 재시작 할 필요성이 없다는 장점이 있다.

- 소켓 프로토콜

기본적인 전송 메커니즘이 요청된 소켓형을 제공하기 위해 하나 이상의 프로토콜

을 허용한다면, 해당 소켓상에서 특정한 프로토콜을 선택할 수 있다. 유닉스 네트워

크와 파일 시스템 소켓을 사용할 것이기 때문에 특별히 프로토콜을 선택할 필요는

없다. [3 ]

- 16 -

3 . 시뮬레이터 플랫폼

3.1 설계 요구 사항

시뮬레이터 플랫폼은 다음과 같은 환경을 고려해야 한다.

case 1) 한 대의 컴퓨터로 구성되는 경우

case 2) 시뮬레이션 호스트에서 시뮬레이션 루프를 관리하고, 각각의 모듈별로 기

능을 구현하는 경우

case 3) 각 시뮬레이터 그룹별로 통신하는 경우.

case 1)의 경우는 모든 시뮬레이터 시스템이 컴퓨터 한 대로 구성이 되는 경우이

다. 이 경우는 운동방정식과 그래픽 구현, 사운드 출력등을 포함한 시뮬레이션 루프

가 한 대의 PC에서 모두 구현되어야 한다. 따라서, 간단한 시뮬레이터 시스템을 구

현하는데 적합하다. case 2)의 경우는 전체 시뮬레이터 시스템이 여러 대의 컴퓨터

로 구성되는 경우이다. 대부분의 경우 시뮬레이터 시스템의 각 모듈이 하나의 컴퓨터

로 구성되고, 구성된 각 컴퓨터들이 통신으로 연결되어 하나의 시뮬레이터 시스템으

로 완성된다. case 3)의 경우는 Distributed Interactive Simulation (DIS) 시스템을

구성할 경우에 필요하다. DIS란 근거리 또는 원거리에 있는 독립된 시뮬레이터들이

하나의 프레임웍 안에서 상호 연관되어 운용되는 방식으로 훈련효과를 크게 증가시

킬 수 있는 시스템이다. [4]

실시간이 구현되기 위해서는 초당 30프레임 이상이 요구된다. 이를 위해서는 한번

의 시뮬레이션 루프가 33ms이내에 구현되어야 한다. 보통 25%정도의 시간의 여유

를 둔다는 것을 감안한다면, 25ms안에 한 번의 시뮬레이션 루프가 돌아야 한다. 시

뮬레이션 루프는 여러 대의 시스템으로 구성될 경우 조종입력 - > 운동방정식 계산

- > 데이터 통신의 순서로, 한 대의 시스템으로 구성되어 있을 경우 조종입력 - > 운

동방정식계산 - > 그래픽 및 사운드구현의 순서로 돌아가게 된다. 그리고, 여분의

25%의 시간동안 실시간 관리를 하게된다.

- 17 -

또한, 시뮬레이션 시스템에 운동장치나 비행 운동판등을 부착할 수 있는 확장성이

요구된다.

3.2 시스템 구성

일반적인 시뮬레이터 시스템의 경우 그림 3.1과 같이 구성된다.

그림 3.1 시뮬레이터 시스템

입력신호가 Instructor ' s Control을 통해 들어가면, Interface card를 통해

simulation host computer로 들어간다. 그러면, 주어진 조종 입력신호에 대해 운동

- 18 -

방정식을 풀어 Simulator에서 원하는 결과 값들을 도출해 낸다. 이 결과 값들이

Visual System등으로 들어가서 적절한 화면을 출력하게되고, 이에 맞추어 각 모듈

에서 음향효과나 특수효과들을 출력한다. 각 모듈 별로 담당하는 기능은 다음과 같

다. [5]

- 시뮬레이션 호스트(Simulation Host )

시뮬레이터의 전체 시스템을 관리하며, 운동방정식 계산, 비행 평가등을 담당하는

부분으로써, 컴퓨터 한 대로 구성되거나 여러 대로 분할하여 구성할 수 있다.

- 인터페이스(Interface)

인터페이스장치를 통한 신호는 두 가지이다. A/ D와 D/ A를 거치는 입출력 신호와

디지털 입출력 신호이다. 센서에서 들어오는 신호는 아날로그 전기신호로써 인터페

이스 부분의 A/ D를 거쳐 컴퓨터로 입력된다. 컴퓨터는 이 값을 운동방정식에서 조

종 입력값으로 사용한다. 각종 스위치로부터 들어오는 값은 0∼5V의 ON, OFF 디

지털 값으로써 컴퓨터로 입력된다. 가변의 아날로그 전기신호를 필요로 하는 액츄에

이터나 계기구동을 위해 인터페이스장치는 컴퓨터로부터 출력 값을 디지털 값으로

넘겨받아 D/ A변환기를 이용하여 아날로그신호로 변환시킨다. 램프, 경고음 발생 등

에 필요로 하는 ON_OFF 값을 컴퓨터로 받아 출력한다.

- 운동장치(Motion System)

시뮬레이터의 운동을 담당하는 부분으로서 플랫폼과 이를 제어하는 컴퓨터부분으

로 구성된다. 컴퓨터의 운동방정식에서 자세 및 각속도 정보를 넘겨받아 플랫폼의 운

동을 제어하게 된다.

- 영상장치(Visual System )

- 19 -

컴퓨터로부터 관측자의 자세, 위치정보를 받아 3차원 그래픽스 알고리즘을 계산,

영상을 디스플레이 장치에 출력하는 부분으로서 영상을 갖춘 비행시뮬레이터에서 가

장 핵심적인 부분이다.

- 조종하중장치(Control Loading System)

조종사에게 실제와 같은 조종의 느낌을 줄 수 있도록 조종 면에 조종하중을 만들

어 주는 부분으로써 액츄에이터가 포함되며 하중에 대한 해석이 필요하다.

- 교관영상(Instruction ' s Display)

조종사의 비행훈련을 모두 관찰할 수 있고 필요한 명령을 주며 비행훈련을 평가할

수 있도록 상황을 디스플레이 해준다.

- 음향장치(Sound/ Audio System)

비행훈련시 조종사에게 실제감을 높이기 위해 비행기의 엔진소리나 경고음, 타이

어 마찰음 등과 같은 음향효과를 만들어 준다.

- 특수효과(Special Effects )

실제감을 주기 위한 방법으로서 고도의 변화를 느낄 수 있도록 조종석에 압력을

가하거나 안개 등을 만들어 준다.

- 계기장치(Simulator Equipment )

실제와 같이 계기를 만들어 조종사의 계기훈련을 할 수 있도록 한다.

- 교관입력(Instructor ' s Control)

교관이 조종사의 비행훈련에 필요한 입력을 할 수 있도록 하는 부분이다.

- 20 -

리눅스운용체계에서 이러한 시뮬레이터를 구성하려면, 디스플레이 부분을 담당할

그래픽 시스템과 음향 장치를 담당할 사운드 시스템이 리눅스 환경 하에서 구동이

되도록 하여야한다. 그 외의 장치들은 주로 하드웨어적인 구성이므로 리눅스 환경하

에서 담당컴퓨터들과 I/ O인터페이스가 이루어져야 한다.

프로그램상의 문제는 리눅스 운영체제가 ANSI C를 지원하기 때문에 이 규약에

따라 코딩을 한다.

또한, 네트워크 부팅 개념을 적용하면 호스트 컴퓨터를 제외한 나머지 시스템의 경

우에는 메인보드와 랜카드, 그래픽 카드만을 갖춘 영상장치처럼 각 시스템에 필요한

장치만을 갖춘 형태로 구성할 수 있다. 이와 같이 시뮬레이터 시스템을 구축함에 있

어서 각각의 하위 시스템을 완전한 컴퓨터 세팅을 갖춘 시스템 개념으로 구축하지

않고, 필요한 기능만을 할 수 있게 만드는 장치 개념으로 구성할 수 있기 때문에, 시

뮬레이터 시스템의 목적에 최적화되게 구성할 수 있다.

3.3 그래픽 시스템

리눅스 운영체계에서의 그래픽 시스템은 Open GL을 사용하면 효과적으로 구현할

수 있다. Open GL은 MS Windows 환경뿐만 아니라 Mac, unix 그리고, Sun

workstation 등 다양한 플랫폼에서 개발이 가능하다. 단지, 각 플랫폼마다 Open GL

함수들과의 인터페이스가 다를 뿐이다. 즉, 3D 그래픽을 구현한다면, 이 구현 함수

자체는 X- Windows에서나 MS- Window s에서나 동일하다. 따라서, 다양한 플랫폼

에서 응용 프로그램을 개발할 수 있으며, 서로 다른 플랫폼으로의 변환이 용이하다.

[6 ]

OpenGL이란 3차원 그래픽 라이브러리이다. 컴퓨터 그래픽 분야에서 유명한 실리

콘 그래픽스(Sillicon Graphics)가 워크스테이션에서 사용하던 IRIS GL을 플랫폼이

나 운영체계와 관계없이 사용할 수 있도록 여러 회사들과 컨소시엄을 구성하여 만

- 2 1 -

그림 3- 2 그래픽 프로그램 순서도

든 그래픽 라이브러리이다. 처음에는 그래픽 기능을 중시한 워크스테이션을 제작할

때 IRIS GL이라는 획기적이고 막강한 라이브러리를 만들었다. 그러나 실리콘 그래

픽스는 여기서 멈추지 않고 사용하기 쉬운 여러 가지 그래픽 툴들을 만들어 나갔다.

OpenGL은 표준이 결정되면서 많은 업체들에 의해 여러 가지 기종으로 포팅되기 시

작하였다. 현재는 SUN, RS6000, 윈도 NT , 윈도 95등에서 사용할 수 있다.

OpenGL의 각 기종별 포팅은 윈도 NT의 경우는 마이크로소프트에서, 나머지는 템

플릿 그래픽스 소프트웨어(T emplate Graphics Software)에서 진행하고 있다. [7 ]

- 22 -

GL 함수들 자체는 플랫폼에 대해 독립적이므로, 플랫폼에 관계없이 일정하게 사

용한다. 따라서, GL함수와 플랫폼들과의 인터페이스 역할을 해주는 함수들이 필요한

데 이 역할을 하는 함수들이 GLUT이다.

이와 같은 함수들을 사용해서 리눅스 기반에서 Open GL을 구현하려면 그림 3- 2

의 순서에 따라 프로그래밍을 한다. [8]

화면에 그려지는 그림들은 display ()함수안에 위치하게 되고, 이 display 함수를

glutDisplayFunc()함수를 통해 callback으로 호출된다.

Open GL 프로그램은 message processing 프로그램이므로 glutMainLoop함수

를 사용해서 루프를 돌려주어야 한다. 그리고, 화면이 갱신 될 때마다

glutDisplayFunc() 함수가 display 함수안의 내용대로 화면을 갱신시킨다.

표 3.1 display mode

모드 내용

GLUT _RGBA 색상을 RGBA모드로 설정한다. 기본값GLUT _RGB RGBA모드와 동일

GLUT _INDEX 색을 색상표모드로 설정GLUT _SINGLE 단일 버퍼모드로 설정. 기본값

GLUT _DOUBLE 이중 버퍼모드로 설정GLUT _ACCUM 누적 버퍼모드로 설정

GLUT _ALPHA 색상 버퍼에서 알파 효과 적용GLUT _DEPT H 깊이 버퍼 적용

GLUT _ST ENCIL 스텐실 버퍼 적용GLUT _MULT ISAMPLE multisample기능 지원

GLUT _ST EREO stereo window 효과 적용

GLUT _LUMINANCE휘도 색상모델 적용된 stereo

window 효과 적용

생성되는 창의 위치와 창의 크기는 각각 glutInitWindowPosition (), glutInit

WindowSize() 함수를 사용해서 설정한다. 이 함수들을 사용해서 창의 위치와 크

기를 설정한 후에 glutCreateWindow () 함수를 사용하여 창을 생성시킨다.

- 23 -

이때의 display 모드의 설정값은 표 3.1과 같다.[9]

3.4 사운드 시스템

소리는 아날로그(analog )인 반면에 컴퓨터는 디지털(digital) 이다. 따라서, 사운드

카드는 Analog to Digital Converter (A/ D 또는 ADC) 이라고 하는 장치를 사용

하여 컴퓨터에서 사운드를 다룰 수 있다. 이것이 하는 역할은 아날로그인 소리(정확

하게는 그에 해당하는 전압)를 메모리에 저장할 수 있는 디지털 또는 수치 값으로 변

환시키는 것이다. 비슷하게, Digital to Analog Converter (D/ A 또는 DAC)는 수

치 값을 아날로그 전압으로 바꾸어 주며 우리는 이를 스피커를 통하여 들을 수 있는

것이다.

이 때 샘플링(sampling)이라고 알려져 있는 아날로그를 디지털로 변환시키는 과

정은 약간의 에러를 수반한다. 샘플링된 신호가 원음에 얼마나 가까운가를 결정짓는

두 가지 요소가 있다. 그 첫 번째는 샘플링 속도(Sampling rate) 이며 단위 시간당

얻어진 샘플의 갯수를 나타낸다(일반적으로 samples per second 또는 Hertz로써

표시한다). 샘플링 속도가 낮으면 원음을 정확하게 나타내기 어렵다. 두 번째는 샘플

크기 (sample size) 이며 하나의 샘플을 표현하기 위해 사용되는 값의 범위를 의미

한다. 일반적으로 비트 (bits )로서 표시한다. 샘플 크기가 크면 클수록 디지털 신호는

더 정확해질 것이다.

사운드 카드는 대개 8 또는 16 비트의 샘플 크기와 4000 에서 44000 Hertz 사이

의 샘플링 속도를 사용한다. 샘플은 하나의 채널(mono) 또는 두개의 채널(stereo)을

포함할 수 있다.

사운드를 컴퓨터가 인식할 수 있는 파일로 변환하는데는 여러 가지 방법이 있는데,

표 3- 2와 같은 방법들이 있다. [10 ]

- 24 -

표 3- 2 사운드변환 방법

파일 변환방식 특징

FM Synthesis

소리를 만들어 내는 좀 오래된 기술. 이 기술은 여러

가지 파형(sine, triangle, square 등)을 결합하는데 그

바탕을 두고 있다. FM synthesis는 D/ A 변환에 비해

하드웨어적인 측면에서는 간단 하지만 프로그래밍 하기

가 어렵고 유연성이 떨어진다.

Wavetable

Synthesis

D/ A 변환의 유연성과 FM synthesis의 다중 채널

(multiple channel) 기능을 결합한 것이다. 이 기술을 이

용하면 CPU에 부담을 적게 주면서 동시에 디지털화된

목소리(voice)를 메모리에 저장하여 재생하거나 또는 수

정할 수 있다.

MIDI

Musical Instrument Digital Interface의 약자이다. 전자

악기를 외부에서 제어하기 위한 하드웨어 및 소프트웨

어의 표준 프로토콜이다. 전자오르간의 건반을 누르는

등과 같은 어떤 사건은 MIDI 버스(bus)를 통하여 전달

되며 MIDI 파일로 저장하여 다시 편집하거나 재생할

수 있다.

MOD

컴퓨터 음악을 위한 공통의 파일 형식이다. 연주될 음

표에 대한 정보뿐만 아니라 악기 (또는 목소리)로부터

얻어진 디지털 샘플까지도 담을 수 있다. MOD 파일은

Amiga computer로 부터 유래되었지만 적당한 소프트

웨어만 있으면 리눅스를 포함한 여타 시스템에서도 연

주될 수 있다.

리눅스에서 사운드를 구동하는 방법은 리눅스 파일 시스템에서 사운드카드 포트인

/ dev/ dsp 포트에 간단하게 ioctl() 함수를 사용하여 이미 만들어져 있는 wav파일 포

맷의 소리 함수를 출력하는 방법으로 구현한다.

- 25 -

3.5 입출력 시스템

I/ O를 읽고 쓰기 위한 루틴은 / usr/ include/ asm/ io.h에 있다.

어떤 포트를 읽고 쓰기 전에, 반드시 프로그램에 해당하는 권한을 주어야 한다. 이

권한을 주는 함수가 ioperm ()이다. 이 함수의 사용 방법은 부록에 첨부하였다.

ioperm () 호출은 프로그램이 루트 권한을 가지고 있기를 요구한다. 따라서 프로

그램을 루트 사용자로써 실행하거나 setuid함수로 해결한다.

그림 3- 3 I/ O port 프로그래밍 방

법

포트를 실제로 읽고 쓰는데 사용하는 입출력 함수는 inb ()와 outb ()이다. 이 함수

는 다음과 같은 역할을 한다.

- inb (port )

=> port에서 한 바이트를 입력 받는다.

- outb (value,port )

=> port에 value값을 출력한다.

I/ O 프로그래밍 방법을 정리하면 그림 3- 3과 같다. [11]

3.6 통합 개발도구

- 26 -

PC를 여러 대 연결하여 시뮬레이터 플랫폼을 구성한다. 각 컴퓨터는 편의상 Node

라는 개념으로 구분한다. 시뮬레이션 호스트의 경우에는 항상 Node1 이라고 정의한

다.

데이터의 양이 적을 경우에는 각 노드들은 diskless로도 구성할 수 있다.

그림3- 4 시뮬레이터 플랫폼

시뮬레이션 시스템은 HDD가 있는 경우와 없는 경우 동일하게 그림 3- 4와 같이

구성된다. 하나의 시뮬레이션 Host에 각각의 역할을 하는 독립적인 장치들이

network를 통해서 연결되어있다.

- 27 -

3.6.1 diskless 개발 도구

diskless 개발 도구로서의 시스템에서는 Node1의 HDD 일부를 다른 Node들이

NFS mount를 하여 사용한다. 각 Node에서 mount한 Simulation Host의 HDD 영

역은 각 Node의 HDD로 인식되어 사용된다. 따라서, network booting 과 NFS

mount의 설정을 마친후에는 HDD가 있는 시스템과 동일하게 사용한다.

이 diskless 시스템의 세팅은 다음과 같은 방법으로 한다.

ⅰ) Node1에 linux를 설치한다.

ⅱ) 나머지 Node들의 network booting을 위한 booting image를 만든다.

=> BOOT P support , RARP support , NFS에 관련된 옵션모두를 포함해서 커

널을 다시 컴파일을 한 후에, 이 이미지를 가지고 부팅 디스켓을 만든다.

ⅲ) Node1의 HDD안에 나머지 Node를 위한 영역을 만든다.

=> Node1내의 공유되어 있는 HDD의 영역을 각 Node의 입장에서는 자신의

HDD라고 인식하므로, 각 영역들에는 각 Node를 위한 시스템 파일들이 모두

존재해야한다. 일반적으로 필요한 파일들은 모두 복사를 하고, 공통적인 시스

템 파일들은 공유를 해서 사용한다.

ⅳ) 각 Node들의 랜카드 하드웨어주소와 ip주소를 일치시킨다.

=> 각 Node에는 HDD가 없기 때문에, 랜카드도 인식되어 있지 않은 상태이다.

하지만, network booting시에는 랜카드를 통해서 Node1의 booting file들이

각 노드에 전달되어야 하기 때문에 각 노드의 랜카드에 대한 정보는 미리 설

정되어 있어야 한다. / sbin/ rarp를 사용하여 ip주소와 랜카드 하드웨어 주소

를 일치시킨다.

ⅴ) network booting을 위해 필요한 파일들을 세팅한다.

=> nfs mount를 통해 파일을 공유해서 사용하려면, 공유하려는 디렉토리는

- 28 -

/ etc/ export s 파일 안에서 지정을 해준다. 실제로 부팅시에 export s 파일에서

공유시켜준 파일들을 마운트 시키는 파일은 / etc/ fstab과 / etc/ mtab이다. 이외

에도, ip주소와 각 Node의 이름들을 일치시키는 / etc/ hosts 파일등을 세팅해

준다.

3.6.2 각 Node마다 HDD가 있는 시스템 개발 도구

보내주어야 할 데이터의 양이 많을 경우에는 용량 면에서 각 Node마다 HDD가

있는 것이 유리하다.

이 경우에는 각 노드에 리눅스를 개별적으로 설치 한 후에, 각각을 네트워크를 통

해 연결하면 된다. 네트워크는 / etc/ hosts 파일을 편집하여, ip주소와 각 노드의 이름

을 일치시킴으로써 연결된다.

그리고, 각 노드들간의 파일의 원활한 교환을 위해서, / home/ work/ share 디렉토

리를 만들어서 NFS 공유를 시킨다. 이는 / etc/ exports 파일 안에서 공유할 디렉토

리를 편집하여 사용한다.

- 29 -

4 . 시뮬레이터 소프트웨어

4.1 계산 흐름

그림 4- 1 계산 흐름

- 30 -

시뮬레이션 루프는 시뮬레이터 호스트에서 돌아간다. 먼저 시뮬레이션에서 쓰이는

변수들을 정의하고, 초기화시킨 후에 조종 입력을 받는다. 만약 하드웨어와 인터페이

스가 되어있는 경우에는 I/ O 보드를 통해서 입력을 받는다. 입력받은 조종 입력값을

가지고 운동방정식을 푼 후에, 결과 값을 통신을 통해 다른 노드로 보낸다. 그 후에,

시뮬레이션 시간을 계산하여 실시간 관리를 한 후에 시뮬레이션을 계속 수행한다. 결

과 값들은 주로 자세나 위치에 관한 데이터들이다. 데이터 값들을 받은 노드들은 받

은 데이터 값들을 가지고 각 노드의 역할을 수행하게 된다. 예를 들어, 그래픽 구동

부의 경우에는 받은 위치나 자세데이터를 가지고 시뮬레이션 물체의 위치와 자세를

디스플레이하고, 운동판 구동부의 경우에도 마찬가지 원리로 운동판의 위치나 자세

를 구동하게 된다.

4.2 프로그램 배분 및 데이터베이스

시뮬레이션 호스트에서는 시뮬레이션 메인 루프가 돌아가고, 매 루프마다 시뮬레

이션이 필요로 하는 데이터가 계산되어 나온다. 이 데이터는 방송모드를 통해서 호스

트에서 뿌려지고, 각 노드에서 필요로 할 때마다 이 방송에 접속해서 그때 방송되는

데이터를 수신해 간다. 시뮬레이션 호스트에서 보내는 데이터는 배열 형태로 보내지

고, 보내는 데이터의 양이 커짐에 따라 배열의 크기도 조절된다. 배열에서 각 원소가

의미하는 데이터는 미리 정해 놓은 규약에 따라 일정하게 한다.

따라서, 이렇게 정해진 규약에 따라서 데이터를 배열로 저장하고, 방송 모드로 보

내지면, 각 노드들은 이 데이터 배열 전체를 받은 후에 필요로 하는 데이터들만 택해

서 사용한다.

4.3 실시간 관리

- 3 1 -

시뮬레이터가 현실감 있게 구동되려면, 실시간 관리가 필수적으로 되어야 한다. 사

람이 시각적으로 화면이 끊기지 않고 부드럽게 연속적으로 보인다고 느끼는 초당 프

레임수가 30이상이다. 따라서, 프레임을 1초에 30번 이상을 화면에 출력해주려면, 시

뮬레이션 속도가 1/ 30초, 즉 33.3ms 이내에 한 번의 시뮬레이션 루프가 돌아야 한다.

그리고, 이에 25%정도의 시간 여유분을 준다면, 실제로 시뮬레이션 루프가 도는데는

약 25ms의 시간이 할당된다. 리눅스에서 이러한 실시간 조절을 위해서

gettimeofday ()함수와 usleep()함수를 사용한다.

gettimeofday ()함수는 시뮬레이션 루프가 돌아가는데 걸리는 시간을 측정할 때

사용되고, usleep()함수는 실시간 조절을 위해 프로세스를 delay시키는 함수이다. 각

함수의 사용법은 부록에 첨부하였다.

실시간 관리를 하려면 시뮬레이션 루프가 시작 할 때의 시간과 시뮬레이션 루프

가 끝날때의 시간을 gettimeofday () 함수로 읽어들인 다음에, 그 시간의 차이를 계

산하여 시뮬레이션 루프가 도는데 걸리는 시간을 계산하고, 그 시간이 33.3ms보다

작을때는 33.3ms까지 delay시킨다.

마찬가지로 디스플레이부도 실시간 관리를 하여야 하는데, 이 경우에는 남는 시간

이나 모자라는 시간을 usleep 함수가 아닌 화면의 세밀도를 조정하여 시간 관리를

할 수 있다.

- 32 -

5 . 시제 개발

5.1 하드웨어

시제품의 하드웨어는 Pentium PC 4대를 사용해서 구성하였다. 한 대는

simuation Host, 다른 세 대는 디스플레이를 담당하도록 설계하였다. 각 PC의 사양

은 표 5- 1과 같다.

그림 5- 1 시제품 구성

- 33 -

표 5- 1 각 Node들의 사양

CPU RAM graphic card HDD Sound Card

Node1 PⅢ- 500 128Mvoodoo

Banshee2000

20GB

(maxtor )

Sound Blaster

128Node2 PⅢ- 500 128M voodoo3- 2000 8GB (IBM ) 없음

Node3 PⅢ- 500 128M voodoo3- 200010GB

(maxtor )없음

Node4 PⅢ- 500 128M voodoo3- 200010GB

(maxtor )없음

각 Node의 운영체제는 Alzza Linux 6.0을 사용하였고, 이 운영체제 하에서는 각

Node의 장치들이 voodoo Banshee 2000을 제외하고는 별 문제없이 원활하게 작동

한다. voodoo Banshee 2000은 3D 가속기능을 제대로 발휘하지 못한다. 따라서,

그래픽 구현을 하지 않는 Node1에 voodoo Banshee 2000을 장착하였다. 각 Node

들은 PCI 방식의 realtek 랜카드를 사용하였으며, 허브는 5 포트 더미허브와 8포트

스위칭 허브 두 종류에 대해서 사용하였는데, 스위칭 허브가 더미 허브에 비해 속도

나 성능 면에서 월등한 결과를 가져 왔다. 더미 허브의 경우에는 속도 면에서 뿐만이

아니라, 성능 면에서도 시간이 오래 지나면 소켓이 자주 끊기는 현상이 발견되었다.

그림 5- 2 시제품

- 34 -

5.2 소프트웨어

리눅스 기반의 시뮬레이터의 플랫폼을 테스트하기 위해, 전체적인 시뮬레이션 프

로그램을 모듈별로 설계하였고, 이 위에 간단한 공의 운동을 표현하는 운동방정식을

얹어서 테스트하였다.

5.2.1 운동방정식

공의 운동은 수평방향으로 F의 힘을 가했을 때 마찰과 공기저항이 없는 상태의 운

동이다.

그림 5- 3 공의 운동

운동방정식은 수평 방향과 수직 방향으로 나누어서 생각 할 수 있다. 수평 방향을

x, 수직 방향을 y라 하자.

- 수평방향의 운동방정식

초기에 공은 x 방향으로 F의 힘을 준다. 공기의 저항이나 마찰이 없으므로, F =ma

로부터 가속도와 속도를 구할 수 있다.

a = Fm

- 35 -

V = Fm

t

이므로, 수평 위치 x는

x = F2m

t2

이 된다.

공이 벽에 부딪힌 후의 속도는 공이 벽에 부딪힐 때의 속도를 V 0라 하면,

V = V 0 + Fm

t

가 된다. 이에 따른 위치는

x = V 0 t + F2m

t2

가 된다.

- 수직 방향의 운동방정식

y 방향으로는 어떠한 힘도 가해지지 않으므로, 자유낙하를 한다고 생각하면 된다.

여기서는 에너지의 개념을 도입해서, 어느 위치에서나 운동에너지 즉, 위치에너지와

운동에너지의 합은 일정하다고 하면 초기 위치 H라 할 때,

E = mg H = m g h + 12 m v2

이 된다.

그런데, 작용하는 가속도는 중력가속도 뿐이므로

a = g

v = g t이다.

따라서,

h = H - 12g

v 2 = H - 12g

(g t) 2 이 된다.

공이 바닥에서 튀어 올라갈 때는, 바닥에서 튀는 지점에서의 속도를 V라 하면,

- 36 -

m gH = 12

m V 2 = 12

m v 2 + m g h

이다.

그런데,

V = g T

이고, 상승속도 v는 중력가속도가 가속도의 반대 방향으로 작용하므로,

v = ( V - g t)

가 된다.

이를 정리하면, 바닥에서 튀어 올라갈 때의 시간에 따른 수직방향 위치는

h =( 1

2V 2 - 1

2( V - g t) 2 )

g

가 된다.

5.2.2 데이터 베이스 및 실시간 관리

시제품에서 각 Node간 통신되는 데이터는 수평방향의 위치를 정의하는 x와 수직

방향의 위치를 정의하는 y이다. 시제품의 경우 간단한 시뮬레이션 시스템이지만, 좀

더 복잡한 시뮬레이션 시스템의 경우에는 이 데이터의 형식도 정의가 되어져야 한다.

따라서, 데이터 베이스의 관리 차원에서 시제품의 데이터 형식도 다음과 같이 정의해

서 사용한다.

- double po s it ion [2]

po s it ion [0] : x 좌표

po s it ion [1] : y 좌표

각 Node의 통신 데이터 형식은 position 배열을 사용하고, 첫 번째 배열을 x 좌표,

두번째 배열을 y 좌표로 정의한다. 한편 실시간 관리를 위해서는 gettimeofday ()함

- 37 -

수와 usleep()함수를 사용하는데, usleep()함수의 경우 실제 프로그램에 사용하였을

경우 정확성이 떨어진다. 이를 위해 본 연구에서는 delay ()함수를 직접 만들어서 사

용하였다.

시제품에 사용된 시스템의 경우, 빈 while()문을 무한 루프 돌렸을 경우, 1ms동안

124478번의 while루프가 돌고, 이때의 오차는 최대 약 0.3% 정도이다. 이는 1ms를

돌렸을 경우 약 0.0003ms, 즉 0.3 s 정도의 오차가 생기는 결과 값이다.

5.2.3 시뮬레이션 프로그램

시뮬레이션 프로그램의 전체 흐름은 그림 5- 4와 같다. 프로그램에서 쓰이는 변수

들은 variables.h에 선언하였다. 시제 프로그램의 흐름도는 그림 5- 4와 같은데,

initialize()함수를 통해 variables .h에 선언된 변수들을 초기화시켰다. readIO() 함수

에서는 조종 입력 변수들을 받는다. 시제품의 경우에는 공에 가해지는 힘 F와 공의

질량을 입력하였다. 공의 질량은 시뮬레이션동안에 변함이 없으므로 initialize() 부분

에서 결정한다. dynamic()함수는 위에서 세운 운동방정식을 풀어주는 부분인데 함

수의 결과 값으로 수평좌표 x와 수직좌표 y가 주어진다. 하지만, x와 y 모두 전역변

수로 선언되어 있으므로 반환 값은 없다. start snd()함수는 방송모드로 데이터를 보

내는 함수인데, x와 y의 각 값들이 double 형으로 선언되어 있으므로, 16바이트를

224.0.0.1 채널로 보내게 된다.

마지막으로 한 번의 시뮬레이션 루프가 돌아가는데 걸리는 시간을 계산한 후에 실

시간을 맞춰주기 위해 루프를 delay 시킨다.

그래픽을 담당하는 Node에서는 graphic() 함수를 구동시킨 후, opengl의

callback함수인 display () 함수에서 startclient ()함수를 구동한다. 이 때 Node1에서

보내진 데이터들을 읽어들여, 그 좌표에 공을 그려주게 된다.

- 38 -

그림 5- 4 시제 프로그램 흐름도

- 39 -

5.3 성능평가

통신되는 데이터의 크기는 최대 1kb로 제한을 한다. 이는 double형으로 데이터를

통신한다고 할 경우 128개의 데이터를 통신할 수 있는 크기이다. 시뮬레이터에서 통

표 5- 3 데이터 크기에 따른 시간

변화 (t cp모드)

데이터 크기 (b y t e ) 시간 ( sec )2 5 6 8 1 85 12 83 9

1 02 4 84 02 04 8 8 6 93 072 8794 0 9 6 8935 12 0 9086 14 4 9427 1 6 8 9578 1 92 97992 1 6 995

1 02 4 0 1028

표 5- 2 데이터 크기에 따른 시간

변화 (방송모드)

데이터 크기 (b y t e ) 시간 ( s ec )2 5 6 17 55 12 1 87

1 02 4 2 1 92 04 8 32 23 072 4004 0 9 6 4775 12 0 5506 14 4 6237 1 6 8 6688 1 92 76492 1 6 866

1 02 4 0 944

- 40 -

신되는 데이터가 주로 x , y , z의 위치와 자세에 관한 데이터임을 고려하면, 1kb의

크기는 시뮬레이터 내부통신에 사용하기 충분한 크기이다.

참고로 데이터의 크기에 따른 tcp모드, 방송모드 각 경우에 대해서 통신하는데 소

요되는 시간은 표 5- 1, 5- 2와 같다.

따라서, 데이터를 방송모드로 통신을 할 경우 약 0.2ms, tcp모드로 통신을 할 경우

약 0.8ms 정도의 시간을 소모한다.

이와 같은 조건들을 근거로 설계 요구조건에 따른 시뮬레이터 플랫폼의 성능을 분

석해 보면 표 5- 3과 같다.

참고 자료를 근거로 운동방정식을 푸는데는 약 10ms 정도의 시간을 할당했

고,[4] [12]이는 그래픽 모듈과 trade- off가 가능하다. 이 두 모듈을 합쳐서 각 case에

따라 최소23.2ms에서 최대 24ms 까지 시간 여유가 있다.

표 5- 4 설계요구조건에 따른 성능 분석

case 1 case 2 case 3

통신과 I/ O 0.5ms 1ms 1ms

운동방정식 10ms 10ms 10ms

그래픽 구현 13.5ms 14ms 13.2ms

tcp 통신 0.8ms

시제품의 경우에는 간단한 운동방정식을 풀었기 때문에 운동방정식을 푸는데 약

0.15ms의 시간이 소요됐고, 데이터를 통신하는데 0.15ms (16byte), 그리고, opengl

로 그래픽을 구현하는데 2ms의 시간이 소요되었다.

- 4 1 -

6 . 결론

본 연구에서는 리눅스기반의 시뮬레이터 플랫폼을 초당 30 프레임의 제한조건을

가지고 구성을 해보았다.

리눅스 기반에서 그래픽은 OpenGL을 사용하여 구현을 하였다. 이를 사용하면

Window s에서 코딩된 소스도 리눅스에서 동일하게 사용이 가능하다는 장점이 있다.

각 시뮬레이터 시스템간의 통신은 방송 모드와 tcp모드 두 가지를 사용할 수 있는데,

시뮬레이터 시스템을 구성하는 측면에서나 시간면에서나 방송모드를 사용하는 것이

더 효율적임을 확인 할 수 있었다. 다만, DIS와 같이 여러 대의 시뮬레이터를 운영하

면서, 시뮬레이터 그룹간의 통신이 필요할 경우가 있는데 이 때는 tcp모드를 사용한

다.

이와 같은 방법으로 구성한 시뮬레이터 플랫폼은 운동방정식을 풀고, 그래픽을

구현하는데 약 23∼24ms의 시간 여유가 생긴다. 이는 운동방정식의 복잡성 정도에

따라 그래픽의 질을 조정하는 방법으로 두 모듈 사이의 trade- off가 가능하다.

현재의 PC성능이라면 23∼24ms 안에서 운동방정식을 풀고 Open- GL함수를 이

용해서 그래픽을 구현하는 하는 것이 가능하기 때문에, linux기반의 시뮬레이터 구성

이 충분히 가능하다는 사실을 확인 할 수 있었다.

추후과제로는 리눅스 시스템에서 사운드를 발생시키는 방법에 대해서 좀 더 연구

가 진행되어야 하고, 실제 항공기의 운동방정식을 탑재한 리눅스 기반의 항공기 시뮬

레이터가 구성되어야 할 것이다. 그리고, 개발자의 입장에서가 아니라 사용자 입장에

서 리눅스 기반 시뮬레이터로의 접근이 쉬워지기 위해서는 사용자와의 인터페이스

부분도 좀더 연구가 필요하다.

- 42 -

참고문헌

[1] Lar s Wirzenius외, T he Linux System Administrators ' Guide",

http:/ / kldp.org, 1993

[2] David A Rusling , "T he Linux Kernel", http:/ / kldp.org , 1996

[3] NEIL MAT T HEW외, 이만용외 역 , 초보자용 리눅스 프로그래밍 , 도서출

판 대림, 1998

[4] 최기영, 다용도 고효용의 훈련용 시뮬레이터의 개발 , 국제항공우주 심포지

엄 논문집, 2000

[5] 박무영, 시뮬레이터 전용 플랫폼 개발 , 인하대학교 석사학위논문, 1999

[6] Mark J .Kilgard, "OpenGL programming for the X window System",

addison- wesley , 1996

[7] RICHARD S. WRIGHT JR외, 신현주 역, OpenGL superbible, 도서출판

에프·원 , 1999

[8] Kurt Wall외 , Linux Programming Unleashed" , SAMS, 2000

[9] Miguel Angel Sepulveda, " GLUT programming: Window s and

Animations ", Linux focus, 1998

[10] Jeff T ranter , "Linux Sound Howto", http:/ / kldp.org ,1999

[11] Riku Saikkonen ,"IO Port Programming mini HOWT O",

http:/ / kldp.org, 1997

[12] 유창선외, PC를 이용한 경비행기 비행운동 시뮬레이터 , 항공우주학회

지,1995

- 43 -

부록 : 리눅스 운용체계의 함수 사용법

(1) 입출력함수 사용방법

- ioperm (from, num, turn_on )

from: 읽고 쓰려는 첫 번째 포트번호

num : 읽고 쓰려는 포트의 수

turn_on: 포트의 엑세스 권한 부여 여부

=> 1: 액세스 권한 부여 0: 액세스 권한 제거

(2) 실시간 관리 함수들의 사용방법

- g ett im e of day ( )

현재 시간을 timeval 구조체 형태로 반환 받는다.

① 헤더 파일

=> < s y s/ t im e .h >

② 변수형

s tru ct tim ev al f ir s t , s e con d ;

s tru ct tim e zon e tzp ;

③ 사용 함수

g et tim e ofday (tim ev al ,t im ez on e ) ;

④ 사용 예

#in c lu de < s y s/ t im e .h >

m ain ( ){

s tru ct tim ev al f ir s t , s e con d ;

- 44 -

s tru ct tim e zon e tzp ;

g e tt im e ofday (&f irs t ,&t zp ) ;

시간체크할 함수

g ett im e ofday (& s e c on d ,&tzp ) ;

- usleep()

프로세스를 sec 단위로 delay 시킨다.

① 헤더 파일

=> < s y s/ t im e .h >

② 사용 함수

u s le ep ( )

④ 사용 예

#in c lu de < s y s/ t im e .h >

함수 ( ){

.

.

.

u s le ep (delay 시킬 시간 s e c ) ;

}

- 45 -

- 46 -