및 Layered Protocol Human Interface 연구개발 산 업 자

Layered Protocol및 Human Interface 연구개발

()최종보고서

2000. 9

주관기관: 한국영상기기연구조합 참여기관: 대우전자,,KBS,LG 삼성전자 전자 위탁기관: 광운대학교,(2) 서울대학교

산업자원부

-1- 제출문

산업자원부장관 귀하

본 보고서를“Layered Protocol 및 Human Interface 연구 개발 "( 개발기간 : 1997.12.1. ~ 2000.9.30.)과제의 최종보고서로 제출합니다 .

2000.9

개발사업주관기관명: 한국영상기기연구조합

개발사업총괄() 관리 책임자 : 장 규 환

연구원:125 장규환외 명

-2- 공업기반기술개발사업 보고서 초록

관리번호: 과제명: Layered Protocol및 Human Interface 연구개발 키워드: 양방향/Digital/Data/ 단말 /ATSC/ATVEF/DASE/DVB/MHP

개발목표및내용 1. 최종 개발 목표 iPCTV용 계층적 소프트웨어 플렛폼을 구축하고 계층간에서 독립적으로 구동 될 수 있는 인터페이스와 프로토콜을 연구개발하며, 사용자의 행동 특성을 고려한 지능적 Human Interface장치를 구현한다 .

2. 당해연도 개발내용 및 결과 DVB-MHP, DASE,그리고 ATVEF specification 을 각각 만족하는 Layered Protocol개발 및 양방향 데이터 방송에 적합한 Human Interface 개발

3.기대효과 ( 기술적 및 경제적 효과 ) 세계3DTV, 대 데이터 방송 규격을 만족하는 기술 확보로 대화형 의 북미시장 유럽 시장을위한기술우위확보.

4. 적용분야 양방향Digital Data 방송 및 단말 분야 .

-3- 목차

제장서론1

제장2 Layered Protocol 및 Human Interface 제절1ATSCDASE 1. ATSC DASE 개요 2. ATSC DASE 2.1 데이터방송서비스 2.2 DASE 수신기 소프트웨어 구조 2.3 DASE Java API 3. Data Broadcast 3.1 데이터 방송 서비스 구성 요소 3.2 데이터 방송 프로토콜 3.3 SDF (Service Description Framework) 제절2ATVEF 1. ATVEF 개요및현황 2. ATVEF 구조및규격 2.1 컨텐츠 규격 2.1.1컨텐츠 Format 2.1.2컨텐츠 Type Support 2.1.3 Embedding TV in web pages 2.1.4 Trigger Receiver Object (tve-receiver object) 2.1.5트리거 (Triggers) 2.1.6 The Local Identifier URL Scheme (“lid:") 2.1.7컨텐츠 캐쉬 (Cache) 2.2 전송 규격 2.2.1 Transport Type A : Return-path Data 2.2.2 Transport Type B : Broadcast Data 2.2.3 Simultaneous Support for Transports A and B 2.3 ATVEF Binding 2.3.1 ATVEF Binding to IP Multicast (Reference Binding) 2.3.2ATVEFBindingtoNTSC

-4- 3. ATVEF 동작 원리 및 서비스 내용 3.1 ATVEF 동작 원리 3.2 ATVEF 데이터 서비스 개요 3.2.1 Enhanced 텔레비전 3.2.2 ATVEF의 단방향 데이터 서비스 FLOW 3.2.3 서비스 시나리오 1. 개요 제절3DVB-MHP 2 . Basic Architecture 2.1 Context 2.2 Architecture 2.3 MHP응용프로그램과 MHP 시스템사이의 인터페이스 3. Transport Protocols 4. Content Formats 5. Application Model 6. Application Signaling 7. DVB-J 플랫폼 8. Security

제3 장 향후 동향 및 결론 제1 절 국제 표준의 향후 동향 1. DASE 의향후동항 2. ATVEF의향후동향 3. DVB-MHP의향후동향 제2 절 국내 방송의 향후 동향

부록 위탁개발 보고서 - Embedded Real-Time Jaba Solution(서울대 ) - iPCTV를 위한 내장형 실시간 컴포넌트 갤체모엘의 설계와 구현 ( 서울대 ) - iPCTV의 GUI 를 위한 멀티미디어 정보부호화 방식 연구 ( 광운대 )

-5- 제장서론1

디지털TV 시대의 개막과 함께 다양한 정보를 하나의 가전기기에서 처리해야한다 는 요구가 높아지고 있다.TV 디지털 의 수신은 물론 인터넷 접속 , 사용자 정보의 관리 등,PC 기존 에서 제공하고 있는 다양한 기능들이 TV 에 포함되어야 할 필요성 이 대두되고 있다. 이러한 시점에서 본 과제에서 개발하는 iPCTV 는 매우 큰 의미가 있다고 할 수 있다. iPCTV 는 기존의 PC 기능과 방송 수신이라는 TV 의 기본기능을 수행하는 복합 멀티미디어 단말기로서,, 서비스 제공자와 사용자간에 지능적 양방향 적으로 필요한 정보를 송수신할 수 있는 기능을 갖는다. 이러한 iPCTV 는 아날로그 시대에서 디지털 시대로의 전환점에서 모든 정보가 디지털화 하면서 복합적인 처리 가 가능해짐에 따라 그 의미가 더욱 부각되고 있다. 이러한 iPCTV 는 고화질 , 고음 질의 고선명TV 수신은 물론 , VOD(Video-on-Demand), 인터넷 접속 , home network 기능및오락기능등의다양한기능을갖는종합정보가전기기의성격을 가지도록 개발되고 있다.

이와 같이 다양한 서비스를 제공하기 위해서는 서비스 제공자에게서 송신되는 다양 한 형태의 정보를 하나의 하드웨어와 단일화된 사용자 인터페이스를 사용하여 처리 하도록하기위한시스템의구축이필요하다이러한단일한형태의시스템은시스. 템 개발의 측면 뿐 아니라, 서비스 제공의 편이성 측면에서도 매우 중요한 의미를 가진다. 또한 다양한 정보를 사용자가 편리하게 취사 선택하기 위해서는 사용자 편 이성을 극대화한 사용자 인터페이스를 제공해야 한다.,VOD, 특히 인터넷 접속이나 home network 기능 등의 편리한 사용을 위해서는 음성인식 등 사용자 중심의 인 터페이스가 확보되어야 한다. 이와 같은 기능을 제공하기 위한 핵심적인 기술이 정 보의 효율적인 전송 및 처리를 위한layered protocol 에 관련된 기술과 사용자가 이러한 기능을 쉽게 사용할 수 있도록 하는human interface 기술이다 . layered protocol은 iPCTV 하드웨어와 응용 프로그램 간의 interface 를 계층적으로 구성함으로서 다양한 정보와 이와 관련된 응용 프로그램간의 상호 호환성을 확보하 는 데 그 목적이 있다. 특히 하드웨어와 응용 프로그램 개발시의 일관성 확보의 측 면에서도 매우 중요한 의미를 갖는다., 그러나 다양한 정보와 이를 처리하는 응용 프로그램을 제공해야 하는 시스템 소프트웨어의 역할을 수행해야 하는 이유로, 그 구조가매우복잡하고초기개발시부담이매우크다고할수있다그러나제공., 되는 서비스를 모두 지원할 수 있기 위해서는 반드시 구현되어야 하는 기술이다.

-6- human interface의 경우에는 각국 사용자의 정보 및 가전기기 사용 특성에 맞추어 최적의 인터페이스를 제공해야 하는데,, 음성인식 기술의 경우 각 국의 언어를 처리 하기 위한 기술을 확보해야 하며, 입력장치 또한 남녀노소 누구나 쉽게 사용할 수 있는 방법을 개발,. 제공해야 한다 또한 그래픽 인터페이스도 다양한 정보를 동시에 출력할 수 있으면서도, 사용자가 관심을 가지는 정보에 대해서는 우선권을 제공하 는 기능을 보유해야 하며,, 아이콘 윈도우 등의 현재 PC 에서 사용하는 그래픽 인터 페이스를 최대한 활용,. 사용자의 친숙도를 높이는 것이 바람직하다

현재layered protocol 은 각국 업체간의 치열한 경쟁 속에서 표준화 작업이 마무리 단계에 이르고 있으며, 국내 업체는 이러한 표준화 작업의 추이를 지켜보면서 관련 기술확보에 총력을 기울이고 있다. 특히 미국과 유럽간에는 상호 표준간의 차이를 두어 시장보호를 추구하면서도, 자신의 표준을 국제표준화 하려는 노력을 지속적으 로 기울이고 있다. 미국과 유럽 시장 모두를 겨냥해야 하는 우리나라의 현실에서는 두개의 표준안 모두를 연구,. 개발해야 하는 어려움을 갖는다 이러한 이유에서 국내 외를 통틀어iPCTV 를 완벽하게 구현할 수 있는 업체는 아직 없으며 , 국내업체의 발 빠른 대응을 통해서 시장 점유율을 초기에 확보할 수 있는 좋은 기회가 열려있다고 할수있다.

한편human interface 의 경우 , 음성 인식 등 사용자 편이성 확보에 필수적인 기술 들이 현실화 하기에는 어려운 수준에 머물러 있으며, 그래픽 인터페이스와 같은 부 문에서도 아직 괄목할 만한 언구 성과는 얻지 못하고 있는 상황이다. 또한 기존의 PC에서 사용하는 키보드나 마우스와 같은 입력 장치의 한계도 편리한 사용자 인터 페이스를 위해서는 반드시 극복해야 할 과제라 할 수 있다.

디지털TV 가 상용화되지 않은 상태에서 iPCTV 규격을 다른 나라 보다 먼저 구성하 고 경쟁력 있는 제품을 세계 시장에 출시 할 경우 소위 멀티미디어 시장에서의 경 쟁력 우위를 선정할 수 있는 계기가 될 수 있다., 또한 최신 기술들의 통합을 요하 는 본 과제는 다른 멀티미디어 분야로의 파급효과가 더 크다고 볼 수 있다., 즉 Layered Protocol의연구개발은 iPCTV 의핵심기술로자리잡을뿐만아니라네트 워크 관련 산업 전반에 그 기술이 파급될 것이며,iPCTV 용 지능적 Human Interface기술은 iPCTV 를 비롯한 사용자 인터페이스 기술이 필요한 모든 기기에 공통적으로 적용될 수 있을 것으로 예상된다.

-7- 본연구보고서의제2ATSCDASE, 장에서는현재각사에서구현한국제스펙인 ATVEF,그리고 DVB-MHP 을 요약 정리한다 .

제장2 Layered Protocol 및 Human Interface

제절1ATSCDASE

1. ATSC DASE 개요

DASE는 데이터 방송 서비스를 지원하기 위한 디지털 TV 수신기 내의 소프트웨어 구조 및 데이터 방송 컨텐츠에 관련된 규격을 정의하고 있다.DASE 의 주요 구성 부분은Java 로 작성된 DASE 애플리케이션을 번역하고 실행시키는 Application Execution Engine (AEE),XHTML로 작성된 DASE 애플리케이션을 해석하고 화면 에 시공간적으로 표현하는 Presentation Engine (PE),,애플리케이션들의 기동 리 소스 관리,life-cycle 조정을 담당하는 Application Manager (AM), 특정 미디어 형 태의 스트림을 해석하는 역할을 수행하는 Content Decoder (CD) 등이다.

S13에서는데이터방송컨텐츠를 MPEG-2 Transport Stream Packet 에 encapsulation하는 방법을 정의하고 있다 . DASE 애플리케이션 및 데이터들은 순 환전송, IP datagram 지원 , 동기화 지원 등의 특징에 따라 DSM-CC Data Download Protocol, Addressable Sections, Synchronous and Synchronized Streaming Data, Data Piping 등의 프로토콜로encapsulation 되어 전송된다 . 또한 S13에서는 위의 프로토콜로 전송된 데이터 방송 애플리케이션 및 리소스들에 대한 기술 및 시그널링을 담당하는SDF(Service Description Framework) 를 제공한다 . S16(Interactive Services)은 디지털 방송을 이용한 양방향 서비스의 규격을 정의하 고있다특히양방향서비스를위한세션프로토콜의정의양방향데이터채널을., 위해 요구되는 동작 및 성능을 포함하는 시스템 구조의 정의와 같은 두가지 이슈에 중점을 두고 작업이 진행되고 있다.

-8- 2. ATSC DASE

2.1 데이터방송서비스

DASE기반 데이터 방송 서비스는 DASE Java API 로 작성된 procedural application과 표준규격에 정의된 HTML 로 작성된 declarative application 들의 조 합으로 이루어진다. Java 응용 프로그램은 Java 프로그램 실행환경 즉 , Java VM(Virtual Machine)을통해해석및실행되며 , HTML 은 PE(Presentation Engine) 에 의해 파싱 및 표현된다.JavaAPI 데이터 방송 서비스는 를 통하여 프로그램 가 이드 등의 정보를 얻을 수 있으며tuning 이나 오디오 언어 선택과 같은 시스템 서 비스를 효율적으로 사용할 수 있다.JavaPackage 뿐만 아니라 표준 에서 제공하는 다양한 기능을 사용하여 기능 상의 제한이 없는 데이터 방송 서비스의 제작이 가능 케 되었다.PE 한편 컨테츠는 기존 Web 컨텐츠의 재활용성이라는 장점이 있다 .

Java응용 프로그램 혹은 HTML 컨텐츠는 텍스트 , 하이퍼텍스트 , 그래픽 , 이미지 , 애니메이션,/ 오디오 비디오 클립 등의 다양한 미디어를 활용하는 대화형 서비스를 작성하는데 적합하다., 예를 들어 농구 경기 중계 방송을 보내면서 TV 화면 한 쪽 에특정선수의상세정보를보여주고또그선수의과거활약장면을비디오클립 으로 제공하여 시청자는 프로그램 정규 방송과 동시에 시청하는 것이 가능해진다.

데이터 방송 서비스는 현재 방송 중인TV 프로그램 내용과의 연관성 여부에 따라 분류될 수 있다.(,, 우선 스포츠 중계와 관련된 정보 선수 이력 정보 용어 게임 규 획,),, 주요경기정보등 드라마부가정보그리고현재진행중인광고에대한부가 정보 등과 같이 특정 프로그램과 연결되어 서비스되는 형태가 있을 수 있다. 반면 에 실시간 뉴스,,,S/W 일기예보 주식시세 다운로드 등과 같이 특정 프로그램 내용 과 독립적인 정보를 제공하는 형태가 있을 수 있다. 후자와 같이 특정 프로그램에 종속적이지 않은(channel unbounded) 데이터 서비스만을 독립적인 채널을 통해 서비스 하는 방식도 예상할 수 있으며, 일각에서는 이런 서비스의 성공 가능성에 주목하고 있다.

-9- 한편 양방향 채널이 확보되는 경우, 데이터 방송 서비스는 새로운 전기를 맞게 될 것으로 기대된다., 사용자의 입력이 방송사에 전달될 경우 여론조사 인기가요순위 (),투표 시청률 조사 및 방영 인물에 대한 인기투표 , 설문조사 등이 실시간에 방송 에 반영되는 획기적인 온라인 서비스가 가능케 될 것이다. 또한 사용자는 방송사 외부의 정보 제공자에 연결하여 더욱 다양한 형태의 대화형 서비스를 제공 받을 수 있다. 최근 T-Commerce 라는 이름으로 거론되고 있는 TV 수신기를 통한 온라인 홈쇼핑은 향후 데이터 방송의 중요한 응용으로 인식되고 있다.

그림1iPCTV 은 전시회에서 시연된 데모 컨텐츠로부터 발췌한 내용이다.

그림1-a 선수 프로필을 보여주는 데이터방송 예

-10- 그림1-b 전국 날씨 메뉴

그림1-c 음반 구매 메뉴 양방향 서비스

-11- 그림1-d 패션쇼에 모델이 입은 옷을 구매하는 할 수 있도록 하는 전자 상거래의 예

2.2 DASE 수신기 소프트웨어 구조

본 절에서는DASE 수신기의 핵심 구성 요소에 대해 설명하고자 한다 . 그림 2 는 DASE 수신기의 소프트웨어 구성 요소 및 필요 자원을 보여주는 개념도이다.

-12- 그림 2 DASE Software Architecture

AM(Application Management)은 애플리케이션의 기동과 life-cycle 제어를 담당한 다. AM 은 PMT(Program Map Table), S13 DST(Data Service Table) 등으로부터 데이터 서비스의 수행에 필요한 정보를 얻게 되며, 애플리케이션이 요구하는 자원 과 시스템 서비스를 해당 수신기에서 제공할 수 있는가를 판단한다.AM 은 애플리 케이션의 형태에 따라AEE 혹은 PE 를 통해 애플리케이션을 기동시키며 , 채널의 변 경 혹은 애플리케이션 종료를 알리는 시그널링 등의 사건이 발생하면 해당 애플리 케이션을 종료시키게 된다.

데이터 방송 애플리케이션은 운영체제나 하드웨어에 독립적으로 모든 수신기에서 동일하게 동작해야 한다.DASE 이런 요구조건을 충족시키기 위해 일찍이 및 DVB-MHP에서는 플랫폼 독립성을 보장하기 위한 핵심적 구성 요소로써 Java VM 을 애플리케이션 실행엔진(Application Execution Engine, AEE) 으로 결정하였다 . 표준Java API 로작성된애플리케이션실행코드는 Java VM 에의해번역및실행 된다.JavaAPI 애플리케이션은 표준 를 통해 수신기 내의 각 구성 요소들을 제어하 고 데이터 및 이벤트를 교환한다. DASE 와 DVB-MHP 는 JavaTV, JMF, HAVi UI 등 상 당량의 표준Java API 를 공유하고 있다 .

-13- PE(Presentation Engine)는 HTML 언어로 작성된 컨텐츠를 해석하여 화면에 시공간 적으로 표현하는 역할을 한다.PE 컨텐츠를 위한 규격은 기존 Web 컨텐츠의 재활 용성 및 향후 확장에 효과적으로 대처하기 위해W3C 에서 권고되고 있는 XHTML 의 채택이 확실시되고 있다. 또한 ECMAScript 혹은 Java application 은 DOM (Document Object Model)을통해 HTML 기반컨텐츠내용을변경추가삭제할수 / / 있으므로 다이나믹한 화면 구성이 가능케 된다.

CD는 특정 미디어 유형으로 작성된 컨텐츠를 디코딩 혹은 해석하여 디스플레이 할 수 있는 형태로 변환시킨다.CD 는 공간적 배치나 미디어 유형 간의 합성을 직접 제어하지는 않지만 사용자 이벤트에 반응할 수 있어야 하며,CD 플랫폼 독립적인 들이 다운로드 및 등록되어 기존의CD 를 대체할 수 있다 .

2.3 DASE Java API

DASE Java API는표 1 과같이구성된다우선 . DASE 는 Personal Java 1,2 를기반 으로 한다. 단 , java.applet, Java.awt 의 일부 , java.rmi, java.sql 등은 우선적으로 정의될 예정인 단순 프로파일에서는 지원되지 않아도 된다.

표구성1 DASE API (version 1.08.03)

API Version Package Reference

Personal http://java.sun.com/products/persona 1.2 Java Java ljava/

JavaTV 1.0 Javax.tv http://java.sun.com/products/javatv/

http://java.sun.com/products/java-m JMF 1.1 Javax.media edia/jmf/1.1/index.html

HAVI UI 1.0 org.havi.ui http://www.havi.org/home.html

DAVIC 1.4 org.davic http://www.davic.org (selected)

DASE 현재 org.atsc Specific 1.08.03

-14- JavaTV API는 서비스 (MPEG-2 program, DVB Service, ATSC Virtual Channel 과 동일 개념),,, 정보의 접근 서비스 선택 미디어 제어 데이터 방송 정보의 접근 및 제어,life-cycleTV 애플리케이션의 제어 등과 같은 수신기 고유의 기능들에 대한 추상화를 제공한다.3Xlet(DASEJavaApplication) 그림 은 이 자신이 속해있는 Service Context(서비스를 선택 , 접근하기 위한 환경 ) 를 통해 현재 미디어의 제어를 수행하고 있는media handler (AV media 의 presentation 을 담당하는 JMF player) 를 얻은 후, media handler 로부터 오디오 언어 선택을 위한 control ( 오디오 언어 정보 및 선택을 위한JMF control) 을 얻고 , 최종적으로 원하는 오디오 언어를 선택 하는 과정을 보여주는interaction diagram 이다 .

그림3 Interaction Diagram: 오디오 언어 절환

-15- JMF(Java Media Framework)는 오디오 , 비디오를 포함한 스트리밍 미디어의 동기 화 및 제어를 위한 일관적인 인터페이스를 제공한다. 그러므로 애플리케이션은 상 이한 전송 프로토콜 및 컨텐츠 포맷을 갖는 미디어 스트림들을 동일한 방식으로 제 어할수있게된다.

HAVI UI(Home Audio Video Interoperability User Interface)는사용 “TV friendly” 자 인터페이스를 구성하기 위한 환경을 제공한다,HAVIUI 애플리케이션은 를 사용 하여 디스프레이 디바이스에 관한 정보를 얻고,, 비디오와 그래픽 간의 배치 Transparency제어 , 비디오 이팩트 등을 구현할 수 있다 .

이외에DAVIC (Digital Audio-Visual Council) 의 일부 API 그리고 ATSC 규격 고유 의 내용에 대한API 가 포함되어 있다 .

3. Data Broadcast

3.1 데이터 방송 서비스 구성 요소

그림4ATSC 는 기반 데이터 방송 서비스 시스템의 개념도이다 . 저작된 데이터 방 송 서비스 컨텐츠는 데이터방송 프로토콜로encapsulation 및 MPEG-2 TS(Transport Stream)패킷화 된 후 , 오비오 / 비디오와 다중화된다 . 그림 4 에서 Program Mux와 Emission Mux 의 차이점은 19.4 Mbps 의 Physical channel 내에 다수의 프로그램( 혹은 Virtual Channel) 이 포함될 수 있음을 의미한다 . PAT(Program Association Table), PMT(Program Map Table). S8 PSIP와 S13 DST와 같은 정보 역시 MPEG-2 Section 및 TS 패킷화를 거쳐 다중화되어 방송파 를 통해 수신기에 전달된다.

-16- 그림 4 Data Broadcast System Diagram

한편 데이터 방송 수신기는 리턴채널을 통해 인터액티브 서버에 접근할 수 있다. 사용자가 입력한 여론조사, 인기투표 등의 정보는 다시 데이터 서버로 전달되어 실 시간에방송내용에반영될수있다또한외부의인증시스템및전자결제서버. 와 연결되는 전자상거래 서비스의 실현이 가능하다.

3.2 데이터 방송 프로토콜

ATSC S13 Data Broadcast표준은 MPEG-2 전송 규격으로 데이터를 전송하기 위 한 프로토콜을 정의하며, 이들 프로토콜로 encapsulation 된 프로그램 요소의 발견 과 애플리케이션과의 바인딩을 위한Service Description Framework (SDF) 를 제공 한다. 또한 기존 ATSC Program and System Information Protocol (PSIP) standard를 사용하여 데이터 서비스를 어나운스하는 방법을 정의하고 있다 . S13 에서 정의하는 프로토콜은 다음과 같이4. 가지 범주로 구분될 수 있다

-17- Data Piping

Data Streaming

Addressable Sections

Data Download

그림5 다른 표준 프로토콜과의 관계

-18- Data piping프로토콜은 MPEG-2 TS 내에 임의의 사용자 정의 데이터를 전송하는 데사용된다데이터는. MPEG-2 Transport Packet 내에직접삽입되며 Section, Table, PES등의 데이터 구조는 사용되지 않는다 . 즉 , MPEG 에서 정의한 어떠한 데이터 포장 방법도 시용되지 않으며 데이터 비트의 해석은 전적으로 응용에 따라 정의된다.

Data streaming은 MPEG-2 Video 나 Audio 의 전송에 사용되는 방법과 같은 방식인 PES (Packetized Elementary Stream)을 이용한 방법으로 특히 timing 기능을 지원 하는 데이터의 전송에 적합하다. 동기적 데이터 스트리밍 (Synchronous Data Streaming)은 전송되는 하나의 데이터 스트림 내에서 데이터 패킷 사이에 시간적인 제한이 주어지는 것을 의미한다. 동기화된 데이터 스트리밍 (Synchronized Data Streaming)은 동기적 데이터 스트리밍과 같이 하나의 데이터 스트리밍 내에 시간적 인 제한이 주어지고 또한 다른 스트림과도 시간적으로 동기 되어 전송되는 방법이 다, 이 방법은 연속적인 데이터 정보를 방송 프로그램과 동기화 시켜서 전송할 수 있는 방법이다.

Addressable section과 Data Download 프로토콜은 MPEG-2 ISO/IEC 13818-6 DSM-CC를 기초로 정의되며 , DSM-CC 프로토콜과 MPEG-2 간의 맵핑은 MPEG-2 ISO/IEC 13818-1의 private section 을 사용한다 . Addressable section 은 데이터그램을 포장하여 전송하는 방법으로 데이터그램 데이터를 비동기적 (asynchronous)인 방법으로 전송하는데 사용된다 .

Download프로토콜은 DSM-CC User-to-Network Download Protocol 을 사용한 다. 이 프로토콜은 데이터 모듈의 carousel 전송 혹은 non-flow controlled 전송을 지원한다. Data carousel 방식은 그림 6 과 같이 carousel 의 contents 를 여러 번 반 복해서 전송하는 방식이다. 만일 data decoder 가 특정 carousel 의 특정 module 을 access하고자한다면요청된 module 이다시전송될때까지기다리기만하면된다 . Non-flow controlled방식으로는 asynchronous data streaming, non-streaming synchronized data들이 있다 . 특히 , non-streaming synchronized data 의 경우 현 재방송되고있는비디오및오디오정보와동기화되어전송될수있다즉., 비디 오스트림과동기되어짧은시간내에산발적으로발생하는데이터의전송에적합 하다.

-19- 그림6 Data Carousel 에서의 Cyclic Transmission

위에서 살펴온 바와 같이ATSC Transport 를 통해 데이터를 전송하는 여러 방식이 있으나,, 각 방식은 반복 전송 타이밍 지원 뿐만 아니라 필터링 ,, 오버헤드 사이즈 등에 있어서 상이한 특징을 갖는다. 프로토콜 방식의 선택은 애플리케이션이 목적 하는 바에 따라 적절히 선택되어야 한다.

3.3 SDF (Service Description Framework)

데이터 서비스는 다수개의 애플리케이션과 각 애플리케이션을 구성하는 다수개의 데이터 자원(program element) 의 조합으로 구성된다 . 각 program element 들은 unique PID에 의해 구별되며 , SDF 의 Data Services Table (DST) 을 통해 기술된 다. DST 역시 하나의 고유한 program element 를 통해 전달된다 . 각 Virtual channel은 하나의 데이터 서비스 만을 포함하지만 데이터 서비스가 포함할 수 있는 program element (data elementary streams)개수의 제한은 없다 .

-20- 그림7DASE 은 와의 연동을 위해 DST 내에서 하나의 애플리케이션에 대한 정보가 기술되는 형태이다. 각 정보는 애플리케이션의 구별 (AppID, Title), 데이터 자원 바 인딩(protocol_encapsulation, Tap(), Name(URI)), 기동 및 수행 (Entrypoint, ContentType, Classpath)그리고 channel boundness 및 priority (Task) 관련 정 보를 제공하기 위해 사용된다.

그림7DASE 에서의 DST 사용

-21- 제절2ATVEF

1. ATVEF 개요 및 현황

1998년 여름에 결성된 ATVEF 는 방송 프로그램의 부가 정보를 HTML 을 근거로 하 여 다양한 종류의 단말기로 이루어져 있는 텔레비전과 세톱박스와PC 로 전송하는 Protocol과 표시 방법의 규격을 정하는 단체이다 . 부가 정보에 대한 규격은 국제 웹 표준 단체인W3C 에서 정한 HTML4.0,CSS1,JavaScript1.1 등이고 , 전송 규격 은IP Multicast 를 사용하고 있으며 , 인터넷 , 케이블 , 위성 , 지상파에서 아날로그 및 디지털 방송에 모두 적용 가능하며 규격의 사용권에 대한 로열티는 무료이다. 이러 한 규격은 여러 차례의 수정과 보완을 통하여1999 년 1 월에 ATVEF 규격 v1.1r26 으 로최종발표되었다.

현재ATVEF 에 가입한 회원사는 방송사 , Cable 업체 , PC 업체 , 컨텐츠 제작사 , 광 고회사 그리고 가전 업체들로 이루어져 있으며,14Founder 현재 개의 회사들과 약 150개의 Adopter 회사들로 구성되어 있다 . 이와 같이 ATVEF 는 쌍방향 방송을 모두 수용하는 산업체의 대표적인 회사들로 이루어져 있으며, 향후 데이터 방송에 있어 서 중요한 역할을 할 것이다.

그 동안ATVEF 는 기술적인 면들만 다루었기 때문에 실제의 사업화 모델을 제시하 지못하였다.ATVEF 의사업화등을총괄하기위해서 2000 년 4 월미국라스베가 스의2000 NAB Show 에서 비영리 조직인 ATVF(Advanced TV Forum) 를 결성하여 ATVEF의 조기 사업화를 추진하고 있으므로 규격화 된 데이터 방송 서비스로서는 가장 먼저 상업화가 될 전망이 크다.

2. ATVEF 구조 및 규격

ATVEF의 구조는 그림 1 과 같으며 , 다른 데이터 방송 서비스 규격 보다 간단하여 구현 방법이 용이하다. 이는 자바 버츄얼 머신 (Java Virtual Machine) 과 웹 브라우 저(Web Browser) 와의 연결이 없고 , 각 회사들만의 자체 기술들을 규격에서 배제하 였고, 현재 규격 결정이 완료된 데이터 방송과 관련된 항목들을 채택하였기 때문에 구현 방법에 있어서 현실성이 뛰어 나기 때문이다.

-22- ATVEF의 규격은 크게 컨텐츠관련 , 전송관련 , 그리고 바인딩으로 이루어져 있다 . 앞 서말한바와같이ATVEF 는주위에서손쉽게구할수있는웹컨텐츠를이용하여 매체에관계없이전송하며여러종류의단말기에서구현이가능하다,.ATVEF 의 규격을 살펴 보면 다음과 같다.

2.1 컨텐츠 규격

2.1.1컨텐츠 Format

ATVEF의 컨텐츠는 현존하는 웹의 표준을 따르며 HTML4.0,CSS1,JavaScript1.1 (ECMAScript, DOM0)를지원한다 .

2.1.2컨텐츠 Type Support text/html (HTML4.0), text/plain, text/css, image/png, image/jpg, audio/basic들 은 단말기에서 기본적으로 지원되어야 한다.

그러나image/gif, audio/wav 들은 반드시 지원하지 않아도 되지만 현존하는 웹 컨 텐츠와의 호환성을 가져야 하am 로 구현할 때 고려되어야 할 사항들이다 .

2.1.3 Embedding TV in web pages

텔레비전전 영상은 방송용 텔레비전 채널을 이용하여 하나의Image 로 처리한다 . TV URL의이용법은 “tv:” 이며 , object, img, body, frameset, a, div ,table 등의 tag들과 같이 사용할 수 있다 .

2.1.4 Trigger Receiver Object (tve-receiver object)

트리거를 받기 위해서TV 용 부가정보를 위한 웹 페이지에 포함되어 있다 . 컨텐츠 Type은 “appication/tve-trigger" 이며 규칙은 다음과 같다 .

-23- 사용 예는 다음과 같다.

enabled, sourceID, releasable, backChannel, contentLevel 과같은속성들을포 함하고 있다.

2.1.5트리거 (Triggers)

트리거는 방송 부가 정보가 전달되는 실시간Event 를 나타내며 , 트리거의 도착 정 보를 이용하여 사용자들이 부가 정보를 이용할 수 있게 한다. 트리거의 특징은 다 음과 같다.

IP Multicast패킷 (packet) 의 내부에서 방송된다 .

어나운스먼트에 의해 정의된Address 와 Port 에 의해 전송된다 .

일반적인 형태는 다음과 같다.

트리거는 아래의 항목들을 포함한다.

-24- 2.1.6 The Local Identifier URL Scheme (“lid:")

“lid:"는 단방향 전송에 있어서 각각의 자료들에 대해서 고유의 이름을 부여하는 것 이다. "lid:" 의 사용법은 절대적인 것과 상대적인 URL Syntax 를 따르며 , 그 사용방 법과 사용 예는 다음과 같다.

사용 예

2.1.7컨텐츠 캐쉬 (Cache)

단말기는 캐쉬에 저장되는 컨텐츠를1MB 까지 지원해야 하며 , 최대 캐쉬의 크기는 “tve-size”로표시한다 .

2.2 전송 규격

ATVEF의 전송 방법은 트리거를 Forward Path 로 전송하고 데이터를 리턴 채널에 의해 모으는 방법의Transport A 와 트리거와 데이터를 Forward Path 로 전송하는 Transport B방식이 있으며 , Transport B 에서 리턴 채널은 선택적으로 사용할 수 있다.. 각각의 전송 방법에 있어서의 특징들은 다음과 같다

2.2.1 Transport Type A : Return-path Data

서브 타이틀( 혹은 캡션 ) 과 텔레텍스트 서비스는 Broadcast Data Triggers [tve:1.0]를 따른다 . Transport A 방식은 제한된 대역폭에서 컨텐츠 데이터를 전송하 기 곤란할 때 데이터 트리거만을 전송하는 방식을 이용하는 것이다. 하지만 이 방 식은 컨텐츠 데이터를 전송할 경로가 없기 때문에HTTP 를 이용한 쌍방향 인터넷 연결이 필요하다.

-25- 2.2.2 Transport Type B : Broadcast Data

이 방식은Transport A 와는 달리 인터넷 연결이 없이 방송용 채널을 이용하여 데이 터 트리거와 컨텐츠 데이터를 전송하는 방식이며, 추가 웹 서비스나 전자 상거래를 위하여 쌍방향 기능을 추가할 수 있다. Transport B 에서는 텔레비전 채널의 하나 혹은 다수의 부가 정보를 제공하기 위해서 어나운스먼트(). 어나운스먼트 를 이용한다 여기서 어나운스먼트는 단말기에 전송되는 컨텐츠들의 사용 언어 종류, 시작 및 종 료 시간,. 대역폭과 최대 저장 크기를 포함한다 또한 컨텐츠 전송을 위하여 앞서 언 급한“lid:” 와 “http:” 모두 이용할 수 있다 .

2.2.3 Simultaneous support for Transports A and B

하나의 비디오 프로그램이Transport A 와 Transport B 방식을 동시에 포함할 수 있 는데, 이것은 인터넷에 연결된 단말기와 방송 채널만을 통해서 컨텐츠를 수신하는 단말기를 모두 전제로 해서 전송하기 때문에 여러 가지 유리한 점들이 있다. 이 방 식에서는 인터넷만을 통한 서비스 혹은 방송 채널만을 통한 서비스 혹은 인터넷과 방송 채널 모두 이용하는 서비스등의 세 가지 방법이 있다. 인터넷과 방송 채널을 모두 이용하는 서비스는 다음과 같은 방식을 이용한다.

방송용 데이터 트리거와 현재 컨텐츠의URL 를 비교하여 ,

일치하면, 스크립트 (Script) 를 수행

일치하나 스크립트가 없으면 현재의 컨텐츠가 재전송된 것으로 간주

일치하지 않으나 컨텐츠의 이름을 가지고 있으면, 새로운 부가 정보가 전송되었다 고 간주하고

일치하지 않고 이름도 없으면,. 트리거는 무시 된다

-26- 2.3 ATVEF Binding

ATVEF바인딩은 ATVEF 컨텐츠가 주어진 네트워크 환경에서 동작하는 형태를 정의 한 것으로서 여러 종류의 네트워크를 지원 하기 위해서는 단일의 표준화가 된 ATVEF Binding이 필요하다 . ATVEF 에서는 인터넷 프로토콜 (IP) 에 바인딩하는 것을 기준으로 삼으며 기존의 아날로그 방송과의 연계도 정의하고 있다.

2.3.1 ATVEF Binding to IP Multicast (Reference Binding)

어나운스먼트Protocol : 어나운스먼트는 현재 가능한 컨텐츠가 단말기에 도착한 것을 알려 준다.

트리거Protocol : 2.1.5 절 참조

Resource Transfer : 컨텐츠를 단방향으로 전송하기에 적합한 방식으로 UHTTP(Unidirectional Hypertext Transfer Protocol)을 이용하고 있으며 , 이는 아날 로그 텔레비전전의 수직 귀선 기간에서IP Multicast 하기에 적합하고 MPEG-2 스트 림내에IP Multicast 를 전송하기에 충분하다 .

2.3.2 ATVEF Binding to NTSC

NTSC등의 아날로그 텔레비전전의 짝수와 홀수의 필드에서 수직 귀선 기간 동안에 도ATVEF 데이터가전송된다이때전송방식은 . ATVEF Transport A 와 ATVEF Transport B방식이사용되며그방식은 Transport A : VBI Line 21Transport B : IP Over VBI의 두 가지를 이용한다 .

3. ATVEF 동작 원리 및 서비스 내용

3.1 ATVEF 동작 원리 ATVEF의 동작 원리는 그림 2 와 같으며 그 동작원리는 다음과 같다 .

모든 텔레비전전 신호(, 위성 지상파 , 케이블을 통하여 ) 는 튜너에 의해 세트나 세톱 박스로 들어온다.

-27- 튜너를 통한 방송데이터에서 영상/ 음성 패킷과 데이터 발송용 패킷이 분리되어 영 상/ 음성 패킷은 바로 디지털 디코더를 통해 화면으로 뿌려지고 데이터방송용 패킷 은IP Multicast Datagram 으로 분리가 된다 .

어나운스먼트 패킷은IP 어드레스 (224.0.1.113) 와 포트 (2670) 를 가지고 있어서 처 음에 어나운스먼트 리스너(announcement listener) 는 위와 같은 어드레스와 포트번 호를 가진 패킷을 찾아서 분석한다.

어나운스먼트 패킷을 찾아서 분석을 하면 데이터와 트리거를 포함하는 패킷의 IP 주소와 포트번호를 찾아낼 수 있다.

위에서 얻어진IP 주소와 포트번호를 이용해서 각각의 패킷이 데이터를 포함하는지 아니면 트리거를 포함하는 패킷인지를 구별할 수 있다.

데이터를 포함한 패킷은 파일 형태로 로컬 케쉬메모리에 저장하고 트리거에 해당하 는 패킷은 트리거를 분석한다.

3.2 ATVEF 데이터 서비스 개요 3.2.1 Enhanced 텔레비전

종래의 텔레비전은 단순히 텔레비전화면을 표시하거나 사용자들에게 단순한 데이터 서비스 정도를 제공해 주는 것이 전부였고 이 또한 사용자들에게 일률적으로 보여 주는 역할 밖에 하지 못했다. 그리고 일부 앞선 서비스에서는 텔레비전에서 인터넷 을 사용할 수 있게 하는 기능도 있었으나 이는 텔레비전과 인터넷의 단순한 물리적 결합에 지나지 않았다.Enhanced 그러나 텔레비전은 이런 텔레비전과 달리 텔레비 전과 인터넷의 유기적인 결함에 의해 개별 사용자에게 서로 다른 데이터 서비스를 쌍방향으로 제공한다.3 그림 은 종래의 텔레비전과 Enhanced 텔레비전과의 차이점 을 보여주고 있다.

그림3. 은 인터넷과 텔레비전이 서로 융합되어 있는 모습을 보여주고 있다 종래의 인터넷 텔레비전은 텔레비전을 시청하는 것과 인터넷 컨텐츠를 보는 것이 서로 다 른 화면으로서 서로의 내용이 연동되지 않지만Enhanced 텔레비전의 경우는 인터 넷 컨텐츠와 텔레비전 내용이 서로 연동되어 움직이게 된다.

-28- 그림4Enhanced 의 경우도 텔레비전의 특징을 잘 보여주고 있다 . 기존의 텔레비전 방송의 경우 모든 사용자에게 똑같은 내용의 데이터만 보여줄 수 있지만 Enhanced 텔레비전의 경우는 사용자의 필요에 따라 그때 그때 다른 내용을 보여줄 수 있다. 위의 그림들처럼Enhanced 텔레비전은 인터넷과 텔레비전의 유기적인 결합을 통해 사용자에게A/V 와 인터넷 컨텐츠를 동시에 보여줄 수 있으며 사용자 개개인의 요구 에 맞는 서비스를 제공해 줄 수 있는 특징이 있다.

ATVEF는 세 개의 어나운스먼트 , 컨텐츠 , 트리거로 구성되어 있다 . 어나운스먼트는 트리거와 컨텐츠를 자동으로 받기 위한 정보를 제공해 준다. 그리고 트리거의 경우 는 컨텐츠의 존재 사실을 알려주는 역할을 주로 하며 컨텐츠의 경우는 화면에 표현 하기 위한Data 의 역할을 한다 . 그리하여 이 세 개의 Engine 들이 서로 유기적으로 작동하며 인터넷 컨텐츠를 브라우저에게 전달하여 시용자에게Enhanced 텔레비전 의 서비스를 제공한다.

3.2.2 ATVEF단방향 데이터 서비스 FLOW

그림5ATVEF 는 향 단 방향 데이터 서비스의 흐름을 보여주고 있다 . 그림 5 의 상단 부분의 스트립은 어나운스먼트, 트리거 , 컨텐츠 패킷이 각각의 Address/Port 의 스 트링을 통해서 전송되고 있는 것이다. 어나운스먼트 패킷에는 Session 정보 즉 title,. start time, end time과 트리거 , 컨텐츠의 IP/Port 정보가 들어있다 . 어나운스 먼트 리스너는SDP 패킷을 지속적으로 검사하면서 어나운스먼트의 내용이 변화하 는 지를 확인한다. 변화하는 내용은 Address/Port, Enhancement Title 등이 될 수 있는데 이런 정보는 즉시 트리거 리스너, 어나운스먼트 리스너에게 알려져서 이 리 스너들은 이 정보를 데이터 수신 작업에 반영한다.

트리거 리스너는 어나운스먼트 리스너로부터 받은Address/Port 를 통하여 트리거 패킷을 수신한다. 이 때 수신된 패킷은 Parsing 과정을 거쳐 브라우저에게 전달된다 . 전달되는 내용은 크게 두 가지로 나눌 수 있는데 하나는 새Enhancement 가 도착 했을 때 그Title 과 Name 을 알려주어 새로운 Enhancement 가 도착했음을 사용자에 게 알리는 것이고 또 다른 하나는Script 를 브라우저에게 전달하여 해당 Enhancement에 대해 Script 가 작동하도록 하는 것이다 .

-29- 마찬가지로 어나운스먼트 리스너는 컨텐츠 리스너에게Address/Port 를 전달하고 컨 텐츠 리스너는UHTTP Protocol 을 사용하여 컨텐츠를 수신하고 이 내용들을 지역의 캐쉬에 저장한다./ 그래서 지정된 어드레스 포트로부터 데이터를 수신하고 있다가 브라우저로부터 특정URL 과 관련된 컨텐츠를 요청받으면 해당하는 컨텐츠를 브라 우저에게 보낸다. 그리고 ATVEF Data Capture Manager 는 앞서 언급한 세 개의 리스너와HTML 브라우저를 연결하는 역할을 한다 .

그림6. 은 컨텐츠의 전달과정을 표현한 것이다 컨텐츠는 방송국이 지정한 컨텐츠 제공자에서UHTTP 프로토콜로 encapsulation 되어 수신기로 전송된다 . 이 때 , 각 패킷은 무작위로 전송되며 지정된 시간동안 계속 재전송된다. 수신기 측에서는 수 신한 패킷을UHTTP 헤더 정보를 이용하여 재조립하고 필요에 따라서 XOR 알고리 즘을 사용하여 순방향 에러 정정 메커니즘을 제공한다. 위의 과정이 끝난 컨텐츠는 수신 버퍼에서 지역의 캐쉬로 복사된다.HTML 엔진이 UHTTPURL 를 이용하여 컨텐 츠의 요청을 하면 있으면, HTTP 헤더를 Parsing 한 후 HTML 브라우저로 해당 컨텐 츠를 넘겨준다.

그림7Script. 은 트리거 리스너를 중심으로 의 흐름을 좀 더 상세히 표현한 것이다 앞서 언급한 것처럼 트리거 리스너는 지정된Address/Part 에서 전송되는 트리거 패 킷을 계속 검사한다.Script 그래서 가 담겨져 있는 새로운 트리거가 나타나면 이를 Parsing하여 화면에 ·Script 를 작동시킬 수 있도록 브라우저에게 보내게 되고 위의 그림처럼Script 의 작동에 따라 광고 화면을 나타내게 되는 것이다 . 이상에서 언급 한 것처럼 단방향 데이터 서비스Flow 는 하부 Network 의 도움을 받으면서 세 개의 Engine들이 상호 작용을 하는 가운데 HTML 브라우저에게 데이터를 전달하는 과정 으로 구성되어 있다.

3.2.3 서비스 시나리오

앞 장에서 언급한 것과 같은Data 의 흐름을 통해 데이터는 화면에 표시되는데 여기 에서는 사용자와의Interaction 을 중심으로 시나리오를 기술한다 . 그림 8 은 화면을 포함한 실제Data Service 흐름을 보여주고 있다 . 그림 8 의 화면 1 은 사용자가 일 반적인A/V 화면을 시청하고 있을 때의 모습이다 . 방송국에서는 사용자에게 A/V 와 관련된 부가 정보를 전송한다.2 이 때 앞서 언급한 일련의 과정을 통하여 화면 와 같이 부가 정보의 도착을 사용자에게 알려준다.A/V 만약 사용자가 와 관련된 부가 정보를 보기를 원하여 리모컨의 버튼을 누르게 된다. 이 때 브라우저는 컨텐츠 캐 쉬에서URL 에 해당하는 컨텐츠를 찾게 되고 이 내용을 컨텐츠 캐쉬에서 인출하여 화면에A/V 와 함께 표시하게 된다 . 이것이 화면 3 에 해당한다 .

-30- 그림9Script 는 방송국에서 보내주는 트리거와 그에 포합된 를 실행하는 화면을 나 타낸 것이다.7 그림 의 결과로 그림 9 이 나왔다고 했을 때 그림 9 의 우측 빗금 친 부분은Script 에 의해 조정되는 부분이다 . 시청자가 부가 정보를 함께 보고 있을 때, 경기 상황에 따라 남은 시간이나 점수 부분들을 계속 변할 수 있으므로 이 내 용을 계속 바뀌어야 한다. 따라서 방송국에서는 이런 내용들을 변화 시킬 수 있는 Script를트리거에담아실시간으로전송하며이 Script 에따라브라우저는화면의 빗금 친 부분을 계속 변화 시키면서 화면에 출력하게 된다.

앞서 두 가지의 시나리오에서 언급한 것처럼 화면 표현은 컨텐츠를A/V 와 함께 나 타내는 것과 함께 방송국에서 실시간으로 전송되어 오는Script 를 적용함으로써 화 면을 동적으로 만들고 사용자에게 간단한 쌍방향 기능을 제공하는 내용이라 할 수 있다.

그림1. ATVEF 구조

-31- 그림 2. ATVEF Data Flow

-32- <인터넷 - OR - 텔레비전 ><-WHILE-> 인터넷 텔레비전 그림3. 인터넷과 텔레비전의 통합

그림4. 개별 사용자에 따른 서비스의 제공

-33- 그림5. 단방향 Data Service Flow

그림6. 컨텐츠의 전달과정

-34- 그림7. 트리거 의 전달과정

-35- 그림 8. Data Service Scenario

그림9. Trigger 관련 화면

-36- 제절3DVB-MHP

1. 개요

1996년에 유럽 위원회의 ISIS 프로그램에 의해 시작된 UNITEL(universal set-top box) 프로젝트가 시작되면서 주 목적은 멀티미디어 서비스를 사용자가 편하게 사용 할 수 있는 일반적인 플랫폼을 만들자는 것이다. 그래서 UNITEL interactive 에서 프 로젝트를 시작하기 위해MHP Launching Group 을 만들었다 . 이 그룹은 DVB 프로 젝트로 옮겨지면서commercially-oriented group 인 DVB-MHP 와 technical group 인DVB-TAM 으로 나뉘어 졌다 . DVB-MHP 는 보다 나은 양방향 방송에 대한 사용 자와 시장의 요구사항을 정의하고DVB-TAM 은 DVB API 의 규격작업을 맡아서 진 행하고 있다.

DVB system은 위성 , 케이블 , 지상파 그리고 마이크로웨이브와 같은 다양한 전송 미디어를통해MPEG2 Transport-Stream(MPEG2 TS) 를전송할수있게하는디지 털 비디오 브로드케스팅 시스템을 만족하는tool-box 를 벌써 제공하고 있다 . 이 tool-box는 또한 양방향 서비스를 제공하기 위한 리턴 채널 (return channel) 을 지 원하고, 진보된 서비스 정보와 같은 보다 나은 정보를 표현할 수 있는 기능들을 지 니고 있다.

멀티미디어 홈 플랫폼(Multimedia Horne Platform:MHP) 은 이것에 더해 서비스 제 공자(Service Provider) 나 컨텐츠 제공자 (content Provider) 등으로부터 제공되어지 는 응용프로그램을 받아서 사용자에게 보여줄 수 있는 기술적인 해결책을 제공한 다.MHP 여기서 제공되어지는 응용 프로그램은 서로 다른 환경에서도 서로 이용이 가능해야 한다., 즉 하나의 플랫폼에서만 독립적으로 동작하는 전반적인 해결책 (Total Solution)이아닌서로다른플랫폼에서서로동작가능한일반적인해결책 , 이다.

여기서는DVB-MHP 플랫폼의 기본적인 구조와 Broadcasting 채널과 양방향 채널 의Transport Protocol, 사용될 컨텐츠의 포맷 , 응용프로그램의 시그날링 , DVB Java플랫폼 그리고 security 에 관해 설명하고 마지막으로 현재의 상황에 대해서 간략하게 논의하겠다.

-37- 2. Basic Architecture

그림 1 MHP Context

그림 2 External Interfaces between MHP and the outside world

2.1 Context

MHP는 간략히 그림 1 과 같은 컨텍스트로 구성된다 . MHP 의 소프트웨어는 스트림과 데이터의 흐름을 제어하고 데이터를 저장장치에 저장할 수 있다. 플랫폼은 바깥으 로 스트림과 데이터를 저장하거나 버리기 위해 전달할 수 있다. 플랫폼은 입력장치 뿐만 아니라 사용자에게 보여질 출력장치를 통한 출력 커뮤니케이션(output communication)들을 통해 입력을 받을 수 있다 .

-38- 또한 플랫폼은 다른 원격 장치(remote entities) 들과의 통신을 제어할 수도 있다 .

그림2 는 MHP 와 외부와의 가능한 외부 인터페이스들을 보여주고 있다 . MHP 터미 널은 브로드케스트 네트웍과 상호작용을 위한 인터렉티브 채널을 가지고 있다. 그 리고 내부적으로MHP 터미널이 제어할 수 있는 다른 자원과 다른 MHP 터미널과 의 연결을 이루고 있다.

2.2 Architecture

MHP모델은 다음과 같은 3 가지 계층으로 구성되어 있다 .

자원들(Resources)

시스템 소프트웨어 (System Software)

응용프로그램들(Applications)

이 모델에서는 전체 플랫폼 안에 하나이상의 하드웨어 개체가 존재할 수 있다. 응 용프로그램들과 시스템 응용프로그램의 관점에서 보여지는 시스템 소프트웨어 사이 에는API 가 존재한다 . 플랫폼안의 하드웨어 개체들은 많은 기능들을 포함하고 있 다.. 이 기능들을 하드웨어 자원이나 소프트웨어 자원으로 표현된다 여기서 논리상 의 자원들(logical resources) 이 어떻게 하드웨어 개체들에 매핑되는 지는 중요하지 않다.locally 하나의 응용프로그램이 단순히 하나의 개체의 요소들을 사용할 수 있 도록 해주어야만 한다는 점이 중요하다.

-39- 그림3 basic Architecture

응용프로그램들은 바로 자원들을 다루지 않는다. 응용프로그램의 호환성을 위해 시 스템 소프트웨어는 응용 프로그램을 하드웨어로부터 분리시켜준다. 시스템 소프트 웨어에 응용프로그램을 관리하는 기능들을 응용프로그램 관리자라 한다. 이 관리자 는 모든 프로그램의 라이프사이클(lifecycle) 을 관리하는 책임을 가지고 있다 .

2.3 MHP응용프로그램과 MHP 시스템사이의 인터페이스

응용프로그램들은 데이터베이스,,, 스트림미디어 디코더 컨텐츠 디코더 그리고 커뮤 니케이션과 같은settop-box 의 자원을 활용하기 위해 API 를 사용한다 . 이 자원들은 settop-box의 기능적인 개체이며 결국 하드웨어와 매핑 된다 .

그림4MHP 는 시스템 안에서의 인터페이스와 미디어와의 정보 흐름의 관계를 보여 주고 있다.API 모든 응용 프로그램들은 를 통해서만이 자원들을 사용할 수 있도록 하여 호환성을 유지시킨다.

-40- 그림4 Interfaces between an MHP application and the MHP system

3. Transport Protocols

DVB 규격은 이미 브로드캐스트 데이터와 인터렉티브 데이터의 전송이 가능하도록 하고 있다. 브로드캐스트 채널 계층은 MPEG-2 TS 를 기반으로 MPEG2 Section 을 변형한DSM-CC Section, Datagram Section, 그리고 DVB-SI (Service Information)등이 있다 . Carousel 방식을 위해 사용되는 DSM-CC Section 과 IP 를 기반으로 하는Multi Protocol Encapsulation (MPE) 방식을 위한 Datagram Section은 Data Broadcasting 을 위해 사용되고 , DVB-SI 는 MPEG2 Transport Stream에 포함된 서비스에 대한 정보를 포함한다 . MHP Application 은 브로드케스 트 채널 계층에서 위와 같은MPEG-2 Section 으로부터 정보와 데이터를 얻는다 .

인터렉티브 채널 계층은IP 를 기반으로 TCP 와 UDP 를 사용한다 . TCP 를 사용하는 경우에는DSM-CC UU 와 HTTP 가 올라갈 수 있다 . 응용프로그램들은 API 를 통해 인터렉티브 체널 계층으로 오는 데이터와 정보를 얻어 사용할 수 있도록 한다.

-41- 그림5BroadcastChannelProtocolStack

그림6 Interaction Protocol Stack

4. Content Formats

다른 종류의 컨텐츠 타입에 대한 포맷의 선택은 호환성을 위해 매우 중요하다. 다 음에 나열되는 포맷은MHP 에서 가능한 포맷이다 . static formats: PNG, JPEG, MPEG2 I-Frames, 1/2 audio clips, text.

Streaming format: MPEG-2 Video, MPEG-1/2 audio, subtitles

Resident fonts:특히 제한된 네트웍 대역폭을 가지는 경우 (e,g. terrestrial) 하나이 상의 폰트를 가지고 있어야 한다.

-42- Downloadable fonts: 내장된 폰트에 더해 서비스 제공자가 원하는 형식의 폰트를 보여주기 원하는 경우에 사용된다.(locator) 이것은 포맷과 로케이터 규격을 포함한 다.

HTML: XML로 전개되어질 수 있는 HTML 문서는 MHP 에서 컨텐츠 포맷으로 고려되 어진다. MHP 의 처음버젼에서는 MHP 응용 프로그램의 signaling 과 lifecycle 를 다 룬다.

5. Application Model

하나의 응용프로그램은 어플리케이션에 대한State Machine 은 ‘loaded’, ‘paused’, ‘active’, ‘destroyed’그리고 각각의 행동에 대한 state 를 가진다 .( 그림 7) 시스템은 어플리케이션들의 시작을 사용자의 입력이나 자동 시작되는 응용 프로그램에 의해 시작된다.MHP 동시에 여러 응용 프로그램들이 실행되어진다면 의 자원을 공유해야 만 한다. 스크린과 같은 한번에 하나의 응용 프로그램에게만 점유되어지는 자원이 있는 반면, 메모리와 같은 여러 응용 프로그램에 의해 동시에 공유되어질 수 있는 자원이 있다.MHP 에서는 하나의 서비스 제공자로부터 오는 여러 응용 프로그램들 사이의 상호작용을 고려한다.

그림 7 lifecycle for DVB-J applications

-43- 6. Application Signaling

DVB-SI(Service Information)에 더해 응용프로그램 시그날링 (Application Signaling)이 정의되어 있다 . 이것은 응용프로그램의 위치 , 관련된 데이터 , 요구되어 지는MHP 프로파일 , 요구되어지는 자원 , 자동시작이 되는지 , 그리고 관련된 응용 프로그램에 대한 정보들을 포함해서MHP settop-box 에 제공한다 .

7. DVB-J 플랫

DVB MHP는 다른 하드웨어와 소프트웨어 상에서의 일반적인 인터페이스를 제공하 기 위한VM(Virtual Machine) 개념을 사용한다 . 이 VM 은 Sun Microsystems 의 JAVA규격을 기반으로 하고 있다 .

이 시스템 소프트웨어는RTOS, 드라이버들 .

그리고 펌웨어(firmware) 들로 구성되어 있다 . 응용프로그램 매니저는 implimetation-specific하고 MHP 의 구성과 동작을 제어한다 . 응용프로그램 매니저 는 모든 서비스를 균등히 접근할 수 있도록 하는navigator 를 포함한다 .

DVB-J API는 다음과 같이 구분할 수 있다 .

SUN에서 정의한 JAVA APIs

Fundamental JAVA APIs(lang, util, beans… )

Presentation APIs(awt, JMF)

Service Selection APIs(JAVA TV)

HAVi에서 정의한 APIs

Presentation/GUI APIs

DAVIC메서 정의한 APIs

CA APIs

-44- Common Infra-Structure APIs

Tuning API, …

DVB에서 정의한 API

Extensions/restrictions to JAVA APIs

Data Access APIs

Service Information and Selection APIs

I/ODeviceAPIs

Security APIs

Other APIs(timer, user settings,… )

8. Security

Downloadable응용프로그램을 load 하고 시작하기 전에 , 컨텐츠 제공자를 확인하고 응용프로그램이 완전한지를 검증하는 것이 필요하다.MHP 에서는 저장되어 있는 증 명(certificate) 을 사용하여 유용화 되어질 수 있는 응용 프로그램들을 위해 전자 서 명(electronic signatures) 이있어야한다어떠한 . Certificate 는단지 public key 만을 포함하고 있어, MHP 안에서 아무런 secret information 을 필요치 않는다 . MHP 에서 는 응용프로그램 인증을 위한 기술적인 방법을 정의하고 있다.

-45- 제3 장 향후 동향 및 결론

제1 절 국제 표준의 향후 동향

1. DASE 의향후동향

DASE는 DVB-MHP 와 마찬가지로 Java 에 기반한 규격으로 플랫폼 독립성과 확장성 이 뛰어나다.10 방송 규격이 최소 년 이상의 기간동안 사용되어야 함을 전제로 하 면, 향후 기술 및 서비스의 발전을 수용할 수 있는 유연한 기술의 선택은 필수적이 라할수있다.

현재DASE 에서 가장 논란이 되고 있는 부분은 PE 관련 사항으로 , 다음과 같은 양 극단의 논리를 오가며 혼란이 지속되어 왔다.

“PE는하나의 CD (Content Decoder) 일뿐이다 .": PE 가 DASE 구조상하나의 CD 일 뿐이라면PE 가 다루게 될 ( 구체적으로 무엇이든 ) HTML 기반 컨텐츠의 규격을 결정하는 것은 부차적인 문제일 수 있다.Java 이러한 논리는 실행환경에 기반하여 정의된DASE 구조 상에서는 전혀 모순이 되지 않는다 . 그러나 PE 를 하나의 CD 로 일반화하는 시각은HTML 기반 컨텐츠의 중요성과 처리의 복잡성을 간과하고 있다 .

“PE는 완전히 독립적인 애플리케이션 형태이며 , PE~only 프로파일도 필요하다 ": 이 논리는(DVB-MHP 와 마찬가지로 ) 규격이 Java 실행환경 중심으로 결정되어 있 다는 사실과 상충되는 견해이다.PE 만의 프로파일은 데이터 방송의 의미와 가능성 을 지나치게 제한하여 데이터 방송의 성공을 위협할 수 있다.

사실 이러한 혼란은 기술적 문제 뿐만 아니라,Java 를 둘러싼 PC 진영과 가전업계 사이의 이해관계에 기인한 문제이다.DASE 우려되는 것은 이러한 혼란으로 인해 의 표준화 작업이 예상보다 지연되고 있다는 것이다.20003/4 최근의 전망은 년 분기 내 최종 규격의 승인이 가능할 것으로 보이나, 최악의 경우 일부 세부 항목에 대해 서는 그 이상의 지연이 발생할 수도 있을 것으로 예상된다. 그러나 이미 발표된 draft 만으로도 구현 및 시험 방송에 문제가 없어 보이므로 일정 상에 큰 문제는 없 다고 판단된다.

-46- 2. ATVEF 의향후동향

ATVEF의 규격 v1.1r26 은 단방향 데이터 서비스를 우선으로 하고 있으나 , 2000 년 말에는 자바와의 연동과 리턴 채널의 포함등을 통하여 쌍방향 서비스 형태로 발전 되어 갈 것이다.

ATVEF의 규격과 사업화 전개 방향은 전세계의 모든 데이터 방송 관련 규격과 조화 를 이루기 위해서 노력을 하고 데이터 방송 시장을 조기에 화성화한다는 것이다. 하지만ATVEF 가 미국의 MicroSoft 와 Intel 에 의해 주도되는 단체인 것처럼 보이기 때문에 미국의 마이크로Sun 사의 자바 버츄얼머신을 기반으로 하는 ATSC 의 DASE(Digital Application Software Environment, ATSC T3/S17)와경쟁관계에 있다는 많은 오해를 불식시켜야만 한다.1 앞서 장에서도 언급한 바와 같이 ATVEF 는 특정 업체에 의해 이끌려 가는 단체가 아니라160 여개의 전세계를 대표하는 업 체들로 이루어져 있다.ATVF 또한 라는 비영리 단체가 최근에 결성되어 사업화에 있어서도MicroSoft 사와 Intel 의 독주를 충분히 견제할 수 있다 . 오히려 DASE 규격 이Sun 사의 pJava 와 JavaTV API 를 포함하고 있기 때문에 향후 많은 로열티를 지 불해야 하는 위기에 처해질 수 있으며,1999 년에 출시하기로 하였으나 현재까지도 입수가 불가능한JavaTV API 의 시장 개방 시점에 DASE 의 데이터 방송 서비스 시 점이 결정되어질 수도 있기 때문에 실제 서비스의 시점을 예측하기가 힘들다.

여기서 중요한 점은 특정 서비스 규격단체들을 경쟁 관계라고 단정 짓는 것보다 서 비스 사업자들이 빠른 기간내에 인프라를 구축하여 서비스를 통해서 수익을 올릴 수 있는 현명한 선택을 부여하는 것이다., 이러한 관점으로 보면 규격의 간편성과 현실성을 갖춘ATVEF 는 DVB 및 다른 규격 단체들과 빠른 행보와 조화를 이루어서 전세계의 데이터 방송 서비스 사업에 막대한 기여를 것으로 예상된다.

3. DVB-MHP 의향후동향

현재 유럽에서는 각각 플랫폼 사업자를 중심으로 자신들만의 플랫폼을 가지고 방송 을하고있다. OpenTV 와 Canal+ 가현재많이사용되는플랫폼솔루션이다 . DVB-MHP는 공통된 누구나 사용하는 플랫폼 솔루션을 가지자는 목표 아래 규격작 업을 마무리 하고 있는 단계이다.

-47- DVB-MHP에는 BBC, 노키아 , NDS, Microsoft, OpenTV, Canal+ 등 많은 제조업 체,, 방송국 연구소들이 모여 작업을 하고 있다 . 그러고 각 회사들의 올해 연말을 기해 상용제품을 하나 둘씩 출시할 예정이다.DVB-MHP 를 전부 만족하기 위해서는 DASE와 마찬가지로 구현하는데 많은 시간이 필요할 것이다 . 그래서 3 단계의 프로 파일을 두고 단계적으로 접근해 나간다는 정책을 수립하고 있다.DVB-MHP 하지만 에서는HTML 을 plugin 형태의 옵션으로 두고 있다 . Java 플랫폼이 기본으로 채택되 어 가도록 스펙에서 규정하고 있다.DASE 이점이 와 다른점이기도 하다 .

현 상황에서는 부분적으로 만족하는 사업모델을 만들어 사업을 빠르게 시작하는 것 이 필요하다.DVB-MHP,ATSCDASE, 궁극적으로는 우리나라에서도 든 든 위성 지 상파,Cable 그리고 에서 통일된 오픈 플랫폼을 채택하는 것이 옳을 것이다 . 올바르 고 빠른 플랫폼 채택이 이와 관련된 모든 회사뿐만 아니라 사용자들에게 보다 나은 서비스를 제공하는데 있어 도움이 될 것이다.

제2 절 국내 방송의 향후 동향

국내 데이터 방송 표준화의 필요성은 방송사와 가전 업체들을 중심으로, 산발적으 로 제기되어 왔으나, 최근 "2002 년 월드컵 이전에 데이터 방송 본방송 실시 ” 라는 다소 공격적인 목표가 구체적으로 제시됨에 따라 본격적민 논의가 진행되고 있다. 이에 따라2000 년 내로 국내 데이터 방송 표준화 규격 내지는 시안이 확정될 예정 이며,2001 년에는 시험방송이 실시될 예정이다 . 국내 데이터 방송 규격 선정의 요 구조건은

국제적Open Standard 의 수용 및 정립

전송방식,H/W 및 S/W 플랫폼으로부터의 독립성과 컨텐츠의 재활용성

인터넷을 비롯한 향후 기술 발전의 수용성 및 확장성

컨텐츠및수신기제작용이성및경제성

등이다.ATSCDASE,DVB-MHP,ATVEF 결국 국내 데이터 방송 규격은 등과 같은 국제적 표준의 수용을 우선적으로 고려하게 될 것이며, 특히 지상파방송과 위성방 송 간의 데이터 방송 컨텐츠 공유가 중요한 이슈로 부각되고 있다. 단 국내 지상파 와 위성방송 기본규격이 각각ATSC 와 DVB 기반으로 이미 선정되어 있는 실정을 고려하여,. 프로토콜 관련 부분은 별도의 표준규격 선정이 불가피할 전망이다

-48- Embedded Real-Time Java Solution

서울대학교

-49- 목차

제1 장서론 제1 절 기술개발의 필요성 제2 절 기술개발의 목표 제3 절 주요개발 내용

제2 장 기술개발 내용 및 방법 제1 절 내장형 시스템을 위한 고려사항 제절2 VxWorks 상에 Kaffe 이식 제절3 VxWorks 상에 Personal Jaba 이식 제4PersonalJaba 절 내장형 리녹스 상에 이식 제5 절 내장형 실시간 시스템 지원을 위한 고려사항

제3 장결과 제1 절 자바 가상 기계의 무결성 테스트 제2 절 내장형 시스템의 적합성 제절요약3

논문 목록

부록

-50- 제장서론1

본 연구에서는iPCTV 아키텍쳐의 응용프로그램 수행환경으로서 자바 모델을 구성 하고, 내장형 실시간 시스템을 위한 자바 수행 환경을 제시하는 것을 목표로 한다.

제1 절 기술개발의 필요성

자바는 높은 이식성, 견고한 보안 체계 등의 장점에 힘입어 광범위한 컴퓨터 응용 분야에 사용되고 있다. 지금까지는 자바의 활용이 인터넷을 이용한 응용에 집중되 어 왔으나 향후 내장형 시스템 분야를 비롯한 산업 전 분야에 활용될 전망이다. 특 히 자바를 이용해 내장형 시스템에서 필요로 하는 응용 프로그램을 작성할 때 얻을 수 있는 이점은 다음과 같다.

￭ 이식성: 자바 표준에 따라 작성된 응용 프로그램은 자바 가상 기계 (JVM: Java Virtual Machine)를 비롯한 자바 수행 환경이 있는 플랫폼이면 수행이 가능하다 .

￭ 재사용성:. 자바는 객체 지향 패러다임을 따르므로 코드의 재사용성이 높다

￭ 동적 적응성: 일반적으로 내장형 시스템의 소프트웨어 응용은 읽기 전용 메모리 (ROM)에 저장되어 응용 프로그램의 기능이 수정 , 추가될 때 새로 ROM 을 만들어야 하지만 자바를 이용하면 수정된 바이트코드를 네트워크를 통해 다운로드 받아 수행 할수있다.

￭ 결합 허용성: 분산 시스템의 형태로 구현된 내장형 시스템의 경우 한 노드에 결 함이 발생하더라도 가용 상태에 있는 다른 노드에서 동일한 바이트 코드를 수행시 킴으로써 결함에 대처할 수 있다.

￭ 개발의 용이성:C 나 C++ 와 같이 시스템에 의존적인 CrossDevelopmentTool 이필요없다.

위와 같은 장점에 힘입어 다양한 형태의 내장형 시스템(, 감시 제어 시스템 디지털 set-top box등 ) 에 Java 의 적용이 고려되고 있으며 , 그 중에서도 지능적이며 양방 향 통신 기능이 부가된 지능형PCTV 와 같은 정보가전 기기의 핵심 부분인 디지털 셋톱 박스(settop-box) 에서 동작하는 응용 프로그램의 실행 엔진으로서 자바 가상 기계가크게주목받고있는것은이미주지의사실이다.

-51- 그러나, 내장형 시스템에 자바를 적용하기 위한 전제 조건으로는 다음과 같은 여러 가지 문제의 해결이 필요하다.

￭ 자바 가상 기계의 느린 수행 속도가 문제가 된다. 자바는 기본적으로 인터프리터 방식의 실행 엔진을 사용하므로,CC++ 기존의 나 에 비해 수행 속도 면에서 크게 뒤지게 된다.

￭ 자바는 동적 메모리 모델을 사용하므로 한정된 메모리를 가지는 내장형 시스템의 특성상 오프라인에 메모리 요구량을 예측하여 안정된 응용 프로그램을 구축하는 데 어려움이 있다., 따라서 메모리 요구량을 예측하고 이에 따라 가비지 수집 (garbage collection)이 응용의 성능을 저해하지 않으면서 충분한 메모리를 확보할 수 있는 메커니즘이 필요하다. 이를 위해 가비지 수집기는 쓰레드 스케쥴링과 연계 하여 설계하여야 한다.

￭ 일반적으로 내장형 시스템에서 동작하는 응용 프로그램들은 실시간 제약조건을 만족시켜야 하는 특성을 가지고 있으나, 현재의 자바는 실시간 특성을 표현하거나 실시간성을보장해줄수있는구조가아니다따라서프로그램레벨에서실시간., 특성을 표현할 수 있도록 실시간 확장 패키지를 제공하고, 자바 가상 기계에서는 실시간 태스크로 명시된 쓰레드의 시간 제약 조건을 보장해 줄 수 있는 프리미티브 (primitive)를 제공하여야 한다 .

이러한 한계를 극복하고 내장형 시스템에 자바를 적용시키려는 많은 노력들이 많이 이루어지고 있으며,, 본 연구에서는 기존의 연구결과를 정리 분석하고 내장형 시스 템의 제약조건을 만족할 수 있는 자바 솔루션을 제공하는 것을 목표로 한다.

제2 절 기술개발의 목표

본 연구에서는 이미97 년에 수행한 과제의 결과로 내장형 시스템에서 실시간 자바 응용 프로그램의 수행을 지원하기 위한 기초연구를 수행하였으며, 본 과제에서는 실시간자바수행환경구축및최적화연구를수행한다본연구의개발범위는. 기존의자바가상기계예( : Kaffe, PersonalJava) 의핵심요소들을내장형시스템 특성을 고려하여 특성화,.VxWorks, 최적화 하는 것이다 이를 위해 내장형 리눅스 와 같은 내장형 시스템을 위한 운영체제와LCD 디스플레이를 탑재한 MPC860 CPU보드로 구성된 내장형 시스템 테스트베드를 구성하고 , 그 위에 특성화된 자바 가상 기계를 이식하고 성능을 평가한다.

-52- 그림1 에서는 본 과제의 개발 목표인 내장형 시스템을 위한 자바 솔루션의 주요 구 성요소들을 보여준다.1 본 연구에서는 그림 의 각 구성요소를 내장형 시스템의 제 약조건과 특성에 맞게 커스터마이징하고, 실시간 응용을 지원하가 위한 확장 기능 구현 및 성능 최적화 작업을 수행한다. 다음은 본 연구의 세부 개발 내용이다

그림1. 내장형 자바 솔루션의 주요 구성 요소

￭ 다양한 내장형 플랫폼에 기존의JVM 을 이식 ➢ VxWorks상에 공개 JVM 인 Kaffe 이식 ➢ VxWorks상에 Sun PersonalJava 이식 ➢ 내장형 리눅스 상에PersonalJava 이식

￭ 자바 가상 기계의 동작 무결성 테스트 및 벤치마크 테스트 ➢ Kaffe에서 제공하는 테스트용 패키지를 이용한 테스트 ➢ Sun 사에서 제공하는 자바 호환성 검사 패키지를 이용한 테스트

￭ 실시간 응용 지원을 위한 기초 연구 및 프로토타입 구현 ➢ 실시간성 지원을 위해 스케쥴링 메커니즘과 결합된 가비지 수집기 설계 ➢ 실시간 쓰레드 지원을 위한 확장 기능 구현

-53- 제3 절 주요 개발 내용

다음은 본 연구의 주요 개발 내용을 요소별로 세분화한 것이다. 전체적인 개발방향 은 다양한 플랫폼의 특성에 맞게 자바 수행 환경의 각 구성요소를 특성화, 최적화 하기 위한 분석과 내장형 시스템의 특성을 고려하여 경량화, 실시간성 지원 등의 특성을 구현하는 것이다.

￭ 클래스 로딩 메커니즘 ➢ Romizing이 성능과 메모리 요구량에 미치는 영향 분석 ➢ 내장형 시스템 특성을 고려한 투명한 클래스 로딩 인터페이스 구현

￭ 실행 엔진 ➢ 바이트코드 인터프리터의 실행시간 개선을 위한 다양한 성능 벤치마킹

￭ 실시간 가비지 수집기 ➢ 실시간성 지원을 위한 가비지 수집기 설계 ➢ 가비지 수집기의 최악 수행시간 및 응답시간 분석기법 제안 ➢ 실시간 스케쥴링과의 연동 기법 제안

￭ 실시간자바쓰레드 ➢ RTOS의 태스크 관리 메커니즘을 이용한 실시간성 개선 ➢ 실시간 특성 표현을 위한 확장API 구현 및 VM 의 지원사항 구현

￭ 경량 윈도우 관리기를 이용한GUI 구현 ➢ AWT 기능 분석 및 필수부와 선택부 분리를 통한 경량화 ➢ 경량 윈도우 관리기(Microwindows) 를 이용한 경량 AWT 솔루션 구현

￭ 자바 수행 환경의 안정화 ➢ 호환성 검사 패키지를 이용한 안정성 검사 ➢ 전체 시스템의 코드 안정화 ➢ 시스템 안정화

-54- 제2 장 기술개발 내용 및 방법

제1 절 내장형 시스템을 위한 고려사항

본 절에서는 내장형 시스템을 위한 주요 고려사항에 대해 기술한다. 내장형 시스템 은 일반적으로 다음과 같은 특성을 가진다., 첫째 일반적으로 내장형 시스템에서 동 작하는 응용프로그램은 실시간 제약조건(real-time constraint) 을 가진다 . 즉 , 프로 그램 수행 결과의 논리적 정확성 뿐만이 아니라 결과를 미리 정해진 종료시한 내에 도출해야 한다.. 부가적으로 종료시한을 어긴 경우에 대한 처리도 수반되어야 한다 둘째,., 내장형 시스템은 한정된 메모리 용량을 가지고 동작한다 따라서 내장형 응 용에서 사용되는 메모리 양은 사전에 예측가능하여야 하며 메모리 접근과 관리에 따른 오버헤드에 의해 응용 프로그램의 실시간성이 저해되어서는 안 된다., 셋째 일 반적인 내장형 시스템은 하드 디스크 등의 대용량 보조 저장장치와 모니터와 같은 범용 디스플레이 장치를 탑재하지 않고 있다. 이와 같은 특성을 고려하여 내장형 실시간 시스템을 위한 자바 수행 환경을 구축하기 위해서는 다음과 같은 작업이 수 행되어야 한다.

￭ 클래스 로더 내장형 시스템은 일반적으로 하드 디스크와 같은 대용량 보조 저장장치를 가지지 않는다고 가정한다. 하드 디스크를 탑재한 범용 컴퓨터 환경에서는 자바 가상 기계 가 사용하는 핵심API 의 경우 zip 또는 jar 와 같은 압축파일의 형태로 파일시스템에 저장하고 필요할 때마다 메모리로 로딩된다. 따라서 내장형 시스템에서는 클래스 로더의 구현에 이식성과 융통성을 부여하면서API 에 제대로 접근할 수 있도록 메 모리 파일시스템이나 네트워크 파일 시스템을 구성하는 작업이 필요하다.

￭ 실시간 쓰레드 현재 자바는 실시간 특성을 표현하거나 실시간성을 보장해 주는 메커니즘을 제공하 지 않고 있다.,API 따라서 자바 레벨에서 실시간 특성을 표현할 수 있도록 실시간 확장 패키지를 제공하고 자바 가상 기계에서는 실시간 특성을 가지도록 명시된 쓰 레드의 시간 제약 조건을 만족시킬 수 있는 프리미티브들을 제공하여야 한다. 최근 에 실시간 자바 표준(The Real-Time Specification for Jave) 가 발표되었으나 아직 full-set으로 구현한 사례가 없으며 아직 안정화되지 않았으므로 이 표준에 따른 구 현은 추후 고려사항이다.

-55- ￭ 실시간 가비지 수집기 이미 언급한 바와 같이 내장형 시스템은 매우 적은 양의 메모리 한도 내에서 동작 하여야 한다. 이를 위해 오프라인에 응용 프로그램의 최대 메모리 사용량이 분석되 어야 하나 동작 메모리 모델을 사용하는 자바의 경우 이러한 사전 분석이 상당히 어렵다., 그러므로 동적 메모리 관리 ( 가비지 수집 ) 를 사용하는 환경에서 최악 메모 리사용량을일정한도내로바운드시킬수있는메커니즘이필요하다또한메모., 리 관리 루틴() 가비지 수집기 의 수행의 결과로 실시간 제약 조건을 가지고 동작하 는 응용 태스크들이 종료시한을 어기는 상황이 발생해서도 안 된다., 따라서 메모리 요구량을 최소화하면서 응용 프로그램의 시간 제약 조건을 만족시킬 수 있는 가비 지 수집기의 설계,. 구현이 요구된다

￭운영체제와의 인터페이스 자바는 플랫폼 독립적이라는 특성 때문에 하드웨어 의존적인 시스템 서비스를 사용 하기 위해서는 해당 플랫폼의 운영체제나 드라이버를 사용하기 위해 공식적으로 약 속된 인터페이스를 사용한다. 내장형 시스템은 일반적으로 실시간 운영체제 (RTOS: Real-Time Operating Systems)나 실시간 실행체제 (real-time executive) 를 탑재하고 있다., 공통적으로 이들은 경량이며 높은 정밀도를 가지는 타이머 짧은 문 맥교환 오버헤드, 실시간 스케쥴링 지원 등의 특성을 가지는 반면 상대적으로 범용 운영체제에 비해 제공하는 시스템 콜이나 라이브러리 등이 빈약하다. 내장형 시스 템을 타겟으로 하는 자바 가상 기계들도 범용 운영체제의 시스템 콜이나 라이브러 리를 가정하고 있는 경우가 많으므로RTOS 나 내장형 리눅스와 같은 경량 내장형 운영체제 상에서 자바 수행 환경을 구축하기 위해서는 운영체제에서 지원되지 않는 시스템 서비스들을 지원하기 위해 적절한 시스템 콜 매핑이나 새로운 함수의 구현 등이 필요하다.

￭ 경량 그래픽 사용자 인터페이스 기존의 범용 시스템에서는 사용자 인터페이스 지원을 위해X( 윈도우 유닉스 계열 ) 나MFC ( 윈도우 계열 ) 와 같은 윈도우 관리기와 GUI 개발 도구를 지원한다 . 그러 나, 이러한 접근 방법은 많은 양의 시스템 자원을 요구하므로 한정된 시스템 자원 을 가진 내장형 시스템에 적합하지 않다., 따라서 어느 정도의 플랫폼 독립성을 유 지하면서 한정된 시스템 자원으로 동작할 수 있는 경량 윈도우 관리기에 기반한 GUI개발이 필수적이다 .

-56- 제2 절 VxWorks 상에 Kaffe 이식

본 절에서는 자바 가상 기계를 실시한 운영체제(RTOS) 상에서 내장형 시스템에 포 팅하여 내장형 시스템을 위한 자바 솔루션을 위한 고려 사항을 추출해 본다. 자바 가상 기계는 소스가 공개된Kaffe 를 사용하였으며 실시간 운영체제는 VxWorks 를 채택하였다. VxWorks 는 RTOS 시장에서 시장점유율 면에서 지배적인 위치를 차지 하고 있으며 화성탐사선에 탑재될 정도로 그 안정성을 인정 받고 있다. VxWorks 의 또 다른 장점은 유닉스와 유사한 시스템 콜과 라이브러리를 제공하며GUI 방식의 개발환경,,, 강력한 디버깅 기능 실시간 특성 안정된 네트워크 솔루션을 제공하므로 응용 프로그램 개발이 용이하다는 점이다.

1. 개발 방향

개발에 사용한Kaffe 공개 버전은 범용 OS 만을 지원하고 있어 VxWorks 와 같은 RTOS를 지원하기 위해서는 VxWorks 에 가장 근접한 OS 인 리눅스로 Kaffe 의 환경 을 설정한 다음 리눅스의 시스템 콜과 라이브러리 루틴을VxWorks 에서 제공하는 것으로 대치해 나가는 상향식(bottom-up) 접근방법으로 연구를 진행하였다 . -60

2. 연구 진행 과정

내장형 시스템으로의 자바 가상 기계 이식을 위한 타겟 보드로는 MPC860(Motorola)를 채택하였다 . MPC860 보드의 사양은 대략 다음과 같다 . 50MHz MPC860 CPU, 16 MB SDRAM,내장 기본 512KB flash 메모리 , 시리얼 통 신 제어기, 이더넷 인터페이스를 기본 구성으로 한다 . 먼저 Kaffe 빌드 환경을 Linux(OS), powerpc(CPU)로 설정하였다 . 사용한 자바 가상 기계는 Kaffe 1.0beta2이며 Windows NT 호스트 상에서 Tornado 통합 개발환경을 이용해 개발 하였다. 먼저Kaffe 소스 코드에서 존재하는 리눅스용 시스템 콜과 라이브러리 루틴들을 VxWorks에서 제공하는 지원되는 것들로 바꾸어 갔다 . VxWorks 가 POSIX 표준을 지원하고 있고 유닉스에 기초를 두고 있기 때문에 대부분의 시스템 콜과 라이브러 리 루틴을 지원하고 있으나 지원되지 않는 것은VxWorks 의 시스템 콜과 라이브러 리 루틴의 조합이나 인자의 타입이나 결과 값의 타입을 맞추어 나가는 방법으로 연 구를 진행하였다.

-57- 그림2. 연구 진행 과정

3. 개발 내용

(1) VxWorks의기본구성

VxWorks는 입출력 시스템 , 파일시스템 , 네트워크와 태스크의 4 가지로 크게 분류할 수 있다. 대부분의 기능은 VxWorks 를 초기에 설정하는 초기화에서 이루어지고 동 적으로 설정하는 부분도 각 부분마다 지원을 하고 있다. 동적으로 설정하는 부분에 스는 디바이스 드라이버 설정이 이에 해당한다고 볼 수 있다.

(2)각 구성 요소에 따른 VxWorks 와 Linux 간의 대치

￭ 입출력 시스템 VxWorks입출력 시스템은 basic I/O 와 buffered I/O 로 구성이 되어 있다 . 디바이스 드라이버의 내장함수를 호출하는basic I/O 함수는 유닉스 호환이며 buffered I/O 는ANSI 호환이다 . basic I/O 시스템 콜과 buffered I/O 시스템 콜은 모두 VxWorks에서 지원하며 동일한 기능을 수행하고 인자 및 결과 값이 정확히 일치하 여 별도의 수정 없이 사용해도 무방하다.

-58- ￭로컬 파일시스템 VxWorks는 실시간 시스템에서 블록 디바이스를 사용하기에 적절한 두 가지의 파일 시스템을 제공한다.MS-DOSRT-11 그 한가지는 호환 파일 시스템과 파일 시스템 이다.KAFFE 파일 시스템은 를 포팅하는 데 있어서 매우 중요한 부분을 차지한다 . 자바 가상 기계는 클래스 파일들이 메모리에 로딩된 상태에서 수행할 수 있기 때문 이다. 연구의 기본 방향이 일단은 리눅스를 포팅 환경으로 설정했기 때문에 리눅스 파일 시스템이 제공하는 기능을 그대로 유지해야 한다는 제약이 있다. VxWorks 에 서제공하는파일시스템중MS-DOS 호환파일시스템이이러한조건에비추어 볼 때 가장 적합하다. 클래스 파일을 로딩하는데 있어서 파일 시스템에서 문제점이 될수있는부분이서로다른파일시스템간의경로표현의차이를들수있다. 일반적으로DOS 파일 시스템의 경우 파일 이름이 8.3 convention 으로 제한되어 있으며 소문자를 파일 이름으로 사용할 수 없다는 제약을 가지고 있으나 VxWorks 에서 제공하는dosFs 는 이러한 문제점을 고려하지 않아도 된다 . 디스크의 초기화 는MS-DOS 5.0 을 정의된 boot sector field 를 그대로 사용하며 , FAT 는 12 나 16 을 사용한다. 디스크의 초기화는 DOS_VOL_CONFIG 라는 자료 구조의 데이터 필드를 dosFsDevInit( )을 사용하여 초기화를 한다 . VxWorks 는 태스크를 사용자 태스크 (user task)와 루트 태스크 (root task) 로 나누는데 dosFsDevInit 은 시스템이 부팅을 한 뒤 수행되는 루트 태스크에서 수행이 이루어진다. 또 한 가지 고려해야 할 점은 일반적인 내장형 시스템에서는 하드 디스크와 같은 대용량 블록 디바이스를 고려하지 않고 있다는 점이다., 따라서 이를 대체하면서 파 일 시스템 접근 루틴을 그대로 사용할 수 있는 대안을 고려해야 한다. 대안으로 고 려할 수 있는 것은 플래쉬 메모리를 이용한 플래쉬 파일 시스템(FFS: Flash File System)과 메모리의 일부분을 디스크처럼 사용하는 램 디스크 (ram disk) 를 사용하 는 방법이다. 본 연구에서는 네트워크 파일 시스템과 램 디스크를 이용한 접근방법 을 사용한다.- 부트 업과 동시에 사용이 가능한 플래쉬 파일 시스템과 달리 램 디스 크를이용할경우에는클래스파일들을네트워크파일시스템으로연결된원격파 일 시스템으로부터 램 디스크로 복사하는 작업이 필요하다., 따라서 초기화 과정 ( 부 트-) 업 과정에서 발생하는 초기 지연 시간이 늘어나는 단점이 있지만 그 이후부터 는 메모리에서 클래스 파일을 접근하기 때문에 성능이 향상될 수 있다. VxWorks 에 서는 다음과 같이 램 디스크를 지원한다. VxWorks 는 램 디스크를 설정하기 위해서 ramDevCreate()라는 라이브러리 함수를 제공한다 . 이렇게 생성된 디스크를 dosFs 와 연결하려면dosFsMkfs() 를 사용하면 된다 . 램 디스크를 생성하고 dosFS 를 설정 하는 과정은 다음과 같다.

-59- 위와 같은 접근방법을 쓸 때 클래스 로딩을 위한 초기화 단계를 정리하면 다음과 같다. - ramDevCreate()를 이용해 램 디스크 설정하고 dosFsMkfs() 로 dosFs 설정 - nfsMount()와 nfsAuthUnixSet() 을 이용하여 클래스 파일을 저장하고 있는 원격지 파일 시스템을NFS 로 연결 -NFS로 연결된 원격 파일 시스템으로부터 램 디스크에 설정된 파일 시스템으로 클래스 파일(classes.zip) 복사 -자바 가상 기계 초기화 과정에서 putenv() 를 이용해 CLASSPATH 를 램 디스크에 잡힌 파일 시스템 상의 경로로 설정

위의 과정을 거치고 나면 자바 가상 기계의 다른 부분 수정 없이 클래스 로딩에 관 련된 작업을 동일하게 수행할 수 있다.

￭ 쓰레드 스케쥴링 Kaffe의 쓰레드 스케쥴링은 사용자 수준으로 구현되어 있다 . 따라서 , 이 버전에서는 일단VxWorks 의 태스크 스케쥴링 메커니즘을 사용하지 않고 사용자 레벨 쓰레드를 포팅하였다. 쓰레드의 중지 후 재개에 필수적인 alarm() 시스템 콜이 VxWorks 에서 지원되지 않는 관계로alarm() 함수를 새로 구현하였다 . 구현된 alarm() 함수의 내 용은 부록에 첨부한다.

￭ 네트워크 VxWorks는 4.3 BSD Tahoe Unix network facility 와 완벽하게 호환되며 Socket, Remote Procedure Calls, Remote File Access, File Export, Remote Command Execution등의 다양한 네트워크 기능을 지원한다 . Kaffe 에서의 네트워크 관련 시 스템 콜 및 라이브러리 함수들과 대부분 동일한 기능을 수행하고 인자 및 결과값이 정확히 일치하여 별도의 수정 없이 사용해도 무방하다.

￭ 내이티브 메쏘드 호출 Kaffe에서는 내이티브 메쏘드 호출을 플랫폼 의존적인 어셈블리 코드로 작성한다. 이식 작업 당시Kaffe 에서는 Powerpc 계열 CPU 를 완벽하게 지원하지 않는 상태여 서 아래와 같이 새롭게 내이티브 메쏘드 호출 투틴을 작성하였다. 구현에서 범용 레지스터r3-r12 를 인자 저장용으로 사용하였으나 컴파일러에서 이들 레지스터들을 안전하게 예약해 두는 것이 보장되지 않는 관계로 수행 중에 인자값이 변경되는 문 제점이 발생하여 별도로r13 레지스터를 백업용 레지스터로 사용하였다 . 실제 구현 내용은 부록에 첨부한다.

-60- ￭ 기타 기타 내이티브API 에서 사용하는 시스템 콜들은 대부분 유사한 기능을 가진 시스템 콜로 대치하였다. 예를 들면 IEEE 754 표준에 관련된 remainder() 같은 경우 거의 유사한 기능을 수행하는fmod() 를 이용하여 구현하였다 . 그밖에 유닉스 프로세스 관련API 들은 VxWorks 에서 전혀 지원이 되지 않으므로 구현되지 않았다 .

제3 절 VxWorks 상에 PersonalJava 이식

본 절에서는Sun 사에서 내장형 시스템 환경에서 동작하기 적합한 형태의 자바 수 행 환경으로 제시한PersonalJava 를 RTOS 를 탑재한 내장형 시스템에 이식하고 동 작의 논리적 정확성을 검증한 내용에 대해 기술한다.

1. 개발 방향

PersonalJava는 윈도우즈와 솔라리스 두 가지 운영체제용 소스가 공개되어 있다. 대상 플랫폼에 사용된RTOS 인 VxWorks 는 범용 유닉스 프로그래밍 인터페이스와 유사한 환경을 지원하며, 특히 POSIX 1003.b 실시간 운영체제 확장 표준을 대부분 지원한다. 따라서 , 본 연구에서는 PersonalJava 의 솔라리스용 소스 코드를 토대로 작업을 진행하였다. 본 연구에서 주요 작업 대상으로 삼은 것은 자바 쓰레드의 성능향상과 신뢰성 향상 을 위해 자바TM 레드를 VxWorks 의 태스크에 매핑하는 것이다 . 또한 , 2 절에서 언급 한바와같이솔라리스와VxWorks 에서지원하는시스템콜과라이브러리의기능 차이를 고려한 상향식 개발 방식을 채택하였다., 또한 타겟 시스템이 디스플레이 장 치를 탑재하고 있지 않은 점을 고려하여AWT 기능 구현은 고려하지 않았다 .

2. 연구 진행 과정

개발에 사용된 시스템의 사양은 표1.CPU 과 같다 는 모토롤라 사의 PowerPC 코 어를 가진MPC860 이며 50MHz 로 동작한다 . 메모리는 16 MB DRAM 이다 . CPU 내 에 이더넷 컨트롤러가 내장되어 있으며, 개발 호스트는 직렬 포트를 이용해 통신한 다. 운영체제로는 VxWorks 5.3.1 버전을 사용하며 가상 메모리는 지원하지 않는다 . 개발 환경은Windows NT 상에서 동작하는 Tornado 통합 개발 환경을 이용한다 .

-61- 표1. 대상시스템의사양 속도 50MHz 캐 쉬 Disable CPU 이더넷 컨트롤러, 통신 기능 시리얼 통신 지원 메모리 크 기 16 MB 일반 DRAM 크기 3MB 램드라이브 파일 시스템FAT 파일시스템 긴 파일 이름 지원 블록 크기 512 bytes 버젼 5.3.1 커널 크기 1.4 MBTCP/IP 지원 VxWorks 가상메모리 지원하지 않음 MMU disable 개발 툴 Tornado 1.0.1

개발 과정은Kaffe 의 경우처럼 솔라리스 VxWorks 에서 지원하는 시스템 콜과 라이 브러리 함수를 비교하여, 유사한 함수로 대치하거나 새로 구현하는 형태로 진행하 였다.

3. 개발 내용

(1) 환성 설정 작업

Kaffe의 경우와 달리 PersonalJava 의 경우 빌드 과정에서 유닉스 의존적인 시스템 유틸리티를 사용하는 것을 가정하고 있는 부분이 많으므로 클래스 라이브러리 생성 등과 같이 결과물이 플랫폼 독립적인 부분은 솔라리스에서 생성한 것을 고정적으로 이용하도록 하였다., 또한 솔라리스에서 계층적으로 구성된 MakefileVxWorks 들을 cross development환경에서 사용하기 용이하도록 하나의 Makefile 로 통합하고 VxWorks BSP에서 필요로 하는 부분을 추가하였다 . 또한, VxWorks 에서 shared library 의 사용이 여의치 않아 static library 형태로 바이 너리를 빌드하기 위해Tornado 에서 제공하는 심볼 테이블 생성 기능을 이용하여 명시적으로 심볼 테이블을 생성하도록 하였다. 생성된 심볼 테이블은 클래스 파일 수행 중에 내이티브 메쏘드를 호출하는 데 필요한 핸들을 찾는 데 사용된다. 그밖에타겟CPU 인 MPC860 이하드웨어 FPU(Floating Point Unit) 를가지고있지 않으므로floating point 연산 지원을 위해 컴파일 옵션으로 - msoft-float 를 추가 하였다.

-62- (2) PersonalJava의 구조 및 주요 포팅 부분

PersonalJava는 그림 3 과 같은 구조를 가지고 있다 . 그림 3 에서 보는 바와 같이 자 바 수행 환경은 호스트 프로그래밍 인터페이스 (HPI : Host Programming Interface)를 기준으로 플랫폼 독립적인 부분과 플랫폼 의존적인 부분으로 구분되며 포팅 작업은 플랫폼 의존적인 부분을 수정하는 작업 위주로 구성된다. 주요 포팅 부분은 다음과 같다.

￭ 쓰레드와 모니터 ￭ 내이티브 메쏘드 호출 ￭ 주요 내이티브API 구현

그림3. PersonalJava 의 구조 및 주요 포팅 작업

(3) 쓰레드와 모니터 구현

본 연구에서는VxWorks 에서 제공하는 태스크 스케쥴링과 태스크간 통신 (IPC) 메커 니즘을 이용해 자바 쓰레드 패키지를 구현한다. 여기서는 VxWorks 의 태스크 스케 쥴링과IPC 메커니즘에 대해 간략하게 언급하고 , 쓰레드와 모니터 구현 내용에 대 해 설명한다.

-63- 가. VxWorks 의 태스크 개념과 IPC

기본적으로VxWorks 는 멀티태스킹 환경을 지원한다 . 멀티태스킹을 지원하는 다른 OS들과 태스크들이 가질 수 있는 상태와 상태 전이 방식은 거의 동일하며 두 가지 의 스케쥴링 방식을 제공하고 있다. 제공되는 스케쥴링 정책 중 하나는 우선순위 기반 선점 스케쥴링(Preemptive priority scheduling) 방식과 또 다른 하나는 라운 드 로빈 스케쥴링(Round-robin scheduling) 방식이다 . 우선순위 기반 선점 스케쥴 링 방식은 낮은 우선순위를 가진 태스크가 수행 중에 높은 우선순위를 가진 태스크 에 의해서 선점되어서 높은 우선순위의 태스크가 실행을 다 끝마치고 난 후에 낮은 수선순위의 태스크가 나머지 부분을 수행하는 방식이다. VxWorks 의 커널인 wind 에 서는256 개의 우선순위 레벨을 가지고 있으며 낮은 값을 가지는 태스크가 우선순 위가 높다. 또한 수행 중에 태스크의 우선순위를 taskPrioritySet( ) 함수를 이용해 변경할 수 있다. 하지만 우선순위 기반 선점 스케쥴링 방식은 동일한 우선순위를 가지는 태스크들에 대해서는 한 태스크가 종료할 때 까지 태스크가pending 되어야만 한다는 것이 문 제가 된다. 따라서 VxWorks 에서는 동일한 우선순위의 태스크들의 스케쥴링을 하기 위해서 라운드 로빈 방식을 제공한다., 즉 동일한 우선순위를 가지는 태스크들에게 타임 슬라이스(time slice) 를 주어서 균등하게 스케쥴링을 하도록 한다 . 또한 태스 크를생성하는taskSpawn() 함수내에서생성되는태스크의여러가지속성을부 여할 수 있다는 점도 특징으로 들 수 있다. VxWorks에서는 IPC 방법으로 5 가지를 제공해 주고 있다 . 각각을 나열해 보면 다음 과 같다. ￭ Shared memory : 공유 데이터 영역 사용 ￭ Semaphore:임계영역 (critical section) 에대한상호배제 (mutual exclusion) 와 태스크간 동기화 -이전 세마포어 (Binary Semaphore) -상호배제 세마포어 (Mutual- Exclusion Semaphore) -계수 세마포어 (Counting Semaphore) ￭ Message queue와 pipc ￭ Signal : 예외 상황처리 ￭ Socket and Remote Procedure Call (RPC)

-64- 나. VxWorks 태스크를 이용한 자바 쓰레드 구현

자바 쓰레드의 구현은 크게 쓰레드 부분과 모니터 부분으로 나누어 볼 수 있다. 먼 저 쓰레드 부분을 살펴보면,PersonalJava 에서의 자바 쓰레드는 커널 수준의 태스 크를 이용한 구현과green 쓰레드라 불리는 사용자 수준 쓰레드 패키지를 이용한 구현의 두가지 형태를 지원한다. 본 과제에서는 VxWorks 의 태스크와 자바 쓰레드 간의1:1 매핑 방법을 취하였다 . 그 이유는 green 쓰레드의 안정성에 대한 우려가 제기되고 있고, VxWorks 의 태스크 관련 기능이 매우 효율적이라 판단했기 때문이 다. 구현을 위해 먼저 우선순위 매핑을 고려하여야 했다 . 자바 쓰레드는 1~10 의 우선순위를 가지고 있다.1 이 가장 낮은 우선순위이며 ,10 이 가장 높다 . 반면 VxWorks는 0~255 의 우선순위를 가지고 있으며 , 0 이 가장 높고 255 가 가장 낮다 . 본 관계에서는VxWorks 의 우선순위 95 를 자바 쓰레드의 우선순위 10 에 , 그리고 104를 자바 쓰레드의 1 에 할당하였다 . 대부분의 구현 내용은 thread_md.c 파일에 있으며,. 주요 함수들의 구현 내용은 다음과 같다

￭ static void * _start(void *tid_) :자바 쓰레드의 엔트리 함수로서 , VxWorks 태스 크의 초기화 루틴이 추가되었다. ￭ sysTfreadCreate() :자바 쓰레드를 생성하는 함수로서 , VxWorks 의 taskSpawn() 을 이용하여 구현하였다. ￭ sysThreadExit()와 sysThreadKill(): 자바 쓰레드를 종료 / 제거하는 함수로서 , VxWorks의 taskDelete() 를 이용하여 구현하였다 . ￭ sysThreadSuspend() :자바 쓰레드를 정지시키는 함수로서 , VxWorks 의 taskSuspend()함수로 구현하였다 . ￭ sysThreadResume() :정지된 자바 쓰레드를 활성화시키는 함수로서 , VxWorks 의 taskResume()을 이용하였다 .

다음으로 모니터 부분의 구현을 살펴보겠다. 주요 구현 부분은 mutex_md.c, condvar_md.c, moniter.c, vx_sync.c에 있다 . 자바 쓰레드는 동기화 방법으로 모니 터를 사용한다. PersonalJava 에서는 mutex 와 조건변수를 이용하여 모니터를 구현 하고 있다.,VxWorks 반면 에서는 동기화 방법으로 세마포어를 제공하고 있다 . 따라 서VxWorks 의 상호배제 세마포어를 이용하여 mutex 를 구현하고 , 이전 세마포어를 이용하여 조건변수를 구현해야 했다. 특히 Solaris 의 조견변수는 사건 발생을 기다 리며 대기하고 있는 중에 시그널이 발생하면,,VxWorks 바로 리턴하지만 의 세마포 어 메커니즘을 이용하는 경우 리턴하지 않기 때문에 시그널 핸들러에서 바로 리턴 하도록 구현해야 했다.. 다음은 주로 구현 내용이다

-65- ￭ coud_init() :조건 변수를 생성하고 초기화한다 . VxWorks 의 semBCreate() 을 이 용하여 구현하였다. ￭ cond_destroy() :조건 변수를 제거한다 . VxWorks 의 semDelete() 으로 구현하였 다. ￭ coud_wait() :조건 변수에 대한 대기 함수이다 . 현재 잡고 있는 mutex 를 놓고 , 조건 변수를 표현하는 세마포어를 잡아야 한다. VxWorks 의 semGive() 와 semTake()을 이용하여 구현하였다 . ￭ coud_signal() :조건 변수에 대해 대기하고 있는 쓰레드들을 깨운다 . VxWorks 의 semGive()를 이용하였다 . ￭ mutexInit() : mutex를 생성하고 초기화한다 . VxWorks 의 semBCreate() 을 이용하 였다. ￭ mutexDestroy() : mutex를 제거한다 . VxWorks 의 semDelete() 을 이용하였다 . ￭ mutexLock() : mutex를 잡는다 . VxWorks 의 semTake() 을 호출하였다 . ￭ mutexUnlock() : mutex를 놓는다 . VxWorks 의 semGive() 을 호출하였다 . ￭ mutexLocked() : mutex가 잡혀있는지 검사한다 . VxWorks 의 semTake() 을 NO_WAIT옵션과 함께 호출하였다 .

(4) 내이티브 메쏘드 호출

자바에서 기본적으로 제공하는 핵심API 에 속한 메쏘드 중 상당수는 C 언어로 작 성된 내이티브 메쏘드이다., 따라서 자바 가상 기계에서는 이러한 내이티브 메쏘드 들을 미리 정의된 인터페이스를 이용해 호출해 주는 부분을 가지고 있어야 한다. 본 연구에서 내이티브 메쏘드 호출과 관련해서 작업을 수행한 부분은 크게 두 가지 로 나눌 수 있다. 첫 번째는 동적 링킹 대신 정적 링킹을 사용하는 관계로 필요한 작업을 들 수 있으며, 두 번째는 실제 내이티브 메쏘드 호출을 수행하는 sysInvokeNative()함수의 수정이다 .

-66- 가. 정적 링킹을 위한 환경 설정 및 소스 수정

이미 언급한 바와 같이 정적 링킹을 이용할 때 내이티브 메쏘드에 대한 핸들을 수 행 중에 얻어 오기 위해서는 먼저 심볼 테이블을 구성해야 한다. 심볼 테이블 작성 은Tornado 통합 개발환경에서 제공하는 makesymtbl 유틸리티를 이용하였다 . 생 성된 심볼 테이블은symTbl.c 파일에 저장되고 실행 바이너리에 링킹되어 사용된 다. 프로그램수행중심볼테이블을이용해내이티브메쏘드의핸들을얻어오는 부분은 다음과 같이 구현하였다. 동적 링킹을 사용하는 솔라리스용 코드에서는 dlopen(), dlsym(), dlclose()와 같은 함수를 이용하여 이러한 작업을 수행한다 . 본 연구에서는 기존의 인터페이스를 최대한 유지하면서 심볼테이블을 이용한 정적 링 킹을 사용하기 위해dlopen(), dlsym(), dlclose() 등의 함수를 VxWorks 의 module 라이브러리를 이용해 구현하였다. 위의 함수 정의는 vx_module.c 에 있으며 , 그 내 용은 부록에 첨부한다.

나. 내이티브 메쏘드 호출 함수 수정

앞에서 언급한 바와 같이 내이티브 메쏘드 호출은sysInvokeNative() 함수를 통해 서 이루어진다. 본 작업에 사용된 참조 코드는 솔라리스를 기준으로 작성된 것으로 Spare CPU를 대상으로 최적화된 어셈블리 코드 형태로 sysInvokeNative() 함수가 구현되어 있다. 따라서 , 타겟 보드의 MPC860 CPU 를 고려할 때 PowerPC 에 최적 화된 어셈블리 코드를 사용하는 것이 성능면에서 이점을 가지지만 이 작업은 상당 히 많은 시간을 요구하며 다른 플랫폼으로의 이식을 고려할 때C 언어로 작성하는 것이 적절할 것으로 판단하고C. 언어로 작성된 함수를 수정하였다 수정시 고려사 항은 자바에서의long 타입이나 double 타입은 64 비트라는 점이다 . 즉 , 앞의 두 가 지타입중하나를가진변수가메쏘드의인자로넘어오게되면이변수는자바스 택에서2( 개의 슬롯 하나의 슬롯은 32)., 비트 을 차지하게 된다 그러나 수정을 위해 사용된 참조 코드에서는 해당 내이티브 메쏘드를 호출하는 데 있어서 자바의 long 타입이나double 타입의 인자가 넘어오더라도 하나의 슬롯만 복사하도록 되어 있 다., 따라서 이 경우에는 나머지 슬롯에 쓰레기 값이 넘어가서 프로그램 수행 결과 에 영향을 미치게 된다. 이러한 문제를 해결하기 위해 sysInvokeNative() 함수 내부 에서 인자의 타입을 검사하여2 개의 슬롯을 필요로 하는 long 이나 double 타입의 인자이면2. 개의 슬롯에 정확하게 인자값이 복사될 수 있도록 수정하였다 수정된 sysInvokeNative()함수의 내용은 부록에 첨부한다 .

-67- (5) 기타 포팅 작업 내용

기타 포팅에 관련된 주요 작업 내용은 솔라리스와VxWorks 의 환경 차이에서 오는 문제들을 해결하는 내용이다. 예를 들어 클래스 라이브러리 로딩과 관련되어 클래 스 파일이 저장된 경로는CLASSPATH 라는 환경 변수에 저장되고 자바 가상 기계 는 이 변수로부터 클래스 파일의 저장 경로를 읽어 와서 클래스 로딩을 수행한다. 그러나, VxWorks 에서는 이러한 환경을 가정할 수 없으므로 클래스 경로를 명시적 으로 변수에 저장해야 한다. 또 한 가지 , floating point 연산에 관련하여 자바는 IEEE754표준을 따르고 있다 . 이에 관련된 주요 변수들이 저장된 헤더 파일이 서 로 다른 문제와 정의되지 않은 변수들에 대한 재정의가 이루어져야 한다. 이를 위 해 정확하게 구현되지 않은 몇 가지 함수와 매크로를 새로 정의하고, 용법에 차이 가 있는 변수들은 수정하였다.. 자세한 내용은 부록에 첨부한다

제4PersonalJava 절 내장형 리눅스 상에 이식

본 절에서는PersonalJava 를 개방성 , 견고성 , 유연성 등의 장점을 지닌 Embeeded Linux에 이식하여 내장형 시스템을 위한 자바 솔루션을 구현할 때 필요한 고려 사 항을 추출한다.RTOSBSP 상용 가 나 디바이스 드라이버와 개발 환경의 구입에 많 은 비용이 소요되고, 주요 기능이 바이너리 형태로 제공되어 운영체제의 동작을 수 정하거나 새로운 기능을 추가하는 것이 어렵고,BSP 최신 기술에 대한 의 자원이 상대적으로 늦는 반면,GNU 내장형 리눅스는 공개 소프트웨어인 개발 도구를 사용 하고, 소스 코드가 공개되어 있어 운영체제의 기능을 수정하는 것이 가능하며, 전세 계의 수많은 개발자들에 의해 최신의 하드웨어, 소프트웨어 기술이 지원되는 등 많 은 장점을 지니고 있어 기존RTOS 의 대안으로 떠오르고 있다 . 하지만 , 기존 RTOS 보다 메모리 요구량이 크고, MMU 기능이 없는 간단한 구조의 프로세서에는 이식하 기 어렵다는 단점도 있다.,, 그러나 위에 언급했듯이 확장성과 유연성 그리고 저비 용의 측면에서 기존RTOS 를 사용하는 것보다 유리하다고 볼 수 있다 .

1. 개발 방향

(1)일단 내장형 리눅스가 아닌 데스크탑용 리눅스 (i386 CPU) 에 솔라리스용 PersonalJava소스 코드를 이식한다 . 이 과정에서 OS( 리눅스 ) 의존적인 부분의 이 식을 마친다. (2)앞의 (1) 단계 이식을 마친 PersonalJava 를 내장형 리눅스 (CPU:powerpc) 에 이 식한다. 이 과정에서는 CPU (powerpc) 의존적인 부분에 대한 이식이 대부분을 차 지한다.4. 최종 개발환경은 그림 와 같다

-68- 그림4 개발 환경

-:Linux.GNUcompiler2.95.2호스트개발환경 -타겟 보드 : MPC860 evaluation board -자바 가상 기계 : PersonalJava 3.1

내장형 시스템으로의 자바 가상 기계 이식을 위한 타겟 보드로는MPC860( 모토롤 라) 를 채택하였다 . MPC860 보드의 사양은 대략 다음과 같다 . 50MHz MPC860 CPU, 64 MB SDRAM,내장 기본 8MB flash 메모리 , 256KB SGRAM, 4KB instruction/data캐쉬 , 시리얼 통신 제어기 , 이더넷 인터페이스를 기본 구성으로 한 다.

-69- 2. 연구 진행 과정

PersonalJava를 데스크탑용 리눅스 (CPU :i386) 에 이식하는 작업을 먼저 진행하여 OS에 의존적인 부분을 수정한 이를 다시 powerpc 용 내장형 리눅스에 이식하는 작 업을 진행하여CPU 에 의존적인 부분을 수정하는 방식으로 연구를 진행하였다 ( 그림 5).참고 이는 데스크 탑 환경에서 개발이 용이함에 착안하여 대부분의 작업을 데스 크탑 개발환경에서 진행하고CPU 에 의존적인 부분만을 목표 보드 환경에서 진행하 기위함이었다내장형리눅스에. PersonalJava 를이식하는작업은 powerpc 용크로 스 컴파일러를 이용하였다., 즉 그림 4 의 리눅스 (NFS) 서버에서 소스 코드 수정 작 업을 하고powerpc 용 크로스 컴파일러를 통해 컴파일하고 , 목표 보드는 NFS 를 통 해 리눅스서버에 접근하여 컴파일을 통해 생성된PersonalJava 실행 이미지를 실 행시키는 방식이다.

그림5 연구 진행 과정

-70- 내장형 리눅스는 범용 유닉스와 유사한 시스템 콜과 라이브러리 함수를 지원하고 있어 대부분의 이식 작업은 쓰레드 관련 부분에 집중되었다. 내장형 리눅스에 이식 하는PersonalJava 는 어떤 쓰레드 패키지를 사용하는가에 따라 green-thread 버전 과native-thread 버전으로 나뉜다 . 본 연구에서는 두 가지 버전의 PersonalJava 를 모두 내장형 리눅스에 이식하였다. 따라서 전체적인 작업은 크게 green-thread 관 련 작업과native-thread 관련 작업으로 분리할 수 있다 . 또한 , 마이크로윈도우즈를 이용한AWT 의 구현도 중요한 작업으로 따로 분리된다 .

3. 개발 내용

(1) 멀티 쓰레딩 지원

자바는 멀티 쓰레드를 지원한다. 응용 프로그램을 병렬적으로 수행함으로써 응용 프로그램의 수행 속도를 향상시킬 수 있는 멀티 쓰레드 기법은 크게 다음의 세가지 형태로 구분할 수 있다. ￭ 다대일(Green-Thread) ￭ 일대일 ￭ 다대다(Native-Thread)

솔라리스용PersonalJava 는 위의 다대일 (Green-Thread) 버전과 다대다 (Native-Thread)버전을 지원하고 있다 . 본 연구에서도 위의 두 버전을 모두 내장 형 리눅스에 이식하였다.

가다대일. (Green Thread)

다대일의 의미는 많은 수의 유저 쓰레드들이 하나의 커널 쓰레드에 매핑된다는 의 미다., 즉 한 응용 프로그램 내의 여러 유저 쓰레드들이 하나의 커널 쓰레드를 통해 커널에 접근한다. 이 모델에서는 모든 쓰레드들의 활용이 사용자 영역에서 이루어 지므로‘’. 유저레벨 쓰레드 라고도 불린다 이 모델에서는 응용 프로그램이 병렬적 으로 수행시킬 쓰레드를 임의의 개수만큼 생성하는 것이 가능하다. 그러나 하나의 커널 쓰레드를 통해 한 응용의 모든 유저 쓰레드들이 커널에 접근해야 하기 때문 에, 하나의 유저 쓰레드로 인해 커널 쓰레드가 블럭되면 응용 프로그램 전체가 블 럭되어버린다따라서이기법은제한된범위내에서만병렬성을제공하고다중., 프로세서 환경에는 사용될 수 없다. 이 모델은 솔라리스 환경에서 자바 쓰레드의 초기 구현 형태이다. Green-thread버전의 PersonalJava 를 이식하는 과정에서 주요한 내용은 다음과 같 이CPU 에 의존적인 부분과 OS 에 의존적인 부분으로 나눌 수 있다 .

-71- 그림6. Green Thread 모델

￭ CPU에 의존적인 부분 문맥 교환시 스택 포인터나 프로그램 카운터 등을 저장하는 데 사용되는 범용 레지 스터의 이름은CPU 에 따라 다르다 . 따라서 해당 CPU 에 알맞은 이름으로 변경해 주어야 한다.

-72- ￭ OS에 의존적인 부분 쓰레드의 문맥 교환이 일어날 때 관련 내용을 저장하기 위해ucontext_t type 의 자 료구조를 사용하고 있는데, 이는 솔라리스에만 존재하고 리눅스에는 존재하지 않는 다. 또한 쓰레드의 문맥을 얻어오고 저장하는데 사용하는 getcontext() 와 setcontext()함수도 ucontext_t type 을대상으로하고있기때문에 Linux 에는구현 되어 있지 않다. 따라서 ucontext_t type 에 대응되는 자료구조인 gcontext_t type 을 정의하고, 이 자료구조를 이용하여 쓰레드의 문맥을 얻어오고 저장하는데 사용되는 getcontext()와 setcontext() 함수를 구현하였다 . 이 경우 실제 쓰레드간의 문맥 교환 은sigsetjmp() 와 siglongjmp() 를 이용하여 이루어진다 . InitContext() 함수는 새로이 생성된 쓰레드를 위한 문맥을 생성하고, 이 쓰레드가 처음으로 수행할 루틴으로의 분기에 필요한 초기화 작업을 수행한다., 즉 쓰레드가 처음으로 수행할 함수의 주소 와 그 함수의 호출에 필요한 인자 등을 문맥에 저장함으로써 나중에 이 쓰레드의 수행 시기가 되면setcontext() 함수를 통해 해당 문맥을 레지스터 등에 저장하여 처음으로 수행할 루틴의 수행을 가능하게 한다. 따라서 이 함수의 경우에도 ucontext_t type대신 gcontext_t type 을 사용하도록 수정하였다 . 자세한 내용은 부 록에 실린Green Thread 관련 소스 코드 부분을 참조하기 바란다 .

나다대다. (Native Thread)

Native thread를 포팅하기 위해서는 리눅스용 쓰레드 패키지가 필요하다 . 현재 배 포되고 있는 쓰레드 패키지에는 여러 가지가 있지만, 그 중에서도 커널 레벨 쓰레 드를 지원하는 쓰레드 패키지로는LinuxThreads 가 유일하며 , 가장 널리 사용되고 있는POSIX 표준을 따르고 있기 때문에 이식이 용이하다는 점을 들어 LinuxThreads를 사용하게 되었다 . 다음은 LinuxThreads 의 특성 및 Solaris 와 Linux 간의 시스템 콜의 차이에 관하여 기술한다.

￭ LinuxThreads의특성 ➢ Thread는 clone() 시스템 콜을 사용하여 생성 ➢ LinuxThread패키지를 구현하는데 SIGUSR1, SIGUSR2 를 사용하였기 때문에 일 반 응용 프로그램에서 이 두개의 시그널을 사용할 수가 없음 ➢ 원칙적으로 모든 쓰레드의PID 는 부모와 동일해야 하지만 , 여기서는 다름 ➢ LinuxThreads의 쓰레드는 실제로는 하나의 프로세스이며 단지 메모리 등 일부 자원을 공유할 뿐이다., 따라서 시그널을 보낼 때 전체 프로세스에게 보낸다는 개념 이 여기서는 없으며, 단지 개별 쓰레드별로 보낼 수 있음 ➢ 커널 레벨 쓰레드를 지원

-73- ￭ Solaris vs. POSIX 함수 표21:1POSIX 에서 알 수 있듯이 솔라리스의 함수와 대응되는 함수가 존재하는 것들도 있지만,thr_suspend,thr_resume 과 같이 대응되는 함수가 없는 경우도 있 다., 대응되는 함수가 존재하지 않는 경우 데스크탑용 리눅스로 포팅하는 과정에서 직접 구현해 줌으로서 해결하였다. 대응되는 함수가 존재하는 경우 , PersonalJava 플랫폼을 포팅하는 과정에서 솔라리스용 해당 함수를 대응되는 리눅스에서의 POSIX함수로 바꾸어 주었다 . 구현 예로 suspend 와 resume 함수 , 시그널 핸들러에 관련된 소스를 부록에 첨부하였다. 함수를1:1 로 바꾸는 과정에서 주의해야 할 점 중의 한가지는 , 보기에 비슷한 함수 일지라도 세부적인 부분에서 다른 점이 존재할 수 있다는 것이다. 예를 들어 함수 를 수행하는 과정에서 에러가 발생하였을 경우, 리턴되는 값들은 어떤 경우 기존의 Solaris용 함수와 다른 함수들이 존재한다 .

-74- 표2. 자바 쓰레드 API, 솔라리스 쓰레드 API, POSIX 쓰레드 API 의 비교

￭ Embedded Linux로의 포팅

솔라리스용PersonalJava 를 데스크탑용 리눅스로 포팅하는 작업을 완료한 후 , 데스 크탑 리눅스용 소스를 이용하여 내장형 리눅스에 포팅하는 작업을 진행함에 있어서 는 별다른 문제점이 발생하지 않았다.LinuxThreads 이미 데스크탑 리눅스에서 패 키지를 이용하여 포팅을 함에 있어서 쓰레드 패키지가POSIX 표준을 따르도록 구 현이 되어 있었기 때문에,LinuxThreads 내장형 리눅스에서도 마찬가지로 가 이미 내장되어 있어서 별다른 수정할 사항이 없게 되었다. 포팅이 제대로 되었는지는 PJCK라는 툴을 사용하여 검증함으로서 확인할 수 있다 .

-75- (2)마이크로윈도우즈를 이용한 AWT 의 구현

여기서는 경량 윈도우 관리기인 마이크로윈도우즈를 이용해PersonalJava 의 AWT 를 구현하는 내용에 대해 설명한다.

￭ PersonalJava에서의 AWT 구현 방법

AWT(Abstract Windows Toolkit)에서 Abstract 는 실제 모양을 가지고 있지 않다는 것을 의미하며 실제 모양은 플랫폼에 종속적이라는 것을 나타낸다.JDK 에서 AWT 관련 응용프로그램을 작성해서 수행시키는 윈도우환경과 솔라리스 환경에서의 나타 나는 모습이 다르다. 이것은 AWT Peer 가 윈도우에서는 윈도우 SDK 에 있는 그래픽 라이브러리를 이용하고 솔라리스 환경에서는Motif/Xlib 를 이용해서 AWT 를 표현하 기 때문이다. Sun사의 PersonalJava 에서는 AWT 를 구현하기 위해서 크게 두 가지의 방법을 제공 한다. 하나는 JDK 에서 구현하는 방법과 동일한 방법으로 AWT Peer 를 이용하는 것 이며 다른 하나는PersonalJava 의 AWT 를 부분적으로 경량화하고 다른 시스템으로 의 이식성을 높이기 위해서 만든Truffle 구조이다 ( 그림 7 참조 ). Peer 구조는 각각의 비주얼한 컴포넌트에 해당하는 것을 네이티브 그래픽 라이브러 리인Peer 컴포넌트로 만들어서 일대일 매칭시켜주는 것으로 , AWT 패키지에 해당 하는 모든 컴포넌트에 맞는Peer 컴포넌트를 가지고 있어야 한다 . 반면 , Truffle 구 조는AWT 를 구현하기 위해서 따로 OTK(Object Toolkit) 라는 컴포넌트들을 만들어 놓고OTK 가 사용하는 부분에 대해서만 내이티브 그래픽 라이브러리를 만들어 주면 된다. OTK는 MVC(Model-View-Control) 구조를 가지고 있으며 , 이 구조는 실제 정보와 사용자 입력을 받는 부분 그리고 정보의 변경을 표현하는 부분을 분리해 놓은 것이 다. 실제정보는 모델 (Model) 이 가지고 있고 , 사용자 인터페이스 (View) 는 사용자로부 터의 입력을 받아 화면내용 및 데이터를 변경한다(Control). Truffle 은 JDK Swing 에 서 보여주는 것과 유사한MVC 구조를 가지고 있다 . OTK 는 사용자 인터페이스에 대해서 시스템에 적합한 방법으로 사용자 인터페이스를 하기 위해서 특정 시스템에 알맞게 수정되는 것을 지원한다. 이 부분은 실행시간에서 변경하는 것이 아니라 정 적으로 변경할 수 있으며,PersonalJava 에서는 참조 모델로 터치스크린과의 인터페 이스를 제공한다. Truffle 구조가 라이브러리의 크기면에서 Peer 구조를 사용하는 것 보다 작다. 기본적으로Sun 사에서 제공하는 PersonalJava Truffle 은 크게 윈도우즈 SDK 과 솔 라리스용Xlib 을 이용한 구조 두가지를 지원하고 있다 . 그러나 내장형 시스템에서 Xlib혹은 윈도우즈 SDK 그래픽 라이브러리를 사용한다는 것은 용량이나 성능면에 서 고려되기 힘들다.

-76- 그림7. Desktop Peer & Truffle 구조

￭ 마이크로윈도우즈

본 연구에서는PersonalJava 의 AWT 부분을 경량이면서 플랫폼 독립적인 형태로 구 현할 수 있는 마이크로윈도우즈 그래픽 라이브러리를 이용한다(8). 그림 참조 마이 크로윈도우즈에서는 그래픽 응용프로그램을 내장형 리눅스 시스템에서 쉽게 사용할 수 있도록 해준다. 데스크탑 리눅스에서 그래픽 응용프로그램을 사용하기 위해서는 X,윈도우를 사용하지만 내장형 리눅스 시스템에서는 적어도 8MBRAM 과 고성능 프로세스를 요구하는X. 윈도우를 사용하기는 어렵다

-77- 마이크로윈도우즈 프로젝트는 이런 내장형 시스템에서 데스크탑 수준의 그래픽 응 용프로그램을 사용하기 위해서 만들어 졌으며, 리눅스 커널 2.2.0 부터는 사용자 응 용프로그램이 프레임 버퍼(frame buffer) 를 통해 그래픽 디스플레이 메모리에 직 접 접근하게 해주며, 이것은 사용자 응용프로그램의 메모리 주소로 매핑함으로써 디스플레이를 제어하도록 해준다.

그림 8. Truffle using Microwindows

마이크로윈도우즈는50-250Kbyte 정도의 메모리 용량만으로도 동작가능하며 X 윈 도우 시스템이 비교해 보면 아주 작은 메모리를 요구한다. 마이크로윈도우즈에서는 하나의 기본적인 화면 출력 루틴을 이용하여 다양한 그래픽 출력 기능을 구현할 수 있다.32RGB 프레임버퍼 구조는 현재 한 픽셀당 비트의 이식 가능한 포맷을 지원 하고,(RTOS). 다른 실시간 운영체제 혹은 하드웨어 위에서도 동작한다 마이크로윈 도우즈는 개발환경에서 타켓환경에 대한 그래픽 에뮬레이션을 제공한다. 개발 환경 과 타켓 환경이 같은 리눅스라면 개발환경에서 컴파일된 응용프로그램을 재컴파일 하지 않고 내장형 시스템에서 테스트할 수 있다.X11 이것은 개발 환경에서 스크린 드라이버를 통해서 타켓 환경의 그래픽 환경을 정확하게 에뮬레이트할 수 있기 때 문이다.

-78- 마이크로윈도우즈는 계층형 구조를 가진다. 마이크로윈도우즈의 가장 낮은 계층은 하드웨어 장비와 연동에 관련된 드라이버들이며 드라이버위에 하드웨어 장비와 무 관한 그래픽 엔진이 탑재되어 있고 가장 위에는API 가 놓여져 있다 . 상위에 있는 API는 크게 두 가지로 구분된다 . 하나는 마이크로윈도우즈 API 이고 나머지는 Mano-X API이다 . 마이크로 윈도우 API 는 마이크로소프트사 윈도우 SDK 에 형식에 맞게 만들어져 있으며Mano-X API 는 Xlib 와 비슷한 형식을 취하고 있다 . 따라서 이미 개발되어있는 응용프로그램의 내장형 시스템으로의 이식이 용이하다.

그림9. 마이크로윈도우즈 구조

본 연구에서는PersonalJava 의 MS 윈도우 버전 소스 파일을 바탕으로 MS 윈도우 SDK API를 마이크로 윈도우 API 로 바꾸어가면서 PersonalJava 를 리눅스로 이식하 였다.MSSDKAPIAPI 현재 마이크로윈도우즈는 모든 윈도우 의 와 동일한 기능의 를 제공하는 것은 아니다.API 따라서 마이크로윈도우즈에서 제공하지 않는 에 대해 서는 직접 리눅스에서 동작하도록 작성해 주어야 한다.

￭ PersonalJava에서의 AWT 구현 과정

➢ 동적 라이브러리 사용 시 차이점 MS윈도우는 동적 라이브러리를 위해서 DLL 을 사용하고 , 유닉스 환경에서는 확장 자가“so" 로 끝나는 동적 라이브러리를 사용한다 .MS 윈도우 환경에서는 DLL 을 만들 때DllMain 이라는 함수를 호출하고 라이브러리에 있는 함수를 사용하게 된다 .

➢ 리눅스에서 프레임버퍼 사용 리눅스 커널2.2.0 이상에서는 사용자 응용프로그램이 프레임버퍼를 통해서 그래픽 메모리로의 접근이 가능하다. 내장형 리눅스에서 마이크로윈도우즈를 사용할 때 커 널이 지원하는 프레임버퍼 기능을 사용하기 위해서 커널의 설정을 변경하였다.

-79- ➢ 엔트리 포인트 차이점 MS윈도우 SDK 프로그램은 엔트리 함수가 main 이 아니라 WinMain 이다 . 마이크로 윈도우즈는 리눅스 환경에서 동작함으로 엔트리 함수가main 이 된다 . 그래서 WinMain을 만들어 주었다 .

➢ 마이크로윈도우즈 초기화 리눅스를 포팅할 때는 이DllMain 이라는 부분은 필요가 없어지게 되며 DLL 초기화 부분에 해당하는 내용을 자바 코드에서 동적 라이브러리를 처음 시작하는 곳에 넣 어주어야 한다. 동적 라이브러리에서 가장 먼저 불리는 부분은 GraphicsSystem.cpp에 InitJNI 부분이며 여기에서 마이크로윈도우즈 그래픽관련해서 초기화 루틴이 들어있고 이때 마우스,, 키보드 스크린 같은 장치를 확인한다 . 사용 되는 함수는 MwInitialize, MwOpenKeyboard, MwOpenScreen, MwOpenMouse 이 다.

➢ PersonalJava 빌드 과정 PersonalJava빌딩 시 JNI(Java Native Interface), NMI 를 사용하기 위해서 동적으 로 만들어주는 헤더 파일을MS 윈도우 PersonalJava 소스에 맞게 변경해 주었다 . PersonalJava의 그래픽 부분은 윈도우용 소스를 이용하고 나머지 부분은 솔라리스 기반을 이용했기 때문에Xlib 을 이용하는 자바 클래스 (sun.awt.gfX) 대신 마이크로 윈도우즈를 이용하도록 자바 클래스(sun.awt.gfW) 를 변경해 주었고 , 이와 관련해서 시스템 관련 프로퍼티(sun.grapchissystem) 를 sun.awf.gfx.GraphicsSystem 으로 변 경해 주었다. PersonalJava 에서는 그래픽과 관련해서 SharedDC 를 사용하는 데 여 기서 윈도우SDK API 중 Mutex 를 사용한다 . 그래서 pThread 패키지에 있는 pthread_mutex_t를 사용해서 WaitForSingleObject, CreateMutex, RealeseMutex 를 구현하였다. PersonalJava 의 truffle gfW 에서 사용하는 키 매핑과 마이크로윈도우즈 에서 사용하는 키 매핑의 차이점을 일치시켜 주었다.MS 윈도우 SDK 에서 사용되 는 멀티바이트문자와 와이드문자 바꾸는 함수는 변경했고, 커서에 관련된 함수를 마이크로윈도우즈에서 사용하는 커서에 관련된 함수로 바꾸고, 키보드 스캔하는 함 수를 마이크로윈도우즈의 키보드 스캔 함수로 수정했다. PersonalJava윈도우 소스에서 사용하는 MS 윈도우 SDK API 중 마이크로윈도즈에 서 제공하지 않는API 중 중요도가 떨어지는 것들은 차후에 구현 혹은 마이크로윈 도우즈의 새로운 버전이 발표될 때 마다 변경하도록 한다.

-80- 제5 절 내장형 실시간 시스템 자원을 위한 연구

본 절에서는 내장형 실시간 응용 지원을 위해 수행한 실시간 가비지 수집기에 관한 연구와 실시간 쓰레드 구현에 관한 연구 내용을 상세히 기술한다.

1. 실시간 가비지 수집기에 관한 연구

21장 절에서 언급한 바와 같이 내장형 시스템에서 사용되는 동적 , 자동 메모리 관 리 기법은 두 가지 목적을 이루어야 한다., 첫째 실시간 응용의 시간 제약 조건을 보장하는 데 메모리 관리 오버헤드가 병목으로 작용해서는 안 된다., 둘째 한정된 메모리 용량을 고려하여 메모리 요구량을 일정 한도 내로 바운드시켜야 한다. 이를 위해 가비지 수집기와 기존의 실시간 스케쥴링 기법을 결합한 새로운 실시간 가비 지 수집 기법을 제안하고 시뮬레이션을 통해 제안한 기법의 성능을 평가한다.

(1) 개요및관련연구

최근의 응용 프로그램들은 다양한 기능을 지원하기 위해 복잡한 내부 자료 구조를 필연적으로 가지게 되었다. 이러한 상황에서 메모리의 효율적 사용을 위해 동적 메 모리 관리의 필요성이 대두되었고, 동적 메모리 관리에서 더 이상 사용되지 않는 메모리 공간의 자동 반환(automatic reclamation) 기능은 생산성 , 견고성 , 프로그램 의 무결성 측면에서 이점을 가진다. 자동 메모리 반환 기능을 담당하는 모듈은 흔 히 가비지 수집기(garbage collector) 라 불린다 . 그러나 , 여러 가지 이점에도 불구 하고 가비지 수집기에 기반한 동적메모리 관리는 가비지 수집 작업의 최악 응답시 간을 바운드시키기 어렵다는 단점 때문에 최근까지 내장형 실시간 응용에는 잘 사 용되지 않았다. 이러한 문제점은 동적 메모리 모델을 채택하고 있는 자바가 내장형 응용에 잘 사용되지 않는 큰 원인 중 하나이다. 본 연구에서는 이러한 문제를 극복 하기 위한 접근 방법을 제시한다. 실시간 태스크들의 예측가능성을 높이기 위해, 가비지 수집기도 실시간 특성을 가 지면서 동작하여야 한다.. 실시간 가비지 수집기는 다음과 같은 특성을 가져야 한다

￭ 병행적/:“” 점진적 수행 정지수행 후 재개 방식으로 인해 초래되는 지연시간을 일정 한도 내로 바운드시킬 수 있도록 가비지 수집기는 자신의 수행을 응용 프로그 램의 수행시간 속에 분산시켜야 한다. 구현 기법에 따라 가비지 수집기는 병행적 (concurrent)혹은 점진적 (incremental) 으로 수행된다 .

-81- ￭ 일관성:/ 병행적 점진적 수행으로 인해 폐기기억 환수 작업이 진행중인 동안에도 응용 태스크의 수행 결과로 인해 객체의 활성상태(liveness) 에 변화가 올 수 있다 . 따라서폐기기억환수기와응용태스크들측면에서바라보는힙의뷰(view) 에대한 일관성을 유지하기 위해 힙 객체의 활성상태에 영향을 주는 동작들은 응용 태스크 에 의해 폐기기억 환수기에 보고되어야 한다. ￭ 예측가능성:, 실시간 시스템의 요구조건 중 하나는 예측가능성 즉 최악 경우의 수 행 시나리오가 알려져야 한다는 점이다. ￭ 응용 태스크의 동작에 대한 간섭 최소화: 가바지 수집기는 실시간 응용 태스크들 의 스케쥴 가능성에 저해가 되어서는 안 된다., 따라서 기본적인 메모리 접근연산이 나 가비지 수집기와 응용 태스크 간의 동기화 오버헤드는 짧으면서도 일정 한도 내 로 바운되는 값이어야 한다.

위와 같은 특성을 고려하여 본 연구에서는 태스크 스케쥴링과 통합된 실시간 가비 지 수집기법을 제안한다. 본 연구의 목적은 경성 실시간 태스크들의 종료시한을 보 장하는 동시에 메모리 요구량을 최소화하는 것이다. 이를 위해 가비지 수집 요청들 은 각각 경성 실시간 비주기 태스크로 모델링되고 고정된 용량을 가진 스포래딕 서 버(sporadic server) 에 의해 스케쥴된다 .

(2) 시스템 모델

본연구에서는시스템내에개의우선순위에따라정렬된주기적태스크집합n

M(={M1 … Mn})을 가정한다 . 모든 주기적 태스크들은 비율단조 (rate monotonic) 스케쥴링기법과 같은 고정우선순위 기반 스케쥴링에 따라 스케쥴된다. 각 태스크는 다음과 같은 속성으로 표현된다.

Mi =(Ci,Ti,Di,Ji,Ai)

Ci:,최악수행시간 Ti:,주기 Di:,종료시한

Ji:,시작 지터 Ai: 최대 메모리 요구량

또한,. 본 연구에서는 다음과 같은 가정을 둔다

가정1) 비주기적 태스크는 없다 . 가정2) 문맥 교환과 스케쥴러의 수행에 따른 오버헤드는 무시할 만큼 작다 . 가정3) 태스크들 간에 선행관계는 없다 .

-82- 가정4) 어떤 태스크라도 자신보다 높은 우선순위의 태스크에 의해 즉시 선점가능 하다., 즉 공유 자원에 의한 블러킹은 일어나지 않는다 .( 이 가정은 이후에 완화된 다.)

본 연구에서는 가상 메모리를 가지지 않고 동적, 자동반환 메모리 관리를 사용하는 메모리를 대상으로 한다. 기본적으로 두 개의 동일한 크기를 가지고 동작하는 복사 알고리즘(copying algorithm) 을 사용하는 것을 가정한다 . 그림 10 은 메모리 모델의

동작을보여준다가비지수집기는더이상사용되지않는메모리들을. fc(Mi,K,t)

비율로 가용 메모리 풀로 반환하고, 응용 태스크들은 fc(Mi,K,t)의 비율로 메모리를 할당한다. 이 경우 가비지 수집기는 응용 프로그램 코드의 일부로 동작하거나 별도 의 태스크로 수행되는데,. 본 연구에서는 별도의 태스크로 수행된다고 간주한다

그림10. 메모리 모델

각 가비지 수집 요청을 {Gk, k≤1}라고할때 , Gk의 시작시간과 종료시간은 와

로잡는다.K 번째가비지수집요청Gk은 가용 메모리 양이 특정 임계치 이하로

내려갈 때 발생한다. 메모리 할당 함수 fc(Mi,K,t) 는 스케쥴링 정책과 응용의 특성 에 따라 다양한 함수의 형태를 가지므로 주어진 시간 간격에서의 메모리 누적할당

량의 상한은 Ai 와 해당 시간 간격 내에서 수행되는 태스크 인스턴스의 수의 곱을 이용해구할수있다즉., 시간t'(tK,≤t'

-83- (3) 가비지 수집기의 시간 제약 조건

가비지수집요청Gk 의 시간 제약 조건은 다음과 같이 정리된다.

￭ Gk 는 비주기적 요청이다. Gk 의 시작 시간은 누적 메모리 할당량과 전체 메모리 양에 의해 결정되므로 사전에 알 수가 없다.

￭ Gk 는 실시간성을 가진다.kGC(k+1)GC 만약 번째 요청이 번째 요청이 발생할 때까지완료되지못하면가비지수집기나응용태스크모두더이상수행을계속 할 수 없는 병목 현상이 발생한다.11 그림 이 이러한 상황을 나타낸다 .

그림 11. Gk의시간제약조건

(4) 스케쥴링과 결합된 가비지 수집기

본 절에서는 태스크 스케쥴링과 결합된 실시간 가비지 수집기의 동작에 대해 설명 한다. 제안된 알고리즘의 목표는 메모리 요구량을 최소화하면서 실시간 응용의 시 간 제약 조건을 만족시키는 것이다. 본 연구에서 대상으로 하는 가비지 수집기는 본 연구진에서 제안한 실시간 복사 알고리즘(ACM LCTES '99, IEEE RTAS '00 발 표논문참조이다).

가. 가비지 수집기의 최악 수행 시간

실시간 복사 알고리즘에서 가비지 수집 과정은 크게 네 가지 요소로 이루어진다; 1)레퍼런스 필드 탐색 2) 객체 복사 3) 동기화를 위한 처리 4) 메모리 초기화 등

이다., 이 때 최악 가비지 수집 시간 CGC는 다음 식으로 주어진다.

-84- R:루트셋최대크기 , E: 갱신엔트리동기화최대크기 ( ) , * M:힙 메모리 크기 , Lk : 최대 활성 객체 양

나. 최악 메모리 요구량

(3)에서 언급한 가비지 수집기의 시간 제약 조건을 고려할 때 두 개의 연속적인 GC요청의 서비스 시간이 중첩되는 것을 방지하려면 먼저 요청된 GC 의 수행이 진 행 중인 동안 응용 태스크들이 사용한 충분히 큰 가용 메모리 풀이 존재해야 한다.

이러한 문제점을 해결하기 위해 예약 구간 RG 를 다음과 같이 정의한다.

K 정의1. 예약 구간 RG는 다음의 조건을 만족하는 최대 크기의 시간 구간 [ tS ,tY

].t를나타낸다 Y는GC 를 위해 할달된 스포래딕 서버의 용량이 다시 충전되는 최조 시간을 나타낸다.

GC 수행 중에 응용 태스크들의 동작을 위해 예약되어야 할 메모리 폼의 크기는 위 에 정의된 예약 구간 크기와(2) 에서 정의된 누적 메모리 할당량 계산식에 의해 구 할 수 있다., 따라서 최악 경우 메모리 요구량은 메모리 예약량과 최대 활성 객체양 의 합에 의해 구해지는 다음 식으로 정리된다.

πj :i예약 구간에서 태스크 의 최대 활성 인스턴스 수

다. 스케쥴링 알고리즘

본 절에서는 스케쥴링 알고리즘 전반에 대해 설명한다. 본 연구에서는 비주기 서버 (aperiodic server)기법 중 하나인 스포래딕 서버를 사용한다 . 스포래딕 서버는 비 주기 태스크 요청을 서비스하기 위한 높은 우선순위의 태스크이다. 서버는 비주기 태스크가 도착할 때까지 자신에게 할당된 대역폭을 보존하며 대기하고 있다가 비주 기 요청이 도착하면 자신의 대역폭 한도까지 서비스해 준다. 미리 할당된 용량을 다 소모하면 자신의 주기만큼 기다렸다가 소모된 용량을 재충전하고 다시 서비스를 재개한다.

-85- 비주기 태스크를 서비스하기 위해 기존에 제시된 기법들로는 스포래딕 서버 외에도 백그라운드 서비스(background), 폴링 서버 (polling server), 슬랙 스틸링 (slack stealing)등이 있다 . 백그라운드 서비스의 경우 가장 낮은 우선순위를 가지고 동작 하므로 메모리 요구량 면에서 최악의 성능을 보일 수 있다. 폴링 서버의 경우 구현 이 쉽다는 장점이 있으나 대역폭 보존 특성이 없으므로 최악 경우에는 백그라운드 서비스와 유사한 성능을 보인다. 슬랙 스틸링의 경우도 비주기 태스크의 평균 응답 시간 면에서 최적임이 이미 증명되었으나CPU 유휴 시간을 균등하게 사용하기 힘 든 특성 때문에 최악 경우 메모리 요구량을 바운드하기 쉽지 않다. 이에 반해 스포 래딕서버를사용할경우균등한유휴시간사용과대역폭보존등의특성으로인 해가장좋은성능메모리요구량기준을보인다(). 본 연구에서 제안하는 스케쥴링 알고리즘하에서GC 는 다음과 같이 서비스된다 . 스 포래딕 서버는 가장 높은 우선순위() 가장 짧은 주기 를 가지고 동작하며 GC 요청이 없을 때는 용량을 그대로 유지하며 대기한다.GC 요청이 도착하면 응용 태스크를 바로 선점하여GC 작업을 수행하며 용량이 고갈되면 CPU 제어권을 내어놓고 서버

용량이 재충전될 때까지 대기한다. 스포래딕 서버의 주기 T8는가장짧은주기를

가진 태스크와 동일하게 잡으며 스포래딕 서버의 용량 Cs 는 실시간 응용 테스크의 종료시한을 보장해 줄 수 있도록 다음의 점화식을 이용해 구한다.

위와 같이 CGC,TS,CS 가 결정되고 나면 가비지 수집기의 최악 응답시간은 다음과 같이 결정된다.

서버용량의 재충전 정책을 고려할 때 최악 응답시간 RGC를 이용하여 예약 구간 RG 를구할수있다.

-86- 또한, 최대 활성 태스크 인스턴스 개수 πi 도예약구간을이용해다음과같이구할 수 있다.

(5) 요약

본 연구에서는 제안한 기법의 성능을 평가하기 위해 자바로 작성된 제어 응용 프로 그램들로부터 뽑은 트레이스 데이터를 바탕으로 시뮬레이션을 수행하였다. 시뮬레 이션 결과 백그라운드 서비스 기법에 비해32-56 % 정도의 예약 메모리 절감 효 과를 얻었으며 다른 스케쥴링 기법들에 비해서도 실시간 제약 조건을 만족시키는 유효 메모리 면에서 최대54-67% 정도의 성능 향상을 보였다 . 지면 관계상 실험에 관련된 내용은 생략한다([Kim00b]). 자세한 내용은 참조 향후 과제는 블러킹에 의 한 영향을 추가하는 것과 실제 플랫폼에서 실험을 수행하는 것이다.

2. 실시간 쓰레드 구현에 관한 언구

본 절에서는 실시간 운영체제인VxWorks 의 내장형 자바 가상 기계인 PresonalJava 상에서 실시간 응용 프로그램의 지원을 위한 자바 쓰레드를 설계, 구현한 내용에 대해 언급한다.

(1) 개요

실시간 시스템은 계산의 논리적 정확성 뿐 아니라 계산 결과를 종료시한(deadline) 내에도출해야하는엄격한시간적정확성을요구한다이를위해최악실행시간. (worst case execution time)분석이 가능해야 하며 , 주어진 종료시한 안에 모든 작업을 처리할 수 있는 기능을 가져야 한다., 그러나 현재의 자바 가상 기계는 하드 웨어 독립적인 바이트 코드를 기반으로 하여 플랫폼간의 호환성은 증진되었으나 플 랫폼 종속적인 네이티브(native) 코드에 비하여 속도가 느리며 , 낮은 쓰레드 동기화 성능,JIT 가비지 수집기와 컴파일러에 의한 예측할 수 없는 지연 등 시간적 요구 사항을 만족하기 어려운 문제들을 가지고 있다.

-87- 본연구에서는이러한한계를극복하기위해RTOS 상에서내장형자바가상기계 를 확장,. 수정하여 실시간 지원을 하도록 한다 이를 위해 기존의 자바 쓰레드에 시 작시간,, 주기 종료시한 등의 시간 속성을 삽입하고 , 실시간 자바 쓰레드 API 클래 스를 구현한다.., 실시간 스케쥴러는 세가지 방식으로 구현한다 첫째는 자바 가상 기계를 수정하지 않고 시간 속성에 따라 쓰레드에 우선 순위를 할당하여 스케쥴링 하는 방식이고, 둘째는 자바 가상 기계를 수정하여 시간 속성에 따라 VxWorks 커 널 스케쥴러를 통해 스케쥴링하는 방식이며, 셋째는 독립적인 스케쥴링 태스크를 구현하는 방식이다.(deadline 또한 종료시한을 넘긴 경우를 처리하기 위한 핸들러 handler)를 구현하여 멀티미디어 응용을 지원하도록 한다 .

(2) 실시간 자바 쓰레드의 설계 및 구현

가구현환경.

실시간 자바 쓰레드를 구현하기 위해, 50MHz 로 동작하는 MPC860 CPU 를 탑재하 고16MB 의 메모리와 Ethernet 컨트롤러를 갖춘 타겟 보드를 사용하였다 . 운영체제 로는Windriver 사의 Vxworks 5.3.1, 개발툴로는 Tornado 1.0 for WindowsNT 를 사 용하였다. 이러한 개발환경에서 소스가 공개된PersonalJava 3.0 을 이식했다 . 작업은 Vxworks의 태스크 제어함수를 이용하여 자바 쓰레드 제어 인터페이스를 구현하는 것과, Vxworks 의 세마포어를 이용하여 자바 모니터 (monitor) 를 구현하는 것이 대부 분을 차지했다., 그 밖에 메쏘드 시그너쳐에 대응하는 네이티브 호출 루틴 작성 , CPU의 바이트 정렬 (byte ordering) 고려 등의 작업이 수반되었다 . Vxworks 의 스케 쥴 가능한 기본 단위는 태스크이며 자바 쓰레드는 결국 이 태스크로 사상되고, Vxworks에서 제공하는 스케쥴링 기법에 따라 태스크가 스케쥴된다 . 스케쥴링 기법은 선점형(preemptive) 우선순위 기법을 사용하며 같은 우선순위 태스크는 라운드 로 빈 방식(round-robin) 으로 스케쥴된다 .

나.API 실시간 자바 쓰레드 의 설계

실시간자바쓰레드클래스RTThread 는기존의자바클래스를상속받고그위에 , 시작시간,, 주기 종료시한 등 시간 속성 , 이를 접근하는 함수 , 스케쥴링 정책 , 우선 순위 할당을 위한 자료 구조 및 종료시한 핸들러 관련 함수들을 추가하여 구현하였 다.system.Current 시간 속성 변수들은 자바에서 현재 시간을 변환하는 TimeMillis()함수에 맞추어 , long 타입으로 정의하였으며 1/1000 초 (ms) 의 정확도를 갖는다.RTThread 다음은 클래스에 정의된 메쏘드들이다 .

-88- 표3. RTThread 클래스의주요메쏘드

메쏘드 이름 기능 RTThread.RTTThread() 클래스 생성자, 기존의 자바 쓰레드 생성자에 시간 속성 인자를 추가 RTThread.srtAttr(start.period, 시작시간,, 주기 종료시한을 설정 deadline) RTThread.getStart(). 시작시간을 반환 RTThread.getPeriod() 주기를 반환 RTThread.getDedline() 종료시한을 반환. RTThread.setPolicy(int policy) 스케쥴링 정책결정. RTThread.setRTpriority() 시간속성과 스케쥴링 정책에 따라 우선 순위를 할당. RTThread.setDeadlineHandler(name) 핸들러 등록

다. 실시간 자바 쓰레드 스케쥴러의 구현

실시간 자바 쓰레드는 주기적으로 수행되어야 한다. 따라서 현 주기에서 수행된 쓰 레드의run() 이 다음 주기의 시작 시간 이후에도 다시 수행되어야 한다 . 주기적 쓰 레드의 스케쥴링 정책으로RM 과 EDF 가 있다 . RM(Rate Monotonic) 스케쥴링은 주 기가 적은 쓰레드가 높은 우선 순위를 갖는 방식이다. 실행시 우선 순위가 바뀌지 않는 정적 우선순위 스케쥴링이다. EDF(Earliest Deadline First) 스케쥴링은 종료시한이 가까울수록 높은 우선순위를 할당하는 방식이다.. 시간에 따라 우선순위가 변하는 동적 우선순위 스케쥴링이다 쓰레드의 매 주기마다 우선순위가 바뀔 수 있기 때문에 스케쥴링 오버헤드가 비교 적 크다.

￭ 자바로 작성된 스케쥴러에 의한 스케쥴링

자바로 스케쥴러를 작성할 경우 자바 가상 기계를 통한Vxworks 태스크에 대한 제 어가 자바 쓰레드API 로 제한되기 때문에 실시간 자바 쓰레드의 정확한 스케쥴링이 어렵다. Thread.setPriority() 가 TM 레드 객체 생성 후부터 쓰레드가 Runnable 상태 가 되지 전까지만 호출될 수 있기 때문에 실행시 우선순위를 변경하는 것이 불가능 하다.,RM 따라서 의 구현은 가능하지만 EDF 와 같이 동적 우선순위 스케쥴링 정책 은 구현 불가능하다.10 자바 쓰레드는 우선순위 레벨이 단계이기 때문에 쓰레드의 개수가10 개 이상인 경우 서로 다른 우선순위의 쓰레드임에도 불구하고 같은 우선 순위를 할당받는 일이 발생할 수 있다. 이는 스케쥴가능성 (scheduleability) 을 낮추 는 요인이 된다., 그러나 자바 가상 기계의 수정이 없으므로 플랫폼 독립성을 가질 수 있다는 점과 쓰레드 생성이나 수행시 오버헤드를 줄일 수 있다는 장점이 있다. 알고리즘은 다음과 같다.

-89- 1. 쓰레드 생성시 쓰레드 리스트에 새로운 쓰레드 추가하고 주기에 따라 쓰레드 리스트를 정렬한다. 2. 쓰레드 시작 전에 쓰레드 리스트에 있는 쓰레드들의 주기에 따라 우선 순위 할당한다.10110 전체 쓰레드의 개수가 개 이상일 경우 부터 까지 각각의 우선 순위마다 같은 개수의 쓰레드를 갖도록 한다. 3. 쓰레드시작후현재시간보다시작시간이늦을경우그시간만큼쓰레드를 지연시킨다. 4.매 주기마다 3 번을 반복한다 .

￭ VxWorks 커널 스케쥴러를 이용한 스케쥴링

Vxworks는 태스크의 우선 순위를 동적으로 설정하는 함수인 taskPrioritySet() 을 제 공하므로EDF 스케쥴링 정책을 지원할 수 있다 . 그러나 , EDF 의 경우 자바 쓰레드 가 수행 중이라도, 새로 생성된 쓰레드의 종료시한이 현재의 쓰레드보다 앞선다면 새로운 쓰레드가 바로 수행되어야 하지만, 모든 쓰레드의 시작 전에 우선 순위가 할당되는 것을 가정하고 있기 때문에 새로운 쓰레드가 수행되지 못한다는 단점이 있다. 쓰레드 시작을 위해서는 쓰레드 객체의 start() 가 호출되어야 한다 . start() 에 서threadCreate() 라는자바가상기계내부함수를이용해쓰레드내부구조를생 , 성하고, Vxworks 태스크를 생성한다 .Vxworks 에서는 taskSpawn() 이라는 태스크 생성 을 위한 함수가 있고,ThreadRTO(). 인자로서 함수의 주소를 준다 이 함수에서 바 자 쓰레드의run() 을 수행하게 된다 . 자바 가상 기계에 추가 구현해야 할 부분은 다음과 같다.start() 우선 호출시 자바 응용 프로그램에서 시간 속성과 우선순위,, 스케쥴링 정책 종료시한 핸들러 관련 자 료를JNI(Java Native Interface) 를 통해 자바 가상 기계의 쓰레드 자료구조에 저장 한다.,Vxworks 다음 태스크 생성시 쓰레드 우선순위에 따라 태스크의 우선 순위를 정한다.ThreaRT0() 마지막으로 에 스케쥴링 정책을 구현한다 . RM의 구현은 앞의 알고리즘과 유사하다 . 차이점은 자바 쓰레드의 우선 순위 레벨 이256 가지인 Vxworks 태스크의 우선 순위로 바뀌었고 , Vxworks 의 타이머 라이브 러리를 이용하여 종료시한 핸들러를 구현할 수 있다는 것이다.EDF 스케쥴링 정책 은RM 구현 위에 우선순위 조정 부분을 추가한다 . run() 함수 수행이 끝날 때마다 , 쓰레드의 종료시한을 다음 주기의 종료시한으로 조정하고 전체 쓰레드 리스트의 우 선 순위를 조정한다.

-90- ￭ 스케쥴러 태스크를 이용한 스케쥴링

스케쥴러 태스크는 실시간 쓰레드보다 높은 우선 순위를 갖고, 실시간 쓰레드의 우 선순위에 모두 같은 값을 할당한다. 스케쥴러 태스크가 시간 속성에 따라 모든 실 시간 자바 쓰레드의 스케쥴링을 수행하는 방법이다. 무한대의 우선순위 단계를 지 원할 수 있다. 그러나 , 태스크 문맥 교환 (context switch) 의 횟수가 많아진다는 단 점이 있다. 하지만 현재 실행중인 쓰레드보다 높은 우선 순위를 갖는 쓰레드에 의 한선점이가능하도록할수있다구현을위해서쓰레드자료구조를새로정의하. 고,. 이 쓰레드 자료 구조의 리스트를 유지하도록 한다

￭ 종료시한 핸들러

종료시한 핸들러는 쓰레드의 수행 중에 종료시한을 넘긴 경우 실행되며, 핸들러의 수행이 끝난 후에 다시TM 레드의 수행을 재개한다 . 종료시한 핸들러는 RTThread 클래스의setDeadlineHandler() 를 이용해 사용자가 정의할 수 있다 . 비디오 플레이 어일 경우 종료시한을 넘긴 프레임을 스킵한다던가, 네트웍 응용일 경우 처리하는 패킷 수를 줄이는 일을 종료시한 핸들러를 이용해 할 수 있다. Vxworks 의 wdStart() 함수에 시간과 핸들러의 함수 포인터를 인자로 주면 주어진 시간 후에 핸들러가 수행된다. 그 후 run() 뒤에 wdCancel() 로 타이머를 취소함으로써 , run() 함수가 종료시한 내에 수행된 후에는 핸들러가 수행되는 것을 막을 수 있다.

(3) 성능 평가

시간 측정을 위해Vxworks 의 vxTimeBaseGet() 를 사용하였으며 , 기본 시간 단위는 320ns이다 . 표 4 에 실시간 자바 쓰레드의 생성시간 , 시작 지연시간 , 문맥 교환시 간 등의 기본적인 성능을 세가지 스케쥴링 구현 방식에 따라 요약하였다. 쓰레드 생성시간은newThread() 에 의한 쓰레드 객체 생성과 생성자의 수행 시간을 합한 것이다. 시작 지연시간은 쓰레드의 start() 가 호출된 후 실제로 run() 이 수행되기 전 까지의 시간이다. 스케쥴러 태스크 방식은 스케쥴러의 스케쥴링 작업이 더해져서 약50% 이상의 시간이 증가하였다 .

-91- 그림12 는 작업 부하가 100% 로 고정되어 있을 때 쓰레드의 개수를 늘려감에 따른 종료시한 초과 비율을 보이고 있다. 자바 스케쥴러 방식은 다른 방식에 비해 종료 시한 초과 비율이 크며, 쓰레드의 개수가 증가함에 따라 종료시한 초과 비율이 늘 어나는것을볼수있다이는자바쓰레드의우선순위레벨이.10 가지이므로쓰레 드의 개수가 늘어남에 따른 스케쥴링의 부정확성으로 인한 것이다. 반면에 커널 스 케쥴러 방식의 경우는 쓰레드 개수가 늘어남에도 불구하고 종료시한 초과 비율에 변화가 없는데 이는 쓰레드 개수에 비해 우선순위 레벨이 많기 때문이다. 스케쥴러 태스크 방식의 경우는 쓰레드 개수가 늘어남에 따라 스케쥴링 오버헤드가 증가하는 때문에 종료시한 초과 비율이 높아지게 된다.

표4. 스케줄링방식에따른기본성능

스케쥴링 정책: RM 태스크 실행시간: 100ms 작업부하: 90% 그림12. 쓰레드 개수에 대한 종료시한 초과 비율

-92- 제장결과3

제1 절 자바 가상 기계의 무결성

본 절에서는 자바 가상 기계를 내장형 시스템에 포팅하여 내장형 시스템을 위한 자 바 솔루션을 구현한 후, 자바 가상 기계가 올바르게 포팅되었는지를 검증하기 위한 무결성 테스트에 관하여 기술한다.

1. PJCK(PersonalJava Compatibility Kit)

PersonalJava Compatibility Kit (PJCK)는 PersonalJava 플랫폼의 구현이 PersonalJava플랫폼 명세서 및 Sun 사의 참조 구현에 합치되는지를 검증하기 위 하여 사용되는 테스트 스위트(test suite) 및 툴셋이다 . 이 테스트의 결과로 PersonalJava플랫폼의 구현은 PersonalJava Compatible™ 을 얻을 수 있게 된다 . 테스트들은 우수한 서버부터 작은JavaOS™ 기반의 시스템에 이르기까지 어떠한 Java플랫폼의 구현에서도 수행이 가능하다 . PJCK 는 JavaTest 테스트 수행 및 테 스트 스위트 관리 툴들을 사용한다. 이런 툴들 또한 어떠한 자바 플랫폼 구현에서 도 수행이 가능하도록 디자인되었다.

2. 무결성의 중요성

무결성은PersonalJava 플랫폼의 구현을 다른 운영체제나 하드웨어 환경으로 이식 을 하는 경우,. 제대로 포팅이 되었는지를 확인할 수 있게 한다 개발자들의 입장에 서는 자바 프로그래밍 언어로 소프트웨어를 구현하였을 경우, 이것이 다른 환경의 PersonalJava 플랫폼 구현에서도 아무런 수정 없이 수행이 된다는 것을 확신할 수 있게 된다. 또한 응용 사용자들로 하여금 알지 못하는 곳에서 어떤 응용 프로그램 을 획득했을 경우,. 그 응용 프로그램을 믿고 실행할 수 있도록 한다

-93- 3. 테스트진행과정

앞서 언급 했듯이PJCK 는 JavaTest 라는 툴을 이용하여 테스트를 진행하게 된다 . JavaTest는 적합성 테스트 프로그램들의 집합을 수행하기 위하여 사용되는 테스트 툴들의 집합을 나타낸다.JavaTest 는 두가지 방식으로 동작하는데 ,Main 은 PC 나 워크스테이션의 서버에서Java(JDK) 를 이용하여 수행되며 , Agent 는 적합성 테스트 를 수행하고자 하는PersonalJava 플랫폼의 구현에서 수행된다 . Main 은 수행하여 야 할 테스트 클래스를 알려주며,Agent 에서 해당 클래스를 찾아 수행한 후 결과를 다시Main 에 알려준다 . 그러면 Main 은 이를 파일과 JavaTest Main 프로그램에 출 력하게 된다.Agent 의 경우 , 해당 플랫폼에서 GUI 를 지원하지 않는 경우를 고려하 여 여러 가지 방식으로 수행 할 수 있는데,GUI 를 지원하지 않는 응용 방식 , 애플 릿 방식 및 프레임 방식이 있다.mpc860 의 경우 VM 및 AWT 를 제외한 API 테스 트의 경우GUI 를 지원하지 않는 응용 방식을 사용하였다 . AWT 의 포팅이 완성되 면 애플릿이나 프레임 방식으로Agent 를 수행하여 테스트할 계획이다 . 그림13 은 JavaTest 의 Main 을 수행하였을 때의 환경 설정을 보인 것이다 . 이곳에 서 수행하고자 하는 테스트를 선택하며,. 기타 환경설정을 하게 된다

그림13. JavaTest 의 환경설정 화면

-94- 다음 그림은Agent 를 수행하는 과정을 보인 것이다 .

Agent 응용은 현재는 그래픽 부분에 대한 지원이 잘 동작되지 않기 때문에,GUI 를 사용하지 않는 방식으로 테스트를 진행하고 있다. 하지만 빠른 시일 내에 그래픽 부분에 대한 지원도 완성될 계획이므로, 차후에는 Agent 응용 또한 JavaTest 의 Main과 같은 방식의 그래픽이 지원되는 화면으로 테스트할 수 있게 될 것이다.

PJCK에포함되어있는 PersonalJava Compatibility 테스트스위트 (Test Suite) 는 적합한PersonalJava 명세서에 합치되도록 PersonalJava 의 런타임 (run-time) 구현 을 검증하도록 디자인되었다.3. 테스트들은 다음과 같이 가지 종류로 분류된다

￭ 자바 클래스 라이브러리(API) 테스트 자바 가상 기계에서 사용되는 핵심API 클래스 라이브러리를 구성하기 위하여 필요 한 구현들에 관한 적합성 테스트를 실시한다.

￭ 자바 프로그래밍 언어(lang) 명세서 테스트 해당 자바 가상 기계가 자바 언어 표준에 맡도록 수행을 하는지를 검증하기 위한 테스트들이다., 이는 컴파일러를 내장하거나 컴파일러를 별도로 구현하였을 경우에 실시하는 테스트 스위트(test suite) 이다 .

￭ 자바 가상 기계(JVM) 테스트 해당 자바 가상 기계가 자바 가상 기계의 표준에 맞도록 구현이 되었는지를 검증하 기 위한 테스트들로 구성되어 있다.

현재 진행되고 있는 과제에서는 단지API 와 JVM 두 가지 테스트 스위트에 대해서 만 실시하면 된다. 자바 프로그래밍 언어 명세 테스트는 별도로 컴파일러 등을 구 현하였을 경우에 실시하는 테스트이기 때문에,. 여기서는 필요하지 않다

-95- 그림14. JavaTest Main 의 Agent Monitor 화면

그림14 는 JaveTest Main 응용 중에서 Agent Monitor 화면을 보인 것이다 . 이 화 면을 통해 어느 주소에 있는Agent 로부터 접속 요구를 받는지에 대해서 알게 되며 , 그Agent 가 어떤 테스트를 수행 중에 있는지를 알 수가 있다 . 현재 화면을 보게 되 면, IP 가 happy.sun.ac.kr 이고 port 번호가 53638 인 Agent 가 로컬 포트 1912 에 연 결되어있다는것을알수있으며아직수행중인테스트는없다는것을화면을통, 하여 확인할 수 있다. 그림15 는 JavaTest Main 의 응용 프로그램이 실제로 테스트 스위트들을 수행하는 진행과정을보인화면이다화면의.progress 상자를보면수행해야할총테스트 의수와현재까지완료된테스트의수그리고앞으로남아있는테스트의수를볼 수 있다. Test result 상자에는 몇 가지 색의 막대들이 움직이게 되는데 , 이는 현재 까지의 테스트 진행 상황을 보이는 표이다.Agent 여기서 녹색 막대는 에 의해서 수 행이 된 테스트 중에서 통과된 테스트의 비율을 표시하며, 주황색 막대는 어떠한 이유로 인하여Agent 에서 수행이 되었으나 실패한 테스트의 비율을 나타낸다 . 화면 에는 나타나지 않았지만 푸른색 막대는Agent 에서 응답이 없거나 기타 다른 이유 로 인해Agent 에서 수행을 할 수 없었던 테스트의 비율을 나타내며 , 화면의 가장 우쪽에 나타난 회색 막대는Agent 에서 수행되기를 기다리는 테스트들의 비율을 보 여준다.

-96- 그림15. JavaTest Main 의 테스트 수행 상태를 보인 화면

그림16 은 JavaTest Main 이 테스트를 수행한 결과를 보이는 화면이다 . 여기서 all, passed, failed, not run등의 탭이 있는데 , all 은 모든 테스트를 보여주며 , passed 는 통과된 테스트들의 목록을 표시하며,failed 는 실패한 테스트들의 목록을 보여준 다.Notrun 은 아직 수행되지 않고 대기중인 테스트들의 목록을 담고 있다 . 현재의 화면은 통과된86 개의 테스트들이 목록을 보여주는 화면임을 알 수가 있다 .

-97- 그림16. JavaTest Main 의 테스트 결과를 보이는 화면

4. PJCK을 통한 무결성 테스트 결과

포팅된PersonalJava 플랫폼의 구현은 native thread 와 green thread 의 두 종류로 구현되어 있으며,, 테스트 또한 두 가지 플랫폼을 개별적으로 수행한 결과 동일한 결과를 보였으며 세부 내용은 다음과 같다.

총 테스트 수 통과된 개수 내 역 VM부문 1912 1910Byte array 관련 2 개 실패 API부문 1235 1205 IEEE remainder 1 (AWT관련제외 ) String관련 1 네트워크 관련 3 BigInterger, BigDecimal 17 Deprecated된 함수관련 3 library load관련 4 기타 1

-98- 제2 절 내장형 시스템에의 적합성

본 과제에서 개발한 자바 수행 환경은 다음과 같은 점에서 내장형 시스템의 특성을 고려하였다.

￭ 클래스 로딩 메커니즘 ➢ 하드 디스크가 부차되지 않는 내장형 시스템 특성을 고려한 투명한 클래스 로딩 인터페이스 구현

￭ 실시간자바쓰레드 ➢ RTOS의 태스크 관리 메커니즘을 이용한 실시간성 개선 ➢ 실시간 특성 표현을 위한 확장API 구현 및 자바 가상 기계의 지원사항 구현

￭ 경량 윈도우 관리기를 이용한GUI 구현 ➢ AWT 기능 분석 및 필수부와 선택부 분리를 통한 경량화 ➢ 경량 윈도우 관리기()AWT 마이크로윈도우즈 를 이용한 경량 솔루션 구현

￭ 자바 수행 환경의 안정화 ➢ 장시간 중단없이 동작하여야 하는 내장형 시스템의 특성을 고려한 시스템 안정 화 ➢ 공인된 호환성 검사 패키지를 이용한 안정성 검사

제절요약3

자바는 플랫폼 독립성,, 코드 재사용성 보안 등의 장점으로 인해 그 동안 인터넷 응 용 분야에서 널리 쓰여왔으며,,, 최근에는 디지털 셋톱박스 웹폰 전자카드 등의 내 장형 시스템으로 그 응용 분야를 넓혀 가고 있다., 그러나 자바를 내장형 시스템에 적용하기 위해서는 느린 수행 속도,, 실시간성 지원 미비 낮은 예측가능성 등의 단 점을 극복하는 작업이 필요하다.

-99- 본 과제에서는 위에서 언급한 요구에 부흥하기 위해 내장형 시스템의 제약조건을 고려하여 다양한 플랫폼 상에서 내장형 자바 솔루션을 개발하였다. 모토톨라 MPC860 CPU보드상에서 Kaffe+VxWorks, PersonalJava+VxVVorks, PersonalJava+VxWorks (자바가상기계 + 운영체제 ) 등의 자바 수행 환경을 개발하였 다.2 절에서 언급한 바와 같이 본 과제에서 개발한 자바 수행 환경은 내장형 시스 템의 특성을 고려하여 경량,PJCK 실시간 지원 등의 특성을 고려하였으며 와 같이 공인된 안정성 검사를 통하여 그 안정성이 증명되었다., 따라서 본 과제에서 개발된 자바수행환경은향후다양한내장형기기에서활용될가능성이높다고할수있 다.PDA 향후 과제로는 이동전화나 와 같이 초경량의 자바 수행 환경을 요구하는 이동 정보 기기에로의 응용을 들 수 있다.

-100- 논문 목록

• Heegoo Kang, Minyoung Sung, Teahyoun Kim, Dongryeol Lee, Soyoung Kim, Kwangyoung Kim, Hyungsoo Kim, Naehyuck Chang and Heonshik Shin,"Implementation and Performance Evaluation of Real-Time Java Thread for Embedded Systems," in Proceedings of the 27th KISS Spring Conference, Apr. 2000.

• Taehyoun Kim, Naehyuck Chang and Heonshik Shin, "Bounding Worst Case Garbage Collection Time for Embedded Real-Time Systems," in Proceedings of the 6th IEEE Real-Time and Applications Symposium.2000.

• Teahyoun Kim, Naehyuck Chang, Namyun Kim and Heonshik Shin, "Scheduling Garbage Collector for Embedded Real-Time Systems," in Proceedings of ACM SIGPLAN 1999 Workshop on Languages, Compilers and Tools for Embedded systems, pp. 55-65, Atlanta, USA, May 1999. also in the July 1999 issue of SIGPLAN Notices.

• Jongwon Kim, Heegoo Kang, Naehyuck Chang and Heonshik Shin, "Analysis of Java Virtual Machine for Embedded Systems," in Procs. of the 26th KISS Spring Conference, Apr. 1999.

• Taehyoun Kim, Kwanyoung Kim, Naehyuck Chang and Heonshik Shin, "Real-time Garbage Collection in Java," in Proceedings of CMC '99. pp. 210-218, Feb. 1999.

-101- 부록

(1) VxWorks상에서 kaffe 포팅시 alarm() 함수 구현

(2) VxWorks상에서 kaffe 의 내이티브 메쏘드 호출부 구현 내용

-102- -103- (3) VxWorks상에서 PersonalJava 포팅시 모듈 로딩 기능 구현

-104- -105- -106- (4) VxWorks상에서 PersonalJava 의 내이티브 메쏘드 호출 함수 구현

-107- (5) VxWorks상에서 PersonalJava 의 IEEE754 표준 관련 기능 구현

① remainder()와의구현 round()

-108- -109- ② IS_NAN 구현

③ 타입간 변환 함수 구현

-110- (6)리녹스 상에서 PersonalJava 의 Green Thread 관련 부분

① 솔라리스에만 정의되어 있는ucontext_t 를 대신하여 리눅스에 사용하는 자료 구조

-111- ② 쓰레드의 문맥에 해당하는 자료구조

③ 데스크탑 버전 리눅스(i386) 에서 사용되는 문맥 관련 매크로들

-112- ④ 내장형 리눅스(powerpc) 에서 사용되는 문맥 관련 매크로들

-113- ⑤ 쓰레드의 문맥을 초기화하는 함수-(i386) 데스크탑 리눅스

-114- -115- ⑥ 쓰레드의 문맥을 초기화하는 함수- 내장형 리눅스 (powerpc)

-116- (7)리녹스 상에서 PersonalJava 의 Native Thread 관련 부분

① suspend 구현

-117- ② resume 구현

-118- ③ signal handler 구현 예

-119- -120- iPCTV를위한내장형실시간컴포넌트 객체 모델의 설계와 구현

서울대학교

-121- 목차

제장서론1 제1 절 연구 배경 및 필요성 가. 시대적 상황 나. 기술 종속의 문제점 다. 실시간 운영체제와 실시간 컴포넌트 객체 모델의 이점 라. 종합적 의의 제2 절 국내외 연구 동향 가. 국내연구동향 나. 국외연구동향 제3 절 기대 효과 가. 기술적 가치 나. 경제적 가치

제2 장 기술개발 내용 및 방법 제1I-PCTV 절 용 멀티미디어 실시간 운영체제 가. 커널 메카니즘 나. 실시간 멀티미디어 지원 다. 멀티미디어 스트리밍 지원 라기능지원.PlugandPlay 마. 저전력 관리 연구 바. 주기적 실시간 쓰레드를 위한 쓰레드 인터페이스의 확장 제2I-PCTV 절 를 위한 내장형 실시간 컴포넌트 객체 모델의 설계와 구현 가.CORBA2.2 표준을 만족하는 ORB 내부 구조 연구 나. 멀티미디어 디스플레이를 위한 객체 모델 연구 다.CORBA 실시간성 의요구조건연구 라.QoS 기술방법연구및 QoS 보장기법구현 마. CCDR(compact common data representation)

제장결과3 제1I-PCTV 절 용 멀티미디어 실시간 운영체제 가.QNX 를 기준으로 한 커널의 기본 성능의 평가 나업콜성능. 다.() 사용자 수준 입출력 인터립트 성능

-122- 라. 쓰레드 스케쥴링 성능 마. 커널과 쓰레드 패키지의 안정성 검증 바., 스트리밍 재생 전력 사용 및 장치별 자동 비율 인식 제2I-PCTV 절 를 위한 내장형 실시간 컴포넌트 객체 모델의 설계와 구현 가. 미들웨어의기본성능측정 나.EIOP 프로토콜 수행 대기시간 다. 정적 메모리 요구사항

참고문헌

-123- 제장서론1

제1 절 연구 배경 및 필요성

가. 시대적 상황

현재 첨단 전자 제품 시장은 컴퓨터,, 통신 가전 기술이 융합 되는 경향으로 가고 있다., 제품에 마이크로 프로세서를 탑재 시켜 제품을 지능화하고 구현과 업그레이 드 과정에서 유연성을 제공하려고 한다. 이전의 제품은 하드웨어적으로 고정되어서 일단 완성된 제품 형태가 되면 기능을 추가하거나 변경하는 것이 어려웠다., 하지만 마이크로 프로세서를 탑재하면서 프로그램을 통해서 기능을 변경하거나,, 수정 확장 하는 것이 용이해졌다. 이런 경향은 내장 시스템 (embedded system) 의 경우를 보 면 알 수 있다.1995 년의 경우 2 천만개의 마이크로 프로세서가 PC 시장에서 소 요된 반면16 억 개의 마이크로 프로세서 칩이 내장 시스템 (embedded system) 에 사용되었으며, 매년 20% 의 증가율을 기록하고 있다 (OSAF 의 보고서를 참조 ). 더군 다나 고성능 마이크로 프로세서의 가격은 크게 인하되었기 때문에, 산업 및 가전제 품 시장에서 하드웨어 중심의 시스템에서 소프트웨어 중심의 유연성 있는 시스템 의 전환은 가속화되고 있다. 소프트웨어의 유연성은 실시간 운영체제의 지원으로 이루어지기 때문에, 실시간 운 영체제는 내장 소프트웨어(embedded software) 에서 중요한 문제로 부각되고 있다 . 내장 시스템 개발에서 많은 경우는 소프트웨어의 개발 비용이 하드웨어의 개발 비 용을 초과하고 있으며, 소프트웨어 개발 환경이 제품 개발의 생산성에 큰 영향을 주고 있으며,. 개발 주기를 단축시키고 있다 더 이상 하드웨어에 부속되어 있는 형 태가 아니라 대등하거나 오히려 더 큰 비중을 차지하고 있다.

-124- (1) 실시간 운영체제

내장 소프트웨어와 관련된 산업분야의 예로는 통신,,, 가정 자동화 자동차 공정 제 어 등이 있다.ATM 먼저 통신 분야에서는 지능형 네트워크 스위칭 시스템이나 서 버,. 음성 메일 시스템을 예로 들 수 있다 이것들이 점차적으로 대화형 비디오나 멀 티미디어 서비스, 고속 데이터 링크와 같은 복잡한 분야로 발전되어 감에 따라 유 연한 시스템을 요구하게 되었다., 즉 현재와 같은 비체계적인 소프트웨어 개발 기법 에서 벗어나 실시간 운영체제를 기반으로 한 체계적인 시스템의 개발이 필요하게 되었다.TV,, 가정자동화 분야에서는 비디오 레코더 리모트 컨트롤러와 같은 다양 한 제품들이 내장 소프트웨어를 필요로 하고 있다. 마찬가지로 자동차와 공정 제어 분야에서도 실시간 운영체제에 대한 욕구가 크다고 할 수 있다. 특히 공정 제어분 야는 산업 시스템뿐만 아니라 과학,, 우주선 방위 시스템을 포함하는 개념으로 안정 적인 동작에 대한 보장과 시간적 제약을 만족시키는 것이 아주 중요하다. 시간적 요구조건의 만족이 필수적인 시스템의 개발은 자연스럽게 비체계적인 시스템의 개 발 기업의 한계를 느끼게 해주었고, 이를 지원하는 실시간 운영체제의 도움을 절실 히 요구하고 있다.

(2) 실시간 컴포넌트 객체 모델

멀티미디어의 시간제약성 현재의 멀티미디어 기기들은 점점 더 좋은 화질과 음질을 향해 발전하고 있다. 화 면과 소리가 나오느냐의 문제에서 벗어나 얼마나 더 좋은 화면과 소리를 만들어 낼 수 있느냐 하는 것이 멀티미디어 기기들의 생존 과제가 되었다. 덧붙여 부가적인 기능을 제공하는 것도 중요한 과제이다.,, 좋은 화질 음질 부가 기능은 모두 처리해 야 할 멀티미디어 데이터의 양이 갈수록 증가하고 있다는 것을 의미한다. 실제로 예를 들면, 초당 20 프레임의 동영상을 처리하고 , 해상도가 320*200 이며 , 한 픽셀 당8 비트의 컬러로 표시한다고 하면 1프레임의 데이터 =** 가로 해상도 세로 해상도 한 픽셀당 비트수 = 320 * 200 * 8 = 512000 = 62.5 Kbyte 1초에 처리하는 데이터 =1 프레임의 데이터 * 초당 프레임 =62.5Kbyte*20프레임 =1,250Kbyte=1Mbyte 가 된다.

-125- 초당20 프레임이나 320 * 200 의 해상도 , 한 픽셀 당 8 비트로 된 화질은 현재 멀티 미디어가 지향하는 수준에는 턱없이 낮은 수치임에 분명하지만,1 그래도 초에 1Mbyte의 데이터를 처리해야 한다는 결론에 도달한다 . 또한 멀티미디어의 데이터 는 엄청난 양 때문에 반드시 압축해야 하는데, 그러면 압축을 푸는 데에도 시간이 걸리게 된다. 문제는 멀티미디어 기기의 소비자들이 요구하는 수준이 점점 높아지 고 있기 때문에,., 점점 더 시간의 제약을 가지게 된다는 점이다 따라서 실시간 운 영체제와 결합된 체계적인 모델의 확립이 필수적이다. 컴포넌트 단위의 객체모델 더군다나I-PCTV 같은 기기는 영상 처리 뿐만 아니라 다양한 기능을 가져야 하므로 이를 컴포넌트 단위로 만들어서 기존의 시스템에 첨가해서 기능을 확장할 수 있는 방향으로 나아가야 한다.I-PCTV 와 같은 정보가전에서 컴포넌트 객체 모델은 소프 트웨어 개발 비용을 줄이면서도 신뢰성과 상호 운용성을 향상시키는 유력한 수단으 로 주목 받고 있다.CORBA,DCOM 컴포넌트 객체 모델은 등의 객체 미들웨어를 통해(1) 서버와 씬 - 클라이언트 (thin client) 간의 분산 컴퓨팅을 구현하고 , (2) 독립 적으로 개발된 소프트웨어 모듈을 통합해 새로운 기능을 구성하는 Plug and Play 를 가능하게 한다. 그러나 최근까지 이러한 컴포넌트 객체 모델은 중대형 컴퓨터와PC 간의 범용 컴 퓨팅 환경을 기준으로 연구되었다.QoS 따라서 등 실시간성이 중시되고 시스템 자 원의 효율적 관리가 필요한 내장형 시스템이 그대로 적용하기에는 무리가 따른다. 이에 따라QoS, 서비스 예측성 등 실시간 요구조건을 만족시키며 내장형 시스템에 적합한 실시간 미들웨어가 요구되고 있다. 주변기기와의 접속성 및 저전력성 또한TV 혼자서 작동되는 구조에서 탈피 , 여러 주변기기와 통신을 하려고 시도하는 추세이므로 주변기기와의 손쉬운 접속기능도I-PCTV 가 가져야 할 기능이다 . 각종 산업 표준 버스에 대해PnP 기능이 일반화되고 있고 Windows 계열의 운영체계에 서 적극 활용되고 있으나,RTOS 일반적인 에서는 그 적용을 찾기 어렵다 ., 또한 I-PCTV 는주변장치들의전력사용역시자동으로관리할수있는저전력시스템 을 지향해야 한다.

-126- 나. 기술 종속의 문제점

이런 중요성에도 불구하고 국내에서는 실시간 운영체제에 대한 개발이 크게 뒤처져 있다. 이에 따라 실시간 운영체제에 대한 기술을 전적으로 외국 기업에 의존할 수 밖에 없다. 이런 현상은 외국에 대한 기술적 종속과 함께 많은 심각한 문제점을 초 래한다. 실시간 운영체제의 전문적 특성상 사용 기업들은 개발 제품에 알맞은 지원 을 받기 위해 실시간 운영체제 개발회사에 자신의 제품정보를 제공하고 있는데 이 것이 제품에 대한 정보유출과 경쟁력 저하로 이어지는 경우가 흔히 발생하고 있다. 오늘날과 같이 정보의 중요성이 더해 가는 시점에서 볼 때 국내기업의 산업정보를 철저하게 보호하여야 하며 신제품개발 과정에서 외국기업이 기밀사항에 접근할 수 없도록 하여야 하는 것은 당연한 일이다. 이를 위해서는 국내에서 실시간 운영체제 와 관련한 기술을 확보해야 하는 것은 절실한 과제이다. 멀티미디어 분야의 기술은I-PCTV 같은 영상 기기에 국한되지 않고 많은 분야에 파급될 수 있다.,, 일반 가전 기기 뿐만 아니라 통신 기기 컴퓨터 등 정도의 차이는 있겠지만, 폭 넓은 분야에서 활용될 수 있는 중요한 기술임을 감안한다면 이를 외 국의 기술에 의존할 경우 막대한 외화의 유출은 물론, 기술상으로도 뒤쳐지게 될 것은 자명하다.

다. 실시간 운영체제와 실시간 컴포넌트 객체 모델의 이점

한편 요즘 기술개발과 관련된 초점은 인터넷과 개인통신장비에 있다. 이와 관련된 실시간 운영체제의 역할에 대해 알아본다면 현재의 산업화동향을 가장 잘 이해할 수 있을 것이다.TV 인터넷과 관련되어서 한창 주목되고 있는 가전제품으로는 의 기능에 웹 검색기능을 추가한WebTV 를 들 수 있다 . 메모리와 디스크가 장착되지 많기 때문에 통신,, 그래픽스 멀티미디어 등의 여러 가지 기능을 효율적으로 관리하 고 지원하기 위해서는 실시간 운영체제는 필수적으로 포함되어야 한다. 이미 소니 社를 비롯한 세계의 여러 회사가 개발 중에 있으며 Microware, Integrated System 등의 선발 기업들이 이를 위한 실시간 운영체제를 상품화하고 있다. 통신분야에서 역시 개인통신장비인PDA(Personal Digital Assistant) 를 개발하기 위해 실시간 운 영체제에 의존하고 있다. 예를 들어 애플社 의 PDA 인 MessagePad 의 경우 내장 된 글자인식기능,, 팩스 전자우편 , 데이터베이스 , 데스크탑과의 인터페이스 등 다양 한 기능을 내장하고 있는데 이들을 관리하는 운영체제로서 자체 개발한 Newton OS 2.0을사용하고있다 . Newton OS 를통해종래에비추어 4-12 배가량의성 능 향상을 가져왔다고 애플社 는 발표하고 있다.

-127- 웹(web) 과 실시간 운영체제의 결합은 새로운 시장을 열어가고 있는데 전문적 실시 간 운영체제를 개발, 판매하는 회사 역시 멀티미디어 단말 장치에서 웹에 접근을 가능하게 하는 기술을 포함시킨 실시간 운영체제를 개발하고 있다.QNX 실시간 운 영체제 개발회사로 유명한QNX 소프트웨어 시스템에서는 제조회사로 하여금 최소 한의 소프트웨어 개발비용으로 웹 도구를 만들 수 있도록 하는 마이크로 커널인 Neutrino를 발표하였으며 , 역시 OS-9 이라는 실시간 운영체제를 개발한 Microware 에서는 인터넷에 관련된 기능이 첨가된Internet OS-9 를 개발하였다 . 실시간 컴포넌트 객체 모델의 이점은 앞에서 언급한 것처럼 다양한 가능을 추구하 는 정보 가전 혹은 멀티미디어의 기기에서 손쉽게 기능을 수정,, 보완할 수 있고 업 그레이드를 용이하게 해 준다.

라. 종합적 의의

실시간 운영체제는 빠른 속도로 제품의 중요한 요소가 되어가고 있으며 여러 분야 에 있어서 중요한 역할을 하고 있다. 소비자가 보다 많은 기능과 그리고 유연성을 요구하게 됨에 따라 품질이 우수한 제품을 효율적으로 생산해야만 하는 상황이 초 래되었고, 이것이 실시간 운영체제를 비롯한 실시간 컴포넌트와 같은 내장 소프트 웨어의 기술개발이 절실하게 된 요인이 되었다.

제2 절 국내외 연구 동향

가. 국내연구동향

국내에서는 실시간 운영체제에 관련해서 연구가 활발히 이루어지지 않았지만 최근 들어 중요성에 대한 인식이 이루어져 가고 있다. 최근에 실시간 운영체제에 관련되 어 수행된 개발내용으로는 전자부품연구소를 중심으로 수행된“ 가입자 단말기용 실 시간 운영체제 개발”. 이 있다 이것은 통산산업부에서 시행한 공업기반기술개발사업 의 기술개발의 일환으로 수행되었다.. 수행결과를 요약하면 아래와 같다

• 가입자 단말기를 위한 기능 분석 -,오디오 비디오 관련 표준화 가구인 DAVIC 의 자료분석 • 기능 분석을 근거로 운영체제의 개발 사양 확정 및 구조 설계 -,,//실시간 커널 프로토콜 그래픽 오디오 비디오 라이브러리 정의 -,,실시간 커널의 기능으로 태스크관리 기능 세마포어 관리 기능 메시지 큐 -,,,,관리 기능 이벤트 그룹 관리 기능 타이머 관리 기능 메모리 관리 기능 - 일정크기의버퍼관리기능등을결정

-128- 실시간운영제재에대한기술을개발하고지원하는회사는외국에는많은곳이있 으나 국내에는 기의 전무하여 많은 투자가 필요한 상황이다. 국내에서는 독립적으 로 실시간 운영체제를 지원하는 회사가 없어서 제품을 개발하는 부서 내에서 자체 적으로 개발하여 쓰고 있는 실정이어서 실시간 운영체제에 대한 체계적인 기술적 혁신을 기대하기 어려운 실정이다. 학계를중심으로한국내의연구노력은아직기술적결실을맺지못한상태이며, 우리 나라의 시스템 소프트웨어 기술은 선진국에 비해10 년 이상 뒤떨어져 있다 . 이에 따라 국내 가전업체들은 외국의 실시간 운영체제 제품에 크게 의존하고 있다. 삼성전자는 미국의ISI 사에서 pSOS 소스코드를 구입해 이를 자사 제품에 맞게 개 량하면서 디지털TV 를 비롯한 정보가전 기기에 채용하였다 . 삼성전자는 이와 함께 개인정보 단말기류와 인터넷 전화기에 윈도CE 와 pJAVA 를 적용하였다 . LG 전자는 엑셀레이티드 테크놀로지사가 개발한 뉴클리어스의 소스코드를 들여왔고 휴대형 PC등에는 윈도 CE 를 적용하기도 하였다 . 역시 미국의 테크네마 사의 소스코드를 도입한 대우전자는 이를 개랑해 알바트로스란 자체 운영체제로 개발하여 인터넷 셋 톱 박스에 적용하였다.( 출처 : 정보통신연구원 98 소프트웨어 동향 보고서 ). 실시간 컴포넌트 객체 모델과 같은 미들웨어 기술 분야는 국내 연구 투자가 아직 미미한 상황이다.DBMS 범용 미들웨어에 대한 연구는 과거 중대형 시스템용 와 OLTP를 중심으로 많이 수행된 바 있다 . 그러나 내장형 시스템에서는 유무선 분산 환경과 멀티미디어 통신을 염두에 둔 초경량의 실시간 미들웨어가 요구되므로 독자 적인 연구가 필요하다. 한편 멀티미디어 기기를 비롯한 정보가전 제품의 기술 경쟁이 이미 미들웨어와 응 용프로그램으로확장되고있어국내기업들은실시간운영체제를제품에적용하기 위해서 추가적으로 커널 개선과 미들웨어 도입, 전문적 설계와 개발 도구의 확보가 필요한상황이다현재각기업별로이를해결하기위한노력을경주하고있으나. 기반 기술과 인력 부족에 따른 어려움을 겪고 있다. 결국 경쟁력있는 정보가전 제 품의 실질적 개발을 위해 미들웨어 등 통합 소프트웨어 기술력이 절실히 요구되고 있는 상황이다.

-129- 나. 국외연구동향

커널 기능과 간단한 개발 도구만을 갖추고 있는 상태에 머물러 있어 통합 소프트웨 어 플랫21 세기 첨단 핵심 기술로 등장하고 있는 내장형 시스템 소프트웨어 시장의 주도권을 장악하기 위해 세계 각지의 유수한 기업들은 치열한 경쟁을 벌이고 있다. 실시간 운영체제를 개발하는 외국 기업은 백여곳에 이르고 있으며 그 대표적인 기 업으로는OSE, LynxOS, VxWorks, OS-9, VRTX, pSOS, CX/UX, QnX 등이 있으 며, 현재 미국의 마이크로텍 , 윈드리버시스템 , ISI 사 , 캐나다의 QSSL 사 등이 개발한 약10 여 개의 실시간 시스템 소프트웨어 [ISI 96][QSSL 96] 가 세계 시장을 분점 하고 있다. 최근에는 급부상하는 정보가전 시장을 장악하기 위해 주요 범용 소프트 웨어 제조사들도 속속 실시간 시스템 소프트웨어 시장에 가세하고 있다. 일례로 마 이크로소프트 사는Windows CE 를 들고 경쟁에 가세하였으며 , 선 마이크로 시스템 사는1997 년 말 유럽의 대표적 실시간 운영체제 제작사인 코러스 사를 전격 인수 하였다.. 이 기업들의 시장점유율은 다음 표와 같다

치열한 실시간 운영체제 시장의 경쟁 속에서 보다 고기능의 개발환경과 다양한 미 들웨어들이 개발되고 있으며,. 이미 일부는 산업계 표준이 되었다 일례로 마이크로 웨어사의OS-9 은 디지털 TV 국제 표준인 DAVIC [DAVIC 99] 의 Reference OS 로 표준 형성에 참여하였고 다양한 미들웨어와 함께 여러 셋톱 박스에서 사용되고 있 다.,, 아울러 마이크로소프트와 선 등은 윈도우 시스템 인터넷 브라우저와 프로토콜 Active X, CORBA [OMG 98]/JAVA 등 핵심 미들웨어 기술을 보유하고 있어 기술 경쟁이 실시간 운영체제의 영역을 벗어나 미들웨어를 이용한 통합 소프트웨어 플랫 폼의 구축으로 확대되어 가고 있는 상황이다. 이미 OMG 가 Minimum CORBA [Alca 98-1], Real-Time CORBA 1.0 [Alca 98-2] 표준을 제창하고 선 마이크로 시스템 사의Jini Architecture [Sun 99] 도 표준화 경쟁을 벌이고 있다 .

-130- 제3 절 기대 효과

가. 기술적 가치

실시간 운영체제와 컴포넌트 객체 모델 기술 같은 미들웨어를 기반으로 한 내장 시 스템의 적용분야는 무수히 많이 존재한다., 이를 커다란 분야별로 나누어 본다면 고 품위TV,VCR. 오디오 콤포넌트 등과 같은 가전제품들과 ,,, 프린터 복사기 스캐너 등의 사무자동화 제품들이 있으며,FAX, 이동전화기나 방송장비 등과 같은 통신시 스템과 산업용 로봇 등과 같은 공장 자동화 시스템 등을 생각할 수 있다. 그 밖에 PDA나 비디오 게임기 , 자동차 등의 여러 응용분야를 생각해 볼 수 있다 . 이들 중 에서 몇가지 분야를 살펴보면 다음과 같다. WEB TV 인터넷은 물론이고 컴퓨터에조차 아직 익숙하지 않은 일반 사용자들이 리모콘 조작 만으로 인터넷의 정보를 얻을 수 있게 하자는 취지의WEB TV 가 실용화를 눈앞에 두고 있다. 여기에 참여하고 있는 회사들로는 Zenith, Mitsubishi, Sony, Phillips 등 이 빠르면 올해안으로 제품을 선보일 계획을 가진 회사도 있다.Zenith 사의 경우는 NetVision이라는 새로운 TV 를 $1,000 정도에 출시할 계획을 가지고 있으며 , Sony 와Phillips 의 경우는 WebTV 사의 셋톱박스 기술을 도입하여 $200~$400 정도의 가 격에 출시할 계획을 가지고 있다. Microsoft 사의 경우는 PC 에서 인터넷을 통해 TV 를 시청할 수 있도록 하기 위한 서비스를 제공하고 있으며,SEGA 와 Nintendo 등 의 회사들은 자신들의 비디오 게임기를 통해서 인터넷을 시용할 수 있도록 하는 기 능을 첨가시키고 있다. 본 프로젝트에서 개발할 운영체제는 이러한WEB TV 등에 사용될 수 있으며 , 이를 바탕으로 하여 필요한 응용 소프트웨어를 개발할 수 있게 된다. PDA 원하는 정보를 그 자리에서 바로 얻어낼 수 있도록 해주는 PDA(Personal Digital Assitant)와 관련된 소프트웨어를 개발하는 데 사용될 수 있다 . 현재 상용화 되었거 나개발되고있는제품들은사용자의펜입력등을통한자료검색기능뿐만이아 니라, WWW 을 이용할 수 있도록 하는 기능도 추가시키고 있으며 , JAVA 기술을 이 용하여 인터넷으로부터 프로그램을 다운로드받아 사용할 수 있도록 하는 기능도 첨 가하고 있다. 본 프로젝트에서 개발될 운영체제를 이용하여 이러한 기능들을 구현 할수있다. 내장 제어(Embedded Control) 시스템 내장 제어 시스템에서는 센서와 액추에이터 사이의 데이터 전송이 실시간으로 이루 어져야 하며,. 이에 사용되는 운영체제는 실시간으로 동작해야 한다 본 프로젝트에 서 개발될 운영체제는 실시간 처리기능을 바탕으로 하고 있으므로, 이러한 요구사 항을 충족시킬 수 있다.

-131- 통신 분야 ISDN전화기 , 이동전화기 등에 사용되는 소프트웨어의 개발에 필요한 운영체제로서 사용될 수 있다. 이러한 통신 시스템 역시 사용자들에게 자연스러운 통화기능을 제 공해야 한다는 점에 있어서 실시간 시스템의 도입이 필수적인 분야이다.

나. 경제적 가치

국내외 실시간 운영체제 시장은 상당히 유동적으로 제품개발시 충분한 시장성을 가 지고 있다.989.( 세계 시장 규모는 년 현재 억 달러로 추정된다 국내 시장은 구체적 자료 없음.) 그러나 향후 시장은 이보다 훨씬 커질 것으로 예측된다 . 특히 정보가전 과 통신 단말기가 향후 수요를 주도할 것으로 보이는데IDC 에 의하면 2002 년 이들 정보가전의 매출랑이5,500 만개에 1,500 억 달러에 이를 것이라 한다 . 이에 따라 디 지털TV 등 정보가전기기의 실시간 운영체제 라이선스 비용을 대당 5.6% 로 산정할 때( 출처 : The Yankee Group, 1998), 2002 년에는 전세계적으로 82 억 달러 가량의 엄청난 수요가 기대된다. 실시간 운영체제에 대한 전세계 시장 크기에 대한 조사와 예상을 살펴보면 다음과 같다.

주시장( 국가 또는 지역 ):,, 미국 유럽 아시아 시장 규모 ( 세계 시장 ) RTOS판매량 (1994-1998)

RTOS총판매액 (1994-1998)

※ 산출근거: IDC(International Data Corporation) Consulting

위의표에서알수있듯이시장규모와성장가능성이매우높다고할수있으며실 시간 운영체제가 영향을 미치는 전체 산업분야를 살펴본다면 더욱 큰 시장규모를 가지고있고생각할수있다.

국내시장을 고려하여 수입대체효과와 수출관련효과를 알아보면 아래 표와 같다.

-132- 수입 대체 효과

수출 관련 효과

또한 실시간 컴포넌트 객체 모델의 연구는 생산성 향상에 기여하는 시장 가치가 매 우 크리라고 전망된다. 본 과제의 결과물인 콤포넌트에 기반한 소프트웨어 개발 기 법,, 객체지향적 설계 기법 추상화를 제공하는 미들웨어 , 그리고 이들을 실제로 구 현하는 설계 도구들은I-PCTV 와 같은 실시간 운영체제를 바탕으로 하는 멀티미디 어 분야에서 소프트웨어 개발 생산성 향상에 크게 기여할 것이다.

제2 장기술개발내용및방법

제1 절 I-PCTV 용 멀티미디어 실시간 운영체제

가커널메카니즘.

본 과제에서 개발한I-PCTV 용 멀티미디어 실시간 운영체제는 기본적으로 사용자 수준 쓰레드 라이브러리를 지원하는 일체형 커널에 기반을 두고 있다.Arx 이를 라 고 명명하기로 한다. 사용자 수준 쓰레드를 지원하기 위한 사용자 수준 스케줄러와 그 상에서 동작하는 사용자 수준 쓰레드를 사용할 경우 얻게 되는 가장 큰 장점은 스케줄링 관련 서비스를 이용할 경우 커널 모드로의 진입이 필요 없어진다는 것이 다. 또한 쓰레드 모델에 의한 스케줄링을 수행하므로 프로세스 모델에서의 많은 오 버헤드가 감소하게 된다.Arx,, 이를 기반으로 의 이식성 확장성 실시간성을 제공하 기 위한 연구를 수행하였다.1 그림 은 본 과제에서 개발한 실시간 운영체제 커널의 기본적인 메커니즘을 보여주고 있다.

-133- 그림1: Arx 커널의 기본 메커니즘

한편 사용자 수준 쓰레드를 통해 실시간성을 지원하기 위하여서는 사용자 수준 쓰 레드의 쓰레드 블록킹 변칙을 해결해야 한다.(1) 이는 사용자 수준 스케줄러로 스 케줄링 이벤트가 전달되지 못하고,(2) 블록킹 쓰레드가 프로세스의 커널 스택을 가 지고 슬립 큐(sleep queue) 에 놓여지기 때문에 발생한다 . 이 두 가지 문제를 풀기 위하여 스케줄링 이벤트 업콜과 동작 가상 쓰레드 바인딩의 메커니즘을 연구하였고 이를Arx 커널에 구현하였다 . 허용 가능한 비용으로 내장 실시간 시스템의 선점형 사용자 수준 쓰레드를 구현할 수 있도록 오버헤드를 낮추는데 초점을 맞추어 이 스 킴들을 설계했다.

(1) 동적 가상 쓰레드 바인딩

가상 쓰레드는 커널 수준 쓰레드와 유사한 역할을 한다. 이 쓰레드는 사용자 수준 쓰레드에게 커널 스택을 제공하고 커널에게는 현재 실행중인 또는 커널 모드에서 블록된 사용자 수준 쓰레드를 구별할 수 있는 식별자(identifier) 를 제공한다 . 그러나 커널 쓰레드와 달리 동적(dynamic) 이며 수동적인 (passive) 존재이다 . 가상 쓰레드 는 단지 사용자 수준 쓰레드의 커널 수준 형상화에 불과하다. 사용자 수준 쓰레드 는 시스템 콜을 통해 커널에 들어가는 시점에서 가상 쓰레드에 묶여진다. 가상 쓰 레드는 수동적인 존재이기 때문에, 사용자 수준 쓰레드를 다중플렉싱하거나 커널에 의해서 스케줄되지 않는다.

-134- 그림2. 는 가상 쓰레드의 커널 데이터 구조체를 보여준다 이는 한 프로세스에서 유 일한 가상 쓰레드 식별자, 사용자 수준 쓰레드가 시스템 콜을 수행하는 커널 스택 으로 구성된다., 사용자 수준 쓰레드가 커널 내에서 블록되면 이와 묶인 가상 쓰레 드는sleep channel 상에 놓여진다 . 또 각 프로세스를 위해 , 커널은 현재의 가상 쓰레드, 미리 마련한 가상 쓰레드들의 풀 (pool) 과 사용자 수준 쓰레드와 묶여 사용 중인 가상 쓰레드들의 리스트(list) 와 같은 필드를 프로세스 구조체 안에 보존한다 . 풀의크기는런타임(runtime) 에조정될수있다가상쓰레드가필요할때풀이비 . 어있지 않으면 풀로부터 하나를 취하고, 그렇지 많을 땐 새로운 가상 쓰레드를 생 성한다., 이와 마찬가지로 시용되던 가상 쓰레드가 양도되면 , 풀로 돌려지거나 폐기 된다. 커널은사용자수준쓰레드를오직그와묶인가상쓰레드에의해서구별할수있 지만 사용자 수준의 쓰레드 스케줄링에 영향을 줄 수는 없다., 결과적으로 사용자 수준 스케줄러는 스케줄링 이벤트 업콜 메카니즘의 도움으로 쓰레드 스케줄링의 전 권을 가진다.

그림2: 다중 쓰레드 프로세스의 커널과 사용자 데이터 구조

-135- (2) 스케줄링 이벤트 업콜

응용 프로그램이 사용자 수준에서 쓰레드를 제어하기 위해서는 쓰레드 블록킹/ 언블 록킹과 타이머 만기와 같은 커널 이벤트에 대해 적절하게 반응해야 한다. 본 보고 서는 커널 이벤트의 효율적인 전달을 목적으로 스케줄링 이벤트 업콜 메카니즘을 제안한다., 스케줄링 이벤트의 발생 시에 커널은 이 이벤트를 업콜을 통해 사용자 수준 스케줄러에게 알려준다., 전형적인 함수 호출과 달리 업콜 인자는 사용자 수준 스케줄러의 선택에 쌓이지 않는다., 대신 스케줄러 콘트롤 블록 (SCB) 이라는 커널 / 사용자 공유 데이터 구조체 안에 위치한 이벤트 큐브를 통해 전달된다.SCB 는 사 용자 주소 공간에 매핑되어 있다. 프로세스의 실행 상태와는 무관하게 커널이 이벤 트를 대기시키므로,. 과부하 상태일 지라도 적은 지연을 가지고 이벤트를 전달한다 그림1SCB 은 내부의 데이터 필드를 보여준다 . 쓰레드 팩키지가 초기화 될 때 , 응 용 프로그램은SCB 의 기본 주소 , 이벤트 큐의 크기 , 사용자 수준 스케줄러의 진입 점과 스택의 주소를 명시한다.1 이 정보는 그림 에서 보여지듯 프로세스 구조체 안 에 저장된다. 이벤트 통지는 다음 절차를 따른다., 이벤트가 발생하면 커널은 먼저 현재 쓰레드의 문맥(context) 을 저장한다 . 이는 쓰레드의 현재 상태에 따라 다르게 처리된다 .

•현재 쓰레드가 커널 모드에서 실행중일 때 이벤트가 발생하면, 커널은 예약된 가 상 쓰레드들의 풀에서 가상 쓰레드 하나를 취하고( 또는 풀이 빈 경우 새로이 하나 의 가상 쓰레드를 생성하고), 프로세스에 이를 붙여서 현재의 가상 쓰레드로 만든 다. •그렇지 않으면,, 커널은 사용자 문맥을 사용자 스택 위에 복사하고 레지스터 파일 안의 옛 스택 포인터(stack pointer) 를 조정하고 이를 SCB 의 “interrupted thread context"필드에 저장한다 .( 쓰레드 팩키지가 쓰레드 문맥을 스택에 저장한다고 가정 한다.)

문맥을 저장한 후, 커널은 이벤트를 만들고 업콜 인자로 이를 채워 이벤트 큐에 놓 는다., 사용자 수준 스케줄러를 실행할 필요가 있으면 사용자 수준 스케줄러의 진입 점과 스택 포인터를 가지고 커널의 리턴 프레임(return frame) 을 마련한다 . 마지막 으로 리턴 프레임을 통해서 제어권이 사용자 모드로 양도된다.

-136- 커널이 사용자 수준 스케줄러를 호출했으면, 사용자 수준 스케줄러는 이벤트 큐를 비울 때까지,. 반복에서 이벤트를 꺼낸다 각 이벤트에 대해 우선순위 스케줄링에서 우선순위 조정과 같은 이벤트 특성에 따른 동작을 수행한다. 큐 안의 모든 이벤트 를 꺼낸 다음,.A 다음에 실행할 쓰레드를 결정하고 이를 디스패치한다 부록 에서 고정 우선순위 스케줄링을 구현한 사용자 수준 스케줄러의 예를 보이겠다.3 그림 (A)와 (B) 는 각각 시스템을 콜 도중에 I/O 이벤트를 기다리며 쓰레드가 블록과 언 블록될 때의 업콜 진행 절차를 설명한다.

그림3: 스케줄링 이벤트 업콜 예제 : (A) I/O 이벤트를 기다리는 시스템 콜 중에 쓰레드가 블록되었을 때,(B) 블록된 쓰레드가 외부 인터럽트로 깨어날 때

1) 이벤트 종류와 업콜 인자 본 과제에서 개발한Arx 커널의 업콜 스킴은 다음의 여섯 가지 스케줄링 이벤트를 지원한다. • BLOCK:쓰레드가 커널 모드에서 I/O 동작의 완료와 같은 이벤트를 기다릴 때 커 널은BLOCK 이벤트를 즉시 업콜한다 . BLOCK 이벤트는 관련 가상 쓰레드 식별자 와블록킹의원인(IO 또는잠겨진세마포어 (semaphore)) 을인자로서포함하고있 다.,lock 쓰레드 블록의 원인이 잠겨진 세마포어라면 을 가진 쓰레드의 가상 쓰레드 식별자가 함께 전달된다.( 이 인자는 3.5 절에서 자세히 설명할 우선순위 계승 프로 토콜에 사용된다). 이 이벤트에 대해서 , “interrupt thread context” 필드는 업콜로 인해 중단된 쓰레드가 없기 때문에 의미가 없는 정보를 담고 있다. • WAKEUP:블록된 쓰레드가 커널에서 깨어날 때 , 관련 가상 쓰레드의 식별자와 함께WAKEUP 이벤트가 사용자 수준 스케줄러에 전달된다 . 또한 커널은 SCB 를 통 해 중단된 쓰레드의 문맥 정보를 제공한다.

-137- • TIMER:사용자 수준 스케줄러가 미리 조절한 타이머가 만기했을 때 , 타이머 지연 값과 함께TIMER 이벤트가 사용자 수준 스케줄러에게 보내진다 . 커널이 이 이벤트 를큐에넣을때요구한타이머값과현재시간의차를계산해서그결과를이벤, 트 안에 기록한다. • SIGNAL:시그널을 프로세스에 넘겨주어야 할 때 , 커널은 프로세스 구조체의 siginfo구조체안에담긴시그널정보와함께 SIGNAL 이벤트를업콜한다 . 3.1 절 에서 상세히 설 명한다. • EXIT:프로세스가 exit(), exec() 와 fork() 를 호출한 경우 , 커널은 이 이벤트를 사 용자 수준 스케줄러에게 보낸다.4.2 절에서 설명한다 . • RESUME:선점 후에 프로세스가 재 시작될 때 , 커널은 선점 지속 기간과 함께 RESUME업콜을 사용자 수준 스케줄러에게 보낸다 . 쓰레드 실행 시간을 유지하기 위해 사용자 수준 스케줄러가 이 이벤트를 사용한다.

표1 은 이벤트 큐를 통해 넘겨지는 이벤트 타입과 해당 업콜 인자를 요약한다.

Event specific argument

BLOCK blockedvid,reason.

WAKEUP unblockedvid TIMER timer delay

SIGNAL siginfo structure

EXIT exitingvid RESUME duration of preemption

표1: 이벤트 업콜 인자 : Xvid 는 가상 쓰레드X. 의 식별자를 의미한다

2) lock이필요없는커널사용자동기화 -

사용자 수준 스케줄러와 커널은 공유하는 이벤트 큐를 두고 서로 경쟁하게 된다. 동기화 문제의 단순한 해결책은 커널이 지원하는locking primitive 를 사용하는 것 이다., 그러나 이 스킴은 사용자 수준 스케줄러가 실행 될 때마다 시스템 콜을 해야 하기 때문에 매우 비싸다.lock 대안으로 커널과 사용자 프로세스 사이의 이 필요 없는 동기화 스킴을 사용한다. 이를 위해 다음 방식으로 사용자 수준 스케줄러를 특별 설계한다.

-138- •사용자 수준 스케줄러를 두 개의 구조로 나눈다. 상위 구조에서는 이벤트 큐를 비 울 때까지 이벤트를 모조리 소비하고, 하위 구조에서 다음으로 실행될 쓰레드를 선 택 한다. •하위 구조의 실행은 안전하게 중지될 수 있다., 이를 가능하게 만들기 위해 사용자 수준 스케줄러는 자기 자신만의 사용자 스택을 갖고 있지만, 이외 다른 문맥 저장 영역이나 쓰레드 제어 블록을 가지지 않는다.

사용자 프로세스의SCB 의 lock 필드는 사용자 수준 스케줄러가 재진입이 불가한 코드(non-reentrant code) 를수행할때또는문맥교환을방지하기를원할때세트 된다., 이벤트가 발생하면 사용자 프로세스의 상태와 무관하게 커널은 이벤트를 이 벤트 큐에 넣을 수 있다. 커널은 업콜을 마치기 전에 사용자 스케줄러가 실행될 필 요가 있는지를 점검한다. lock 필드의 값이 0(zero) 이고 업콜 시점에 이벤트 큐가 비어있었을 경우에만 사용자 수준 스케줄러를 실행한다. 큐가 비지 않았다는 사실 은 사용자 수준 스케줄러가 큐에서 이벤트를 꺼내는 동안 커널의 업콜 핸들러로 인 해 저지 당했음을 의미한다. 따라서 이러한 경우에는 사용자 수준 스케줄러를 실행 하지 않는다., 만약 업콜 시점에 이벤트 큐가 비어있었으면 사용자 수준 쓰레드의 실행 중이거나, 또는 사용자 수준 스케줄러가 하위 구조를 실행하고 있었음을 앙시 한다., 어느 경우든지 커널은 새로운 사용자 수준 스케줄러를 실행한다 . 실행중인 사용자 수준 스케줄러가 있었다면,, 스케줄러는 같은 스택을 사용하기 때문에 새로 운 스케줄러가 예전 스케줄러를 지운다. 사용자 수준 스케줄러의 실행이 안전하게 중단되도록 설계했기 때문에,. 이상 기술한 과정들도 역시 안전하다

-139- 나. 실시간 멀티미디어 지원

(1) 사용자 수준 타이머의 관리

내장 실시간 시스템에서 높은 해상도의 타이머 서비스의 제공은 매우 중요하다. Arx운영체제는 100μ s 기본 시간 간격의 프로그램 가능한 타이머를 제공한다 . 프로 그래머는clock_setres() 시스템 콜로 타이머 시간 간격을 바꿀 수 있다 . 또한 각 프로세스는 사용자 수준 스케줄러가 관리하는 자신만의 사용자 수준 타이 머(SCB 의 timer 필드 ) 를 갖는다 . 사용자 수준 스케줄러는 timer 필드를 다음 타임 아웃 값으로 세트한다.timer,TIMER 타이머 만기 시 커널은 필드를 지우고 업콜을 만들어 사용자 수준 스케줄러를 실행한다.timer 사용자 수준 스케줄러는 를 다음 타 임아웃 값으로 세트한다., 이를 목적으로 사용자 수준 스케줄러는 쓰레드 도착 시 간, 종료시한과 깨어날 시간을 포함하고 있는 타임아웃 이벤트의 리스트를 관리한 다.tau_1tau_2,4 두 개의 주기적 태스크 와 에 대해 그림 는 사용자 수준 스케줄 러가 어떻게 리스트를 관리하는지를 설명한다. 시간 t_1 의 TIMER 업콜 이전에 , 리 스트는t_2 와 t_5 를 갖고 있다 . 시간 t_1 에 tau_2 가 도착한 후 , 사용자수준 스 케줄러는t_2 를 다음 타임아웃 이벤트로 기록하고 t_3 ( 새로 도착한 tau_2 의 종료 시한) 와 t_4 (tau_2 의 다음 도착시간 ) 를 리스트에 넣는다 . 시스템 클럭을 알기 위한 비싼 시스템 콜을 피하기 위해서, 커널은 시스템 시간을 SCB의 current system time 필드에 기록한다 . 사용자 수준 쓰레드는 단순히 필드 의 값을 읽어서 현재 시스템 시간을 얻을 수 있다.(clocktick) 커널이 매 클럭 틱 마다 필드를 갱신 하지만, 단지 현재 실행중인 프로세스의 필드만을 갱신하기 때문 에 오버헤드는 거의 없다.

그림4: 타임아웃 이벤트 리스트의 관리

-140- (2)실시간 이벤트 처리 : 이벤트 큐의 크기 제한

실시간 시스템에서‘; 중대한 이벤트에 적시에 반응하는 일은 매우 중요하다 그렇지 않으면,. 시간적 결점이 발생해서 환경에 비극적인 피해를 입힐 수 있다 전달된 이 벤트에 적시에 반응하는 일은 응용 프로그램 작성자의 책임이지만, 중대한 이벤트 를 놓치지 않는 일은 실시간 커널의 몫이다. 본 보고서의 이벤트 큐는 제한된 크기 의 원형 큐로 구현되기 때문에, 시스템이 이벤트가 돌발하는 순간적인 오버헤드를 경험할 때에는 이벤트를 잃어버릴 수 있다., 다행히도 이벤트 큐에 동시에 놓일 수 있는 이벤트의 최대 개수를 분석할 수 있다., 따라서 다음 분석을 통해 큐의 크기를 제한할 수 있다.

• BLOCK과 WAKEUP: 이 이벤트들은 사용자 수준 쓰레드가 호출한 시스템 콜의 수행 도중에 발생된다. 따라서 이러한 종류의 이벤트의 총 개수는 한 프로세스 내 에서 블록할 가능성을 가진 쓰레드의 개수를 넘지 않는다., 단 예외적으로 사용자 수준 스케줄러가BLOCK 이벤트를 꺼내기 전에 , 같은 쓰레드의 WAKEUP 이벤트가 그 이벤트(BLOCK 이벤트 ) 의 바로 뒤에 있을 경우도 있다 . 한 프로세스 내의 블록 당할 수 있는 쓰레드의 개수를b. 라고 하자 이런 종류의 이벤트는 많아야 b+1 개 가 동시에 큐에 존재할 수 있다. • TIMER:이 이벤트는 SCB 의 timer 필드가 적절하게 세트되어 있을 때에만 전달된 다.TIMER 커널은 이벤트를 전달할 때 이 필드를 리셋하기 때문에 , 사용자 수준 스 케줄러가 다시 한번 필드를 세트하지 않는 한 또 다른TIMER 이벤트는 전달될 수 없다., 그러나 사용자 수준 스케줄러는 이벤트 큐에서 TIMER 이벤트를 제거하기 전 에timer 필드를세트하기때문에동시에두개의 , TIMER 이벤트가큐에있을수 있다. • SIGNAL:오직 현재 실행중인 쓰레드만이 이 이벤트를 만들 수 있기 때문에 , 많아 야한개의동기적SIGNAL 이벤트가큐에존재한다한편외부인터럽트소스에 . , 서발생한비동기적SIGNAL 이벤트는여러개가있을수있다 . i 를전용인터럽트 핸들러 쓰레드의 개수라고 하자., 그러면 큐에 존재하는 비동기적 SIGNAL 이벤트 의개수는i+1 을넘지않는다 . TIMER 이벤트와같은이유로 1 을추가한다 . sigval필드는 32 비트 long 형이므로 비동기적 SIGNAL 각각을 최대 2^32 -1 개까 지 나타낼 수 있다.

분석 결과와 여분의 큐 헤더를 합해서 큐 크기의 한계 값을 구하면 다음과 같다.

-141- SIGNAL이벤트는 충분히 많은 수의 미처리 인터럽트를 담을 수 있으며 , 큐 크기는 분석한 바와 같이 한계 값을 가지므로, 커널이 이벤트를 잃어버리지 않는다고 보장 할수있다.

(3) 커널 오브젝트에 대한 우선순위 계승 프로토콜

다중쓰레드 응용 프로그램에서의 쓰레드는open file table 같은 공유 커널 데이터 구조에 대해 경쟁을 해야 하기 때문에, 커널 동기화 오브젝트에 의해서 보호되어야 한다. 그런 커널 수준 동기화 오브젝트 때문에 사용자 수준 스케줄러로 커널의 도 움이 없이 완전하게 사용자 수준에서 우선순위 계승 프로토콜을 구현하는 것은 불 가능하다., 이 문제를 해결하기 위해서 사용자 수준 쓰레드가 커널 수준 오브젝트에 의해서블록되었을때Arx 커널은사용자수준스케줄러에게쓰레드가 lock 을잡 고있다는정보를제공해준다특히커널은세개의인자., - 블록되어있는쓰레 드의 가상 쓰레드의id, 블록된 이유 (SYNC or IO), 가상 쓰레드의 식별자1)- 를가 지는BLOCK 업콜을 해준다 . 그림5BLOCK 는 이벤트 업콜에 의해서 커널 동기화 오브젝트에 우선순위 계승 프 로토콜이 어떻게 적용될 수 있는지를 보여준다.

그림5: BPI 를 위한 BLOCK 이벤트 통지 : T2 쓰레드가 시스템 콜을 하면서 커널 동기화 오브젝트를lock 하고 , 우선순위가 높은 T1 에 의해서 T2 가 선점되는 상황이다 .

1)다른 프로세스가 오브젝트의lock 을 잡고 있으면 , 이 값은 -1 이다 .

-142- 표2: 쓰레드 관리를 위한 시스템 콜

다. 멀티미디어 스트리밍 지원

I-PCTV는 액세스 네트웍으로부터 MPEG 동화상 등의 멀티미디어 데이터을 실시 간으로 재생해야 한다. 이러한 기능을 지원하기 위해서는 운영체계 내부에서 야기 되는 두 번 이상의 데이터 복사와 커널 진입의 오버헤드를 제거하고 데이터 소스에 서 바로 디스플레이로 전송되는 스트리밍 기법에 대한 연구를 하였다. 스트리밍 모 듈은I-PCTV 에서 사용될 가능성이 있는 윈도우 및 여러 상용 RTOS 에 쉽게 이식 가능한Plug-in 모듈로 구성하였다 . 구체적으로 이를 뭐하여 사용자 수준 I/O 를 연구하여 구현하였다., 주변 장치를 사용하는 내장 실시간 시스템에서 프로그래머는 사용자 수준I/O 로 다음과 같은 이익을 얻을 수 있다 . :

•성능사용자수준장치구동기는장치레지스터에직접접근할수있기때문에: I/O동안 사용자 프로세스와 커널 사이의 복사 작업을 피할 수 있다 . •탄력성:, 새로운 장치를 추가했을 때 프로그래머의 장치 구동기는 응용 프로그램 코드의 일부이기 때문에 커널을 다시 만들어야 할 필요가 없다. •효율성: 응용 프로그램의 목적에 맞춘 간단하고 효율적인 장치 구동기를 작성할 수 있다. •이석성:. 사용자 수준 작치 구동기는 서로 다른 운영체제에 쉽게 이식된다

UIO를 허가하려면 , 커널이 사용자 프로세스가 I/O 장치에 직접 접근할 수 있는 통 로를 열어주어야만 한다.,I/O 게다가 장치의 인터럽트를 처리할 사용자 인터럽트 핸들러를 디스패치할 수 있어야만 한다. 사용자 수준 인터럽트 디스패치를 지원하 기 위해,SGI 의 Irix 는 커널의 특정 문맥에서 사용자 인터럽트 처리코드를 직접 실 행한다. 이 스킴은 커널 인터럽트 처리와 비교해 짧은 인터럽트 지연 시간을 갖고 있지만,., 두 가지 결점을 지니고 있다 첫째 인터럽트 핸들러의 작성에 제약이 따른 다., 예를 들어 커널이 디스패치한 사용자 인터럽트 핸들러에서 시스템 콜과 부동소 수점연산을할수없다둘째커널이인터럽트를서비스하기때문에낮은우선순., 위인터럽트핸들러가높은우선순위쓰레드의실행을간섭하는우선순위역전현 상이 발생한다.

-143- 그림6: SIGNAL 업콜을 동반한 외부 인터럽트의 처리

이 문제를 제거하기 위해, 업콜 메카니즘을 이용하여 새롭게 고안된 시그널 메카니 즘은 프로그래머가 외부 인터럽트를 시그널로 매핑할 수 있도록 허용했다. 그리고 각 인터럽트는 사용자 수준의 전당 핸들러 쓰레드가 처리하게 했다. 이러한 목적을 위해 사용하기에는 전통적 시그널 메카니즘은 두 가지 중대한 문제를 안고 있기 때 문에 사용할 수 없었다. 첫째 , 시그널을 수신하는 프로세스가 non-interruptible 모 드에서 블록된 경우,., 시그널 전송이 무한정 연기될 수 있다 둘째 시그널 전달과 처리 시에, 여러 번의 보호 경계막 횡단과 문맥 교환으로 인한 오버헤드가 발생한 다. 개발 커널의 시그널 메카니즘은 시그널 큐잉(queueing) 과 확실하고 결정적인 시그 널 통지 방법을 포함한 실시간 시그널 확장을 명세한POSIX 1003.1 규약을 따른 다. 이는 인자로서 siginfo 구조체를 운반하는 SIGNAL 업콜에 기반 한다 . 이 시그 널 스킴은 특히 효율적인 인터럽트 전달을 위해 최적화 되었다. 하드웨어 인터럽트 에 매핑된 시그널의siginfo 구조체 내의 sigval 값은 같은 종류의 현재 대기중인 인터럽트 개수를 나타낸다., 따라서 인터럽트가 발생하고 이벤트 큐에 같은 인터럽 트 종류의SIGNAL 이벤트가 존재하면 , 커널은 단지 이벤트의 sigval 필드를 증가시 킨다.SIGNAL., 이는 여분의 업콜을 절약한다 또한 전통적인 시그널과 달리 , 사용 자 수준 스케줄러는 안전하게 사용자 공간에서 시그널 마스크(signal mask) 를 관리 한다;6 그러므로 그림 에서 묘사된 바와 같이 시그널 마스크를 복원하기 위해서 커 널 모드로 되돌아갈 필요가 없다. 표3 은 장치의 접근 권한을 획득하고 전용 핸들러 쓰레드를 등록하기 위한 함수들 의 원형을 보여준다.

-144- 표3: 장치에 대한 접근과 사용자 수준 인터럽트를 제어하는 API 들

• uio_request(ioa_start, loa_end. [type] ):이 함수는 ioa_start 에서 io_end 까지의 I/O주소에 접근할 수 있는 권한을 사용자 프로세스에게 준다 . 메모리가 매핑된 장 치(memory-mapped device) 에 해당하는 주소라면 , 이들은 페이지 정렬 (page aligned)되어야 한다 . 마이크로 프로세서가 I/O 장치에 대한 I/O 매핑과 메모리 매 핑된 주소를 모두 지원한다면,(type)IOMAP 주소의 형식 인자 을 또는 MEMORYMAP으로 명시해야한다 . 커널은 사용자 프로세스에게 허가한 주소 쌍을 리스트로 관리한다., 이 함수가 실행되면 리스트를 이용해서 사용자 수준 I/O 의 충 돌 여부를 점검한다., 충돌이 없으면 허가한 주소를 나타내는 정수 핸들을 리턴한 다.,0.Arx 아니면 을 리턴한다 커널은 마이크로 프로세서의 메모리 변호 메카니즘 으로I/O 주소를 보호한다 . 만약 한 페이지가 몇 가지 다른 장치의 메모리 주소를 가지고 있다면,. 다른 프로세스가 소유한 장치에 접근할 수 있다 따라서 uio_request는 메모리 매핑된 장치의 페이지가 정렬될 것을 요구한다 .

-145- • uio_release(handle):이 함수는 handle 이 나타내는 장치 주소에 대한 접근 권한 을 양도한다. • uio_int_request(irq, handier, type, flag): 이 함수는 사용자 인터럽트 핸들러를 등록한다. type 인자는 KERNEL_DISPATCH 또는 USER DISPATCH 이다 . USER_DISPATCH를 선택하면 , SIGRTMIN 과 SIGRTMAX 사이에서 사용되고 있지 않 은 시그널 번호를 인터럽트(irq) 에 할당한다 . 호출한 프로세스가 다중쓰레드 응용 프로그램이면,.flag0, 이 함수는 핸들러 쓰레드를 생성한다 가 면 인터럽트를 불가 능하게 만들고 리턴한다.,irq, 함수가 성공적이면 번호 시그널 번호와 쓰레드 식별 자를 담은irq_jnfo 구조체의 포인터를 리턴한다 . 아니면 , 에러를 나타내는 0 을 리 턴한다. 쓰레드 식별자는 핸들러 쓰레드의 우선순위와 같은 속성을 조절하는데 필 요하다. • uio_int_release(irq, flag): 이 함수는 사용자 인터럽트 핸들러를 등록부에서 삭제 한다.flag 가 1 이면 관련 핸들러 쓰레드를 중지한다 . • uio_jnt_enable(irq), uio_lnt_disable(irq):이 함수는 인터럽트를 가능 , 불가능하게 만든다., 등록된 핸들러가 시그널 기반 핸들러이면 실제 인터럽트를 무력화하지 않 고 단순히 관련 시그널을 마스크 또는 언마스크한다.

라기능지원.PlugandPlay

I-PCTV 는 각종 주변 기기의 인식을 쉽게 하고 장치간 상호 충돌 가능성을 없애 최종사용자가쉽게쓸수있는시스템을지향해야한다현재.PCI,PnP, IEEE1394등의 각종 산업 표준 버스에 대해 PnP 기능이 일반화되고 있고 Windows계열의 운영체계에서 적극 활용되고 있으나 , 일반적인 RTOS 에서는 그 적용을 찾기 어려운 상태이다.I-PCTV 본 과제에서는 에서 사용될 주변 장치의 자 동 인식과 저전럭을 위한PnP 및 저전력 장치 관리 모듈을 개발하였다 . 커널의 플러그인 지원 모듈은 프로세스가 아닌 다른 형태의 개체로서 존재하여야 한다. 이를 위해 ‘detachable object(DTO)’ 라는 개념을 개발하였다 . DTO 는 다음과 같이 정의할 수 있다. 1. 커널의 특정 서비스를 제공하는 함수들의 집합으로 커널 내 임의의 위치에서 수 행될 수 있다. 2.한객체 (object) 에서다른객체의서비스를맡기위해서는직접함수호출이아 닌, 일종의 메시지 전송 형태인 Inter-Object Communication(IOC) 을 통해야만 한 다. 3 다른 객체와 연관을 맺지 않은 객체는 내부의 함수를 커널에게 제공한다.

-146- 위의 정의에서2 번은 객체들간에 상호 작용을 하기 위해서는 반드시 객체별로 독자 적으로수행가능한쓰레드를갖고있음을의미한다또한번에서와같이상호작.3 용이 없는 독립적인 객체의 경우에는 쓰레드가 없을 수도 있다.3 번의 예로서 스케 줄러와 같은 서비스를 생각할 수 있다. 새로운 스케줄 정책을 제공하는 객체는 다 음에 수행할 쓰레드를 선택하는 일종의 함수인 것이다. 이와 같은 방식을 사용하여 하나의의 객체는 독자적으로 동작할 수 있으며, 커널의 각 부분들을 최대한 분리시 켜 조립성을 얻을 수 있다.

(1) 플러그인 모듈 메커니즘

객체의 구조 DTO는 헤더 부분과 취치 독립적인 코드 / 데이터의 두 부분으로 구성되어 있다 . 헤더에는 객체의 식별자(identifier), 코드 및 데이터의 크기 , 사용하는 인터페이스의 버전 등의 정보가 들어있고,DTO 의 1 번 정의에 의해 커널 내 임의의 위치에 놓여 질 수 있도록, 객체의 코드 및 데이터는 공유 라이브러리와 마찬가지로 위치 독립 적으로 만들어져야 한다. 객체의 이미지 생성 위와 같은 구조를 갖는 객체를 생성하기 위해서는 별도의 프로그램이 필요하게 된 다. 객체는 하나의 파일에 의해 구현되어야 하며 커널이 이해할 수 있는 목적 파일 형식(object file format) 으로 컴파일되어야 한다 . 이와 같은 형식의 대표적인 예로 서ELF 를 들 수 있다 . 컴파일러를 통해 만들어진 위치 독립적인 목적 파일은 적당 한 변환 도구를 이용하여 객체 헤더를 만들고, 목적 파일에서 객체의 코드와 데이 터를 분리하여 커널이 이해할 수 있는 객체 이미지를 만들어 낸다. 객체의 적재(loading) DOT는 커널 주소공간 내 임의의 비어있는 위치에 적재된다 . 이때 커널은 내부적으 로 적재된 객체의 리스트와 객체가 차지하고 있는 공간에 대한 정보를 유지하고 있 다./ 커널은 객체의 헤더를 이용하여 위치 독립적인 코드 데이터를 적절한 커널 메 모리 영역으로 복사한 후,(relocation) 재배치 작업을 수행한다 . 이 작업을 수행한 후 커널은 객체의 진입 함수(entry function) 를 실행시킨다 . 이 함수의 위치는 객체 의 헤더에서 얻을 수 있는 정보이며, 주로 객체의 초기화와 관련된 작업을 수행한 다.. 일반적으로 다음과 같은 작업을 수행하게 된다 • 내부적으로 사용할 커널의 함수 위치를 얻는다. 커널은 버전에 따라 메모리의 레 이아웃(layout) 이 바뀔 수 있기 때문에 DTO 는 커널의 특정 함수가 고정된 위치에 존재한다는 가정을 할 수 없다., 따라서 그와 같은 함수들의 위치를 초기화 시 모두 얻어 두어야 한다. 이러한 커널 제공 함수들의 위치는 진입 함수에게 인자로서 넘 겨진다.

-147- • 커널에 단순히plug-in 되는 객체의 경우 자신이 제공하는 서비스들을 커널에 등 록한다. 예를 들어 , 새로운 스케줄링 정책을 지원하는 plug-in 객체는 커널의 스케 줄러를 변경하는 인터페이스를 통하여 자신의 함수들을 커널의 스케줄러로 등록한 다. • 외부에 자신이 제공하는 인터페이스 함수를 제공하지 않고IOC 를 통해 서비스를 제공하는객체의경우에는서비스를할수있는쓰레드를생성하여,IOC 를기다리 도록 한다. 객체의 삭제 적재되었던 객체가 더 이상 필요가 없어질 경우, 커널은 객체를 커널 주소공간에서 제거한다.MMU 가 지원되는 프로세서에서는 객체가 차지하고 있던 물리 페이지들을 반환하는 작업을 한 후,. 커널이 유지하고 있는 객체 리스트에서 객체를 제거한다 만약MMU 가 지원되지 않는다면 두 번째 작업만 수행하면 된다 . 반환된 메모리는 새로운 객체의 적재를 위해 사용될 수 있다. 객체를 위한 메모리 관리 지금까지는 별도의 메모리 관리자를 통해 객체의 적재와 삭제가 이루어진다고 생각 했다.. 이와는 달리 커널의 동적 메모리 관리 함수들을 이용할 수도 있다 예를 들어 커널의malloc()/ free() 인터페이스를 사용하여 객체의 코드와 이미지가 놓일 메모 리를 할당 받을 수도 있다. 제안된 모델을 구현하기 위해서는 프로세서가 수행 모 드와MMU 를 지원하면 가장 좋다 . 이 두 가지 기능을 통해 커널의 보호와 효율적인 메모리 사용이 가능하기 때문이다.., 그러나 필요조건은 아니다 즉 어떠한 프로세서 에서도 이 기법을 통해 조립성과 확장성을 극대화할 수 있을 것으로 기대한다.

(2) 플러그인 모듈의 구현

커널의 서비스 함수는DTO 가 메모리에 적재된 후 처음으로 실행되는 진입 함수 (entry function)에의해 DTO 내에알려지게된다이를구현하는방법에는다음의 . 세 가지가 있다. • OLE 형태의 구조화된 방법 C++의 클래스 개념과 비슷하게 커널의 특정 객체가 제공하는 멤버 함수의 리스트 를 담고 있는 구조체의 개체를 생성하여DTO 내에서 구조체의 함수를 호출하는 방 식이다., 예를 들어 쓰레드 관리 함수들을 모두 담은 구조체를 커널로부터 받아내어 그 함수들을 직접 호출한다.

-148- 이방법은정형화된인터페이스를만들어서비스를할수있다는장점이있는반 면, 모든 서비스 구성요소가 커널에 존재해야 하기 때문에 불필요한 것들 조차 커 널에 항상 자리를 차지하고 있어야만 한다는 단점이 있다. 따라서 기본적으로 커널 에서 제공해야 하는 함수들을 정의하여DTO 가 사용할 수 있도록 하는 데는 의미가 있을 수 있다.HALDTO 하드웨어를 접근하기 위해 사용하는 이나 서비스를 위한 기본 함수들을 정의하여 제공하는 것을 예로 들 수 있다. • 커널의 함수를 통한 특정 심볼의 해석 리눅스의 동적 모듈에서 사용하는 방식으로(get_kerrn_syms 함수 ) DTO 에서 필요 한 커널의 서비스 함수의 심볼 이름을 주면 해당되는 심볼의 주소를 얻을 수 있는 방식이다. 이 방법은 Unix 의 dl_sym 이나 윈도우의 GetProcAddress 를 통해서 응용 프로그램이 직접 심볼의 위치를 얻어내는 방법과 동일하다. 이 경우 명시적으로 심볼을 해석하기 때문에 해석할 수 없는 심볼 에러(unresolved symbol error)가 발생할 확률이 낮은 반면 , DTO 작성자가 사용할 모든 심볼에 대 해 미리 심볼 해석 함수를 이용해 함수 포인터를 할당 받아야 하는 단점이 있다. • 공유 라이브러리의 로더에 의한 자동 심볼 해석 커널에 존재하는DTO 로더가 공유 라이브러리를 적재하여 필요한 심볼을 필요할 때마다 찾아서 해석하는 방식으로,DTO 커널의 모든 심볼에 관한 정보를 커널 로 더가 알고 있어야만 한다. 따라서 일반 공유 라이브러리 로디를 활용할 경우 구현이 쉬워질 수 있는 반면, 커 널의 심볼에 관한 정보를 컴파일 시 알아야만 커널에 적재되었을 때 해석할 수 없 는 심볼이 발생하지 않는다.

본 연구에서는 첫째와 둘째 방법을 함께 사용하여 다음과 같이 적용하였다.

• 구조체를 통한 메소드 객체의 제공:HAL 과 커널이 기본적으로 제공해야 하는 기 본 서비스 함수의 객체, 그리고 파일을 시스템이나 디바이스 드라이버 등 다른 객 체나 서비스들이 빈번히 사용하는 특성DTO 가 제공하는 서비스 함수들의 객체에 적용된다. • 커널의 함수를 통한 심볼의 해석: 위의 경우 이외의 서비스들에 대해서 커널의 심볼을 적재할 때 사용한다.

구조체를 통한 메소드 객체의 제공 이 경우DOT 에 관련한 정보는 커널이 항상 관리를 한다 . 비록 HAL 이나 커널의 기 본 서비스 객체의 경우는DTO 와 무관하지만 더미 (dummy) DTO 를 이용함으로써 일관된 구조를 제공할 수 있다. DTO 의 이름 , 참조계수 (reference counter) 와 같이 DTO를 기술하기 위해 필요한 객체 데이터가 존재하며 , 만일 DTO 가 제공하는 메소 드 객체가 존재하면DTO 객체에 존재하게 된다 .

-149- 하나의DTO 는 각각 유일한 메소드 객체만을 제공해야 하는데 , 이것은 개념적인 것 보다 구현상의 문제 때문이다.DTO 즉 내에 여러 개의 메소드 객체가 존재할 경우 이들을 외부에서 구별하기가 모호한 문제가 발생한다.DOT 이때 의 메소드 객체를 사용하는 것은 아래의 그림과 같이 두 가지 방법이 있을 수 있다. 방법1DTO 은 메소도 객체를 복사하여 가 자신만의 메소드 인스턴스를 만들어 사용 하는 것이고,2 방법 는 메소드를 가리키는 포인터를 두어 , 이를 통해 함수를 호출 하는 방식이다., 첫번째 방식이 안전성 측면에서 우수한 반면 두번째 방법은 모듈이 사용되고 있는 동안에도DTO 를 변경하기 용이하다는 장점이 있다 . 하지만 포인터 를 이용할 경우 서비스를 제공하는 객체를 참조하는 다른 모든DTO 가 하나의 메소 드를 공유하기 때문에,DTO 한 에서의 잘못된 연산으로 인한 서비스 제공 메소드 객체의 변경이 다른DTO 에게 영향을 끼치게 된다 . 본 연구에서는 확장성을 최대한 으로 높이기 위해 방법1. 을 사용하도록 한다

또한 어떠한 방법을 사용하더라도 메모리 관리를 위해,DTO 객체를 사용하고 있는 의 개수를 알아야 한다.DTO 즉 어떤 객체가 더 이상 사용되지 않을 경우 자동적 으로 메모리를 회수(garbage collection) 하거나 새로운 버전으로 업그레이드할 수 있도록 한다.DTO 이를 위해 각 객체는 메소드 객체의 인스턴스 개수나 (1 방법 의 경우), 자신의 메소드 객체를 가리키고 있는 메소드 포인터의 개수 ( 방법 2 의 경우 ) 를 나타내는 참조 계수를 갖고 있다. 서비스 인터페이스 DTO가 객체 메소드를 사용하기 위해서 필요한 인터페이스는 첫째 , 다른 DTO 나 커 널 서비스를 가져오기 위한 함수,,DTO 둘째 가 자신이 제공하는 서비스를 등록하 기 의한 함수,, 셋째 이들을 쉽게 관리하기 위해 제공되는 상위 레벨의 함수들로 볼 수 있다.

-150- • MO := DTOCreateInstance(DTO_ID) 원하는 객체의DTO 식별자 (identifier) 를 입력으로 넘겨주면 , 해당 DOT 의 메소드 객체 인스턴스를 새로이 할당하여 이에 대한 포인터를 넘겨준다. 이때 내부적으로 인스턴스를 위해 새로이 메모리 공간을 할당한다. • DTODeleteInstance(MO) DTOCreateInstance()함수를 통해 넘겨받은 메소드 객체를 반환한다 .

DTOCreatelnstance()함수가반환하는것은오른쪽그림과같이 DTO 관리테이블 의DTO 인터페이스에 대한 포인터의 주소이다 . 이 DTO 인터페이스 포인터가 실제 메소드 테이블을 가리킨다.,2 즉 단계의 간접적인 포인터 접근을 통해 실제 함수에 접근하게 된다.,DTO 따라서 관리 테이블의 정보만을 변경함으로써 DTO 를 새로운 버전으로 쉽게 업그레이드할 수 있다.

• DTOExportService(type, method_table | port) DTO가 자신이 제공하는 서비스의 종류를 지정할 때 사용한다 . 서비스의 타입이 메 소드 함수 테이블을 제공해야 할 경우 두번째 인자로 함수 테이블을, 그렇지 않고 IOC를 통해 서비스를 제공하는 경우에는 포트 번호를 두번째 인자로 넘겨준다. 포 트는IOC 를 참조하기 바란다 .

• handle := DTOLoad(path) 경로(path) 에 해당하는 DTO 파일을 커널에 적재한다 . 성공적으로 DTO 를 적재하였 을경우해당DOT 에대한핸들을반환하게된다이핸들의실제값은커널에서 . 관리하는DTO 의 자료구조에 대한 포인터나 DTO 파일에 있는 DTO 의 식별자를 이 용할 수 있다.DOT 만일 동일한 식별자를 지닌 가 이미 커널 내에 존재할 경우 커 널은 새로운DTO 를 적재하는 것을 거부하고 에러를 반환한다 .

-151- • DTOUnload(handle) DTOLoad()함수에 의해 적재된 DOT 를 커널에서 제거하며 , DTOLoad() 함수에 의 해 반환된 핸들을 인자로서 넘겨준다.DOT 이 함수를 호출하였다고 해서 반드시 객체가 커널에서 삭제되는 것은 아니다.0 앞에서 설명했듯이 참조 계수가 이 되어 더 이상 객체를 참조하는DTO 가 없을 경우에 비로소 커널에서 삭제하게 된다 . 따 라서 참조 계수가0 이 아닌 경우 삭제할 수 없음을 알려주는 에러를 반환하고 삭제 명령을 무시하게 된다. • handle := OTOUpgrade(path, option) 경로(path) 에 해당하는 DTO 를 새로운 버전으로 업그레이드한다 . 이것은 커널에 존 재하는DTO 를 현재의 버전보다 높은 버전으로 대체할 경우 사용한다 . 커널의 다른 부분에서 현재DTO 를 참조하지 않을 경우 단순히 새로운 버전으로 대체함으로써 쉽게 업그레이드할 수 있다., 그러나 참조 계수가 0 이 아닌 경우 ,DTO 를 변경하는 데 좀더 신중을 기해야 한다.DTO 업그레이드하려고 하는 의 서비스 함수를 다른 개체가 현재 사용하지 않고 있다는 보장을 할 수 없기 때문이다. 따라서 가능한 선 택사항으로서 가장 간단한 방법은 단순히 에러를 반환하고 업그레이드를 거부하는 것이다.DTO 다른 방법으로 커널의 모든 서비스를 중지하고 를 새로운 버전으로 업 그레이드할 수 있다.DTO 앞에서 설명한 바와 같이 커널에서 의 서비스를 이용하기 위해서는 메소드 테이블의 포인터를 통해 간접적으로 접근하기 때문에 참조 계수가 0이 아니더라도 DTO 를 실행 중에서 바꿀 수 있다 . 하지만 여전히 DTO 의 서비스 함수가 현재 수행중이 아니라는 것을 확신한 상태에서 변경해야만 한다는 점에는 변함이 없다.. 따라서 커널 서비스를 중단하는 시점에 대한 결정이 필요하다

위의세가지상위레벨인터페이스중두개는DTO 파일의경로가인자로넘겨진 다..DTO 이 경로를 기술하기 위한 표기법이 정의되어야 한다 파일이 존재할 수 있는매체는파일시스템,ROM 과같은저장매체네트워크등일수있다따라서 , . 이와 같은 여러 매체에 대한 지원을 위해 경로 기술을 다음과 같이URL 기술과 비 슷하게 매체와 매체 내에서의 경로로 표기한다.

매체에 따라 아래의 표와 같은 세 가지 종류의 경로가 존재한다.

Source Path Complete DTO path 147.46.116.107/u0/seoym/my network://147.46.116.107/u0/seoy Network dto m/mydto File /u0/seoym/mydto file://u0/seoym/mydto system Memory 0x12456 memory://0x123456

-152- 마. 저전력 관리 연구

(1) 저전력관리기법

최근 내장형 시스템의 이동성이 중시되면서UI 장형 시스템이 전지에 의해서 구동되 는 부분이 커지게 되면서 시스템이 가능한 한 적은 전력으로 구동되도록 할 필요성 이 크게 증대되고 있다. 또한 이동성이 큰 시스템이 아니더라도 에너지 절약의 차 원에서 절전 기능에 대한 관심이 높아지고 있다. 이러한 절전 기능에 대한 요구로 많은 연구가 이루어져 왔고 그에 대한 결과로 다양한 저전력 관리 기법들이 등장하 였다.,CPU 우선 하드웨어 레벨에서 회로의 구성이나 소자의 구성 구조의 변경 등 으로 저전력 관리 방법들이 있다. 또한 소프트웨어 레벨에서도 컴파일러가 저전력 소모 코드를 생성하고, 운영체제와 같은 시스템 소프트웨어가 저전력을 관리할 수 있도록 하는 방법이 있다. 이 프로젝트에서 연구된 부분은 이중 운영체제에서 저전 력 시스템을 구현하는 방법에 관한 부분이다. 운영체제에서 저전력을 지원하는 방 법은 우선 대표적인 것으로 시스템이 사용 중이 아닐 경우 절전 모드로 전환하여 시스템의 유지에 필요한 최소한의 전력만을 사용하는 방법과 상황에 따라CPU 에 공급되는 전압과 수행 주파수를 조절하는 방법이 있다. 절전 모드 (sleep mode) 는 구현이 간단하고 확실한 절전 효과를 기대할 수 있어서 일반 시스템에서 많이 사용 되고 있다., 시스템이 일정 시간 이상 사용되지 않았거나 일정 시간 사용되지 않을 것이 확실할 경우,, 현재의 시스템의 정보를 저장한 후 시스템의 동작이 다시 필요 할 경우 다시 저장된 정보를 복구해서 다시 수행을 하는 방법이다. 이러한 방법은 실시간상이 보장이 필요한 시스템에서는 그대로 적용하기에는 문제가 있지만, 일반 시스템에서는 쉽게 적용할 수 있다. 절전 모드이외에 비교전 최근에 등장한 저전력 지원 방법은 전압 및 속도 조절(Voltage and Speed Scaling) 방업이 있다 . 이는 더적은계산능력으로도처리가가능한경우CPU 에공급되는전압과속도를낮추 어적은전력으로같은일을수행할수있는방법이다본연구에서는이방법에. 관한 연구를 주로 다루도록 한다.

(2)전압및속도조절 (Voltage and Speed Scaling) 기법

최근 마이크로프로세서에서는 입력 전압이나 입력 클럭 주파수를 조절하여 계산 속 도와 저전력 소모 둘 중에 하나에 비중을 두어 수행을 할 수 있도록 하는 기능을 제공하고 있다. 예를 들면 ARM 의 ARM7TDMI 프로세서의 경우 ARM7TDMI 를 33MHz의 주파수로 5V 입력전압과 3V 의 입력전압을 주고 동작을 시켰을 경우 수행 속도와 소비 전력에 따른 수행 명령의 수를 표로 나타내면 아래와 같다.

-153- 표에 따르면 저전압 모드로 동작할 경우 수행 속도는60% 수준으로 떨어지지만 같 은 전력을 사용했을 때 수행할 수 있는 명령의 수는200% 이상 향상되는 것을 알 수 있다. 즉 가능하다면 낮은 전압을 사용해 수행을 하는 것이 적은 전력을 소모함 를 알 수 있다. 이러한 현상이 생기는 이유는 다음과 같은 법칙으로 설명할 수 있 다. 아래의 식과 같이 전력의 소모는 전력의 공급 전압의 제곱에 비례함에 비해, 회 로의 지연시간은 공급 전압에 반비례한다.

여기서V,f 는 입력전압 는 회로의 평균 스위칭 주파수 ,V1는회로스위칭의임계전 압을 말한다. 이와 같이 공급 전압을 가능한 한 낮춤으로써 저전력 시스템의 구현 이 가능하다., 그러나 시스템에서 항상 저전력 동작이 중요할 경우도 있지만 빠른 응답시간이 요구되는 경우도 있을 수 있다.CPU 따라서 적절하게 에 공급되는 전압 을 조절하여 빠른 응답 시간을 가지면서도, 전력을 크게 사용하지 않는 시스템의 설계가 필요하다. 이를 위해 운영체제에서 현재 시스템에서 빠른 응답시간을 요구 하는 작업이 있을 경우 높은 전압을 공급하고, 그렇지 않은 작업만이 있을 경우에 는 낮은 전압을 공급하는 저전력 관리 시스템을 채용하였다.

-154- 바 주기적 실시간 쓰레드를 위한 쓰레드 인터페이스의 확장

구현된 쓰레드 패키지는POSIX 1003.1b 와 1003.1c 표준을 따른다 . 쓰레드 프로그 래밍 모델 앞 시스템API 는 Mach, NT, Solaris 등 운영체제마다 다양하게 발전해 왔다. Pthread 는 이러한 상이한 쓰레드 모델에서 오는 이식성 상의 난점을 해결하 고자POSIX 섹션 1003.1c 에서 정의한 쓰레드에 관한 표준 규약이다 . 이 표준은 선 점형 우선순위 스케줄링, 타이머 관리와 우선순위 계승과 같은 실시간 시스템에 관 련된 많은 특징들을 포함한다., 그러나 실시간 프로그램에서 주기 , 종료시한 , release time과 초기 위상 등의 시간 속성을 명시하는데 필요한 특징들은 부족하다. 또한,., 주기적 실시간 쓰레드의 정확한 행동 방식을 정의하지 않는다 이들 없이 Pthread라이브러리로 구현된 주기적 쓰레드들은 지터 (jitter) 를 경험하게 된다 . 게 다가,Pthread 는 주기적 쓰레드를 지원하지 않으므로 , 프로그래머는 임시변통 적인 방법으로 코드를 작성해야 한다. 이러한 문제를 다루기 위해서 시간적 속성을 제공 하는 인터페이스를 가지고Pthread 라이브러리를 확장 구현했다 . 이들 함수의 원형 을 표3. 에서 정리한다 본 과제의 실시간 운영체제는 이러한 문제점을 해결하기 위하여Pthread 를 확장하 여 실시간 응용 프로그램을 위한 확장된 쓰레드API 를 지원하도록 하였다 .

(1) Pthread API의기본개념및특징

먼저Pthread 의 확장 API 설계의 기초 배경으로서 Pthread API 의 기본 개념 및 특징들을 살펴본다. 다음은 기본적인 Pthread 함수들의 원형 (prototype) 이다 .

-155- • Pthread시작 함수 (start function) 의 원형 하나의 쓰레드는pthread_create() 함수를 호출함으로써 생성된다 . pthread_create()는 그 첫 인자로 쓰레드 시작 함수의 포인터를 입력받는다 . 쓰레드 시작 함수의 원형은void* 타입의 인자를 가지는 어떠한 함수도 될 수 있다 . • pthread_exit()과 pthread_join() 이렇게 생성된 쓰레드는 쓰레드 시작 함수의 수행을 마치거나pthread_exit() 을 호 출할 때 종료된다. 종료하는 쓰레드는 pthread_exit() 의 인자로 수행 결과에 대한 정보를 지정할 수 있다. 이 정보를 넘겨 받을 쓰레드는 pthread_join() 함수를 호출 한다. pthread_join() 은호출시첫번째인자의대상쓰레드가종료한상태가아니 면 그 쓰레드가 수행을 종료할 때까지 수행을 멈추고 기다린다. 만약 넘겨 받을 정 보가 없을 때는pthread_join() 의 두 번째 인자를 널 (null) 로 줌으로써 단순히 동기 화를 위하여 사용할 수도 있다. • Pthread속성 (attribute) POSIX쓰레드는 프로그래머가 지정하는 다양한 속성 (attribute) 를 지닐 수 있다 . 이러한 속성은 쓰레드 생성시에만 지정 가능하며, 일단 생성된 쓰레드에 대해서는 그 속성을 변경 할 수 없다. 마찬가지로 이미 생성된 쓰레드에 대하여 그 쓰레드를 생성할 때 사용한 속성 변수를 참조하여 값을 얻어내는 것은 의미가 없다. 속성(attribute) 템플릿을 쓰레드의 종류별로 사용함으로써 쓰레드들의 클래스나 생 성정책(policy) 개념을지원하는데사용할수도있다예를들면스택의크기가크 . 고 높은 우선순위를 갖는 쓰레드들과 그렇지 않은 쓰레드들의 클래스들의 구현은 간단히 이에 대한2 가지 속성을 만들어 놓고 pthread_create() 시 인자로 줌으로써 해결할 수 있다. • Detached state와 joinable state Pthread의속성중 detachstate 는 PTHREAD_CREATE_JOINABLE, PTHREAD_CREATE_DETACHED의 2 가지중하나의값들가질수있다기본값은 . PTHREAD_CREATE_JOINABLE이다 . PTHREAD_CREATE_JOINABLE 속성은 쓰레드가 종료한 뒤에도 그 쓰레드의 정보 를 유지함으로써 다른 쓰레드가pthread_join() 함수를 그 쓰레드에 대하여 호출할 수 있도록 하여준다. 즉 pthread_join() 함수는 PTHREAD_CREATE_JOINABLE 속성 을가진쓰레드에대하여만호출될수있다. PTHREAD_CREATE_DETACHED 속성 을 가진 쓰레드는 그 쓰레드와 관련된 저장영역을 다른 쓰레드가 재활용할 수 있게 해준다.

-156- PTHREAD_CREATE_JOINABLE속성을 가진 쓰레드는 최종적으로 pthread_join() 이 나pthread_detach() 를 호출해 주어 그 쓰레드의 저장 영역을 해제 (free) 시켜주어 야 한다. 다른 속성 함수와 마찬가지로 pthread_attr_setdetachstate() 와 pthread_attr_getdetachstate()는 pthread_create() 의 인자로서 속성 값 (attr) 을 넘겨 주기 전에만 유효하다. 이미 생성된 쓰레드는 pthread_detach() 함수의 호출을 통 해서PTHREAD_CREATE_DETACHED 의 속성으로만 바꾸어 줄 수 있다 . • 뮤택스 변수와 컨디션 변수의 범위 뮤택스(mutex) 변수와 컨디션 변수 (condition variable) 는 쓰레드를 간에 공유되어 야 하므로 전역 변수이어야 한다. PTHREAD_MUTEX_INITIALIZER 와 PTHREAD_COND_INITIALIZER로 초기화시키면서 정의할 수도 있다 .

(2) POSIX_THREAD와 RT_THREAD

POSIX쓰레드는 확장성과 이식성을 최대한 고려하여 설계되었다 . Pthread 속성은 이의 가장 대표적인 예로,PthreadAPI 벤더들이 자체 를 변경하지 않고 새로운 속 성을 추가함으로써Pthread 자체에 명시되어 있지 않은 다른 기능을 지원할 수 있 도록 설계되었다. 일례로 이러한 Pthread 속성 중 sched_param 구조체는 정수 (int) 타입의sched_priority 를 기본적으로 포함하는 한 , 벤더들이 원하는 임의의 필드를 추가할 수 있도록 허용하고 있다. 즉 구현별로 확장시키고자 하는 스케줄링 파라미 터들이 있으면 이sched_param 구조체에 멤버들을 추가시켜서 사용하도록 하고 있다. 그러나,PhreadAPI 이러한 확장 속성을 무분별하게 사용하게 되면 자체를 복잡하 게 만들어 그 결과 원하지 않는 버그를 만들어 내게 되는 문제가 있다. 아래는 Pthread에서 쓰레드의 우선순위를 설정하기 위하여 호출해야 하는 일련의 API 이다 .

위의 그림에서 보듯이 쓰레드 우선순위를 변경하기 위해서는 총5API 번의 호출이 필요하다. 먼저 param 값이 attr 의 속성으로 세팅되기 전에 먼저 기본 param 값을 얻어내어서(4 번째 줄 ) 필요한 멤버 값만 변화시키고 (5 번째 줄 ), pararn 값을 새로 세팅한다(6 번째 줄 ).

-157- 따라서 지원하는 속성의 갯수가 늘어나면API 호출이 복잡해지고 상호 충돌하는 속 성의 효과에 대해 판단하기 어려워지는 경우가 쉽게 생길 수 있다.Arx 의 실시간 응용 프로그래밍을 위한Pthread 확장 API 에서는 위의 sched_param 을 확장한 접 근방법을 시용하지 않고 클래스의 개념을 사용한 확장 방법을 사용한다. Arx쓰레드 라이브러리는 POSIX_THREAD, RL_THREAD 의 2 가지 클래스 (class) 에 대한API 를 지원한다 . • POSIX_THREAD POSIX 1003.1c의 규약에 따른 쓰레드이다 . pthread_create()를통해생성할수있다 .

• RT_THREAD POSIX_THREAD를 확장한 쓰레드로서 실시간 태스크 모델을 위한 API 를 사용할 수 있다. thread_create()를통해생성할수있다 .

RT_THREAD는 POSIX_THREAD 의 속성을 계승한 하위 객체로서 생각할 수 있다 . 즉, RT_THREAD 는 POSIX_THREAD 가 사용할 수 있는 모든 함수를 사용할 수 있지 만, POSIX_THREAD 는 RT_THREAD 를위해제공되는함수를사용할수없으며만 , 약 이를 어기면 에러 메시지를 출력하면서EPERM 을 리턴한다 .

(3)실시간 쓰레드 확장 API

POSIX 1003.1c는 선점 우선순위 스케줄링 , 타이머 관리와 우선순위 계승과 같은 실시간 시스템에 관련된 많은 기능에 대한 지원을 포함한다., 그러나 실시간 프로그 램에서 요구하는 주기,, 종료시한 릴리스 타임과 초기 위상 등의 시간 속성을 명시 하는데 필요한 기능의 규약은 결여되어 있다., 또한 주기적 실시간 쓰레드의 정확한 행동방식을정의하지않고있다이에따라본과제에서시간속성을제공하는인. 터페이스를 가지고Pthread 라이브러리를 확장 구현했다 . 이들 함수의 원형이 다음 과 같다.

-158- 1) 실시간 주기적 쓰레드 모델 실시간주기쓰레드의시간행위는네개의파라미터ti (i,ri,di,pi)φ 로기술된다 . 여기서φi,ri,di,pi. 는 초기 위상 는 릴리스 타임 는 종료시한이고 는 주기이다 주기 적 쓰레드의 초기 위상은 장벽(barrier) 이라는 개념적인 동기화 객체로 명시된다 . 릴 리스타임은쓰레드가매주기로부터수행가능(ready) 상태가될때까지의시간이 다.. 이러한 실시간 주기적 쓰레드 모델을 나타낸 그림이 다음과 같다

-159- thread_sysbarrier_wait()을 호출한 주기적 쓰레드들은 다른 쓰레드 ( 보통 메인 쓰레 드) 가 thread_sysbarrier_release() 를 부를 때까지 하나의 장벽인 시스템 장벽에서 기다린다., 이 방식에 의해 관련된 모든 주기적 쓰레드들은 동기화된 수행을 시작할 수 있다. 2) RT_THREAD 쓰레드의 생성과 기본 동작 RT_THREAD클래스의 쓰레드는 thread_create() 함수를 통하여서만 생성될 수 있 다.attrPOSIXTHREAD 이 함수의 인자인 은 클래스의 속성에 해당하는 것으로서 pthread_attr_xxx()및 pthread_attr_setschedparam() 등의 함수로 원하는 속성을 설 정할 수 있다. 이 인자에 널 (NULL) 값을 주면 POSIX 의 기본 속성으로 생성된다 . 기본 우선순위는PTHREAD_DEFAULT_PRIORITY 로서 이 값은 PTHREAD_MIN_PRIORITY에 1 이 더해진 2 의 값이다 . POSIX 쓰레드의 우선순위는 숫자 상으로 더 큰 값이 더 높은 우선순위를 나타내며PTHREAD_MIN_PRIORITY 부 터PTHREAD_MAX_PRIORITY 의 값을 가질 수 있다 . Arx 에서는 이들이 각각 1 과 254로 정해져 있으며 메인 쓰레드는 기본적으로 PTHREAD_MIN_PRIORITY(1) 를 가 진다.255 즉 레벨의 우선순위가 존재한다 .Arx 쓰레드 라이브러리 전체에서 사용 되는 우선순위는0 부터 255 까지의 256 레벨이며 우선순위 0 은 아이들 (idle) 쓰레드 에,255 는 시그널 처리기 쓰레드 등에 예약되어 있다 . 여기에서 메인 쓰레드의 기본 우선순위를1, 로 생성되는 쓰레드들의 기본 우선순위 를2. 로 정한 이유는 다음과 같다 시스템 장벽을 사용하여 쓰레드들의 수행을 동기 화시킬 경우, thread_sysbarrier_release() 는 각 쓰레드들의 thread_sysbarrier_wait() 가 모두 호출된 뒤에 최종적으로 수행되어야 한다. 이를 위해서는 thread_sysbarrier_release()를 호출하는 쓰레드의 우선순위가 thread_sysbarrier_wait()를 호출하는 쓰레드들의 우선순위보다 낮아야 한다 . 일반적으로main() 함수에서 쓰레드들을 생성한 후 최종적으로 thread_sysbarrier_release()를 호출한다 . 따라서 가본 우선순위로서 메인 쓰레드는 가장 낮은 우선순위(1) 로 , 생성되는 쓰레드들은 이보다 높은 우선순위 (2) 로 정해져 있다. 따라서 기본 속성 (NULL) 으로 쓰레드를 실행하게 되면 (FIFO 정책 ), main() 함 수에서 쓰레드를 생성할 경우, thread_create() ( 또는 pthread_create()) 에 의하여 첫 번째로 생성된 쓰레드가 바로 수행하게 되며 그 쓰레드가 스스로CPU 를 내어놓 기 전까지main() 함수 ( 메인 쓰레드 ) 로 수행이 돌아오지 않는다 . thrad_create()함수의 속성 (attribute) 인자에 이어서 있는 인자들은 각각 실시간 주 기 쓰레드의 주기,, 종료시한 속성 릴리스 타임을 설정할 수 있도록 한다 .period 인자를0. 으로 하면 무한 주기를 갖는 비주기 쓰레드가 된다

-160- 3) 종료시한 속성과 종료시한 초과 처리 쓰레드 시스템에 순간적인 과부하가 지워지면, 주기적 쓰레드는 종료시한까지 수행을 끝마 치지 못하는 경우가 발생한다. 종료 시간 초과 처리기는 이러한 순간적인 시간 결 점을 대비하기 위해 제공되는 기능이다. 프로그래머는 종료시한 초과 처리기에서 종료시한이나 주기 등을 재설정하거나 쓰레드의 수행을 종료시키는 작업 등을 할 수 있다. 종료 시간 치리를 하기 위해서는Arx 의 RT_THREAD 를 생성하는 thread_create() 에 서dparam 값을 적절하게 세팅하고 쓰레드를 생성시켜야 한다 . 종료시한 초과 처리 기는 쓰레드 생성시 별도의 다른 쓰레드로 생성되어 보류(suspend) 상태로 존재하 다가 종료시한 초과 사건의 발생시 활성화되어 수행된다. deadline_param 구조체 는 다음과 같은 멤버들을 가지고 있다.

deadline 종료시한

dattr 종료시한 처리 쓰레드의 Pthread attribute

dhandler 종료 시한 처리 쓰레드가 될 함수의 포인터

args 종료 시한 처리 쓰레드 생성시 넘어갈 인자 dhandler가 널 (NULL) 이거나 dparam 자체가 널 (NULL) 이면 종료시한 초과 (deadline miss)에 대한 처리를 하지 않는다 . 그렇지 않은 경우 deadline 이 0 으로 설정되어 있으면thread_create() 함수의 인자인 period 와 같은 값으로 deadline 이 설정된다 . 종료시한 초과 처리기(deadline miss handler) 는 dparam 의 dattr 의 속성 (attribute) 과args 를 가진 별도의 쓰레드로 생성된다 . 종료시한 초과 처리기 함수는 다음과 같은 원형으로 작성되어야 한다.

첫 번째 인자인args 는 dparam 의 필드 값에 해당한다 . 두 번째 인자인 owner 는 종료시한 초과 처리기 내에서 종료시한 초과가 난 쓰레드의 아이디(id) 를 얻는데 사 용될 수 있다.(,) 이를 통해 해당 쓰레드의 시간적 속성 주기 종료시한 등 을 재설정 하거나,(cancel) 쓰레드를 취소 시키는 등의 작업을 할 수 있다 . 이렇게 등록된 종료 시한 초과 처리기는owner 쓰레드가 생성되면서 생성되며 , 종료시한 초과가 발생 하면 수행 가능(ready) 상태가 된다 .

-161- 4) thread_wait_next_period() thread_wait_next_period()는 다음 주기의 쓰레드 도착 시간을 계산할 수 있도록 사 용자 수준 스케줄러에게 현재 인스턴스가 완료했음을 알려준다. thread_wait_next_period()는 다음 주기까지 수행을 멈추며 만약 이 함수를 호출하 기전에쓴시간이한주기이상을넘어가면그만큼해당하는다음주기에수행 가능(ready) 상태가된다이때놓친주기의횟수를리턴값으로넘긴다 . . 이전 주기의 수행 정보에 대한 값을period_info 구조체 타입의 time_info 를 통해서 받을 수 있다. 정보를 받고 싶지 않으면 인자를 널 (NULL) 로 한다 . period_info 구조 체는 다음과 같은4 가지 멤버 (member) 를 가지고 있다 .

이전 주기에서 스케줄되어 수행을 시작하기를 희망하는 request_point 시스템 타이머시각으로서 틱 단위의 값이다. 이전 주기에서 실제 스케줄러에게 스케줄되어 수행을 시작한 sched_delay 시각과 스케줄 희망 시각과의 차이 시간이다. 즉 스케줄링에 의해 발생하는 지연 시간이다. 이젠 주기의request_point 로부터 response_time thread_wait_next_period()에 의하여 CPU 를 내어놓음으로써 한 주기를 마칠 때까지의 시간이다.

miss 놓친 주기의 횟수이다.. 리턴값과 같은 값이다

이들 정보를 실시간 주기적 모델에 더하여 함께 나타낸 그림이 다음과 같다..

-162- 5)시스템 장벽 (system barrier) 과 장벽 (barrier) 장벽(barrier) 은 사용자가 thread_barrier_init() 을 통해서 정의하여 사용할 수 있는 일반 장벽과 시스템에 이미 초기화되어 정의되어 있는 시스템 장벽의 두 가지 종류 가 있다. 시스템 장벽은 처음에 주기적 쓰레드들을 생성하고 동기화시켜 수행을 시 작시키고자 하는 경우에 주로 사용한다.

• thread_barrier_init() 장벽(barrier) 변수를 초기화시킨다 . • thread_barrier_wait() 다른 쓰레드가 해당 장벽(barrier) 에 대하여 thread_barrier_release() 가 호출될 때까 지수행을멈춘다해당장벽. (barrier) 에대하여이미 thread_barrier_release() 가수 행된 적이 있었다면 바로 진행한다. thread_barrier_release() 에 의하여 깨어나면 위 상(phase) 인자의값동안수면 (sleep) 한다 . • thread_barrier_release() 해당 장벽(barrier) 에 대하여 thread_barrier_wait() 를 하여 수행을 멈춘 모든 쓰레드 를 깨운다.( 수행 가능 (ready) 상태로 만든다 .)

시스템 장벽은 초기화 과정이 필요 없이 사용하며 인자에 장벽 변수가 오지 않는다 는 점을 제외하고는 일반 장벽과 똑같다. 주의할 점은 배리어 함수가 제대로 동작 하려면 해당 장벽에 대한 모든thread_barrier_wait() ( 또는 thread_sysbarrier_wait())들이 thread_barrier_release() ( 또는 thread_sysbarrier_release())보다 반드시 먼저 호출되어야 한다는 것이다 . 예를 들 면thread_barrier_release()( 또는 thread_sysbarrier_release()) 를 호출하는 쓰레드는 thread_barrier_wait()(또는 thread_sysbarrier_wait()) 를 호출하는 모든 쓰레드들보다 우선순위를 낮게 주는 식으로 사용해야 한다.

6) 동적인스케줄링속성변환 A/x는 RT_THREAD 클래스의 쓰레드의 시간 속성을 쓰레드가 생성된 뒤에도 동적 으로 변환하고 그 값을 얻을 수 있도록 하기 위하여 thread_set_period(), thread_set_deadline(), thread_set_releasetime(), thread_get_period(), thread_get_deadline(), thread_get_releasetime()과 같은 함수들을 제공하고 있다 . thread_set_deadline()의 호출은 쓰레드의 생성시 deadline_param 구조체를 통해 종료시한 초과 처리기를 등록했을 경우에만 유효하다.

-163- 여기에서의 특징은 종료시한 속성 전체를 설정하는 함수는 제공하지 않는 다는 점 이다.. 즉 종료시한 초과 처리기를 동적으로 바꾸는 것은 지원하지 않는다 종료 시 한 초과 처리기를 바꾸는 것은 기존의 종료 시한 쓰레드의 종료와 새로운 종료 시 한 쓰레드의 생성을 의미한다. 이와 같은 새로운 쓰레드의 생성은 수행중인 실시간 프로그램에 상당한 부하를 줄 수 있다. 따라서 어떠한 쓰레드에 대한 종료시한 처 리기의 등록은 해당 쓰레드의 생성에서만 가능하도록 하고 있다. POSIX THREAD클래스를 포함하여 모든 쓰레드는 pthread_setschedparam() 과 pthread_getschedparam()을 통해서 동적인 스케줄 속성의 변환을 하거나 값을 얻 어낼 수 있다. 주의할 점은 pthread_attr_settschedparam() 은 쓰레드를 생성하기 전에 의미가 있는 것이라는 점이다.

7)보류 (suspend) 와 계속 (continue) RT_THREAD클래스의 쓰레드는 다른 쓰레드를 보류 (suspend) 상태로 만들었다가 다시 컨티뉴(continue) 상태로 만들 수 있다 . 이는 thread_continue() 와 thread_suspend()함수를 짝을 이루어 사용함으로써 이루어진다 . thread_suspend()함수는 thread_continue() 에 의하여 깨어날 때까지 인자의 쓰레 드의 수행을 멈춘다. thread_continue() 함수는 thread_suspend() 에 의하여 보류상 태에 있는 쓰레드를 깨운다.( 수행 가능 (ready) 상태로 만든다 .) 이 API 는 다른 쓰레 드 간의 제어를 손쉽게 하는 기능을 제공해 준다.

-164- 제2 절 I-PCTV 를 위한 내장형 실시간 컴포넌트 객체 모델의 설계와 구현

가.CORBA2.2 표준을 만족하는 내부 구조 연구

CORBA에서의 요청의 방식은 1) synchronous, 2) deferred synchronous(Dll 를 써 서만 가능함.), 3) oneway ( 응답이 없음 ), 4) asynchronous (CORBA 2.2 표준에는 없지만CORBA 3.0 에 포함될 예정 ) 의 4 가지가 존재한다 . 모든 IDL 인터페이스는 암묵적으로Object 인터페이스로부터 상속받는다 . 오브젝트의 참조의 구현은 CORBA ORB를 구현하는 언어에 따라 다르게 된다 . C++ 로 ORB 를 구현할 경우에 는 연산자를 지원하는 구조체들에 대한 맵-> 함수 ( 또는 클래스에 대한 포인터 또는 오버로드된 연산자를 가지고 있는 클래스의 오브젝트-> 멤버 함수 ) 로 구현된다 . C 에서의 오브젝트 참조는 불투명한 포인터들에 대한 맵(void* 타입 ) 으로 구현된다 . 구현상 자주 사용되는 용어로서 프록시는 스텁 함수들을 지원하는 지엽적인 C++ 오브젝트를 가리킨다.CORBA 의 오브젝트 어댑터는 한 오브젝트의 인터페이스를 호출자가 원하는 다른 인터페이스로 바꾸는 오브젝트이다. 이것은 오브젝트 레퍼런 스를 생성하고,,ORB 목표 오브젝트가 서번트가 변형된 것임을 보장하며 서버측의 가 디스패치한 요청들을 받아들이는 일을 한다. C++ 에서 서번트 (servant) 는 C++ 오 브젝트의 인스턴스로서 프로그래머들은 오브젝트 어댑터와 함께 서번트들을 등록해 야 한다.

(1)오브젝트 레퍼런스 (Object Reference)

IOR(Interoperable Object Reference Format)은 상호 작용 가능한 오브젝트 레퍼 런스 형식이다. IIOP 를 위해 lOR 은 호스트의 이름 , TCP/IP 포트 번호 , 그리고 오브 젝트 키를 가지고 있다. 각 오브젝트의 레퍼런스는 정확히 하나의 오브젝트를 나타 낸다.. 한 오브젝트는 여러 레퍼런스와 이릉들을 가질 수 있다 이는 오브젝트 레퍼 런스는 오브젝트 자체가 아니라는 오브젝트 시스템 디자인을 위하여 깊은 의미를 가지고 있다.Nil 레퍼런스는 ‘ 찾지 못했다 ’,‘ 거기 없다 ’ 의 의미를 전달하는데 유용 하다.. 레퍼런스는 실제로 참조하는 객체가 없는 상태가 될 수 있다 이와 같은 경우 는non_existent 연산을통해서검사할수있다레퍼런스에속한오브젝트가소멸 . 될 때 서버가 클라이언트에 알려주는 자동적인 메커니즘은 코바에 존재하지 않는 다. 레퍼런스는 오브젝트 레퍼런스의 캡슐화 개념에 의하여 불투명한 것이지만 강 하게 타입이 정해져 있다(strongly typed). polymorphism 과 늦은 바인딩은 원거리 오브젝트에 대해,C++ 지엽적인 오브젝트에 대하여서와 똑같이 동작한다 .IOR 형식 에 첨가하여,ORB 는 독점적인 레퍼런스 인코딩을 제공한다 .

-165- 오브젝트 레퍼런스의 내용은1) 리파지터리 아이디 , 2) 끝단 정보 , 3) 오브젝트 키 로 이루어진다. 리파지터리 아이디는 타입 검사를 위한 것으로 표준으로 정해져 있 다.. 실제 내용은 인터페이스 리파지터리 아이디이다 끝단 정보는 클라이언트 측의 ORB에 의해 정확한 목표 주소공간을 확인하기 위해 쓰이며 역시 표준으로 정해져 있다.ORB 오브젝트 구현하는 서버에 물리적인 연결을 만들기 위해 가 필요한 모든 정보를 포함한다. 구체적으로 어떤 프로토콜을 쓸 것인가와 물리적인 주소지정 정 보를가진다하나의레퍼런스는한개이상의프로토콜을지원할수있으며.,ORB 는 가장 적합한 프로토콜을 투명하게 고른다.CORBA 앞으로의 는 아마도 클라이언 트가 오브젝트 레퍼런스를 위한QoS 정책을 골라서 프로토콜의 선택에 영향을 미 칠 수 있도록 할 것이다., 물리 주소 정보는 직접 주소 포트 번호와 임플리멘테이션 리파지터리의 주소로 이루어진다. 오브젝트 키는 표준에서 정한 사항은 없고 구현 마다 다를 수 있는 정보이다.ORB 이는 서버 쪽 에 의해 주소공간 안의 목표 오브 젝트를 알아보기 위해 시용된다.lOR 끝단 정보와 오브젝트 키의 조합은 한 에서 여 러 번 나타나 수 있다.- 이러한 여러 끝단 키 쌍들은 다중요소 프로파일로 부른다 . 프록시는 스켈리톤을 구현한 것을 말하며 타입 안정성을 보장한다. 원격 오브젝트 에 대한 요청은 오브젝트 레퍼런스→→ 프락시() 네트워크 경유 스켈리톤 인스턴스 → 서번트의 경로를 통해 이루어진다.C++ 스켈리톤과 서번트의 상호작용은 의 가상함 수 호출이나 델리게이션(delegation) 으로서 구현된다 . 지역 (collocated) 오브젝트에 대한 요청은 오브젝트 레퍼런스→→ 프락시 서번트의 경로로 이루어지며 간단히 C++의 함수 호출에 의해 요청이 수행된다 .

(2) GlOP

GlOP는추상프로토콜로서 ORB 간의통신을위해직접사용될수있는구체적인 프로토콜이 아니다.GlOP 틀에 맞도록 어떻게 특정 프로토콜이 생성될 수 있는지 기술한다. 주요 요소는 1) 트랜스포트 가정 , 2) 공통 데이터 표현 (CDR), 3) 메시 지 형식으로 이루어진다.GlOP 다음 그림은 메시지 헤더와 요청 헤더의 정의를 나 타낸다.

-166- 트랜스포트의 가정은 커넥션 오리엔트,,, 양방향 연결 신뢰 보장 바이트 스트림 추 상화의 제공으로 이루어져 있다. 트랜스포트는 메시지의 크기에 제한을 주지 않으 며 수신 측이나 송신 측 모두,,,, 메시지 프래그멘테이션 복사 재전송 정렬 같은 문 제에 관계할 필요가 없다 공통의 데이터 표현(CDR) 은 각각의 IDL 데이터 타입의 네트워크 상에서의 데이터 의 이진 배치 형식을 기술한다. 빅 엔디안과 리틀 엔디안 모두를 지원하며 수신 측 에서 바이트 스와핑을 책임져야 한다. 스스로 데이터 포맷의 정체에 대하여 정의하 지 않으며 따라서 송신측과 수신측 사이의 교환될 데이터들의 타입에 대한 동의가 있어야 한다. CDR 인코딩은 효율성을 위한 절충으로 마샬링 (marshalling) 은 단순하 면서 효율적이다. 반면 이러한 효율성을 위하여 데이터의 크기는 커지는 단점이 있 다..ANS.1 또한타입불일치는런타임시탐지할수없다참고로 에의해쓰이는 BER는태그길이값인코딩방식을사용한다이는런타임시더좋은타입안정 - - . 성을 제공하지만,. 마샬링 오버헤드와 대역폭 모두에서 효율이 떨어진다

-167- 메시지 형식은8.CORBARPC 개의 메시지 타입들이 있다 의 기본적인 기능을 구현 하기 위해서는 이들 중 단지2. 개만 필요하다 나머지는 제어 메시지들이거나 최적 화를 지원하는 메시지들이다. 메시지 프래그멘테이션과 양방향 통신을 위한 기능도 구현 가능하다.GlOP 는 클라이언트와 서버의 역할이 관계된 이내에서 단방향이다 . GIOP1.2에선 , 클라이언트와 서버는 하나의 연결을 이용해서 역할을 바꿀 수 있다 .

(3) ORB 상호 동작성

ORB의 상호 동작성을 위한 구조는 ORB 서비스와 lOR (Interoperable Object Reference:상호동작 가능한 객체 레퍼런스 ) 로 이루어진다 . ORB 서비스는 ORB 코 어를 제외한ORB 의 나머지 부분의 서비스를 말하는 것으로서 예를 들면 보안 , 트 랜잭션 기능,, 복구 복제 등의 기능등을 제공할 수 있다 . 서로 다른 ORB 들 간에 상 호 동작성을 위해서는 어느ORB 서비스가 사용되는 지에 관하여 서로 동의할 필요 가 있다.ORB 또한 클라이언트 는 서버 객체의 오퍼레이션을 호출하기 위하여 어느 ORB서비스가 사용되어야 하는지를 결정할 수 있어야 한다 .

그림7: lOR 의 구조

-168- 그림 8: lOR Components lOR은 상호 동작 가능한 객체 레퍼런스로서 어떤 ORB 내에서도 내부적으로 사용 될 필요성은 없으며 객체 레퍼런스 도메인 경계를 넘나들 때만 사용된다.lOR 들은 미래의 프로토콜들을 위한 프로토콜 정보들을 가지고 있도록 확장될 수 있을 뿐만 아니라,lOR. 벤더들이 그들 자신의 독점적인 프로토콜을 에 첨가할 수 있다 예를 들어한IOR 이 IIOP 와 DCE-CIOP 정보를동시에가질수있다또한한 . lOR 은같 은 프로토콜을 위한 여러 프로파일 바디들을 가질 수 있다.IOR3 예를 들어 한 이 개의IIOP 프로파일 ( 각각은 다른 호스트와 포트 번호를 가리킨다 ) 을 가질 수 있다 . 이를 통해 로드 밸런싱또는 고장감내ORB 등을 구현할 수 있다 . OMG에서 태그 값들을 위한 네임 스페이스를 관리한다 독점적인 프로토콜을 지원 하기 위해, 벤더는 한 개 또는 그 이상의 태그 값들을 배타적으로 사용할 수 있도 록 할당 받기를 요청할 수 있다.. 태그 값은 프로파일 데이터의 형식을 결정한다 IOR이 최소한 한 개의 IIOP 프로파일을 가지고 있는 한 , 어떤 상호 작용 가능한 ORB도 lOR 을 사용할 수 있다 . 만약 lOR 프로파일이 TAG_MULTIPLE_COMPONENTS태그를 가지고 있으면 , profile_data 필드는 MultipleComponentProfiie형의 연속적인 배열을 가지고 있다 . CORBA 에 의해 명 시된 요소중의 하나가ORB 타입을 인코드한다 . IIOP를 이용하는 lOR 안의 끝단의 정보는 다음과 같이 인코드된다 .

-169- 태그가 붙은 컴포넌트는 컴포넌트의 타입과 컴포넌트를 위한 데이터의 두 가지 필 드를 가지는 구조로 이루어진다. 그림7 은 lOR 의 구조를 나타낸다 . 그림 7 에서 component data 는 ORB 서비스를 나타내는 것으로 각각의ORB 서비스에 대하여 component id 가 그림 8 와 같은 식 으로OMG 를 통하여 부여된다 .

그림9: 메시지에서의 서비스 context

서비스context 는 또한 GlOP 메시지의 REQUEST 메시지와 REPLY 메시지에도 포 함될 수 있는데, 그림 9 는 GlOP 메시지에 서비스 context 가 어떻게 포함되는지를 보여준다.contextOMG. 다음의 서비스 들이 현재 에 정의되어 있다

나. 멀티미디어 디스플레이를 위한 객체 모델 연구

본 과제에서는I-PCTV 를 위한 멀티미디어 디스플레이를 지원하는 실시간 컴포넌트 객체 모델을 설계하고 구현하기 위하여GNU 의 GNOME CORBA 프레임웍을 기반 으로 하였다.GNOME 은 GUI 와 컴포넌트 기반 컴퓨팅을 지원하는 라이브러리와 데스크탑 환경을 지원하는 응용프로그램으로 구성되어 있다. 본 과제에서는 GNOME CORBA프레임웍을 Arx 에 이식함으로써 멀티미디어 디스플레이를 위한 객 체 모델을 지원하였다.GNOMECORBA 프레임웍은 CORBA2.2 의 대부분을 지원 하는ORBit 미들웨어와 객체 마이그레이션의 기능을 지원하는 Bonobo 를 포함한 다.

-170- (1) GNOME CORBA 프레임웍

GNOME CORBA 프레임웍의 구조 GNOME CORBA프레임웍은 응용 프로그램이 쉽게 ORBit(GNOME 이 사용하는 CORBA의 구현 ) 을 사용할 수 있도록 한다 . 이러한 프레임웍의 한 부분은 ORBit 의 주요 루프를GTK+ 의 루프와 CORBA 의 요청이 왔을 때 보안을 담당하는 부분 , 그 리고GNOME 네임 서비스에 접속하는 표준 함수와 합칠 수 있게 한다 . 응용 프로 그램이 특정한CORBA 객체와 접속할 수 있게 하기 위해 GNOME CORBA 서버는 GOAD(GNOME Object Activation Directory)안에 정보를 담아둔다 . 이러한 디렉토 리는 한 프로그램이 다른 프로그램에게 전달할 수 있는CORBA 객체에 대한 정보 를 가지고 있다. 각각의 디렉토리에 소속된 엔트리는 유일한 구현 ID(“GOAD ID") 와객체가지원할수있는인터페이스의리스트사람이읽을수있는객체에대한, 설명과 객체의 인스턴스를 어떻게 만들 수 있는지에 대한 정보를 포함한다. 만약 한 응용 프로그램이CORBA 객체를 제공하려면 , 단순히 GOAD 시스템에 객 체를 넣기만 하면 된다.‘.goad‘ 응용 프로그램은 데이터 파일을 적절한 디렉토리 에 일련의 과정으로 설치한다., 그러면 객체를 만들거나 없애려고 할 때 몇 개의 함 수가 호출되는데, 이 과정에서 응용 프로그램은 여분의 실행 라인 옵션을 처리하게 된다. 일단 , GOAD 에 객체가 등록되면 , 클라이언트 응용 프로그램은 하나의 함수 호출로 동작시킬 수 있다. 또한GNOME 의 일부분으로 제공되는 CORBA 프레임웍은 factory 나 referenced-counted object 같은 공통적으로 사용되는 인터페이스를 위한 많은 인 터페이스를 정의하고 있다.

Arx에 이식된 GNOME CORBA 프레임웍 Arx에 이식된 GNOME CORBA 프레임웍은 원래 GNOME CORBA 프레임웍의 구조 와 동일하며, 동작도 같다 . GNOME CORBA 서버가 내부적으로 동작되고 있고 , 이 서버는GOAD 를 내부에 가지고 있으면서 , 객체에 대한 요청이 오면 GOAD ID 를 가 지고 객체를 식별해서,. 정보를 얻어낸 다음 서비스를 제공한다

(2) Bonobo 컴포넌트 시스템

Bonobo는 재사용이 가능한 소프트웨어 컴포넌트를 만들기 위한 GNOME 아키텍쳐 로 코비 객체의 마이그레이션을 통해 효율적으로 멀티미디어 그래픽 응용프로그램 을 개발할 수 있도록 도와준다. 그림 10 은 Gnumeric spreadsheet 에 사용된 Bonobo의 모습이다 .GNOME 포스트스크립트 뷰어 ,PDFviewer 등은 모두 Bonobo를 사용한 응용프로그램들이다 .

-171- 그림10: Banabo 를 사용한 Gnumeric spreadsheet

Bonobo(컴포넌튼 소프트웨어 ) 의 장점 컴포넌트 소프트웨어는 프로그래머에게 다른 컴포넌트를 덧붙이는 방식으로 더 크 고,.Gnumeric 더 복잡한 응용 프로그램을 만들 수 있게 해준다 예를 들어 스프레 드쉬트 컴포넌트를 첨가하면 응용 프로그램에 테이블 형태의 데이터를 넣을 수 있 다. 또 , HTML 을표시할수있는컴포넌트를넣으면 HTML 텍스트를볼수있다 . 그래픽을할수있는컴포넌트를넣으면그래픽기능도넣을수있을뿐만아니라, SVG(structure vector graphics)컴포넌트를 넣으면 SVG 파일을 수정하거나 처리 할수도있다. 컴포넌트 소프트웨어는 또한 프로그래머가 알아야 할 정보의 양을 줄여주기 때문에 응용 프로그램의 구조를 훨씬 쉽게 만든다. 그 이유는 각각의 소프트웨어 컴포넌트 가 매우 잘 정의된CORBA 인터페이스를 따르고 있기 때문이다 . 따라서 , 다른 컴포 넌트와 연동이 가능하다. Bonobo 에서는 CORBA 가 컴포넌트를 연동하는 통신층을 담당하고 있다., 하지만 기본적인 원칙은 사용자가 실제 CORBA 인터페이스와 컴포 넌트 간의 프로토콜에 대해 알아야 할 필요가 없도록 하는 것이다. 대부분의 세부 사항은 내부적으로 처리하고,. 디폴트 동작도 설계에 포함한다 이것은 사용자가 의 도적으로 수정하지 않는 한 계속 사용된다. CORBA의 맨 위에 컴포넌트 시스템을 올려 놓았기 때문에 어떤 언어로 작성된 컴 포넌트라도 사용할 수 있다는 이점이 또 하나 생기게 되었다. 단지 하나의 제약은 CORBA 인터페이스가 사용한 형식에 맞추어 컴포넌트를 만들어야 한다는 것이다. Bonobo 아키텍쳐의 경우에는 상호작용을 정의하는 않은 인터페이스가 준비되어 있으며, 컴포넌트가 Bonobo 인터페이스를 구현하면 다른 어떤 종류의 Bonobo 를 기반으로 한 컴포넌트와도 연동할 수 있다.

-172- Arx이 이식된 Bonobo Arx에 이식되어 있는 Bonobo 도 GNOME CORBA 프레임웍과 마찬가지로 원래의 구조를 충실히 따랐기 때문에 위의 장점을 고스란히 가지고 있다. Arx 의 Bonobo 도 여러 개의 컴포넌트를 조합해서 사용하는 것이 가능하고,CORBA 내부적으로 인터 페이스를 기반으로 해서 통신을 하고 있다. 또한 사용자가 적은 시간을 들여 프로 그래밍을 할 수 있도록 사용하기 쉽게 설계되었다. Bonobo 인터페이스를 Arx 에 이 식해 놓은 것은 당분간“bonobo” 로 부르기로 하고 , 이것은 GTK+ 객체 시스템을 상당 부분 기반으로 한다.GTK+ 객체는 대부분의 BonoboCORBA 인터페이스를 감추어 준다. 이는 Bonobo GTK+ 객체가 실제로는 주어진 인터페이스를 구현한 CORBA서버를 나타낸다는 것을 의미한다 . 이런 CORBA 서버는 디폴트 동작을 포 함하고 있고,GTK+ 내부적으로는 동작을 바꾸기 위해서 표준 오퍼레이션을 사용한 다. 대개 gtk_signal_connect 함수를 사용해서 동작을 바꾼다 .

다.CORBA 실시간성 의 요구 조건 연구

현재OMG 의 실시간 코바의 연구에 관련하여 활동하고 있는 워킹 그룹은 다음과 같은3. 가지가 있다 ✓ 실시간 코바 분석 및 디자인 워킹 그룹(Real-Time CORBA Analysis & Design Working Group) ✓ 내장 시스템 워킹 그룹(Embedded Systems Working Group) ✓ 고성능 코바 워킹 그룹(High Performance CORBA Working Group)

이들 워킹 그룹에서 연구하고 있는 기술 분야의 가시적 성과물은 아래와 같다. • 최소형 코바 (Minimum CORBA) ￭ 합동 수정 제안서가 용인됨.: orbos/98-08-04 • 실시간코바1.0(RealtimeCORBA1.0) ￭ 합동 수정 제안서가 용인됨.: orbos/99-02-12 • 고장 감내 코바 (Fault Tolerance) ￭ 최종 수정된 명세서가 존재함.: orbos/00-04-04 • 동적 스케줄링 (Dynamic Scheduling) ￭ 합동 초기 제안서 orbos/99-10-06 • 향상된 관점의 시간 (Enhanced View of Time) ￭ 수정된 제안서가 용인됨.: orbos/99-10-12 • 결합된계산(Aggregatedcomputing) ￭ RFP: orbos/99-01-04 ￭ 제안서에 대한 응답은 아직 존재하지 않음. • UML Profile for Scheduling, Performance, and Time

-173- ￭ RFP: ad/99-03-13 ￭ 제안서에 대한 응답은 아직 존재하지 않음.

그러나 합동 수정 제안서로서 용인된 실시간 코바1.0 은 미들웨어가 수행되는 기반 환경 정의와 완성된 해결책을 제시하지 않고 있다. 또한 기반 운영체제에 의해 제 공된 쓰레드로서 스케쥴 가능한 실체를 정의하여 스케쥴링 실체에 대하여 매우 좁 은 정의를 내리고 있다. 이 외에도 타이밍 제약이 있는 객체들에 대한 정의가 결여 되어 있을 뿐만 아니라 지나치게 단순한 우선순위 모델의 제시, 지나치게 추상적인 스케쥴링서비스의정의로전역요소에대한미고려가등의여러가지문제점을가 지고 있다. 먼저 , OMG 에서 실시간 CORBA 의 조건으로서 명세한 RFP 의 요구사항 들을 살펴보면 다음과 같다.

• 의무 사항 -OMG설계 명세서로의 확장 - 스케쥴링할 수 있는 실체의 정의 - 스케쥴링할 수 있는 실체의 우선순위 제어를 위한 인터페이스 - 클라이언트의 우선순위를 서버에 보낼 수 있는 방법들 -,우선순위 역전을 피하거나 제한할 수 있는 방법들 - 함수 호출 차단을 제한할 수 있는 방법들 -‘’자원 관리를 위한 자원 들의 정의 - 자원할당 방법 - 클라이언트와 서버 측의 프로토콜 선택 방법 - 바인딩을 명백하게 설정하는 인터페이스들 -BOA가아닌 POA 를참조 • 선택 사항 -,클라이언트의 요청 타임 아웃과 응답 타임 아웃을 위한 인터페이스 - 유저가 제공한 트랜스포트 프로토콜의 설치를 위한 인터페이스 -RTORB간의 상호 운용 프로토콜 -‘스케쥴링 실체 ’ 를 위한 런 타임 인터페이스 • 토의점 - 기반 운영체제에 대한 가정들 -POSIX와의 관계 -,,,동시적인 서비스 시간 서비스 트랙잭션 서비스 이벤트 서비스와의 관계 - 보안 서비스와의 관계 -“바인딩의정의 ” - 메시징 명세와의 관계 -CORBA실시간 응용 프로그램을 만드는 방법

-174- 이에 관련하여 실질적으로 적용 가능한 실시간 성 코바의 요구조건으로 다음과 같 은 것들을 연구하였다. 양끝단QoS 요구사항을 명시할 수 있는 정책과 매커니즘 실시간ORB endsystem 은 반드시 응용 프로그램이 IDL 오퍼레이션을 할 때 적은 개수의 매개변수(, 실행 시간 실행 주기 ,, 대역폭 지연 요구 등 ) 를 사용해서 QoS 요 구사항을 표시할 수 있게 해야 한다., 예를 들어 화상 회의 그룹웨어는 통계적인 실 시간 지연 데드라인을 감안해서 높은 처리량을 나타내도록QoS 를 요구할 수 있다 . 반면에, 항공기의 제어 플랫폼은 엄격한 실시간 데드라인을 가진 주기적인 오퍼레 이션을 수행할 필요가 있다. QoS의 수행을 강제할 수 있는 실시간 운영체제 시스템과 네트웍 QoS요구사항을 표시할 수 있는 문제와는 별개로 , ORB 는 QoS 의 수행을 강제할 수 있는 네트웍과OS 의 지원이 없이는 응용 프로그램에 양끝단 QoS 를 보장 할 수 없다. 그러므로 , ORB endsystem 은 반드시 CPU, 메모리 , 저장장치의 처리량 , 네트 웍 어댑터 처리량,, 네트웍 접속 대역폭 대기시간 등과 같은 스케쥴링 자원을 조작 할 수 있어야 한다.,OS 예를 들어 스케쥴링 메커니즘은 반드시 클라이언트의 요청 에 높은 우선순위를 두어야 수행이 완료될 수 있도록 하고, 낮은 우선순위를 가진 요청이 높은 우선순위를 가진 요청을 무한정 블록시킬 수 없도록 해야 한다. 실시간 통신 프로토콜 화상회의와 같은 멀티미디어 응용 프로그램의 처리량,, 대기 시간 신뢰성은 원격 로 그인이나 파일 전송과 같은 전통적인 응용 프로그램의 그것보다 훨씬 더 엄격하고 다양하다.ATM 마찬가지고 과 같은 전통적인 네트웍이 제공하는 채널 속도 , 비트 에러율,( 서비스 등시적이고 대기시간의 범위가 정해진 전달을 보장하는 서비스와 같은).,ORBendsystem 는 전통적인 이더넷 네트웍의 그것보다 훨씬 높다 따라서 은 특정한 응용 프로그램 속해있는 네트웍/, 호스트 환경에 특화되고 최적화된 일정 범위의 통신 프로토콜을 제공해야 한다. 실시간 요청의demultiplexing 과 실행 ORB의 endsystem 은 , 목표 객체의 연산을 바라는 클라이언트의 요청을 demultiplex하고 실행해야 한다 . 일반적인 ORB 에서 demultiplexing 은 여러 계층에 서 이루어 진다.( 예를 들어 , 네트워크 인터페이스 , 프로토콜 스택 , 유저와 커널의 경계, 그리고 ORB 의 Object Adapter). 하지만 , Layered demultiplexing 은 들어온 클라이언트의 요청이 여러 프로토콜 계층을 지나가는 동안, 내부의 표들을 탐색하 는 시간이 늘어나기 때문에,, 고성능 실시간 응용에 알맞지 않다 . 더더구나 , layered demultiplexing은 , 목표 객체 수준의 중요한 QoS 정보에 , 최하위 단계의 디 바이스 드라이버와ORB endsystem 의 I/O subsystem 의 프로토콜 스택에서 접근할 수 없기 때문에,. 우선순위 역전을 일으킬 수 있다

-175- 메모리 관리 현대의RISC 하드웨어는 , 데이터를 복사할 때 , CPU, 메모리 , 그리고 I/O 버스 같은 자원 들를 많이 소모한다. 그래서 , ORB endsystem 의 다중 계층들은 ( 예를 들어 , 네 트워크 어댑터, I/O subsystem 프로토콜 스택 , Object Adapter, 그리고 프리젠테이 션 계층). 은 데이터 복사를 줄이기 위해 공조해야 한다 프리젠테이션 계층 프리젠테이션 계층에서는, 바이트 순서 , 정렬상태 (allignmetn), 워드 길이의 차이 등 을 마스크 해 주는 이동 가능한 데이터 형식으로 응용 수준의 데이터를 바꿔준다. 프리젠테이션의 변환의 가격을 줄여주는 많은 최적화가 있는데, 예를 들어 프리젠 테이션 계층의 변환을 위한 컴파일된 코드와 인터프리트된 코드 사용을 절충하는 것이 있다. 컴파일된 marshaling 코드는 빠르지만 , 많은 내장형 실시간 환경에서 무시할 수 없을 정도의 과도한 메모리를 요구한다., 반면에 인터프리트된 marshalling코드는 느리지만 , 메모리 사용이 적다 .

라.QoS 기술방법연구및 QoS 보장기법구현

(1) QoS 기술 방법 연구

현재까지 연구되어 온QoS 의 기술 방법은 다음과 같은 것들이 있다 . • IDL자체를 확장하여 QoS 를 표시할 수 있도록 하는 QDL (Quality Definition Language)같은 것을 정의하여 제공한다 . 별도의 컴파일러의 도움이 필요하다 . QuO에서 사용되고 있다 . • QoS를 표시할 수 있는 일반적인 factory 오브젝트를 제공한다 . • CORBA::NamedValue를 이용하여 QoS 를 기술한다 . • CORBA::Policv를 이용하여 QoS 를 기술한다 . OMG에서는 마지막의 방법을 Messaging 규약에서 채택하여 사용하고 있다 . 구체 적으로CORBA::Policy 인터페이스의 상속되어 확장된 QoS 인터페이스들을 사용하 는 방법이다.. 본 과제에서도 이를 구현하였다

(2) OMG CORBA QaS 명세의 구현

본 과제에서는OMG CORBA Messaging Specification 의 QoS 명세를 구현하였다 . 이는 그림11 의 프레임 워크를 바탕으로 이루어진다 .

-176- 그림11: QoS 프레임 워크

모든QoS 는 다음과 같은 CORBA::Policy 를 상속한 인터페이스로 정의된다 .

메시징 명세의QoS 제공의 기본 메커니즘은 클라이언트의 QoS 요청에 대하여 QoS를 만족시키지 못할 경우에는 결과를 리턴하는 것이 아니라 예외를 발생시키는 것으로 이루어진다. PolicyManager 인터페이스는 QoS Policy 세팅에 대하여 질의 하거나 오버라이딩을 위한 동작들을 기술한다.POA 에 대하여 QoS 를 적용하는 것 은PolicyList 를 POA::create_POA 에 인자로 넘겨주는 것으로 이루어진다 . Policy Value를 전달하는 메커니즘은 2 가지가 있다 . 한 가지는 IOR: TAG_POLICIES 의 일 부로서IOR 프로파일 컴포넌트 (IOP::TaggedComponent) 로 넘겨주는 것이다 . 다른 하나는 요청의 일부로ServiceId 를 INVOCATION_POLICIES 로 하여 GIOP 메시지 헤더의 서비스context 로 넘겨주는 것이다 . 그림 12 는 메시징 Module 의 이에 대한 정의 부분을 보여준다.QoS(1)(2)(3) 메시징 는 리바인드 지원 동기화 범위 요청 과 응답의 우선순위(4) 요청과 응답의 타임아웃 , (5) 라우팅 , (6) 큐 정렬로 이루어 진다. QoS의 일반적인 사용 시나리오는 서버쪽과 클라이언트의 두가지로 나누어 생각할 수 있다.

-177- • 서버 쪽에서는 1. QoS의 어떠한 설정 셋을 가지고 POA 를 생성한다 . 2.객체 레퍼런스가 생성될 때 QoS 가 그 안에 인코드된다 . • 클라이언트쪽에서는(1) 전체 ORB (2) 현재쓰레드에대한모든호출 , (3) 특정 객체 서버의3QoS 가지에 대한 할당으로 나누어지게 된다 . 이들의 설정이 서로 충 돌할때더상위레벨뒤에나열된것이하위레벨의설정을( ) override 하게된다 . 각각에 대하여, 1.전체 ORB 에 대한 QoS 할당 : 먼저 ORB’s PolicyManager 인터페이스를 얻어서 한다. 이는 ORB::resolve_initial_references("ORBPolicyManager"): 를 통해 이루어진 다. 2.현재 쓰레드에 대한 모든 호출 CORBA::PolicyCurrent 인터페이스를 얻어서 한 다. 이는 ORB:: resolve_initial_references("PolicyCurren“): 를 통해 이루어진다 . 3.특정 객체 서버 : get_client_Policy() 를 통하여 QoS override 에 대하여 질의할 수 있으며, set_policy_overrides 를 통하여 수정된 QoS 를 가지는 새로운 객체 레퍼런 스를 얻어낼 수 있다.

그림12: 메시징 모듈

-178- 마. CCDR(compact common data representation)

CORBA에서 원격 메소드 주문은 다양한 CORBA 구현들에서 상호 운용을 하게 해 주는GIOP 를 통해서 이루어진다 . CORBA 2.2 GIOP 는 CDR 이라는 전송 문법을 사 용한다.CDR 은 GIOP 가 전체 통신망에 IDL 데이터 타입을 보내기 위해 OMGIDL 에 정의된 데이터 타입을 통신망 메시지 표기법으로 바꾸는 것이다. 이것은 바이트 정렬(ordering) 이나 메모리 정돈 (alignment) 같은 플랫폼사이의 문제를 IDL 데이터 타입을 빨리 인코딩하고 디코딩하는 방식으로 지원한다. 특별히 CDR 은 32 비트 경 계로 정수를 정돈하고 공통 통신망 바이트 정렬을 하기보다는little endian 과 big endian바이트 정렬 모두를 지원한다 . 그 결과 같은 방식으로 정렬하고 정돈하는 것을 지원하는 프로세서 상에서 수행될 경우, GIOP 메시지의 mashalling 과 ummashalling은 빨라지게 된다 . 명백하게 CDR 의 일반성 (generality) 과 효율은 통신 망 부하를 증가시켜서 얻는다. 내장형 통신망에CDR 를 적용하기 위해서 , CCDR(compact common data representation)을 제안한다 . CDR 을 2 가지 방법으로 최적화시킨다 . 첫째 , 정수를 32비트 경계에 정돈할 필요가 없도록 CCDR 에 압축된 데이터 인코딩을 첨가한다 . 이렇게 하면 덧붙이는(padding) 바이트를 줄일 수 있다 . 그림 14 는 메소드 주문 foo->op('c', 1234, 'd', "HI")를 CCDR 로 인코딩할 때가 CDR 로 인코딩할 때보다 바이트를 줄일 수 있다는 것을 보여준다.CDR 이 예를 통해 에서 두 개의 정수 (1234와 6) 를 정돈하는데 필요한 6 개의 덧붙이는 바이트를 줄일 수 있다 . ( 정수 6 은 문자열 길이를 표시하기 위해 의도적으로 사용한다.) 이런 압축 인코딩 방식은 메시지 인코딩과 디코딩을 처리하는데 드는 부담을 증가시킬지도 모르고, 노드에 여분의 버퍼 공간이 필요할 지도 모른다. 이런 단점은 만약 인코딩한 메시지 하나 가 내장형 네트워크 메시지 크기에 딱 맞다면 줄어들 수 있고, 이런 경우는 내장형 제어 시스템에서 자주 일어난다.

-179- 둘째,.CDR4 정수를 위해 가변 길이 인코딩 방식을 소개한다 에서 정수를 바이트로 저장하지만,IDL 프로그램에 쓰이는 대부분의 정수는 232-1 보다 작다 .CDR 에서 정수가IDL 데이터 타입의 string 과 sequence 의 크기를 표시하기 위해 매우 자주 쓰이는 것이 그 예이다.. 명백하게 이런 정수값은 대부분의 경우보다 매우 작다 그 러므로 정수가 실제 값에 따라15 부터 바이트까지 변하는 가변 길이 정수 인코딩 방식을 제시한다.4 표 에서 처음의 2 개의 MSB 는 정수의 실제 바이트 길이를 나타 낸다. 인코딩 / 디코딩시의 부담을 줄이기 위해 CCDR 에는 하나의 big endian 바이트 정렬만을 지원한다.14 그림 의 메소드 주문의 예로 되돌아가서 보자 . 가변 길이 인 코딩 방식을 사용해서 여분의5,2 바이트를 줄이고 앞의 가지 방식을 결합해서 단순 한 메소드 주문 시에 총11 바이트를 줄이는 것을 알 수 있다 .

표4: 가변길이정수표현

그림14: 인코딩 예

-180- 제장결과3

제1 절 I-PCTV 용 멀티미디어 실시간 운영체제

본 과제에서 개발한I-PCTV 용 멀티미디어 실시간 운영체제인 Arx 를 평가하기 위하 여 제안서에서 언급한 실험과 함께 다양한 실험을 수행하였다.Intel 모든 실험은 100MHz Pentium프로세서와 256KB 의 이차 캐쉬를 갖는 기계에서 수행하였으며 , 측정은Intel Pentium 프로세서의 64-bit cycle 카운터를 사용하였다 .

가.QNX 를 기준으로 한 커널의 기본 성능의 평가

온과제에서개발한실시간운영체제와QNX version 4.23A 와의성능비교실험을 수행하였다.5ArxQNX 표 에 와 의 기본 성능 지수를 나타내었다 .Arx 에서 보여지는 8.09ms의 보통의 스케줄링 지연은 QNX 보다 훨씬 작은 값이다 . 시스템 서비스의 오버헤드의 차이를 확인하기 위해서clock_gettime() 시스템 콜을 사용하여 시간을 측정하였다.ArxQNX6 이 결과 가 보다 배 빠르게 동작함을 알 수 있다 . 이런 큰 차 이가 나는 것은QNX 가 micro-kernel 구조를 사용하기 때문이다 . Arx 는 클럭 인터 럽트 핸들링에서도QNX 보다 좋은 성능을 보여준다 .

표5: Arx 와 QNX 의기본적인커널성능지수 (unit:ms )

나업콜성능.

Arx 커널을 업콜에 상당히 의존하기 때문에 업콜 지연을 최소화하는 것이 매우 중 요하다그림.16 은라운드로빈스케쥴링정책을사용하고고정우선순위스케줄링 을 하는 사용자 수준 스케줄러 구현했을 때Arx 커널에서의 업콜 성능을 나타낸다 . 업콜 지연은 커널 업콜 핸들러가 시작하고 사용자 수준 스케줄러가 수행되기까지의 시간으로 정의되고,3.11s.16 그 값은μ 로 측정되었다 그림 에서 보듯이 쓰레드를 다시 수행시키기 위해서 필요한 시간은 쓰레드가 커널 모드에 또는 사용자 모드에 있는지의 여부에 크게 영향을 받지 않는다. 이것은 resume() 시스템 콜이 일반적인 시그널 검사 기능을 생략하도록 만은 특수한trap handler 에 의해서 다루어지도록 설계하였기 때문이다.

-181- 그림16: 업콜 성능

다.() 사용자 수준 입출력 인터럽트 성능

Arx사용자 수준 인터럽트 성능을 보이고 Unix 시그널과 비교하기 위해서 Arx 와 Unix에서 시그널 핸들링에 따른 지연을 측정하였다 . 시그널 핸들링 지연은 커널 인 터럽트 핸들러가 수행하기 위해서 첫번째 명령어를 수행했을때부터 시그널 핸들러 가 수행하기 위해 첫번째 명령어를 수행하기까지의 시간으로 정의된다. Unix시스템으로서는 Linux version 2.0.31 이 사용되었다 . 사용자 수준 인터럽트 핸 들링은Linux 에서 지원되지 않기 때문에 Linux 시그널과 임의의 인터럽트를 연관지 을 수는 없다. 따라서 Linux 에서는 alarm 시그널을 사용하였다 . 왜냐하면 alarm 시 그널은 클럭 인터럽트에 의해서 발생되기 때문이다. 정확한 시그널 핸들링 지연을 측정하기 위해서 측정된 지연에서 클럭 인터럽트 핸들러의 수행시간은 제외시켰다. 실험을 위해서 간단한 오디오 플레이 프로그램을 작성해서 주기적으로4KByte 의 오디오 데이타를 사용자 수준DMA 를 통해 오디오 기기에 전송하도록 하였다 . 이 기기는 각DMA 전송의 끝에서 end-of-DMA 인터럽트를 발생시키고 , 또 플레이어 는 다음 전송을 시작한다. 표 6 에 Arx 와 Linux 에서 측정된 시그널 핸들링 지연을 나타내었다.

표6Arx 와 Linux 에서 측정된 시그널 핸들링 지연

-182- 시그널을 받는 프로세서가 사용자 모드와 커널 모드에서 동작하는 두 가지 경우 대 하여 지연을 나열했다.ArxLinux 결과에 따르면 시그널은 시그널보다 훨씬 적인 지연을 가짐을 알 수 있다.Arx 더욱 종요한 것은 에서의 시그널 핸들링 지연은 시 그널을 받는 프로세스의 상태와 관련없이 상수값을 가진다는 것이다.Linux 반면에 에서는61% 까지 값이 크게 변한다 . 이것은 Arx 에서는 특정한 핸들러 쓰레드에 의 해서 인터럽트가 서비스되기 때문이다. 이것은 예측가능하고 결정적인 시그널 핸들 링을 제공하여 내장 실시간 시스템에서Arx 사용자 수준 I/O 기법을 사용하는 것을 이상적으로 만들어 준다. 표의 마지막 줄은 시그널 핸들러에서 돌아와서 콘트롤을 얻기까지의 시간을 나타낸다.Linux 는 Arx 보다 큰 부하를 갖게된다 . 왜냐하면 Linux 시그널 핸들러는 커널 내부에서 사용되는 시그널 마스크를 복구하는 시스템 콜을 해야만 하기 때문이다.

라. 쓰레드 스케줄링 성능

다른 운영체계에 비해서Arx 가 제공하는 다중쓰레딩 기법이 성능면에서 이점이 있 다는 것을 보이기 위해Arx, Solaris, Window98 상에서 다중쓰레드 자바 프로그램 을 통해 측정을 하였다. 이 실험은 266 MHz Pentium-Ⅱ PC 에서 이루어 졌다 . 왜 냐하면Solaris 를 100 MHz Pentium PC 에 설치하는데 실패했기 때문이다 . 또 50ns 의 정밀도를 갖는 타이머 보드를 사용하였다. Pentium event counter 는 사용자 모 드에서는 사용할 수 없기 때문이다.C 벤치마크에 사용된 자바프로그램은 부록 에 나와 있으며, 각 쓰레드가 synchronized 오브젝트에 의해 보호되는 글로벌 배열에 자신의 쓰레드id 를 100,000 번 써 넣는 작업을 하게된다 . 자바 가상 머신은 Kaffe version 0.10.0을 Arx, Solaris, Windows98 에 JIT 모드가 가능하게 포팅된 것을 사 용하였다. 쓰레드의 개수를 바꾸어 가면서 쓰레드 수행에 걸리는 총 시간을 측정하였다. 쓰레 드 스케줄링 성능만을 관찰하기 위해서,Javaclassfile 을 로드하는 시간을 제외하 였다. 이 실험에서 자바 벤치마크 프로그램의 모든 쓰레드는 같은 우선순위를 가지 고,.17. 라운드 로빈 정책으로 스케줄링 된다 그림 은 실험의 결과를 요약한 것이다 그림17(A) 는 세 가지 다른 운영체계 상에서 총 실행시간을 나타내고 , 그림 17(B) 는 문맥 교환 횟수를 나타낸다.Arx 예상대로 는 훨씬 더 많은 문맥교환이 발생했음 에도 불구하고Solaris 와 Windows98 보다 훨씬 적은 스케줄링 부하를 가짐을 알 수 있었다.

-183- 예상과는 대조되게Solaris 에 대한 Arx 의 성능향상은 근소한 차이임을 알 수 있다 . 이것은Solaris 는 커널 쓰레드를 사용하지만 mutex lock/unlock 도구는 사용자 수 준 라이브러리로 구현되었고,Solaris 의 라운드 로빈 quantum 크기가 매우 커서 쓰 레드 스케줄링 부하가 총 실행시간에 거의 영향을 주지 않기 때문이다.Arx 의 quantum크기는 1ms 이고 반면에 Solaris 의 quantum 크기는 200ms 이다 . 한편 Arx는 상당한 차이로 Windows98 보다 우수한 성능을 나타냈다 . Solaris 와 다르게 Windows는 mutex 도구들이 시스템 콜로 만들어져 있다 . Solaris의 quantum 크기가 작아진다면 Arx 가 Solaris 보다 훨씬 좋은 성능을 보일 것이라고생각한다이예상은다음과같은간단한계산에의해서해볼수있다.. 20개의 쓰레드를 Solaris 에서 동작시켰을때 200ms quantum 크기로 걸린 총 실행 시간은5109ms 이었다 . round-robin quantum 이 1ms 이라면 , 거의 5000 번의 추 가적인 문맥 교환이 발생할 것이다.Solaris 에서의 스케줄링 부하는 200mus 였기 때문에1000ms 의 추가적인 시간이 총 실행 시간에 더해 지게 된다 . 증가된 시간 은 반복적으로 문맥교환의 수를 늘이게 될 것이다. 결과적으로 총 수행시간은 더 증가하게 될 것이다.6,374ms 이 총 수행시간이 수렴할 때까지 계산해보면 가 된 다.25%. 이 값은 원래 값보다 정도 증가한 값이다 이 결과는 커널 수준 쓰레드의 바람직한 특성을 가지면서도 커널 수준 쓰레드보다 Arx에 사용된 기법으로 만든 사용자 수준 쓰레드가 훨씬 좋은 성능을 가짐을 나타 낸다.

그림17: Arx, Solaris, Windows98 의 쓰레드 스케줄링 성능 : (A) 모든 쓰레드의 총 수행시간,(B) 이에따른문맥교환의발생횟수

-184- 마. 커널과 쓰레드 패키지의 안정성 검증

(1) 유저 스케줄러 동작의 검증

그림18 은 전형적민 유저 스케줄러의 의사 (pseudo) 코드와 각 블럭의 수행 중에 만족해야할Assertion 들 , 유저 스케줄러의 선행조건 (pre-condition) 과 후행조건 (post-condition)을 함께 표현한 것이다 .

그림18. 전형적인 유저 스케쥴러의 의사코드 (pseudo-code)

-185- 먼저 선행조건을 살펴보자. 유저 스케쥴러가 이벤트가 발생하여 커널에 의해 invoke될때는 HeadIdx !=TailIdx 이지만 , UnlockScheduler() 에 의해 호출될 때는 다 음 절에서 설명하는 바와 같이HeadIdx = TailIdx 일 수 있다 . 그러므로 , 선행조건은 HeadIdx, TailIdx가 가질 수 있는 값의 범위만으로 표현된다 . 스케쥴러가 끝나는 상황에는HeadIdx = TailIdx 를 만족해야 한다 . CurThread 변수 ()현재 수행 중인 쓰레드를 가리킴 가 지정하는 쓰레드로 문맥교환 되어야 한다 . 각 Assertion들이 만족됨을 보고 , 마지막의 후행조건이 만족됨을 보임으로써 유저 스 케쥴러가 논리적으로 올바른 동작을 함을 보인다. 먼저,IDLE 이벤트가 상태일 때 수행되던 쓰레드를 T,그때의 HeadIdx 를H라고 하자. 1. L1은 HeadIdx 와 TailIdx 가같은경우를처리하며 , UnlockScheduler() 에서유저 스케쥴러가 동기적으로 호출되는 경우를 위해 필요하다., 즉 불필요한 처리를 막기 위한 것이다.CurThread 는 스케쥴러를 호출한 쓰레드를 가리키므로 , RestoreThreadContext()에 의해 문맥교환이 완료되면 , Assertion 1 이 만족된다 . 만 약 이것을 처리하는 도중 이벤트가 발생하면 새로운 유저 스케쥴러가 현재 스케쥴 러를override 하면서 처음부터 다시 시작한다 . 그 때는 L1 이 거짓이 되어 Assertion 1.에는 영향을 미치지 못한다 2. L2에서 L5 까지의 while loop 는 HeadIdx != TailIdx 가 만족되어야만 수행이 된 다. 즉 , HeadIdx != TailIdx 가 loop invariant 가 된다 . L3 에서는 이벤트가 BLOCK 인 경우, CurThread 를 run queue 에서 삭제하고 sleep queue 에 삽입하며 , 쓰레드의 상태를TBLOCK 으로 바꾼다 . BLOCK 은 쓰레드가 커널에서 blocking 을 할 때 , 동기 적으로 발생하는 이벤트이므로CurThread 가 T임이 보장되며, 스케쥴러가 처음 invoke될때만역시 BLOCK 이벤트가발생할수있으므로 HeadIdx = H가보장된 다. L4에서 HeadIdx 가 가리키는 이벤트의 문맥이 유효하다면 이벤트에 저장된 문맥을 CurThread의 문맥에 복사하는 작업을 한다 . 앞 절에서 설명한 바와 같이 유저 스 케쥴러의 상태가IDLE 일 때 이벤트가 발생하는 경우에만 문맥이 유효하기 때문에 , SaveContext()를 수행하기 전에는 Assertion 4 가 보장된다 . 그러므로, Assertion 3, 4 가 만족된다 . 이것은 유저 스케쥴러에서 CurThread 를 바 꾼 후에, 새로운 스케쥴러가 이전 스케쥴러를 override 하는 경우에 CurThread 와 관 련된 작업이 이루어질 수 없음을 보장한다. 3. Assertion 5가 만족함을 보이기 위해 , L2 와 L5 를 살펴본다 . L2는 HeadIdx 와 TailIdx 을 비교하는 것이다 . 이것을 외부 인터럽트에 대해 atomic 하게 수행되는 기계어로 쪼개면 다음과 같다.( 일반적인 CPU 를 가정 ).

-186- (1) HeadIdx를 레지스터에 load (2) TailIdx들 레지스터에 load (3) 두레지스터값을비교 (4)같으면 L6 으로 분기 이경우HeadIdx 와 TailIdx 이서로동일한경우와다른경우에대하여새로운이벤 트가 발생하는 경우 올바르게 동작하는가를 생각해본다.

●HeadIdx 와 TailIdx 이 동일한 경우 이벤트가 발생하지 않으면 당연히 만족된다., 만약 이벤트가 발생하면 커널은 규칙1invoke 에 따라 이전의 문맥을 무시하고 새로운 유저 스케쥴러를 하므 로 다음 스케쥴러에서check 된다 . ●HeadIdx 와 TailIdx 이서로다른경우 이 경우 이벤트가 발생하면 커널은TailIdx 값을 증가시키며 , 유저 스케쥴러는 수행이 재개(resume) 된다 . (1) 은 TailIdx 과 관계가 없으므로 문제가 발생하지 않으며,(2) 에서 TailIdx 이 레지스터에 로드가 된 후에 이벤트가 발생한 후 다 시 되돌아오면 레지스터에는 잘못된 값이 남게 된다.TailIdx 하지만 두 값이 이 증가되기 이전에 서로 달랐기 때문에 비교의 결과는 동일하다. 또한 TailIdx의 값이 비교이외의 다른 용도로 사용되지 않기 때문에 문제가 발생하 지 않는다.

L5는 HeadIdx 의 값을 1 증가시키고 인덱스 값이 이벤트 큐의 크기보다 크면 0 으로 만든다.L2 과 마찬가지로 쪼개어 보면 다음과 같다 . (1) HeadIdx를 레지스터에 load (2)레지스터 값을 1 증가 (3) 모듈러연산수행 (4)레지스터 값을 HeadIdx 에 store (5) L2으로 점프 이 경우에도L2 에서와 같이 생각해본다 . ●HeadIdx 와 TailIdx 이 동일한 경우 HeadIdx와 TailIdx 이 같아지는 경우는 (4) 가 수행된 후에나 발생할 수 있다 . HeadIdx와 TailIdx 이 달랐기 때문에 블록 내의 코드가 수행되었기 때문이다 . HeadIdx값이 반영이 된 후이기 때문에 새로운 유저 스케쥴러가 수행된다 . ●HeadIdx 와 TailIdx 이서로다른경우 (4)에서 HeadIdx 가 증가되어도 HeadIdx != TailIdx 이라는 사실에는 변함이 없기 때문에 이벤트가 발생하더라도 문제가 생기지 않는다. 이상에서 살펴본 바와 같이 어떠한 상황에서도Assertion 5 가 만족된다 .

-187- 4. L6에서 유저 스케쥴러는 US_DISP 상태가 된다 . L6 에서는 run queue 에서 쓰레 드를 선택한다 (큐에서 삭제하지는 않는다.)CurThread이결과로 가바뀔수있으 며,0.CurThread0L7, 수행될 쓰레드가 없는 경우에는 이 된다 가 이면 이 수행되며 sleep()시스템 콜을 통하여 수행을 끝마친다 유저 스케쥴러가 sleep() 을 호출한 후 새로운 이벤트가 발생하면, 유저 스케쥴러가 invoke 된다 . 즉 , sleep() 이후의 코드 는 수행되지 않는다., 만약 이벤트가 발생하지 않으면 프로세스는 영원히 깨어날 수 없다. Assertion 6 은 당연히 만족된다 . CurThread 가 0 이 아닌 경우에는 문맥교환이 발생하며,L8L9 유저 모드에서 가능한 경우에는 을 그렇지 않은 경우에는 를 수행한 다. L8 의 RestoreThreadContext() 는 쓰레드의 문맥을 로드하고 마지막에 스택 포인 터를 변경함으로써 문맥교환을 수행한다. 그러므로 Assertion 7 이 성립한다 . L9에서는 resume() 시스템 콜에 커널 스택 번호를 넘겨준다 . resume() 은 해당하는 스택으로 커널 스택을 교환하고, 커널 스택에 저장된 문맥을 로드함으로써 문맥교 환을 수행한다. 그러므로 Assertion 8 이 성립한다 . 두 경우 모두 완전히 문맥교환이 이루어지기 전에 새로운 이벤트가 발생하면 이벤 트 큐의 문맥이 무효화되어 유저 스케쥴러에게 넘어가기 때문에L3, L4 에서 CurThread와 실제 복구된 문맥 사이의 inconsistency 가 발생하지 않게 된다 . 5.그러므로 , 유저 스케쥴러가 수행을 끝마쳤을 때의 후행조건들이 만족된다 . 이상에 따라 유저 스케쥴러는 올바르게 동작함을 알 수 있다.

(2) 라이브러리 코드의 검증

그림19 과 그림 20 은 라이브러리 코드에서 스케쥴러를 lock 하고 unlock 하는 작업 을 의사 코드로 표현한 것이다. 유저 스케줄러와 마찬가지로 함수의 선행조건과 후 행조건, 블록이 수행을 끝마친 후의 Assertion 들을 표현하였다 . 먼저LockScheduler() 를 살펴보자 . 선행조건으로는 SchedLock 이 0 이며 , 후행조건 으로는SchedLock 이 1 이어야 한다 .

1.첫번째 문장에서 SchedLock = 1 이고 . SchedLock 변수의 값이 1 로 되기 전에 유저 스케쥴러가 호출되어 선점이 된 후에 수행이 재개(resumption) 되더라도 SchedLock의 값은 선점되기 이전의 값을 갖는 것이 보장이 되므로 Assertion 1 이 만족된다. 2.그러므로 후행조건이 만족된다 .

-188- 그림19: LockScheduler() 의 의사코드

그림20: UnlockScheduler() 의 의사코드

-189- 두번째UnlockScheduler() 는 기본적으로 SchedLock 을 0 으로 바꾸는 작업을 한다 . 하지만SchedLock 이 1 인 동안 이벤트가 발생하여 유저 스케쥴러가 진행을 하지 못한 경우를 위해서HeadIdx 와 TailIdx 를 비교하여 값이 서로 다른 경우 유저 스케 쥴러를invoke 하는 일을 부가적으로 수행한다 . 만약 , 여기서 유저 스케줄러를 invoke하지 않는다면 영원히 이벤트가 처리되지 못할 수가 있다 . 선행조건을 살펴보면, 함수는 현재 수행되고 있는 쓰레드에 의해 호출되는 것이므 로CurThread != 0 이어야 하며 , 정상적인 상황에서는 SchedLock = 1 이어야 한다 . 이 함수가 수행된 후에는SchedLock = 0 이어야 하며 , CurThread 가 함수를 호출하 기 이전과 동일해야 한다., 즉 정상적으로 문맥교환이 발생해야 함을 의미한다 . 먼 저 함수가 호출될 때 수행되던 쓰레드가 T라고 하자. 1. Assertion 1을 살펴보자 . L1 에서 SchedLock 이 0 으로 바뀌기 이전에 이벤트가 발생하였다면 어떠한 상황에서도HeadIdx != TailIdx 가 만족된다 . 하지만 , 그렇지 않고SchedLock 이 1 로 바뀐 후에 이벤트가 발생하는 경우에는 HeadIdx = TailIdx 가 될 가능성이 있다. 예를 들어 , HeadIdx 가 레지스터에 로드가 되고 TailIdx 는 아 직 로드가 되지 않았을 때 이벤트가 발생하는 경우를 생각해보자.,HeadIdx 이 때 와TailIdx 가 0 이라고 하자 , 두 값이 동일하고 SchedLock 이 0 이므로 이벤트가 발생 하면 커널은 유저 스케쥴러를invoke 한다 . 유저 스케쥴러는 이벤트를 처리하고 정 상적으로 수행을 끝마치게 된다. 수행의 결과로 HeadIdx 와 TailIdx 가 각각 1 이 된 다. 쓰레드가 수행을 재개할 때까지 이벤트가 한번만 발생했다고 가정하자. 쓰레드 가 수행을 재개하면,TailIdx 의 값인 1 이 레지스터에 로드된다 . 따라서 비교 결과가 HeadIdx != TailIdx가된다즉 . , HeadIdx 와 TailIdx 가같지만 Uscheduler() 를 invoke하게 된다 . 하지만 , 유저 스케쥴러에서 HeadIdx 와 TailIdx 가 같으면 그냥 문 맥교환을 하므로 문제가 발생하지는 않는다. 그러므로 Assertion 1 이 만족된다 . 2‘ Assertion 2를 설명하기 전에 어떻게 쓰레드가 자신의 문맥을 저장하고 유저 스 케쥴러로 문맥교환을 하는 가를 살펴보자.L3 의 SaveContext() 함수는 UNIX 의 setjmp()와 동일한 기능을 수행한다 . 즉 , SaveContext() 를 호출하면 현재 쓰레드의 문맥을 저장하고 무조건0. 을 넘겨준다 후에 문맥이 복귀되면 다시 L3 를 수행하게 되며SaveContext() 함수가 1 을 넘겨 주게 된다 . 그러므로 L4 의 if 문이 거짓이 되어 L8로가게된다 .

-190- 그러면L3 에서 L7 까지를 수행하고 난 후에 Assertion 2 가 만족됨을 보이기로 하자 . 먼저L5 에서 SchedLock 을 1 로 바꿔 유저 스케줄러가 invoke 되는 것을 막는다 . 이 것은HeadIdx 와 TailIdx 가 실제로 다르다면 필요없는 작업이 된다 . 왜냐하면 규칙 2-1에 의해 유저 스케쥴러가 invoke 되지 않기 때문이다 . 하지만 HeadIdx 와 TailIdx 가 같으면 유저 스케줄러가invoke 되고 두 값이 같기 때문에 다시 되돌아온 후 , 또 한번 유저 스케줄러가invoke 되게 된다 . 이와 같이 불필요한 작업을 방지하기 위해 SchedLock을 1 로 세트하며 어떠한 경우에도 유저 스케쥴러가 불리지 않도록 하는 것이다..L4 이후의 작업은 유저 스케쥴러를 고려하지 않아도 된다 에서 현재 문맥 을 저장한다. SaveContext() 는 0 을 리턴하므로 L5 가 수행된다 . L5 에서 스택포인터 를 유저 스케쥴러의 것을 바꾼다. L6 에서 SchedLock 의 값을 0 으로 다시 리셋하며 lock을 푼다 . 그리고 L7 에서 유저 스케줄러를 호출한다 . 만약 L6 에서 SchedLock 이 0<<으로 바뀐 후에 유저 스케줄러가 호출되어도 HeadIdx와 TailIds 가 같다는 것이 보장된다.>>유저 스케줄러로 문맥교환이 이루어 졌으므로 ( 스택 포인터가 바뀌었 음)5 규칙 와 규칙 6 에 따라 쓰레드의 문맥은 저장되지 않는다 .,L4 즉 후에 에서 저장된 문맥이 복구된다. 이것은 Headidx 와 TailIdx 가 같은 경우 이벤트가 발생하면 L7이 불필요한 작업이 됨을 의미한다 . 이상에서 알 수 있듯이 제어의 흐름이 언제 나“L4L5L6L7L4L8”.→→→→→ 가 된다 그러므로 제어가 L8 에 왔을 때 Assertion 2가 만족된다 . 3. L2에서 HeadIdx 와 TailIdx 가 같아서 L9 로 오게 되면 바로 후행 조건이 만족된 다. 4.그러므로 후행조건인 SchedLock = 0 과 CurThread = T가 만족된다.

-191- 바., 스트리밍 재생 전력 사용 및 장치별 자동 비율 인식

1)스트리밍 재생 throughput

멀티미디어 데이터의 처리 능력을 알아보기 위해서 초당 멀티미디어 스트림 처리량 을 측정하였다. 초당 멀티미디어 스트림 처리량은 디스크 혹은 네트웍 상에 존재하 는 동영상이나 음향과 같은 고용량 데이터를 처리하는 성능을 나타내는 것으로, 본 실험 평가에서는Pentium 100MHz PC 상에서 디스크에서 동영상 데이터를 읽어 처 리할수있는성능을측정하였다이때성능은커널의버퍼링기능과디스크관리. 성능, 커널의 데이터를 유저 레벨로 전달하기까지의 방법 등에 의해 결정되게 된다. 본 연구에서 개발된 실시간 운영 체제는 이중 유저 레벨I/O 를 적용해서 디스크에 서 읽은 데이터를 효율적으로 유저 레벨에서 사용할 수 있어서 초당 스트리밍 재생 처리량을 향상 시켰다.

2)스트리밍 재생 overhead

멀티미디어 처리 시에는 하나의 화면 프레임 혹은 일정시간의 데이터를 단위로 읽 어들인 후 처리를 하게 된다. 즉 일반적으로 디스크로부터 일정량의 데이터를 읽은 후,, 그데이터를처리하고다시데이터를읽는것을반복하게된다이때각데이 . 터 블록의 처리 요구가 발생한 이후 실제 데이터를 처리하는데 까지 지연된 시간을 스트리밍 재생overhead 라 한다 . 본 성능 측정 실험에서는 앞의 실험과 같은 PC 상에서 동영상을 프레임 단위로 읽어 들이며, 하나의 프레임을 처리하는 데 소요되 는 오버헤드를 측정하였다.

-192- 3) 장치별평균전력감소비

임베디드 시스템의 소비 전력을 감소 시키기 위해서 낮은 전력으로 시스템을 동작 시키거나, 사용하지 않은 장비는 휴지 (sleep) 상태로 유지시켜 소비 전력을 감소 시 킬 수 있다. 본 실험에서는 장시간 시스템의 입출력이 최소화된 상태에서 작동시킬 경우 시스템에서 소비한 전력의 양과 각 장비를100% 사용했을 때의 소비전력을 비교하며 소비 전력의 감소량을 성능 측정 척도로 사용하였다. 사용한 시스템의 종 류와 주변 장치에 따라 전력 감소비가 다를 수 있으므로, 각 시스템 설정에 따라 전력 감소비를 측정한 후 평균하였다. 다양한 시스템의 전력 감소비를 측정하기위 해서CPU 는 x86 과 ARM, 디스크는 플래시 디스크와 일반 하드디스크 , 네트웍 카 드,CPU 플로피 드라이브 등과 같은 및 사용 장비를 교체하며 전력 사용량을 측정 하였다.

4) 장치별자동인식비율 iPCTV의 주변 장치는 별도의 설정 없이 그대로 연결할 경우 , 운영 체제에서 이를 인식하여 사용이 가능하여야 한다. 그러나 이를 위해서는 각 하드웨어 벤더들이 이 를 지원하도록 하드웨어를 설계하고 드라이버를 제공하여야 한다. 따라서 본 실험 에서는 윈도우 시스템에 대해서Plug and Play 를 지원하고 현재 드라이버의 소스 가 공개되어 있는 장비들 중 현재 본 운영 체제에서 드라이버의 포팅이 이루어진 장비에 대해서 실험을 수행하였다.

제2 절 I-PCTV 를 위한 내장형 실시간 컴포넌트 객체 모델의 설계와 구현

가. 미들웨어의 기본 성능 측정

개발한 실시간 미들웨어의 성능 측정을 위해서 ORB operation latency variance, Normalized ORB with Resource Saturation, Null ORB Operation Throughput, ORB Operation당횟수를 OS Context Switch , OS/ORB Processing Overhead 측정하고 기존 실시간 미들웨어와 그 결과를 비교하였다. 실험에 시용한 시스템은 Pentium 100MHz, 32MB RAM의 PC 이며네트웍을통해통신할때발생하는오버 , 헤드를 제거하기 위해서 하나의PC 상에 클라이언트와 서버가 같은 컴퓨터에 있는 것을 가정하고 실험을 수행하였다.

-193- 1) ORB작업 지연 시간 분산도 (ORB operation latency variance)

Real-time CORBA ORB에서 작업 지연 시간은 클라이언트와 서버간의 통신 속도 에 큰 영향을 준다. 작업 지연 시간이 클 경우 통신 속도는 그에 따라 크게 감소되 게 된다., 이러한 통신 속도의 감소는 성능의 하락 뿐만 아니라 실시간 시스템에서 최악 수행 시간 측정에 어려움을 주게 되어 시스템의 예측 가능성을 낮추게 된다. 따라서ORB 작업 지연 시간은 중요한 의미를 갖는다 . ORB 작업 지연 시간은 ORB 의 종류가 사용환경에 따라 다양한 수치를 가질 수 있으므로 절대적인 수치 이외에 도 분산도를 같이 고려하여ORB 및 시스템의 예측 가능성을 가늠할 수 있는 척도 로 사용된다. 실험 내용은 클라이언트가 1 초에 20 번 씩 CORBA two-way call 를 수행한 결과를 낸 후 분산을 계산하였다. 클라이언트와 서버는 모두 같은 우선 순 위 레벨을 갖도록 하고 수행하였다.

-194- 2) Normalized ORB Latency with Resource Saturation

Normalized ORB Latency with Resource Saturation는 일반적인 상황이 아닌 매우 높은 부하를 갖는 극한 상황에서도 한정된 동작이 보장되는 것을 보이기 위한 척도 로 사용된다. 실험에서는 많은 수의 낮은 우선 순위를 갖는 클라이언트들이 처리 요청을 하고 있을 때 높은 우선 순위를 갖는 클라이언트의 요청이 수행되는 시간을 측정하는 방법으로 하였다. 이를 실험하기 위해서 정해진 수의 낮은 우선 순위의 클라이언트들이110 초의 번의 주기로 요청을 보내는 상황에서 높은 우선 순위를 갖는 클라이언트의 요청이 처리되는 시간을 측정하였다. 이때 높은 우선 순위를 갖 는클라이언트의요청의처리시간이최대가될때까지낮은우선순위의클라이 언트를 늘려가도록 하였다.

3) Null ORB Operation Throughput

Null ORB Operation Throughput은 ORB operation 에 단위 시간당 operation 이 처 리될 수 있는 최대 수를 말하는 것으로, ORB operation 틀 실행하는 데 소요되는 ORB와 OS 에 의한 overhead 를 측정하기 위한 것이다 . 실험 방법은 위의 실험 PC 상에서 하나의 클라이언트가 연속적으로void 타입을 갖는 Null ORB Operation 을 수행하고,. 단위 시간 당 수행 횟수를 측정하는 방법을 사용하였다

4) ORB Operation당횟수 OS Context Switch ㆍ

ORB operation은 기본적으로 같은 시스템 내의 다른 프로세스 혹은 쓰레드 , 다른 시스템의 다른 프로세스와의 통신을 하게 되므로 필연적으로 많은 수의 context switch가발생하게된다따라서 . OS context switch 에의한지연시간은 ORB 의 효율성과 시스템의 예측 가능성에 큰 영향을 주게 된다.ORB 의 설계 시 프로세스 간의context switch, 커널과의 유저 레벨 사이의 context switch 를 고려함으로써 context switch를 줄일 수 있다 . 또한 미들웨어를 위해서 실시간 운영체체를 최적 화 할 경우 이러한context switch 를 줄일 수 있다 . 특히 본 연구와 같이 운영체제 기술과 미들웨어 기술을 모두 보유하고 있을 경우, 이러한 미들웨어에 대한 운영체 제의 최적화가 가능하다. OS context switch 횟수는 void, long, long sequence 타입의two-way ORB operation 를 반복 수행한 평균을 측정하였다 .

-195- 5) OS/ORB Processing Overhead 분포

OS/ORB Processing Overhead는 IIOP 통신 프로토콜의 마샬링 / 언마샬링 , 디멀티 플렉싱과 디스패칭,ORBoperation 오브젝트 어댑터의 데이터 카피 연산과 같은 에 의해 발생하는 일련의 작업에 소요되는CPU 시간과 실시간 운영체제의 커널에서 네트워크 프로토콜 수행 등과 같이I/O 서브시스템 하에서 소요되는 시간을 합한 것을 의미한다. 실험은 ORB Operation 당 OS Context Switch 횟수 측정과 같은 방법으로ORB Operation 을 수행을 한 후 그 수행 시간을 측정하였다 .

나.EIOP 프로토콜 수행 대기시간

본 과제에서 설계한 내장형 실시간 미들웨어에서는 줄어든 메시지의 양이 부분적으 로EIOP 메시지를 실행할 때의 부담 (marshaling , unmarshaling 을 포함 ) 으로 작용 한다. 송신자 측면에서 본 프로토콜 실행 부담은 invocation stub, CAN 디바이스 드라이버, 82527 CAN 컨트롤러의 실행시간으로 측정하였다 . 수신자 측면에서 봤을 때는CORBA 함수를 호출하는 첫번째 CAN 메시지와 skeleton code 가 dispatch 되 는 시간 사이의 간격을 실행시의 부담으로 본다. 프로토콜의 수행 대기시간을 발행자(publisher) 와 가입자 (subscriber) 측면에서 측정 하였다.21 그림 에 측정 결과를 나타내었다 . 함수를 호출할 때의 프로토콜 수행 대 기시간은 매개변수가 증가함에 따라서 같이 증가한다는 것을 주목한다. 매개변수의 개수가고정되어있을때조차도대기시간은매개변수의값에따라서달라질수있 는데,CCDR 그 이유는 이 가변 길이 정수 인코딩 체계를 가지고 있기 때문이다 . 측 정 시에는 최악의 대기시간을 얻기 위해서 매개변수의 값에는 가장 큰 것을 사용하 였다. 그림21 에 나타나듯이 최악의 프로토콜 수행 대기시간은 매개변수의 개수가 적절히 작을 때(6 특별히 개인 경우 )1ms.6 에는 보다 작다 이 개의 매개변수의 개수는 실제 적으로 관심이 있는 대부분의 필드버스 응용 프로그램에서 전형적인 값이다. 더 중 요한 것은 순수한EIOP 수행 대기시간은 송신자 측면에서 본 전체 프로토콜 수행 대기시간 중 단지34.5% 만 차지하는 반면에 , CAN 디바이스 드라이버와 버스 어댑 터는 각각24.6% 와 40.9% 를 차지한다 . 측정값은 또한 EIOP 가 평균적으로 GIOP 메시지 양을37.5% 를 감소시킨다는 것을 보여준다 .

-196- 그림21: 프로토콜 처리 지연시간

(a) small value (b) large value

그림22: 프로토를 처리 지연 시간의 세부 구성 요소

-197- 다. 정적 메모리 요구사항

본 과제에서 설계한 내장형 실시간 미들웨어의 정적 메모리 요구량을 측정한다. ORB의 핵심적인 코드와 데이터 부분의 크기와 라이브러리의 크기를 합한 것을 정 적 메모리 요구량으로 본다.GNUglibV1.2.1 은 본 과제의 미들웨어와 ORBit 를 위 한 것이고,ACE 라이브러리는 TAOORB 를 위한 것이다 . 본 과제에서 설계한 내장형 실시간 미들웨어와GNU ORBit V0.4.3. 최소 TAO V1.0의 정적 메모리 요구사항을 GNU 유틸리티인 size 를 가지고 분석하였다 . 그림 23에 측정값이 나타나있다 . 이 값은 Intel 386 프로세서를 대상으로 한 GNU C 컴 파일러V2.8.1 을 가지고 세 개의 ORB 를 컴파일해서 얻었다 . 옵션으로는 -O3 -m386 -frepo를사용하였다 . i386 을대상으로한최소 TAO 와 ORBit 은 Redhat Linux 5.1에서 만들어진 반면에 , 본 과제의 미들웨어는 mArx 에서 만들어 졌다 . 표 7에서 TAO(spare) 은 Sun Spare 워크스테이션에서 실행한 TAO 의 메모리 크기를 나타낸다.

-198- 그림23: 본 과제의 I-PCTV 미들웨어와 ORBIT, TAO(i386), TAO(sparc) 의 정적 메모리 요구랑

표7: I-PCTV-CORBA 와 ORBit 모듈의 메모리 요구량

-199- 참고 문헌

[Alca 98-1] Alcatel et al. Joint Revised Submission: Minimum CORBA, OMG TC Document orbos/98-05-13, May 19, 1998. [Alca 98-2] Alcatel et al. Joint Revised Submission: Real-time CORBA, OMG TC Document orbos/98-12-10, December 30, 1998. [DAVIC 99] Digital Audio Video Council (DAVIC), http://www.davic.org, 1999 [ISI 96] Integrated Systems Inc., pSOSystem Programmer's Reference. Part Number 000-5078-001, March 1996 [OMG 98] Object Management Group, The Common Object Request Broker: Architecture and Specification, February 1998, Revision 2.2 [QSSL 96] QNX Software Systems Ltd., QNX, Operating System System Architecture, July 1996 [Sun 99] Sun Microsystems, Jini Connection Technology, http://www.sun.com, 1999

-200- iPCTV의를위한 GUI 멀티미디어 정보부호화 방식 연구

광운대학교

-201- 목차

제1 장서론

제2 장 기술 개발 내용 및 방법

제1 절 멀티미디어 정보부호화 방식 및 분산처리 기술 1. I-PCTV를 위한 멀티미디어 정보부호화 방식 조사 , 분석 2. I-PCTV를 위한 MHEG 엔진의 설계 3. CORBA 기술 및 표준화 동향 분석

제2CORBA 절 기반의 IIOP 클라이언트 엔진 개발 1. CORBA 상호 운용성 2. IIOP 엔진 설계 및 구현 3. IIOP 엔진의동작과정 4. IIOP 엔진 기능성 테스트

제3 절 상호 운용성 테스트 및 임베디드 운영체제로의 포팅 1. 상호 운용성 테스트 2. windowsCE 환경으로 포팅 3. VxWorks 환경으로 포팅

제장결과3

-202- 제1 장서론

다양한 멀티미디어 정보통신 서비스를 지원하게 될I-PCTV 개발에 있어 요구되는 여러 기술 요소 중에 사용자 편리성 및 접근용이성에 가장 큰 영향을 주게 될 GUI 방식은, 표현되는 멀티미디어 정보의 부호화 방식에 따라 여러 가지 형태로 제시될 수 있다., 그러므로 본 연구에서 조사 분석하게 될 멀티미디어 부호화 방식은 사용 자와I-PCTV 사이의 상호작용 및 정보표현에 직접적인 영향을 주는 주요한 기술요 소로서 방식 선택에 있어 매우 많은 연구가 요구되는 분야이다. 한편, 주문형 비디오 서비스나 Interactive TV 와 같은 멀티미디어 정보 서비스는 처 리되는 정보의 양과 실시간 전달 특성을 지원하기 위해 대용량의 저장 장치와 고속 의 통신망을 필요로 한다. 대량의 멀티미디어 정보를 통신망을 통해 분산시키고 이 들을 유기적이고 효율적으로 연결시키기 위해서는 분산처리 환경을 기반으로 하는 분산 플랫폼의 구축이 필요하다. 분산처리 환경은 이 기종 시스템,, 운영체제 플랫폼 상에서 동작하는 다양한 응용들 간의 상호 운용성(InteroperabiIity) 을 보장하기 위한 미들웨어로서 존재하며 , 기본적 으로 클라이언트-. 서버 형태의 구조를 갖는다 현재 공통의 객체 요구 중개자 (ORB, Object Request Broker)의구조를정의한객체처리기술표준인 CORBA(Common Object Request Broker Architecture)가 활발히 연구되고 있다 . CORBA버전 2.0 사양에서는 서로 다른 ORB 들간의 상호운용을 지원하기 위하여 GIOP/IIOP (General/Internet Inter-ORB Protocol)프로토콜을 정의하고 있다 . 상 호운용이란CORBA 사양을 따르는 서로 다른 ORB 들간에 공통의 메시지 형식과 통 신 프로토콜을 정의하여 상호 객체 참조 및 객체 서비스를 투명하게 제공할 수 있 도록 한 것으로서 클라이언트는 서비스 객체의 위치를 투명하게 서비스를 제공받을 수 있다. 본 연구에서는 다양한 대화형 멀티미디어 정보통신 서비스를CORBA 분산처리 환 경에서 지원하기 위한 기반기술을 조사 및 분석하였다..CORBA 또한 환경에서 상 호운용성을제공하기위해정의된IIOP 프로토콜엔진을구현하여 , Non-CORBA 플랫폼에 기반을 둔 운용들이CORBA 분산환경과 통합될 수 있는 분산 멀티미디어 환경을 제공하였다. 이를 위해 (1) I-PCTV 의 GUI 를 효율적으로 지원하기 위한 표 준화된 멀티미디어 정보부호화 방식 및 분산처리 기술을 조사,,(2) 분석하고 CORBA기반의 IIOP 클라이언트 엔진을 개발하고 , (3) IIOP 엔진의 상호 연동성을 시험하기 위한 환경을 구축하고,IIOP 개발한 클라이언트 엔진을 임베디드 운영체 제인WindowsCE 와 VxWorks

-203- 제2 장 기술 개발 내용 및 방법

제1 절 멀티미디어 정보부호화 방식 및 분산처리 기술

본 연구에서는 다양한 대화형 멀티미디어 정보통신 서비스를CORBA 분산처리 환 경에서 지원하기 위한 기반기술을 조사 및 분석하였으며, 대표적인 멀티미디어 정 보부호화 방식인MHEG 엔진을 설계하였다 .

1. I-PCTV를위한멀티미디어정보부호화방식조사분석 , 다양한 멀티미디어 응용들을 상호 동작하게 하여 분산 컴퓨팅의 장점을 실현하기 위해서는 멀티미디어 정보의 공통 부호화 방식이 필요하다. 이러한 필요성을 바탕 으로MHEG,XML,SMIL,PREMO,HyTime, 등 국제 표준화 기구 및 산업계 등에 서는 다양한 정보부호화 방식을 제안하고 있다.I-PCTV 본 연구에서는 와 갈은 멀 티미디어 정보서비스의 사용자 인터페이스를 지원하는 다양한 부호화 방식에 대하 여 조사,. 분석하였다

(1)MHEG MHEG(Multimedia Hypermedia information Export Group)은 멀티미디어 및 하이 퍼미디어의 정의,, 부호화 원칙 시스템 요구사항 , 객체 클래스를 이용한 부호화 표 현들을 목적으로ISO/IEC JTC1 SC29/WG12 에서 표준화 작업을 수행하고 있다 . MHEG은 여러 미디어들을 추가적인 처리 없이 직접 상호 교환하거나 프리젠테이션 하는 것을 가능하게끔 부호화하는데,MHEG 이를 최종형태의 부호화 표현이라고 한다., 또한 멀티미디어 프리젠테이션을 위해 미디어들 간에 시 공간적인 관계를 기 술할 수 있는 자료구조를 제공하며 사용자와의 단순한 형태의 상호작용도 지원한 다. SC29/WG12 MHEG 에서는 멀티미디어 및 하이퍼미디어 정보 부호화에 관련된 표준화 작업을 다음과 같아 구분하여 수행하여 왔으며 현재 각 부분에 대한 표준화 작업이완료또한진행중이다.

• ISO/IEC 13522-1 : MHEG Object Representation, Base Notation(ASN.1) • ISO/IEC 13522-3 : MHEG Script Interchange Representation • ISO/IEC 13522-4 : MHEG Registration Procedure • ISO/IEC 13522-5 : Support for Base Level Interactive Applications • ISO/IEC 15522-6 : Support for Enhanced Interactive Applications • ISO/IEC 13522-7 : InteroperabiIity and Conformance Testing for ISO/lEC 13522-5

-204- (2) SGML, XML및 SMIL 1) SGML SGML(Standard Generalized Markup Language)은 일반화된 마크업의 한 예이다 . 이것은 국제적인 표준(ISO 8879:1986) 으로 , 1986 년 최초로 공개되었다 . SGML 은 간단하고,.SGML 플랫폼에 독립적이며 유연한 마크업 설계안을 제공한다 은 항공기 유지보수 지침서에서 스텔스 폭격기의 기술문서에 이르기까지, 그리고 환자의 병원 기록부터 음악악보 표시까지, 인간행동의 많은 영역에서 사용되는 다양한 문서타입 을 기술하는데 쓰이는 언어이다. SGML은 사용자들에게 각자의 요소형을 선언할 수 있는 수단을 제공함으로써 사용 자에게 힘을 준다.SGML 따라서 은 메타언어로 설명되는 것이 쉽다 .SGML 의 유연 성은사용자들로하여금각문서에서허용된것을정의하게할수있는문서형정 의(document type definition) 흑은 DTD 로 알려진 규칙 집합을 제공함으로써 이루 어진다.

2) XML XML(Extensible Markup Language)은 1996 년 W3C 의 후원으로 형성된 XML Working Group에 의해 개발되었다 . 설계목표는 웹 사용자에게 강제적으로 HTML 태그를사용하는대신에자신이원할때자신만의태그와속성을정의할수있는 수단을 제공하는 것이다.HTML 보통 마크업 언어는 의 예에서 보듯이 정보를 문서 들의 특정한 클래스로 표현하는 방식을 정의한다.XML 을 이용하면 자신만의 독특 한 마크업 언어들을 정의할 수 있게 되므로 문서를 다양한 클래스들로 표현하는 것 이가능하다이는. XML 이 SGML, 즉마크업언어를위한국제표준메타언어로쓰 여졌기 때문이다. XML 은 ‘XML 문서들 ’ 이라 불리는 데이터 객체들의 집합을 설명하 고 부분적으로XML 문서들을 처리하는 컴퓨터 프로그램들의 행위에 대해 기술한 것 이다. XML 은 SGML 의 응용 또는 제한된 형식의 SGML 이다 . 구조적으로 XML 문서 들은SGML 문서들의 특징을 따른다 . 이러한 XML 은 XML- 언어 , XML- 링크 , XML- 스 타일 그리고XML- 처리기로 구성되어 있다 .

-205- • XML-언어 유효성을 위한XML 의 요구 사항을 만족시키는 XML 문서는 그 스스로를 설명하고 있다고 말할 수 있다.XML 모든 유효한 문서는 특별한 헤더 정보로 시작한다 . 이러 한 헤더 정보(DTD 로 알려진 ) 에는 XML 문서를 처리하려고 하는 소프트웨어를 돕는 선언들이 정의되어 있다.XML 또한 그것은 문서가 유효화 되도록 해준다 . 이러한 XML언어는 명확한 표현을 위해 간단하고 명료한 문법을 이루고 있다 .

• XML-링크 98년 3 월 , 이전에 XLL(Extensible Linking Language) 이란 이름의 XML 링킹과 포인 팅/ 어드레싱 메커니즘을 W3C 가 새롭게 XLink 라는 이름으로 발표하였다 . XML 의 하 이퍼링크 기능은 기본적인HTML 스타일의 하이퍼링크를 여러 가지 새로운 면에서 능가한다. 자바스크립트 코딩 같은 힘든 수작업 없이도 스마트 링크를 생성할 수 있다. XLL 의 본래 스펙은 Xpointer 와 Xlink 스펙으로 다시 분리된다 . Xlink 는 구조를 생성하기 위해XML 문법을 사용하므로 HTML 과 같은 단순한 한 방향의 링크뿐만 아니라 보다 다양한 형태의 링크와 멀티 엔드 링크를 기술할 수 있다. Xpointer 는 XML문서의 내부구조로 번지지정을 할 수 있도록 도와주는 구조설계에 사용된다.

• XML-스타일 XML은 내용을 표현과 분리하므로 웹 설계자들은 디자인 , 디스플레이 , 출력을 제어 하는 방법을 모색해야 한다..XML 스타일 시트가 그 해답이다 현재 과 같이 사용될 수 있는 스타일 시트에는 세 가지 타입이 있다. CSS(Cascading style sheets)는 개발자들이 여려 웹페이지들의 스타일과 레이아웃 을한번에제어할수있게해준다.CSS 는템플릿처럼작용해웹개발자들이 HTML 요소를 위한 스타일을 정의하고 그것을 웹페이지들에 적용할 수 있도록 해준다. CSS를이용하면변화를주고싶을때딘지스타일만변경시키면그요소가사이트 안에 나타날 때마다 자동적으로 업데이트된다. DSSSL(Document Style Semantics and Specification Language)은문서트리변 환 언어이며 스타일 언어이다. CSS 가 전문적인 출판에 적합하지 못한 반면 DSSSL 은SGML 은 사용하는 전문적인 출판업자들이 많이 사용한다 . 그러나 DSSSL 은 복 잡하며 웹에서는 거의 사용하지 않는다는 약점을 지닌다. 마지막으로 XSL(Extensible Stylesheet Language)은 W3C 에 NOTE 으로 제출되어 있으며 웹상 에서XML 데이터와 문서들을 포맷하기 위해 제안되었다 . XML 은 선언적인 구조들 ( 태 그) 과 스크립트를 조합함으로써 광범한 사용자층에게 사용될 수 있도록 설계되었 다.

-206- • XML-처리기 XML언어 규약 (XML Language Specification) 은 XML 처리기 (XMLprocessor) 라고 불리는 것이 어떻게 수행되어야 하는가를 서술하고 있다.XML 처리기는 XML 문서 를 읽고,. 문서가 유효하고 잘 구성된 것인가를 검사하는 프로그램이다

XMLSGMLDTD은 과 를 사용하는 점을 비롯해서 많은 부분에서 서로 비슷한 특징 을 보이고 있다. 그러나 SGML 과 XML 은 차이가 있다 . XML 은 SGML 의 복잡한 개념 을 축소화 하였으며,SGML 에는 없거나 미약했던 부분을 여러 부분에서 수정 보완 했다. XML- 링킹 (XLL) 과 XML- 스타일 (XS) 이 이에 해당된다 . 그림 1 은 SGML 과 XML 의 관계를 표현하고 있다.

그림1. SGML 과 XML 의 관계

3) SMIL SMIL(Synchronized Multimedia Integration Language)은 W3C Synchronized Multimedia(SYMM)작업 그룹에 의해 제안된 XML 의 응용이다 . 이 언어의 목적은 서로 다른 멀티미디어 객체들을 동기적으로 맞추어 표현하기 쉽게 하려는 것이다. HTML같은 Markup 언어들은 웹상에서 멀티미디어 데이터를 표현하고 전송하는데 적합하지 않다.SMIL 은 시간에 대한 멀티미디어 동기화를 가능하게 한다 .SMIL 문 서는HTML 과 같이 단순한 텍스트 에디터를 사용하여 작성할 수 있다는 것이다 . 따 라서 멀티미디어를 만드는 사람들은 복잡한 스크립트 언어를 배우지 않아도3 개의 단순한SMIL 요소를 이용하여 멀티미디어 정보를 표현할 수 있다는 것이다 . 1998 년615RFCSMIL1.0 월 일에 이 발표된 이후로 현재 SMlL 에 대한 발전은 급속도로 이루어지고 있다.

-207- (3) PREMO (Presentation Environment for Multimedia Objects) PREMO는 멀티미디어의 부호화 , 전송 , 또는 하이퍼미디어 , 문서형식 등과는 다른 멀티미디어 표현과 프로그래밍 툴에 중점을 두는ISO/IEC JTC1/SC24 WG6 에 의 해 추진되고 있는 표준이다.PREMO 의 주요한 특징은 다음과 같다 .

• PREMO는 표준 프로그래밍 환경을 제공하는 것을 목표로 하는 표현 환경이다. PREMO는표현기술에중점을두고있다는점이다 . • 초기SC24 표준은 합성 이미지나 이미지 처리 시스템에 중점을 두고 표준화 작 업이 진행되었으나,. 현재는 멀티미디어 표현을 목표로 하고 있다 또한 고 수준의 가상현실 플랫폼 기술도PREMO 의 범위에 있다 .

• PREMO는객체지향적이다 .

PREMO는 현재 4 개의 부분으로 구성된다 . 구조적으로 PREMO 는 프로파일로 세분 되는 구성요소로 이루어진다. 구성 프로파일은 객체들과 비객체들이 실체가 될 수 있는 객체 형태들과 비객체 데이터 형태들의 모음이다. 프로파일은 특정 응용 영역 에 맞게 조정된 여러 객체들의 가능한 조합으로 구성된 표준의 일부분을 정의한다.

• Part1 : Fundamentals of Premo PREMO의 범위 , 정의와 핵심 개념에 대한 설명을 한다 . 전체적인 구조를 기술하고 있으며,PREMO 구현에 독립적인 방법으로 객체들의 외부에 보여지는 특성들을 정 의하기 위한 일반적인 의미들을 열거하고 있다.

• Part2 : Foundation component 멀티미디어 정보의 제작, 표현 및 상호작용을 위해 유용한 객체 형태들과 비객체 형태들의 초기 집합을 열거한다. 모든 구현은 이러한 객체 형태들을 지원해야만 한 다.

• Part3 : Modeling, presentation, and interaction component 추상 컴포넌트이며 모델링,, 구조 미디어 제어를 조합한다 . 실제 모델링과 표현요소 들이 이로부터 유도된다.

-208- • Part4 : Multimedia system services 분산환경에서 동기화, 시간 종속적인 미디어들을 다루는 상호 작용적 응용들을 지 원하는 컴퓨팅 플랫폼을 만들기 위한 기반을 제공한다.

현재PREMO 는 가상 현실 , 3D 오디오 , MHEG 엔진의 구현을 포함하는 새로운 구 성 요소들을 정의하기 위한 활동을 하고 있다.

(4) 기타 부호화 방식 SMSL(Standard Multimedia/Hypermedia Scripting Language)은 ISO/IEC JTC1/SC18/WG8에서 작업중인 멀티미디어 스크립트 언어의 표준이다 . SMSL 은 객 체지향모델(object-oriented model) 로 기술되는데 , 객체의 데이터 구조 및 관계는 HyTime을 이용하고 , 객체에 적용되는 동작 방식만을 추가로 정의한다 . SMSL 은 소 스언어와 구문, IL(Intermediate Language), SMSL 스크립트를 사용하는데 필요한 서비스 등의 세 요소를 포함한다.IL 은 시스템의 플랫폼에 독립적이며 ,IL 형태의 스크립트는 이식이 용이하므로 기존의 소프트웨어 툴을 사용하는 플랫폼에서 스크 립트를 처리할 수 있다. QuickTime은 애플사의 매킨토시 시스템 소프트웨어인 시스템 7 의 확장판으로 시스 템에서 멀티미디어 정보의 디스플레이, 압축 , 편집 등을 가능하게 한다 . QuickTime 은 멀티미디어 정보를 저장하기 위하여QMF (QuickTime Movie File) 라는 화일 형 식을 사용한다.QMF 는 프리젠테이션 중 다른 시간에 시작되고 끝나는 여러 트랙 (track)들로 구성되는데 Movie Manager 를 이용하여 트랙들의 플레이를 동기시키고 모든 정보가 정확한 시간에 화면에 나타나거나 사운드 처리 장치에 보내질 준비가 되었는지를 확인한다. 트랙은 시스템이 그 미디어를 플레이 시키고자 하는 시간과 미디어에 대한 포인터의 목록을 지니고 있다.QuickTimePlayer 현재 는 몇몇 다른 플랫폼에서 이용이 가능하다. HyTime은 SGML 을 이용한 하이퍼미디어 문서 표현을 위한 ISO 표준이다 . HyTime 은 하이퍼 링크를 이용하여 문서 객체들을 연관시키고 시간, 공간 좌표계에 따라 문서 객체들을 상호 연관시킨다.SGML 파서에 의해 파싱된 HyTime 문서는 HyTime엔진에 의해 해석되고 표현된다 .

-209- OMFI(Open Media Framework Interchange)는 멀티미디어 상호교환 형식과 공통 골격을 정의하기 위하여Avid Technology 사에 의해 주도되고 있는 산업 표준이다 . OMFI모델은 애플 컴퓨터사의 Bento 형식을 이용하여 부호화 된다 . Bento 형식은 화일안에저장된상호연관관계가있는객체를표현하는범용구문이다.OMFI 는 QMF와 유사하게 오디오 , 비디오와 같이 시간축 상의 동기화가 중요시 되는 미디어 들을 표현하는데 가장 초점을 두고 있으며 객체들 간의 동기화를 위해 기능을 확장 시킨 트랙 모델을 사용한다.OMFI 는 비디오 테이프나 필름 같은 소스를 표현하기 위해MOBs(OMFl Media OBjects) 라는 객체를 제공한다 . 교환 형식에 소스를 식별 하기 위한 정보를 포함시킴으로써 재디지탈화(redigitization) 가 필요할 때 원본 소 스들을 재사용할 수 있다.

2. I-PCTV를 위한 MHEG 엔진의 설계 MHEG엔진은 MHEG 객체를 시스템이 인식할 수 있는 자료 구조로 변환하고 이를 해석하여 객체들간의 동기화 관계 및 링크 관계를 해석한다. 또한 표현 모듈을 통 해 사용자에게 해석된 정보를 표현하거나, 표현 모듈을 통해 전달 받은 사용자의 입력을 처리해 주는 기능을 수행한다.2MHEG 그림 는 엔진의 기능모듈을 도시한 것이다.

(1) 객체 관리자 부호화된MHEG 객체들을 내부 자료 구조로 변환하며 MHEG 엔진상에 존재하는 객체들을 관리한다. 이를 위하여 객체 관리자는 객체 테이블을 두어 객체에 관한 여러 상태값과 속성값 등을 기록한다. 그리고 Visible 객체들의 정확한 표현을 위해 Display스택에 관한 정보도 관리한다 .

그림2. MHEG 엔진의 기능 모듈

-210- 여러 기능 모듈들로부터 객체의 속성에 관한 질의가 들어오면 객체 테이블에서 해 당 정보를 검색하여 알려주며,Action 처리 모듈에서 객체에 대한 행위를 적용하는 경우, 객체 관리자는 객체 테이블에서 해당 객체의 테이블 포인터를 전달한다. 객체 가 시스템 내부에 존재하지 않는 경우는 통신 시스템을 호출하여 해당 객체를 전송 하도록 한다.

(2) 인터프리터 객체들이 가지고 있는 정보를 해석하여 동기화 기능을 수행하고 해석된 정보를 표 현 모듈을 통하여 사용자에게 표현한다. 또한 표현 모듈을 통해 사용자와의 상호작 용 기능을 수행한다.Event 이 기능을 수행하기 위해 인터프리터는 내부적으로 처 리모듈, Action 처리모듈 , Application 관리모듈 , Connection 관리모듈로구성 되며,. 이들이 상호 작용하여 객체 해석 과정이 이루어진다

1) Event 처리 모듈 시스템에서 발생하는 여러event 를 수신하고 , 이를 바탕으로 링크 조건을 검사한 다.Event 의 발생은 객체에 어떤 행위를 가한 경우 , 타이머가 종료된 경우 , 사용자 가 객체에 대하여 상호 작용을 가한 경우에 발생한다. 링크 조건과event 는 각각 세 가지 정보 (Event Source, Event Type, Event Data) 를 가지고 비교되는데,. 세 가지 정보가 모두 같을 때에만 링크 조건이 만족된다 링 크 조건이 만족되면 링크 효과에서 기술된Action 객체를 Action 처리 모듈이 처리 하도록 한다.

2) Action 처리 모듈 Event처리 모듈로부터 Action 객체의 처리가 요구되면 Action 객체의 단위 행동 (Elementary Action)들을 순서대로 처리한다 . Event 처리 모듈로부터 단위 행동들 을 수신하기 위해Action 큐가 필요하며 , 단위 행동의 수행시 객체 관리자로부터 행위의 대상이 되는 객체의 테이블 포인터를 얻어온다. 객체 테이블은 객체 관리자 가 관리하는 테이블로,.Action 객체들의 여러 속성이나 상태값이 기록되어 있다 처 리 모듈은 얻어온 객체 테이블상의 여려 값과 단위 행동의 인자를 비교하여 행위를 적용시킬 것인가에 대한 판단을 한다. 예를 들어 객체가 활성 상태인 경우에 활성 화 행위가 적용되면 이는 무시된다.Action 처리 모듈은 처리해야 할 행위의 형태 에따라표현모듈, Connection 관리모듈 , Application 관리모듈 , Event 처리모 듈, 객체 관리자 등을 적절히 호출한다 . 또한 Presentable 객체의 표현에 관한 행위 처리 시 표현 모듈을 통해 이를 사용자에게 표현한다.

-211- 3) Application 관리 모듈 Application관리 모듈은 응용의 전환을 관리하기 위한 부분이다 . Application관리 모듈은 ‘Spawn' 행위 처리 시 현재 응용에 관한 정보를 저장하거 나 새로운 응용이 종료 시 이전 응용으로 복귀하는데 필요한 정보를 읽어오는 기능 을 수행한다. Application Identifier 스택에는 복귀되어야 할 응용들의 순서를 기록 한다.

4) Connection 관리 모듈 Connection관리 모듈은 ‘OpenConnection' 행위에 의해 연결된 새로운 name space와의 접속을 관리한다 . 외부와의 접속은 통신 시스템을 이용하며 , 접속 설정 시 새로운name space 에 관련된 정보를 Connection 테이블에 기록하여 이를 관 리한다.

(3) 표현 모듈 표현 모듈은 인터프리터의 요구에 의해 사용자에게 미디어를 표현하거나 사용자와 의 상호 작용을 처리한다. 미디어 데이터가 참조 되어있는 경우 파일 시스템이나 통신 시스템을 이용하여 해당 미디어 데이터를 전송 받아 표현한다. 이때 표현되는 각Presentable 객체들은각각 Display Stack 의한층을차지하게되며 Display Stack에서의 위치를 바꿈으로써 중첩된 부분에 대한 다양한 처리가 가능하다. 표현 모듈은 텍스트,,,, 오디오 그래픽 이미지 동화상 등을 화면에 출력하기 위한 모듈과 사용자 인터페이스,. 사용자 입력 처리 모듈로 구성된다

3. CORBA 기술 및 표준화 동향 분석 CORBA(Common Object Request Broker Architecture)는분산컴퓨팅기술과객 체 지행 기술을 접목시킨 객체 지향 분순 컴퓨팅 기술에 관한 대표적인 산업계 표 준으로서, 여러 회사들로 이루어진 컨소시엄 형태의 OMG(Object Management Group)라는 비영리단체에서 업무를 맡고 있다 . 1989 년 HP, SUN, Unisys 등 8 개 회사들로 발족한 이 단체는 현재 전세계700 개 이상의 전산분야 회사들이 가입하 여 가장 큰 소프트웨어 분야의 컨소시엄으로 발전하였다.OMG 는 다양한 전산 환 경에서상호연동하는객체지향분산시스템구축기술및표준을제공하는데그 목적이 있다.

-212- 1991년에 발표된 CORBA 1.1 은 객체 간의 인터페이스를 위한 IDL(Interface Definition Language)과 클라이언트 , 서버 객체들간의 API(Application Programming Interface)를 정의하고 있다 . 1994 년 12 월에 발표되고 1995 년 12 월 에 개정된CORBA 2.0 에서는 여러 업체에서 개발한 다양한 CORBA 미들웨어들 간 의 클라이언트- 서버 컴퓨팅을 지원하는 GIOP/IIOP(General Inter-Orb Protocol/Internet Inter-Orb Protocol)사양이 추가되었다 . 또한 CORBA 와 OSF DCE환경 , CORBA 와 OLE/COM 환경간의상호연동을지원하기위한사양들이정 의되어 있다. 이후에 IDL 과 JAVA 언어 매핑 사양 , POA(Portable Object Adaptor) 사양,199910CORBA/IIOP2.3 컴포넌트 개념 등이 추가되면서 년 월에 표준이 발 표되었으며,3.0 현재 에 대한 표준화 작업이 진행 중이다 . 이종의 네트웍,, 컴퓨터 운영체제 , 플랫폼 상에 존재하는 여러 분산객체들 간의 상 호연동을 지원하기 위한 분산처리환경 구조로서OMG 는 OMA(Object Management Architecture)를 정의하였다 . OMA 의 구성은 그림 3 과 같이 ORB(Object Request Broker),객체 서비스 (Object Services), 공용 기능 (Common Facilities), 도메인 인 터페이스(Domain Interfaces), 응용 객체 (Application Objects) 등 5 개의 요소로 이루어진다.

그림3. OMA 구조

-213- ORB는 OMA 구성 요소들을 연결해 주는 객체 버스 (Object Bus) 역할을 담당하며 , 객체 서비스는 시스템 수준의 공통 기능들의 집합으로서ORB 의 기능을 강화한다 . 객체 서비스는 현재15 가지 서비스에 대한 표준이 정의되어 있는데 , 각 서비스의 이름은 Naming, Event Management, Persistent Object, Concurrency, Externalization, Relationships, Transaction, Query, Licensing, Property, Time, Security, Trading Object, Collection서비스 등이다 . 공용 기능은 분산 응용들이 공통으로 요구하는 기능들의 묶어 놓은 집합이며, User Interface, Information Management, System Management, Task Management등 4 가지 기능에 대한 표 준이 정의되어 있는 상태이다. 도메인 인터페이스에 관한 표준은 현재 작업이 진행 중인 상태이며 아직 정식 표준으로 정의된 것은 없다.CORBA 응용 객체는 분산 객체가 아닌 일반 응용들을CORBA 분산환경으로 통합하기 위한 인터페이스를 정 의하는 표준으로 역시 작업이 진행 중에 있다. OMA구조의 근간이 되는 ORB 의 구성은 그림 4 와 같으며 , 각 구성요소에 대한 사 양들이 모여CORBA/IIOP 표준을 구성하고 있다 . CORBA 분산환경 하에 존재하는 모든 객체들의 통신은ORB 를 통해서 이루어지며 ORB 는 다양한 인터페이스 호출 방법을 제공하여 응용 객체들에게 최대한의 융통성을 보장한다. 현재OMG 산하의 여러 TF(Task Force) 및 SIG(Special Interest Group) 에서는 실 시간 응용 지원,,SecurityCORBA 멀티미디어 정보 처리 등을 분산환경에서 지원 하기 위한 다양한 표준화 작업을 진행하고 있다.

그림4. ORB 구조

-214- 제2 절 CORBA 지반의 IIOP 클라이언트 엔진 개발 본 연구에서는CORBA 환경에서 상호운용을 위해 OMG 에서 정의한 IIOP 프로토콜 을 엔진을 구현하여,Non-CORBA 플랫폼에 기반을 둔 응용들이 CORBA 분산환경 과 통합될 수 있는 분산 멀티미디어 환경을 제공하였다.

1. CORBA 상호 운용성 비록CORBA 는 여러 회사들의 표준 시스템 통합기술이지만 이 표준을 구현한 제품 들은 각기 다른 구현 방법을 사용하고 있으며,CORBA 실제 를 다양한 분야에서 사 용할 경우 여러 종류의CORBA 제품을 사용할 수도 있다 . 이러한 상황에서 가장 필요한 기술은 서로 다른CORBA 제품들 간의 상호 연동과 다른 외부 서비스들과 의 상호 연동 기술이다.CORBA 상호연동이란 클라이언트 객체가 ORB 종류나 프 로토콜에 상관없이 모든 구현 객체를 이용할 수 있게 해주는 기술을 의미한다. 그 림5,ORBAORBB 에 도시한 바와 같이 에 존재하는 클라이언트가 에 존재하는 구 현객체의 메소드를 호출할 수 있게 해주는 기능이다.CORBA 이를 위하여 표준 2.0에서는 그림 6 과 같은 ORB 간의 상호연동을 위한 프로토콜 구조와 ORB 간의 상 호 연동 구조를 정의하였다.ORB 또한 서로 다른 에서 생성된 객체들을 식별하기 위한 표준 객체 참조자 양식으로IOR(Interoperable Object Reference) 를 정의하였 다. 그림6 에서 GIOP(General Inter-ORB Protocol) 는 서로 다른 ORB 사이에 상호연 동하기 위한 표준으로CORBA 상호운용에 필수 요소이며 , 이를 TCP/IP 상에서 구 현한 것이IIOP(Internet Inter-ORB Protocol) 이다 . ESIOP(Environment-Specific Inter-ORB Protocol)는 DCE(Distributed Computing Environment) 와 같은 특정한 분산 서비스 시스템들과의 호환성을 제공하기 위한 프로토콜이다.

그림5. CORBA 상호 연동

-215- (1) ORB간상호연동구조 CORBA표준사양에서는 서로 다른 ORB 사이에 상호 연동하기 위해 CORB 브리지 를 사용한다.ORB 브리지는 내부에 직접 전송 모듈을 추가하여 ORB 간에 직접적인 통신을 지원하는 인- 라인 브리지 (in-line bridge) 와 ORB 에서 제공하는 API 를 사용 하여ORB 간의 통신이 이루어지는 요청 - 수준 브리지 (request-level bridge) 가 있다 . 요청-SIIDIIORB 수준 브리지에서 클라이언트는 나 를 사용하여 다른 에 존재하는 구 현객체를 마치 자신의ORB 에 존재하는 구현객체처럼 호출한다 . 이 호출은 DSI 를 사용하는 양쪽ORB 사이의 브리지를 통하여 전달된다 . 그림 7 에 인 - 라인 브리지와 요청-. 수준 브리지의 구조를 도시하였다

그림6. CORBA 2.0 상호운용 명세 구조

(a)인라인브리지 -

(b)요청 - 수준 브리지 그림7. ORB 브리지

-216- 위에서 설명한 브리지를 사용하여 다양한 규모의CORBA 응용 시스템을 구축할 수 있으며,CORBA 에서는 이를 위하여 CORBA 도메인이라는 개념을 정의하였다 . CORBA도메인은 다양하며 , 관리적인 측면이나 , ORB 의 종류 , 네트워크 프로토콜 , 서비스 등 용도와 목적에 따라 구분된다., 또한 동일 회사의 ORB 제품일지라도 설 치되는 도메인이 다르면 서로 연동시키는 메커니즘이 필요하다. 따라서 도메인을 구성하려면 브리지를 사용해서ORB 시스템들간에 네트워크를 구성해야 한다 . CORBA표준에서는 브리지를 사용하여 도메인을 연결하는 방법으로 직접 - 브리징 (Immediate Bridging)과 중간 - 브리징 (Mediate Bridging) 을 정의 하였다 . 직접 - 브리 징 방법은 그림8-(a) 와 같이 각 도메인을 그물처럼 연결하여 한번의 브리징 과정 을 거쳐 두 도메인을 연결한다. 중간 - 브리징은 백본 - 브리징 (Backbone Bridging) 이 라고도 불려 우며,8-(b) 그림 와 같이 중간에 통일된 백본 프로토콜을 위치시켜 두 번의 브리징 과정을 통하여 두 도메인을 연결한다.

(a)직접 - 브리징

(b)중간 - 브리징

그림8. 브리징 방법

-217- (2) GIOP(General Inter-ORB Protocol) GIOP는 서로 다른 ORB 사이들 사이에 상호연동하기 위한 표준으로 CORBA 표준 2.0에서 처음 정의되었으며 (GIOP 버전 1.0), CORBA 표준이 2.1, 2.3 으로 개정되 면서GIOP 표준도 1.1, 1.2 로 개정되었다 . GIOP 표준은 서로 다른 ORB 들이 통신 하기 위하여 교환하는 메시지 형태와 공통의 데이터 표현 방법 및GIOP 메시지를 전송하는 네트워크 전송 계층에 대하여 몇 가지 요구사항을 명시하고 있다.

1) 전송 계층에 대한 요구사항 GlOP 표준에서 명시하고 있는 전송 계층에 대한 요구 사랑은 다음과 같다.

• 연결 지향적인 전송 계층 GlOP는 요구 메시지 식별자 (Request ID) 의 범위와 정도를 정의하기 위한 서버와 클라이언트 사이의 연결(connection) 을 필요로 한다 .

• 신뢰성있는전송계층 전송 계층은 전송 도중에 바이트의 순서가 바뀌지 않음과 정확히 전달 되었음을 보 장하여야 한다.

• 바이트 스트림(byte stream) 지원 메시지의 크기에 제한이 없어야 하고 수신자는 연결을 연속적인 바이트 스트림으로 여기며, 분할 (fragmentation) 과 정렬 (alignment) 에 관여하지 않는다 .

• 고장에 대한 명확한 통지 연결에 이상이 생겼을 경우 명확하게 통지하여야 한다.

• 연결을 생성하는 방법은TCP/IP 의 일반적인 모델로 매핑이 가능해야 한다 .

GIOP 표준은 최소한의 요구 사항을 만족시키는 모든 연결 지향적인 전송 계층 프 로토콜위에서 동작하도록 디자인되었으며,GIOP 가 하부의 전송 계층의 연결을 사 용하는 방법은 다음과 같다.

-218- • 비대칭적인 연결 사용(Asymmetrical Connection Usage) GlOP는 연결을 사용하는 두 주제로 클라이언트와 서버를 정의하였다 . -:클라이언트 연결 생성 및 연결을 통한 요구 전송 . -:서버 요구 수용 및 응답 전송 .

• 요구 다중화(Request Multiplexing) ORB내의 여러 클라이언트가 하나의 연결을 공유할 수 있으며 , 이러한 경우 , 각 요구는목적객체를고유하게식별하여야하며하나의객체에또는서로다른객, 체에 대한 요구는 같은 연결로 보내질 수 있다.

• 요구 중복(Overlapping Requests) GlOP는 고유한 요구 / 응답 식별자를 사용한다 .

• 연결 관리(Connection management) GlOP는 요구 취소와 연결 종료를 위한 메시지를 정의하였다 .

2) CDR(Common Data Representation) 서로 다른 환경에 존재하는ORB 를 상호 연동하기 위해서는 서로 다른 데이터 표현 방법을 사용하는ORB 사이에 상호 인식이 가능한 데이터 표현 방법이 있어야 한 다.GlOP 이를 위하여 표준에서는 공통의 데이터 표현 방법으로 CDR 을 정의하였 다. CDR은 모든 OMG IDL(Interface Definition Language) 데이터 타입들에 대한 공통 의 전송 구문으로,.ORBOMG 이진 구조를 사용하여 데이터를 표현한다 의존적인 IDL데이터를 상호 인식이 가능한 CDR 로 변환하는 과정을 마샬링 (marshaling) 이라 하며, 그 반대의 과정을 언마샬링 (unmarshaling) 이라 한다 . 마샬링은 ORB 의존적 인 데이터를 상호인식이 가능한 공통 구문으로 인코딩하는 것이며, 언마샬링은 반 대로 디코딩하는 것이므로,, 본 보고서에서는 마샬링과 인코딩을 언마샬링과 디코딩 을 같은 의미의 용어로 사용하겠다.

CDR의 특징은 다음과 같다 . • big-endian과모두지원 little-endian CDR로 인코딩된 데이터는 데이터의 바이트 순서를 표시하는 꼬리표를 사용하기 때 문에, big-endian 과 little-endian 을 모두 지원한다 . 또한 클라이언트와 서버가 서로 다른 바이트 순서를 사용하더라도 메시지 수신측에서 바이트 교환(byte swapping) 을 하면 되기 때문에,GIOP 메시지를 생성할 때 상대편의 바이트 순서를 신경 쓰 지 않아도 되는 장점을 제공한다.

-219- • 바이트 정렬(byte alignment) CDR은 단순 데이터 타입의 데이터를 규칙적으로 정렬시킨다 . 즉 , 대부분의 시스템 에서 그러하듯이,short 형의 데이터는 2 바이트 ,long 형의 데이터는 4 바이트 , double형의 데이터는 8 바이트를 사용하여 데이터를 해당하는 바이트의 배수 자리 에 정렬시킨다., 비록 배수로 정렬하기 위한 패딩으로 인한 자원 낭비가 초래되지만 보다 효율적이고 밀도 있는 인코딩과 디코딩을 제공하므로 장점이 더 크다.

• CDR로 인코딩된 데이터 스트림은 그 자체만으로는 식별 불가능 CDR로 인코딩된 데이터 스트림은 그 자체만으로는 포함된 데이터를 식별하자 못한 다. 예를 들어 , long 형의 데이터와 double 형의 데이터가 연속으로 인코딩되었다 면,16.4long, 인코딩된 데이터의 크기는 바이트이다 첫 바이트는 형의 데이터이며 다음4 바이트는 바이트 정렬을 위한 패딩이고 , 마지막 8 바이트는 double 형의 데 이터이다. 이 16 바이트 스트림을 수신한 수신자가 이 스트림이 long 형과 double 형의 데이터가 인코딩되어 있다는 정보를 알지 못한다면 이 스트림을 디코딩할 수 없다., 왜냐하면 데이터 타입이 무엇인지 , 패딩이 되었는지 안되었는지 모르기 때문 이다. 따라서 송신자와 수신자 사이에는 교환하는 데이터에 대한 정보에 대한 동의 가 선행되어야 한다.

3) GlOP 메시지 GIOP버전 1.0 에서는 7 개의 메시지를 정의하였으며 , 버전 1.1 에서는 Fragment 메 시지를 추가로 정의하였으며, 버전 1.2 에서는 CloseConnection 메시지를 클라이언 트도 생성할 수 있게 하였다.. 또한 상위버전은 하위버전과 호환성을 유지한다 GIOP메시지 종류를 표 1 에 도시하였다 . 또한 , GIOP 메시지는 모든 GIOP 메시지 에 공통인GIOP 헤더와 각 메시지별로 고유한 메시지 헤더 및 메시지 몸체로 구성 되며,9 이를 그림 에 도시하였다 .

GlOP헤더는 5 개의 필드를 가지며 그 의미는 다음과 같다 . - magic:대문자 ‘G' 'I' 'O' 'P' 가 들어가며 , GIOP 메시지임을 나타낸다 . - version : GlOP버전을 나타낸다 . -byte-order:사용한 바이트 순서를 나타낸다 . - message type : GlOP메시지의 종류를 나타낸다 . - message size : GlOP헤더를 제외한 메시지 길이를 나타낸다 .

-220- 표1. GlOP 메시지 종류

메시지 종류 메시지 생성 주체 비 고 Request Client Reply Server CancelRequest Client LocateRequest Client LocateReply Server CloseConnection ServerGIOP 1.2 에서 Client or Server MessageError Client or Server Fragment Client or ServerGIOP 1.1 에서 추가

그림9. GIOP 메시지 구조

-221- • Request 메시지 Request 메시지는 클라이언트의 요구를 서버로 전달하는 메시지로 그 구조는 그림 9.Request6에 도시되어 있다 메시지 헤더는 개의 필드로 구성되며 그 의미는 다음 과 같다. - service context :특정 ORB 서비스에 필요한 데이터를 포함 . - request id :해당 요구 메시치를 별하는 고유한 식별자 . -responseflag:서버의 응답을 요구하는지 여부 . - object key :요구를 처리하는 서버 객체를 식별 . lOR 의 object key 와 동일 . - operation name :구동할 오퍼레이션 이름 . - Principal : BOA에서 사용하기 위한 client 식별자 . 현재 사용되지 않음 .

• Reply 메시지 클라이언트Request 메시지에 대한 응답으로 서버가 클라이언트로 전달한 메시지 로,9.Reply3 그 구조는 그림 에 도시되어 있다 메시지의 헤더는 개의 필드로 구성 되며 그 의미는 다음과 같다. - service context : Request메시지와 동일 . - request id :어느 Request 메시지에 대한 응답인지를 식별 . - status :응답 상태 ( 이상 유무 ) 를 나타냄 .

• CancelRequest 메시지 CancelRequest 메시지는 클라이언트가 자신의 요구를 취소하는 메시지로 더 이상 해당 요구에 대한 응답을 기대하지 않는다는 것을 서버에게 알린다. CancelRequest메시지 헤더는 어느 요구에 대한 취소인지를 식별하는 request id 필드만 갖는다.

• LocateRequest 메시지 LocateRequest메시지는 클라이언트가 생성하며 , 메시지에 포함된 객체에 대한 객 체 참조가 유한한지 여부와 현재 서버가 직접 해당 객체에 대한 요구를 처리할 수 있는지 여부 및 불가능하다면 어느 서버가 처리할 수 있는지에 대한 정보를 알기 위하여 서버로 전송한다. LocateRequest 메시지 헤더는 request id 필드와 어느 객 체에 대한 요구인지를 식별하는object key 필드를 갖는다 .

-222- • LocateReply 메세지 LocateRequest메시지에 대한 응답으로 서버가 생성하여 클라이언트로 전송하며 , 헤더로request id 필드와 요구에 대한 응답 상태를 나태는 locate_status 필드를 갖는다.

• CloseConnection 메시지 CloseConnection메시지는 GlOP 1.1 까지는 서버만 생생하였으나 , GlOP 1.2 에서는 클라이언트도 생성할 수 있게 되었으며, 클라이언트와 서버 사이의 연결을 닫을 때 사용한다.GlOP, 이 메시지는 메시지 종류를 식별하는 헤더로만 구성되며 메시지헤 더와 메시지 몸체는 없다.

• MessageError 메시지 MessageError메시지는 GlOP 메시지에 이상이 있을 경우 그에 대한 응답을 전송 되며, CloseConnectin 메시지와 마찬가지로 메시지 종류를 식별하는 GlOP header 로만 구성된다.

• Fragment 메시지 Fragment메시지는 GlOP 1.1 에서 추가된 메시지로 플래그 필드의 ‘the more fragments bit'가 TRUE 세팅되어 있는 요구나 응답 메시지에 뒤따라서 보내진다 . 즉,Request, 클라이언트가 메시지를 분할하여 보낼 경우 첫 번째 메시지는 플래그 필드의‘the more fragments bit’ 를 TRUE 로 세팅하여 보내며 , 나머지 메시지는 Fragment메시지로 전송한다 . 서버는 전체가 도착할 때까지 기다려 처리한다 . 클라 이언트는 분실된 메시지들 전부 보내기 전에Cancel Request 메시지를 사용하여 취소할 수 있다.

(3) IIOP(Internet Inter-ORB Protocol) lIOP는 GlOP 메시지를 TCP/IP 를 사용하는 인터넷을 통하여 전달하기 위해 필요한 프로토콜 프로파일을 정의하였다. IIOP 에서 정의한 프로파일은 lOR 에 포함되며 이 를 그림10 에 도시하였다 . IIOP 1.0 은 GIOP 1.0 을 지원하며 , GIOP 버전이 1.1, 1.2로 개정되면서 IIOP 역시 1.1,1.2 로 개정되었으며 ,GIOP 의 개정된 내용을 반영 하고 하위버전과의 호환성을 유지한다.

-223- 그림10. lOR 구조

IIOP는 IOR 에 TaggedProfile 형태로 포함되며 , Profileld 가 TAG_INTERNET_IOP 인 것이IIOP 프로파일이다 . IIOP 프로파일은 다섯 개의 필드로 구성되어 있으며 , 각 필드의 의미는 다음과 같다.

- iiop_version :자신이 처리할 수 있는 IIOP 버전을 의미한다 . - host :특정한 object 에 대한 위한 GlOP 메시지가 보내져야 할 인터넷 호스트를 식별한다.IP 주소와 호스트 이름이 모두 사용가능하며 , 인터넷 주소 A,B,C 클래 스를 사용가능하지만,D 클래스 주소는 사용할 수 없다 . -port:연결을 기다리고 있는 TCP/IP 포트 번호를 의미한다 . IIOP를 위한 'well known’ 포트가 아직까지 할당되어 있지 않다 . - object_key : IOR을 생성한 에이전트가 제공하며 , 클라이언트의 요구 메시지가 어느object 에 대한 것인지를 식별하는데 사용된다 . - components : TaggedComponent의 연속된 집합으로 해당 프로파일에 기술된 객체를 가동시킬 때 필요한 추가적인 정보를 포함한다.

2. IIOP 엔진 설계 및 구현 본 연구에서는IIOP 클라이언트 엔진을 개발하였다 . 효율적인 엔진의 개발을 위해 WindowsNT환경에서 동작하는 IIOP 엔진을 확보하는 작업을 선행하였다 . OMG의 회원사인 SunSoft 의 IIOP 프로토콜을 표준화 작업에 참여하면서 이를 구현 하였고,OMG 를 통하여 공개하였다 .SunSoft 의 IIOP 엔진은 GPL 라이센스를 갖는 공개 소프트웨어로 유닉스를 기반으로 구현되었으며, 이후 여러 회사 및 단체에서 IIOP엔진을 개발하는데 있어 참조 모델이 되고 있다 . 본 연구에서는 SunSoft 의 IIOP엔진을 분석하고 이를 WindowNT 환경으로 포팅하여 WindowsNT 환경에서 동작하는IIOP 엔진을 확보하였다 .

-224- (1) IIOP 엔진 설계 본 연구에서는 설계한IIOP 클라언트 엔진은 ORB 인터페이스와 4 개의 세부 모듈을 가지며,11. 그 구조를 그림 에 도시하였다

그림11. 1I0P 엔진 구성 모듈

1)엔진 API 모듈 엔진API 모듈은 IIOP 엔진을 구동시키는 인터페이스를 제공하며 , CORBA 의 정적 호출 인터페이스인SII(Static Invocation Interface) 와 동적 호출 인터페이스인 DII(Dynamic Invocation Interface)를모두지원한다 . IIOP엔진이 가동되면 , 엔진 API 모듈은 하부의 메시지 처리 모듈에서 제공하는 함 수를 사용하여GIOP 메시지를 생성하고 , 서버로 전송한다 . 또한 서버로부터 응답 메시지를 받으면,IIOP 결과값을 추출하여 그 값을 엔진을 구동한 응용에게 전달한 다. IIOP엔진을 구동시키기 위하여 엔진 API 모듈에서 제공하는 함수는 표 2 와 같다 .

표2. 엔진 API 모듈에서 제공하는 함수

함수 설명 SII_Invocation()CORBA 정적 호출 인터페이스 (SII) 지원 DII_Invocation()CORBA 동적 호출 인터페이스 (DII) 지원

-225- 2) 메시지처리모듈 메시지 처리 모듈은IIOP 엔진에서 필요한 중요한 기능들을 제공하는 핵심 모듈로 , 엔진API 모듈이 사용할 수 있는 다양한 함수를 제공한다 . 메시지 처리 모듈에서 제공하는 대표적인 기능은 다음과 같다.

• 서버와소켓연결설정 IIOP엔진을 사용하는 클라이언트와 서비스를 제공하는 서버 사이에 TCP 소켓 연 결을 설정한다.

• GlOP메시지생성및해석 . 클라이언트와 서버 사이에 교화되는GIOP 메시지를 생성 및 해석하는 기능으로 , 하부 모듈의 기능을 이용하여 표준CDR 형태로 인ㆍ 디코딩한다 .

•ㆍ메시지 송 수신. 연결된TCP 소켓을 통하여 GIOP 메시지를 송ㆍ 수신한다 .

위의 세 가지 기능은IIOP 엔진의 핵심 기능이며 , 이러한 기능들을 제공하는 메시 지 처리모듈의 함수를 표3. 에 도시하였다

표3. 메시지 처리 모듈에서 제공하는 함수

함수 기능 Invocation::start() 서버와 연결을 설정,GIOP 헤더 및 메시지 헤더 생성 Invocation::invoke() 생성한GIOP 메시지 송 ㆍ 수신 및 서버의 응답 해석 Invocation::put_param() 오퍼레이션에 필요한 파라미터 인코딩 Invocation::get_value() 응답 메시지에서 결과값을 디코딩

-226- 3) COR 모듈 COR모듈은 메시지 처리 모듈에서 GlOP 메시지를 생성 및 해석하는 과정에서 호 출되며,ORB 서로 다른 환경의 클라이언트와 서버가 메시지를 송ㆍ 수신할 경우 의 존적인IDL 데이터를 상호 인식이 가능한 공통 구문으로 변환하는 인코딩 기능과 그 반대인 디코딩 기능을 수행한다. 이러한 데이터의 변환은 각 데이터 타입에 따라 다르기 때문에,ㆍ 인 디코딩하기 위 해서는 해당 데이터의 타입을 정확하게 알아야 한다. 데이터 타입이 분명한 단순 데이터 타입(Primitive Data Type) 의 데이터인 경우는 직접 인 ㆍ 디코딩이 이루어진 다. 그러나 여러 가지 데이터 타입의 데이터 여러 개로 구성되는 복합 데이터 타입 (Constructed Data Type)의 데이터인 경우와 데이터의 타입이 분명하지 않은 데이 터인 경우에는 직접 인ㆍㆍ 디코딩할 수 없다., 따라서 이러한 데이터를 인 디코딩하 기 위하여 데이터의 타입 정보를 저장하는 타입코드를 사용한다. 타입코드는 해당 데이터의 정확한 정보를 담는 것으로, 단순 데이터 타입인 경우는 단순히 데이터의 타입 정보만을 담고 있으나, 복합 데이터 타입의 데이터인 경우에는 구성 요소의 개수와 각 구성요소의 데이터 타입에 대한 정보를 모두 포함한다., 즉 타입코드 정 보만 알면 해당 데이터를 전부 해석할 수 있다. CDR모듈에서는 타입코드 정보와 데이터를 함께 제공받아 데이터 인 ㆍ 디코딩을 수 행한다.CDR 그러나 모듈은 복잡한 타입 코드 정보를 해석하는 기능을 갖고 있지 않기 때문에,. 타입코드 모듈에서 제공하는 타입코드 해석기를 사용한다 CDR모듈에서 데이터를 인ㆍ 디코딩하기 위하여 제공하는 함수를 표 4 에 도시하였 다.

표4.CDR 모듈에서 제공하는 함수

함수 기능 CDR::put_X() 단순 데이터 타입인XCDR 형의 데이터를 스트림으로 인코딩 CDR::get_X()CDR 스트림에서 단순 데이터 타입인 X 형의 데이터를 디코딩 CDR::encoder() 타입코드 정보를 사용하여 모든 타입의 데이터를 인코딩 CDR::decoder() 타입코드 정보를 사용하여 모든 타입의 데이터를 디코딩

-227- 4) TypeCode 모듈 TypeCode모듈은 CDR 모듈에서 호출되며 , 데이터의 타입정보를 제공할 뿐만 아 니라 복합 데이터 타입의 데이터와 타입이 명확하지 않은 데이터의 타입코드 정보 를 해석하는 타입코드 해석기를 제공한다. 타이코드 해석기는 타입코드 정보를 해석하여 해당 데이터의 정확한 타입을 분석한 다. 해석한 정보를 바탕으로 해당 데이터 타입의 데이터를 변환하는 함수를 CDR 모듈로 호출하여 데이터를 인ㆍ 디코딩하도록 한다. 해석한 데이터의 데이터 타입이 복합 데이터 타입일 경우에는 타입코드 해석기를 재귀호출하여 정확한 데이터 타입 을 분석한다. TypeCode모듈에서 타입코드를 해석하기 위하여 제공하는 함수를 표 5 에 도시하 였다.

표5, TypeCode 모듈에서 제공하는 함수

함수 기능 데이터 타입을 해석하여 데이터를 해당 타입에 맞게 Continue_Encoding() 인코딩 데이터 타입을 해석하여 데이터를 해당 타입에 맞게 Continue_Decoding() 디코딩

5) 인터페이스 설계 위에서 설계한 각 모듈의 인터페이스를 그림12 에 도시하였다 . 엔진API 모듈은 응용 SII 와 DII 를 지원하는 SII Invocation() 과 DII Invocation() 을 제공하며, 메시지 처리 모듈은 클라이언트와 서버 사이의 소켓 연결 설정 , GIOP 메 시지의 생성 및 해석,GIOP 그리고 생성된 메시지를 클라이언트와 서버 사이에 송 ㆍ수신하는 함수들 (Invocation::start(), Invocation::invoke(), Invocation()::put_param(), Invocation::get_value())을 엔진 API 모듈로 제공한다 . CDR모듈은 단순 데이터 타입인 X 타입의 데이터를 인 ㆍ 디코딩하는 CDR::put_X(), CDR::get_X()을 제공하며 , 그 이외의 데이터를 인 ㆍ 디코딩하는 CDR::encoder(), CDR::decoder()를 제공하며 , TypeCode 모듈은 타입코드를 해석 하는Continue_Encoding() 과 Continue_Decoding() 을 제공한다 .

-228- 그림12. 인터폐이스 설계

(2) IIOP 엔진 구현 위에서 설계한IIOP 엔진을 Windows NT 환경에서 구현하였고 , 컴파일러로는 Visual C++ 6.0을 사용하였으며 , C++ 정적 라이브러리 형태로 구현하였다 . IIOP엔진의 각 모듈을 구현하고 , 각 모듈간의 인터페이스를 구현하였다 . CORBA 표준에서는TypeCode 모듈이 제공해야 하는 함수들을 정의하였는데 , 본 IIOP 엔진 은CORBA 표준에 따라 구현하였으며 , 일부 함수는 CORBA 표준과 호환성을 유지 하면서 기능을 확장하였다. 구현한IIOP 엔진은 클라이언트 버전으로 서버의 기능은 포함되어 있지 않다. GlOP표준 1.0 에서는 클라이언트가 생성시키는 메시지로 Request 메시지 , LocateRequest메시지 , CancelRequest 메시지를 정의하였으나 , 본 IIOP 엔진은 간 소성(simplicity) 을 위하여 응용에 Request 메시지만을 제공하며 , LocateRequest 메시지를 사용하지 않고 클라이언트의Request 에 대한 서버의 Reply 메시지의 상 태 정보로 그 기능을 대체한다. 또한CancelRequest 메시지도 제공하지 않는다 . 마지막으로 MessageError 메시지 는lIOP 엔진 내부적으로 발생시킨다 . 그러나 본 IIOP 엔진에서는 제공하지 않는 클라이언트 생성 메시지와 서버 생성 메시지에 대한 정의를 포함하여, 향후 사용할 경우에 대한 확장성을 고려하였다. Request메시지는 클라이언트 응용이 요구할 경우 IIOP 엔진에서 생성하며 , MessageError메시지는 서버가 Request 메시지 , CancelRequest 메시지 , LocatcRequest메시지 , LocateReply 메시지를 보냈을 경우나 서버의 메시지에 이 상이 있을 경우IlOP 엔진 내부적으로 생성하여 서버로 전송한다 .

-229- 3. IIOP 엔진의동작과정 본 절에서는 구현한IIOP 엔진을 통하여 클라이언트의 요구가 어떻게 서버로 전송 이 되며,IIOP 서버로 전송되는 과정에서 엔진 내부적으로 어떤 일이 발생하는 지 에 대하여 설명한다. 설명은 GlOP 메시지를 생성하는 과정 , GlOP 메시지를 생성하 는데 필요한CDR 인ㆍㆍ 디코딩하는 과정 , CDR 인 디코딩하기 위하여 타입 코드를 해석하는 과정,GlOPㆍ 마지막으로 생성한 메시지를 송 수신하는 과정을 각 모듈간 의 호출 관계 및 사용하는 함수를 중심으로 설명한다. IIOP 엔진의각모듈에서제공하는함수들과각모듈의호출관계는그림12 에도시 한 인터페이스 설계에 나와 있는 것과 같다.API 응용은 엔진 모듈에서 제공하는 SII_Invocation()함수와 DII_Invocation() 함수를 사용하며 , 엔진 API 모듈은 메시지 처리모듈에서 제공하는 함수들을 사용하여GlOP 메시지를 생성 및 해석하고 , GlOP 메시지를 송신 및 서버의 응답 메시지를 수신하고,. 원하는 결과값을 추출한다 메시 지 처리 모듈은 실제GlOP 생성 및 해석 , 메시지의 송ㆍ 수신 작업을 수행하며 , CDR모듈에서 제공하는 함수들을 사용하여 CDR 로 데이터를 인ㆍ 디코딩한다 . CDR 모듈은 실제 전송할 데이터의 인ㆍ 디코딩을 수행하는 곳으로 필요한 경우 TypeCode모듈에서 제공하는 타입코드 해석기를 사용한다 . 엔진API 모듈은 메시지 처리 모듈에서 제공하는 함수들을 사용하여 클라이언트 요 구 메시지를 생성하고 서버로 송/. 수신한다 또한 메시지 처리 모듈은 메시지를 생 성하는 과정에서CDR 로 변환하기 위하여 CDR 모듈에서 제공하는 함수를 사용하 며, CDR 모듈은 필요한 경우 TypeCode 모듈의 타입코드 해석기를 사용한다 .

(1) 메시지생성과정 엔진API 모듈은 GIOP 메시지를 생성하기 위하여 메시지 처리 모듈에서 제공하는 함수를 사용한다.GIOP 메시지는 GIOP 헤더 , 메시지 헤더 , 메시지 몸체 , 마지막으 로 전체 메시지 길이 정보를 삽입하는 순서로 생성된다.GIOP 메시지 처리 모듈은 헤더 및 요구(Request) 메시지 헤더를 생성하는 기능을 수행하는 함수 (Invocation::start()), 파라미터를 인코딩하여 메시지 몸체에 추가하는 기능을 수행 하는 함수(Invocation::put_param()), 마지막으로 GIOP 메시지의 전체 길이 정보를 삽입하는 기능을 수행하는 함수(Invocation::Invoke()) 를 제공한다 . 그림13 에 엔진 API 모듈에서 GIOP 메시지를 생성하는 각 과정을 담당하는 메시지 처리 모듈의 함수를 도시하였다.

-230- 그림11. 메시지 생성 과정

메시지 처리 모듈에서 제공하는 각 함수는 해당하는 기능을 수행하기 위하여, 내부 적으로 여러 가지 함수를 사용하며,CDR 특히 인코딩을 하기위해서는 CDR 모듈에 서 제공하는 함수를 사용한다.

(2)메시지 송 ㆍ 수신 및 응답 메시지 해석 과정 위에서 생성한GIOP 메시지를 전송하기 위하여 서버와 소켓 연결을 생성하고 , 연 결한 소켓을 통하여GIOP 메시지를 송신하고 서버의 응답 메시지를 수신한다 . 메 시지 처리 모듈은 서버와TCP 소켓을 연결하는 기능을 수행하는 함수 (Invocation: :start())와 메시지를 송ㆍ 수신하는 기능을 수행하는 함수 (Invocation::invoke()) 를 제 공한다. 그림14 에 메시지 송 ㆍ 수신 및 응답 메시지 해석 과정을 담당하는 함수와 내부적으 로 호출하는 함수를 도시하였다.

그림14. 메시지 송 ㆍ 수신 및 해석

Invocation::start()함수는 내부적으로 client_endpoint::lookup() 함수를 호출하여 연결할 서버의 정보를 찾으며, Invocation::invoke() 함수는 Invocation::send_message()함수를 사용하여 메시지를 송신하며 , Invocation::read_message()함수를 사용하여 서버의 응답 메시지를 수신한다 . 또 한Invocation::read_message() 함수는수신한서버응답메시지의 GlOP 헤더를 해석하여 메시지의 타입 정보를 추출하고,. 해당 메시지 헤더를 해석한다 서버 응답 메시지에서 결과값을 추출하기 위하여 엔진API 모듈은 메시지 처리 모 듈에서 제공하는Invocation::get_value() 함수를 사용한다 .

-231- (3) CDR인 ㆍ 디코딩 과정 메시지 처리 모듈은GIOP 메시지를 생성 및 해석하는 과정에서 CDR 인 ㆍ 디코딩을 위하여CDR 모듈을 호출한다 . CDR모듈은 기본적으로 단순 데이터 타입의 데이터를 인 ㆍ 디코딩 하는 put_X()/get_X()함수를 제공하며 , 모든 데이터 타입의 데이터 즉 , 단순 데이터 타 입의 데이터뿐만 아니라 복합 데이터 타입의 데이터와 데이터의 타입이 명확하지 않은 데이터까지 인ㆍ 디코딩하는encoder()/decoder() 함수를 제공한다 . encoder()/decoder()함수는 인 ㆍ 디코딩 할 데이터의 타입이 단순 데이터 타입인 경우put_X()/get_X() 함수를 호출하며 , 전달 받은 타입코드 정보에 근거하여 필요 한 경우 자기 자신의 재귀 호출하여CDR 인ㆍ 디코딩을 수행한다 . 그리고 복합 데 이터 타입의 데이터이거나 데이터 타입이 명확하지 않은 경우TypeCode 모듈의 타입코드 해석기를 호출한다. 그림15 에 CDR 인 ㆍ 디코딩하는데 필요한 함수와 함수들 사이의 호출과정을 도시 하였다.

그림15.COR 인 ㆍ 디코딩 과정

(4) 타입 코드 해석 과정 타입 코드 해석기는 인ㆍ 디코딩하려고 하는 데이터의 타입이 복합 데이터 타입이거 나 복잡한 타입코드 정보를 해석할 필요가 있는 경우CDR 모듈에 의하여 호출된 다., 타입코드 해석기는 전달 받은 데이터의 타입코드 정보를 해석하고 해석한 정보 를 바탕으로 해당 데이터를 인ㆍ 디코딩 하는 적절한 함수를 호출한다. 타입 코드 해석기는 전달 받은 데이터의 타입이 단순 데이터 타입일 경우 CDR::en/decoder()함수를 호출하여 데이터를 인ㆍ 디코딩하며 , 데이터 타입이 except타입과 struct 타입인 경우 Struct_En/Decoding() 함수를 , union 타입인 경 우에는Union_En/Decoding() 함수를 호출하여 , 해당 데이터를 인ㆍ 디코딩한다 . 그 밖의 경우, 각 데이터 타입을 해석하고 해석된 타입 정보를 바탕으로 CDR::en/decoder()함수를 호출하여 인ㆍ 디코딩을 수행한다 . 그림16 에 TypeCode 모듈에서 제공하는 타입코드 해석기에서 제공하는 함수와 각 함수사이의 호출관계를 도시하였다.

-232- 그림16. 타입코드 해석 과정

Struct_En/Decoding()함수와 Union_En/Decoding() 함수는 각 구성 요소의 타입 을 해석하여CDR::en/decoder() 함수를 호출하거나 , 자기 자신을 재귀호출하여 인 ㆍ디코딩을 수행한다.

4. IIOP 엔진 기능성 테스트 IIOP엔진을 구현한 SunSoft 에서는 자사의 IIOP 엔진의 기능성을 테스트하기 위한 테스트 프로그램을 구현하였다.Sunsoft 의 테스트 프로그램은 UNIX 기반으로 구현 되었으며,SIIDII 정적 인터페이스인 와 동적 인터페이스인 를 모두 테스트할 수 있 다. 본 테스트에서는SunSoft 에서 제공하는 테스트 프로그램을 사용하였으며 , 서버 역 시SunSoft 에서 제공하는 서버 프로그램을 사용하였다 . 테스트는WindowsNT 환경에서 수행하였으며 , 서버 역시 WindowsNT 환경에서 실 행되어 있으며,.lOR 클라이언트의 요구를 기다리는 상태이다 테스트에서는 표준 을 사용한 객체 참조를 사용하는 경우와 그렇지 않은 경우(SunSoft 에서 정의한 객체 참조 형식을 사용하는 경우)., 각각에 대하여 진행하였다 또한 테스트 프로그램이 잘 동작하는지 여부와 테스트 프로그램을 실행한 결과가 정확한지를 통하여 IIOP 엔진의 기능성을 검증하였다. 그림17 에 기능성 테스트를 위한 서버와 클라이언트 환경을 도시하였다 .

그림17. 기능성 테스트 환경

-233- 먼저SunSoft 에서 정의한 객체 참조 형식을 사용하여 테스트 프로그램의 서버 프 로그램을 실행한 결과와 클라이언트 테스트 프로그램을 실행한 결과를 각각 그림 18과 그림 19 에 도시하였다 . 그림에서 도시한 바와 같이 테스트 프로그램은 동작은 정상이며, 실행 결과값 역시 정확하였다.

그림18. 서버 프로그램 실행 화면

그림19. 클라이언트 테스트 프로그램 실행 결과

두 번째로,IOR 표준 형식의 객체 참조를 사용하여 테스트 프로그램의 서버 프로그 램을 실행한 결과와 클라이언트 테스트 프로그램을 실행한 결과를 각각 그림20 과 그림21 에 도시하였다 . 그림에서 도시한 바와 같이 테스트 프로그램은 동작은 정상이며, 실행 결과값 역시 정확하였다.

그림20. 서버 프로그램 실행 화면

-234- 그림21. 클라이언트 테스트 프로그램 실행 결과

이상에서 본 연구에서 구현한IIOP 엔진을 사용한 기능성 테스트에서 테스트 프로 그램이 정상적으로 동작하였고,., 그 결과 역시 정확함을 확인하였다 따라서 본 IIOP엔진은 정상적으로 동작함을 알 수 있다 .

제3 절 상호 운용성 테스트 및 임베디드 운영체제로의 포팅 본절에서는IIOP 엔진의상호연동성을테스트하기위한환경을구축하여본연구 에서 개발한IIOP 엔진을 테스트하였다 . 또한 , 개발한 IIOP 엔진을 임베디드 운영체 제인WindowsCE 와 VxWorks 로 포팅하였다 .

1. 상호 운용성 테스트 IIOP엔진의 상호 운용성을 테스트하기 위하여 대표적인 CORBA 플랫폼인 IONA 사 의Orbix 와 대표적인 공개 소프트웨어인 MICO 을 사용하는 테스트 환경을 구축하였 으며,22 그림 에 도시하였다 . 그림에 도시한 바와 같이, 클라이언트는 WindowsNT 환경에 구축하였으며 , 정적 인 터페이스인SII 와 동적 인터페이스인 DII 를 통하여 서버를 호출한다 . Orbix 플랫폼 을 사용하는 서버 역시WindowsNT 환경에 구축하였으며 , Orbix 버전 2.3c 를 사용 하여Grid 서버를 구현하였다 . MICO 플랫폼을 사용하는 서버는 Solaris 2.6 환경에 구축하였으며, MICO 버전 2.2.7 를 사용하여 Bank 서버를 구현하였다 . 또한 클라이 언트와 서버는LAN 으로 연결되어 있다 .

-235- 그림22. IIOP 엔진 기반의 클라이언트 응용과 Orbix 서버 /MICO 서버와의 상호 연동 테스트 환경

Orbix환경에서 구현한 Grid 테스트 프로그램의 실행 결과와 MICO 환경에서 구현 한Bank 테스트 프로그램의 실행 결과를 그림 23 와 그림 24 에 각각 도시하였다 .

그림23. Orbix Grid 서버와의 테스트 결과

-236- 그림24. MICO Bank 서버와의 테스트 결과

이상에서 본 연구에서 구현한IIOP 엔진을 사용한 상호 운용성 테스트에서 테스트 프로그램이 정상적으로 동작하였고,., 그 결괴 역시 정확함을 확인하였다 따라서 본 IIOP 엔진은 다른 플랫폼을 사용하는 서버와도 정상적으로 동작함을 알 수 있다.

2. WindowsCE 환경으로 포팅 Windows NT환경에서 개발한 IIOP 엔진을 Windows CE 환경으로 포팅하였다 . WindowsCE로포팅하기위해초기에는 WindowsCE Toolkit for VC++6.0 을사용 하였으며, 이후 PlatformBuilder 2.11 과 WindowsCE 2.11 이 설계된 타깃 시스템을 사용하였다. WindowsNT에서 WindowsCE 로 포팅하는 과정에서 소스의 많은 변경이 요구되지는 않지만 시스템 관련 함수들은 많이 변경되어야 한다. 처음 포팅 작업은 표준 입ㆍ 출력 함수를 제공하지 않는WindowsCE 버전 2.01 에서 수행하였기 때문에 상당한 애로 사항이 있었으며, Windows CE 는 WindowsNT 가 제공하는 모든API 를 지원하지 못하고 일부 API 만 제공하기 때문에 , 지원하지 못하 는API 들은 직접 구현하거나 제공되는 다른 유사한 API 들을 이용하여 원하는 기능 을 구현하였다. 또한 , 기존 WindowsNT 의 WinSock 1.1 에서는 비슷한 기능을 갖는 유사한API 를 여러 가지 제공하는데 반하여 WindowsCE 의 WinSock 1.1 에서는 이 러한 비슷한 기능을 수행하는API 들을 1~2 개의 API 로 통합시켜 놓았기 때문에 포 팅작업 과정에서WindowsCE 가 지원하는 API 로의 매핑작업이 필요하였다 . 표준 입 ㆍ출력 함수 문제는 이후에 이를 지원하는WindowsCE 버전 2.11 로 업그레이드함 으로써 해결되었다.

-237- Windows CE용 IIOP 엔진을 개발하기 위한 시스템 구성도를 그림 25 에 도시하였으 며,5. 개발 환경을 표 에 나타내었다

그림25. Windows CE IIOP 엔진 개발을 위한 시스템 구성도

표5. Windows CE IIOP 엔진개발환경

개발 환경 설 명 개발 호스트 플랫폼 Windows NT 4.0 개발도구 Windows CE Platform Builder 2.11 Target Board x86, 10M-Ethernet 디버깅 환경 시리얼, LPT

Windows CE타깃 시스템을 사용하기 위해서는 동적으로 IP 주소를 할당할 DHCP 서버가 필요하며,LPT. 디버깅을 위한 시리얼 케이블과 케이블이 필요하다 시리얼 케이블은 일반 널 케이블을 사용하였으며,LPT 케이블은 표준방식으로 연결된 케이 블이 아니라 디버깅을 위해 특수 제작된 케이블을 사용하였다. 포팅하는 과정에서의 주요 변경 사항은 다음과 같다.

• Windows NT용 IIOP 엔진에서는 메모리 할당을 위해 calloc(x,y) 함수가 사용되는 데, Windows CE 에서는 calloc(x,y) 함수가 지원되지 않아서 이와 거의 같은 기능 을 하는realloc(NULL,y) 함수로 대체하였다 . 이렇게 대부분의 많은 유사 기능을 가 진 함수들이1~2 가지의 함수로 대체되어 사용되는 부분이 많으므로 이 부분을 변 경하였다.

-238- • Windows NT에서는 stdio.h 에 BUFSIZ 가 정의 되어있는데 Windows CE 에는 정 의되어 있지 않았다. 그래서 Windows NT 의 stdio.h 파일을 참고하여 lIOP 엔진의 orbobj.cpp파일 내에 BUFSIZ 를 512 로 정의하였다 . #define BUFSIZ 512

• Windows CE는 isascii(), isalpha(), isprint() 등의함수들은지원하지않고 wide character버전인 iswascii(), iswalpha(), iswprint() 등의 함수만 지원하므로 is...() 함수들을isw...() 함수로모두 대치하였다 .

• PlatformBuilder에서 oldnames.lib, libc.lib, libcd.lib 을 링커가 찾는 문제가 발생 하는데PlatformBuilder 자체의 lib 디렉토리 내에 존재하는 corelib.lib 파일을 세 가지 모두 각각의oldnames.lib, libc.lib, libcd.lib 파일로 이름을 변경한 복사본을 만든 다음IIOP 엔진 lib 디렉토리에 복사해야 문제를 해결할 수 있다 .

• Visual Studio Windows CE Toolkit 6.0의 내장 OS 가 2.01 버전에서는 stdio.h 를 지원하지 못하는데, Platform Builder 2.11 부터는 stdlib.h 에서 지원하므로 , printf() 함수와 같은I/O 함수들을 사용할 수 가 있다 .

• int main (int argc, char *const *argv)함수대신 int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevlnstance, LPWSTR IpCmdLine,int nCmdShow)함수를 사용하였다 . Windows CE 에서는 WinMain() 함 수가 프로그램의entry-point 이므로 Windows NT 에서와 같이 main() 함수를 사용 할수없다.

3. VxWorks 환경으로 포팅 Windows NT환경에서 개발한 IIOP 엔진을 VxWorks 환경으로 포팅 하였다 . VxWorks로 포팅하기 위해 Tornado 컴파일러를 사용하였으며 , Tornado 는 GNU GCC와 같은 개발환경을 제공하므로 Unix 개발환경과 유사한 점을 많이 가지고 있다. 그러나 Tornado 1.01(VxWorks 5.3) 에서 C++ 언어의 컴파일 환경은 Unix 에서 의컴파일환경과약간다른점을갖고있다또한.Socket 관련부분에서는지원되 지 않는 함수가 존재한다.Tornado2.01.01 그러나 에서는 에서 지원하지 못하는 대부분의 함수들을 지원하므로, 본 연구에서는 Tornado 2.0 을 사용하여 포팅작업 을 진행하였다.

-239- 개발환경은 호스트PC 와 타깃시스템 (PC) 으로 구성하였다 . 타깃시스템은 펜티엄 90, VGA, NE2000호환 (ISA-IRQ:5), FDD, 모니터를 갖춘 시스템을 이용하였으며 , 이를 그림26 에 도시하였다 .

그림26. VxWorks IIOP 엔진 개발을 위한 시스템 구성도

타깃시스템의 설치 및Booting 과정은 다음과 갈다 . • Tornado IDE메뉴에서 Bootrom 이미지를 만들고 나서 (Project > PC486 > Boot ROM Target> bootrom_uncmp) f:₩>mkboot.bat a: bootrom_uncmp 명령으 로 부팅 디스켓을 만든다.

• Tornado IDE메뉴에서 VxWorks 이미지를 (Project > PC486 > VxWorks Target > VxWorks)만든다 . 이때 BSP 설정 메뉴에서 INCLUDE_CPLUS 를 포함시킨 후 VxWorks이미지를 만들어야만 C++ 언어를 사용할 수 있게 된다 .

• Tornado번들로 포함된 ftp 서버를 실행한다 .

• 타깃시스템에서 부팅디스켓으로 부팅하고 나서,“c" 타깃시스템에서 명령어로 세 부 환경을 설정해 준다.. 다음은 환경 설정하는 화면을 나타낸 것이다

-240- • 타깃시스템에서‘@’ 누르면 호스트컴퓨터의 VxWorks 이미지로 부팅하게 된다 . 다 음과 같은 화면이 나타나면 호스트PC 와 타깃시스템과의 연결 설정이 제대로 되였 다는 것을 나타낸다.

VxWorks로 포팅시 주요 변경 사항은 다음과 같다 . • 모든 파일에 다음 파일을 가장 맨 윗줄에 첨가한다. #include "vxWorks.h"

• 프로그램의entry-point 는 main() 함수가올수없다기존의 . main() 을임의의함 수로 바꿔야 한다. 예 ) main() 함수를 gridClient() 로 대치한다 .

-241- • x86계열에서는 Little-endian 이고 , MIPS 계열은 Big-endian 이므로 byte-order 문제 를 고려해줘야 한다. 컴파일할 때 -DCPU=180486 또는 -DCPU=R4000 와 같은 옵션을 추가해주면 컴파일시 각CPU 에 맞게 컴파일 된다 . IIOP 엔진 소스의 bat 파일 및makefile 내에서 180486 으로 설정되어 있으므로 타깃 CPU 에 따라 컴파일 옵션부분을 변경해주면 된다.

• Tornado 1.0에서 hostgetbyname() 함수를 지원하지 못하는 문제로써 , Tornado 1.01에서 gethostbyname() 함수를 지원하지 못하므로 유사한 기능을 하는 hostGetByName()함수를 사용해야 한다 . Tornado 1.0 에서 DNS 루틴을 지원하지 못하므로hostAdd() 함수를 사용하여 host table 에 domain name 을 추가해줘야 한 다. 예를들어 GridClient.cpp 와같은실제로구현하는파일내에추가하여호출해 줘야 한다.

• VxWorks에서 C++ 언어를 컴파일하는 방법은 C 언어를 컴파일 하는 방법과는 조 금 다르게munch 라는 과정을 거쳐야 컴파일이 정상적으로 수행된다 . VxWorks 환 경에서C++ 언어를 컴파일하는 단계는 표 6 와 같다 .

표6. VxWorks 환경에서의 C++ 컴파일 단계

1단계 cc386

위 과정을bat 파일 및 makefile 을 만들어 컴파일 작업을 쉽게 하였다 .

-242- 제장결과3 본 연구에서는I-PCTV 의 GUI 요구사항을 분석하고 , 다양한 멀티미디어 / 하이퍼미디 어 정보부호화 방식을 조사,I-PCTV 분석하여 의 사용자 인터페이스를 효율적으로 지원하는 멀티미디어 정보부호화 방식을 제시하였다.,Non-CORBA 또한 플랫폼에 기반을 둔 응용들이CORBA 분산환경과 통합되어 분산 멀티미디어 환경을 제공할 수 있도록 하는IIOP 프로토콜 엔진을 설계 및 구현하였고 , CORBA 상호 운용성을 테스트할 수 있는 환경을 구축하여 개발한IIOP 엔진의 상호 운용성을 테스트하였 으며, 이들 임베디드 운영체제인 WindowsCE 와 VxWorks 환경으로 포팅하였다 . 따 라서 전체적인CORBA 분산처리 환경을 탑재하는 것이 상당한 오버헤드로 작용하 는PDA, HPC, Smart Phone, Car PC 와 같은 소형 디바이스나 , 실시간 운영체제를 이용하는I-PCTV 용 Set-Top Box 와 같은 시스템에 , 본 연구에서 개발한 IIOP 엔 진을 탑재함으로써 상당한 오버헤드를 줄일 수 있으며, 경제적인 효과도 누릴수 있 을 것으로 기대된다.

. 자료수집 및 분석 다양한 멀티미디어 및 하이퍼미디어 정보부호화 방식을 조사,, 비교 분석하였다 . 멀 티미디어 정보부호화 방식에 관련된 국내외 자료들을 수집,, 분석하고 관련 기술 수 준,, 선진국의 개발현황 특히 관련 국제표준 , 외국의 활용사례 등을 면밀히 분석 , 검토하였다.

.I-PCTV의 GUI 요구사항 분석 대화형TV 서비스 , 인터넷 멀티미디어 서비스 등 다양한 멀티미디어 응용들을 지원 하는I-PCTV 를 위한 효율적인 GUI 요구사항을 분석하여 멀티미디어 부호화 방식 선정에 반영하였다.

.I-PCTV를 효율적으로 지원하는 멀티미디어 정보부호화 방식 제시 I-PCTV의 GUI 요구사항 분석 및 다양한 멀티미디어 부호화 방식 분석을 통해 I-PCTV에 적합한 GUI 를 효율적으로 지원하는 멀티미디어 부호화 방식을 제시하였 다. 현재 상호 작용적인 멀티미디어 응용서비스를 지원하는 효율적 규격인 MHEG-5표준 부호화 방식을 채택하였고 , I-PCTV 에 적용하기 위해 관련 기술을 상세히 분석하였다.

-243- .I-PCTV를위한 MHEG-5 엔진구조설계 I-PCTV를 위한 멀티미디어 정보부호화 방식의 제시에 따라 . MHEG-5 멀티미디어 정보부호화 방식을 지원하는 정보처리 엔진의 기능 구조를 설계하여, 엔진을 구성 하는 주요 기능 모듈을 제시하였다.

.,분산처리기술및표준화동향조사분석 최근의 분산처리 기술에 관련한 자료를 수집, 분석하였다 . 특히 OMG 의 CORBA 분 산 컴퓨팅 기술에 관한 표준문서,, 기술동향 응용사례 등을 상세히 조사 , 분석하였 다.

. IIOP 클라이언트 엔진 개발 Non-CORBA플랫폼에 기반을 둔 응용들이 CORBA 분산환경과 통합되어 분산 멀 티미디어 환경을 제공하는IIOP 프로토콜 엔진을 설계 및 구현하였다 .

.CORBA상호 운용성 테스트 망 구축 개발한IIOP 엔진과 Orbix 환경과 MICO 환경의 서버를 사용하는 테스트 프로그램 을 구현하였으며,. 이들 간의 상호 운용성을 테스트하였다

. 임베디드 운영체제로의 포팅 WindowsNT환경에서 개발한 IIOP 엔진을 임베디드 운영체제인 WindowsCE 와 VxWorks로 포팅하여 , PDA, HPC, Smart Phone, Car PC 와 같은 소형 디바이스나 , 실시간 운영체제를 이용하는I-PCTV 용 Set-Top Box 와 같은 시스템에 적합하도록 하였다.

-244- -245-