::: 삼성전자 소프트웨어멤버십 블로그 :::

  맵에 위치한 각각의 고정노드로 부터 시간데이터를 전송받은 뒤 이를 거리로 환산하고 이들 값들을 삼각측량법에 적용합니다. 그럼 이동노드의 위치를 찾을 수 가 있습니다. 가상으로 위치를 추적해 보는 프로그램을 만들어 보았습니다. 먼저 프로그램을 실행시키고 고정노드와 이동노드를 화면에 불러옵니다. 그리고 각각의 원하는 위치에 둡니다.

제가 일단 임의로 둬 보았습니다. 이동노드의 위치는 (332,198) 이고 각가의 고정노드와의 실제거리는 약324,243,335라고 나오게 되었습니다. 여기에서 각각의 고정노드가 시간데이터를 보낸 값을 거리로 환산해 보았더니 약 320,240,330 였다고 설정해 보겠습니다. 오차가 생겼다는 가정을 두는 것 입니다.

이렇게 나온 거리값을 삼각측량을 적용하여 계산된 위치를 표시해 보겠습니다.
녹색점으로 표시된 곳이 계산된 이동노드의 위치입니다. 좌표는 (332,195)입니다. y좌표만 3만큼의 오차가 발생했습니다. 이를 통해 시간데이터를 통한 거리값이 최대한 정확하게 나온다면 위치추적이 가능하리라 생각합니다. 다음에는 실제로 시간데이터를 전송받아 실시간으로 위치추적하는 모습을 보여드리겠습니다.

ALTERA의 quartus 프로그램에 Verilog HDL을 이용하여 timer를 설계 하였다.
입력은 외부에서 33MHz를 받아 PLL로 채배하여 내부에서 1기가까지 카운팅 할수 있도록하였다.
주파수의 이동시간을 측정하기 위하여 고속의 Timer를 설계 하였다.
테스트 화면은 132MHz로 테스트한 화면이다. 외부 프로세서와 통신하기 위하여 32비트 대역의 SPI모듈도 설계하였다.

위 시뮬레이션 그림을 보면 리셋 신호가 High인 동안 클럭이 카운트 됨을 알수 있다.

먼저 저희 팀이 이번에 진행한 프로젝트의 초기 목표는 NDS에서 간단하게 음악을 작곡할 수 있는 프로그램과 플랫폼을 만들어보자 라고 정의될 수 있습니다. 따라서 NDS에서 Standard MIDI File을 재생 구현하고 동작하도록 만드는 선행 과정이 필요합니다.  실제 이러한 부분에 대해 조사를 해보시면, 미디 스펙을 구현한 소스를 구하는 것도 쉽지 않고, 미디 스펙에 대해 자세하게 설명된 페이지가 그렇게 많지 않다는 것을 아실 수 있습니다.

이런 부분을 맨바닥부터 만드는 것은 3개월 프로젝트 내에 도저히 다할 수 없다고 판단되어 nds 사용자들이 모두 알고 사용하고 있는 문쉘 소스를 분석하고, 해당 부분을 포팅하여 사운드 재생 부분을 만들어보려고 계획을 하였습니다. 문쉘에 대해 간략히 소개를 하자면, NDS에서 돌아가는 미디어 플레이어라고 생각하시면 되고, 요새 대부분의 사용자는 R4 등을 이용해서 많이 사용하고 있습니다.

다른 프로그램도 아니라 문쉘 소스를 분석하는 이유는 문쉘의 플러그 인 중 미디 파일을 재생하는 부분이 low level부터 구현이 되어있기때문에 분석용으로 적절하다고 판단이 되었고, 문쉘을 선택하기 이전에도 다른 미디 스펙을 구현한 프로그램 등을 조사하였는데, 너무 오래되어 유지보수가 전혀 안된다던가, 실제 동작이 안되는 경우가 너무나도 많아서 결국 문쉘을 먼저 분석하는 것을 목표로 하였습니다.

그런데 문쉘의 공식 홈페이지 에서 직접 소스를 다운받을 수 있으면 좋았겠지만, 문쉘 제작자가 잠수를 탄지 몇개월이 되어가고 있으며, 홈페이지도 죽어있는 상태라 간접적인 어떤 지원을 전혀 받지 못했습니다. (그리고 아시다시피 일본인이고 본인이 영어를 못한다는 것을 홈페이지에 공지를 해두었기 때문에 프로젝트 초반에 메일을 몇번 보내봤는데 답장이...-_- ) 따라서 문쉘 전체 소스를 공개하는 것이 법적으로 문제가 있을지 없을지 애매한감이 없지만, 일단 이 곳에서 받으실 수 있습니다.

그리고 문쉘 제작자는 플러그인과 사운드 뱅크도 적절하게 NDS용으로 만들어서 같이 공개해두었는데, 여기서 받으실 수 있습니다. 이 프로젝트 시연을 실제로 해보면 귀가 민감하신 분은 약간 음질이 버벅이거나 지직이는 것을 느낄 경우가 생길수있는데, 음원 자체가 PC에 있는 음원과 달리 최소한의 재생을 목적으로 만들어져있기 때문에 그렇습니다.

서문이 길었구요, 실제 문쉘이 어떻게 사운드를 재생하는지 살펴보겠습니다.

1> IPC
실제 문쉘 코드를 아무런 지식 없이 보게 되면 ARM9 쪽에서는 사운드를 직접적으로 재생하는것 같은 코드가 전혀 없고 추적을 해보면 IPC를 통해서 ARM7으로 전송하는 것을 알 수 있습니다.  글을 읽으시다보면 IPC가 무엇인지 궁금해하실것 같은데, NDS 구조상 ARM9과 ARM7을 사용하고 있습니다. 이 곳의 글과 그림을 보시면 대충 어떻게 구성이 되어있는지 감을 잡으실 수 있을겁니다. 그래서 두개의 MCU간 데이터를 교환하는 어떤 방법이 있어야하는데, 까마귀님의 글에 따르면  libnds에서 제공하고 있는 공통적인 메모리 영역이 있습니다.

글에 의하면 NDS는 ARM9과 ARM7 간의 통신을 위해 IPC 통신 기능을 가지고 있습니다. 하지만 IPC 설정을 해줘야 하고 보낼 수 있는 데이터의 양도 최대 64byte까지로 한정되어있기 때문에 무엇인가 부족한 면이 있다고 적혀있고, libnds에서는 ARM7과 ARM9이 공유하는 메모리를 이용해서 가상의 IPC 기능을 구현했는데, \devkitPro\libnds\source\include\nds 폴더에 ipc.h 파일에 나와있습니다.

그리고 까마귀님의 글에 따르면, Sound 출력 부분은 ARM7 만이 접근할 수 있으며 따라서 ARM9으로 디코딩한 후에 ARM7쪽에 동기를 맞추어 버퍼를 넘겨주는 식으로 코드를 짜야하며 테스트 코드를 ARM9에서는 파일만 읽어서 데이터를 ARM7에 넘겨주고 ARM7이 디코딩 + 출력까지 다하는 거라고 적어두셨는데, 문쉘도 크게 보면 이러한 구조를 따르고 있습니다.

한가지 주의할점은 문쉘은 위의 ipc.h를 그대로 쓰는 것이 아닌 별도의 ipc3.h라는 파일을 정의해서 사용하고 있습니다. 문쉘을 살펴보다보면 원래의 libnds가 아닌 libnds에 있는 헤더파일을 수정해서 고유하게 사용하는 것이 있는데 터치스크린 영역 같은 부분이 그렇습니다. 일단 ipc3.h 파일을 보면 다음과 같이 정의되어있습니다.

대부분의 상수와 구조체는 동일하게 정의가 되어있는데, 다음과 같이 sTransferRegion3 라는 것을 수정한 것을 확인할 수 있습니다. 이 중 사운드 관련 멤버들은 다음과 같습니다.

 typedef struct sTransferRegion3 {
  ...(중략)
  EIPCREQ IR;

  s64 IR_samples;
  ...(중략)
  EstrpcmControl strpcmControl;
  u32 strpcmFreq,strpcmSamples,strpcmChannels;
  u32 strpcmVolume16;
  u32 strpcmWriteRequest;
  EstrpcmFormat strpcmFormat;
  s16 *strpcmLBuf,*strpcmRBuf;
 
  ... (중략)
  TExecPCM *pExecPCM;
} TransferRegion3, * pTransferRegion3;

위의 구조체의 멤버를 사용해서 실제 사운드 데이터를 ARM9에서 ARM7으로 실어보내는데, strpcmWriteRequest 등 플래그 변수를 사용하여 ARM9과 동기화를 맞추고 있습니다. 하지만 실제로 변수 하나만 가지고 데이터 동기화를 맞출 수 없으므로 ipc 인터럽트가 있습니다. 이러한 부분은 먼저 다음과 같은 식으로 초기화를 해주고, 그리고 ARM7 측에서 사운드 재생 후 레지스터를 다시 설정하는 식으로 동기화를 맞추고 있습니다. 즉, ARM7 측의 main.c 를 살펴보면 다음과 같이 계속해서 루프가 돌고 있습니다.

...(중략)
    if(IPC3->strpcmControl!=strpcmControl_NOP) // 이렇게 NOP이 아닐때 실행되도록 계속해서 체크를 하고 있습니다;
    {
      REG_IME=0;    // 인터럽트 마스크 활성화 여부를 결정하는 레지스터입니다. 일단 off
      main_Proc_strpcmControl();
      REG_IME=1;   // 그리고 다시 on.
    }
...(중략)

여기서 main_Proc_strpcmControl 부분이 실제로 사운드를 재생해주는 함수인데, 이런식으로 되어있습니다. 일단 레지스터 등을 세팅하고 타이머를 통해서 인터럽트가 생길 수 있도록 해줍니다. 이 부분은 다음 글에서 더 자세히 적어보겠습니다.

static inline void main_Proc_strpcmControl(void)
{
  switch(IPC3->strpcmControl){
    case strpcmControl_Play: {
      strpcmPlay();
      irqSet(IRQ_TIMER1, InterruptHandler_Timer_Null);
      switch(strpcmFormat){
        case SPF_PCMx1:
            irqSet(IRQ_TIMER1, InterruptHandler_Timer1_PCM);
            break;
      }
    } break;
    ...(중략)
  }
  IPC3->strpcmControl=strpcmControl_NOP; // 재생후 NOP으로 맞춰주죠. 결국 ARM9에서 다시 이 플래그 변수를 바꾸는 식으로 되어있습니다.
}

여기서 strpcmPlay 부분을 살펴보면 실제로 IPC3의 구조체 내부의 변수를 통해서 ARM9에서 전달된 데이터를 받아옵니다.

static void strpcmPlay()
{
  // REG_IME=0;
 
  IPC3->IR=IR_NULL;
 
  strpcmCursorFlag=0;
 
  strpcmFormat=IPC3->strpcmFormat;
 
  strpcmLBuf=IPC3->strpcmLBuf;
  strpcmRBuf=IPC3->strpcmRBuf;
 
  // ...(중략)
   
  strpcmSamples=IPC3->strpcmSamples;
  strpcmChannels=IPC3->strpcmChannels;
  //...(중략)
}

이런식으로 끊임없이 플래그 변수의 세팅과 IPC의 데이터 전송을 통해서 ARM9에서 ARM7으로 데이터를 전송 하고 있습니다.

정리하자면, NDS에서 단순히 함수 호출을 하나만 한다고 사운드가 원활하게 재생이 되는 것이 아닙니다. 물론 libnds에서 관련 함수를 제공하긴 하지만, 단순히 raw파일을 재생하는 용도에서 그치므로 midi 같은 스펙을 충족시키기 위해서는 위와 같은 복잡한 과정이 필요합니다. 다음 글에서는 실제로 미디 스펙의 구현이 어떻게 되어있는지, 사운드 레지스터를 어떻게 설정하는지 등을 설명하겠습니다.

1. Introduction

두 개의 Host USB간에는 직접적으로 통신을 할 수 없기 때문에 특수한 역할을 하는 Hardware 및 Firmware가 필요합니다.  그중에서 Cypress사의 FX2LP를 이용한 8bit 비동기 통신을 하는 Hardware 및 Firmware의 구조와 역할에 대해서 설명하겠습니다.


2. Hardware Connection Diagram

위의 그림은 두 개의 FX2LP를 연결할 때 연결하는 핀의 이름과 방향을 나타내고 있습니다. 두 개중에 하나는 Master의 역할을 하고 나머지 하나는 Slave의 역할을 하게 되는데, 각각의 역할에 따라서 FX2LP의 여러 기능들 중 자기역할에 적합한 기능을 선택해서 쓰게 됩니다.

Master는 GPIF(General Programmable Interface)라는 core를 사용합니다.

GPIF란 USB 2.0의 대역폭에 비해 8051코어가 너무 느리게 동작하기 때문에 이것을 대신해 외부에서 들어오는 데이터를 빠르게 FIFO에 채우고(또는 USB를 통해 전송 받은 FIFO의 데이터를 외부로 내보내고), 패킷을 날리는 일을 해주는 State Machine 입니다.

이것도 일종의 프로세서이니 만큼 입력과 출력이 있고, 우리가 프로그램을 해 줘야 동작을 합니다.

- RDYn Pin

신호가 적정 레벨까지 Wait, Continue, Repeat하기 위해 허용 또는 거절하는 역할.

RDY0과 RDY1은 Data Flow를 컨트롤 하는데 사용.

- CTLx Pin

Strobe로 사용되는 Programmable control outputs Pin.

CTL0, CTL1, CTL2는 appplication에서 사용됨.

- PORTA

PA0과 PA1은 slave의 FIFOADR0과 FIFOADR1이 연결되어 master에 의해 접근되는 FIFO의 주소를 조정하는데 사용.

- PORTB

이 모듈은 8비트 Data 전송을 하기 때문에 PORT[0:7]가 Master와 Slave에 서로 연결되어 Data bus로 작용.

Slave도 역시 8051을 거치지 않고 외부 핀으로부터 직접 연결되는 Slave FIFO를 사용합니다.

- SLRD

FIFO를 위한 Slave Read Line.

Slave를 위한 Read Strobe로서 작용하게 되고 Master의 CTL0은 Strobe를 제공.

- SLWR

FIFO를 위한 Slave Write Line.

Slave를 위한 Write Strobe로서 작용하게 되고 Master의 CTL1은 Strobe를 제공.

- FLAG B/FLAG C

FLAG B는 Slave Endpoint6 FIFO의 'Full'의 상태를 가리키는데 사용.

FLAG C는 Slave Endpoint2 FIFO의 'Empty'의 상태를 가리키는데 사용.

- FIFOADR[0:1]

Master는 FIFOADR Pin을 사용하여 4개의 Slave FIFO중 하나를 선택하고 SLRD와 SLWR 신호를 사용하여 8비트 FIFO Data를 조정.

-PKTEND

Max 패킷 사이즈 보다 작은 IN Packet을 USB로 전송하는 역할.

3. 8051 Firmware Programming for Master

Firmware는 제멋대로인 USB INs 와 OUTs 을 조절하기 위해서 사용됩니다.

OUTs (FIFO Writes)

- Endpoint 2 OUT has data

- Peripheral Interface Not Busy(GPIF IDLE)

- Slave Interface FIFO Not Full

INs (FIFO Reads)

- Peripheral Interface Not Busy(GPIF IDLE)

- Slave Interface FIFO Not Empty

- Endpoint 6IN Available Not Full

GPIF는 FIFO Reads와 Writes 사이의 자원을 공유하기 때문에 주변 인터페이스의 상태가 physical bus 전송의 어떠한 형태로 도달하기 위해서는 GPIF를 사용하기 전에 항상 확인을 해야합니다.

Firmware는 short packet을 조절하기 위해 512byte FIFO Reads와 Writes에 최적화되어 있고 In과 OUT에서 AUTO모드를 사용합니다. 이 말은 OUT 전송의 경우에 주변의 Domain으로부터 USB Domain까지 또는 IN 전송의 경우에는 USB Domain으로부터 주변의 Domain까지 max-size(512 bytes)packets이 자동으로 위임된다는 것을 의미합니다.

Short Packets은 Master가 Slave's PKTEND에 strobing함으로서 조절 되는데, Slave의 PKTEND가 CTL2에 연결되어 있어서 GPIFIDLECTL 레지스터에 PKTEND를 strobe하기 위해 사용 됩니다.

4. 8051 Firmware for the Slave

Slave는 오직 AUTO 모드로 동작하기 때문에 레지스터의 초기화나 EP6AUTOINLEN 레지스터를 명세화 하는 것을 제외하고는 Data를 전송하거나 받기 위해 Code가 필요하지 않습니다.

차량을 위한 FOTA를 소개해봅니다.

[소개]
FOTA는 소프트웨어를 무선으로 교체하는데 사용되는 기술을 총칭하는 말입니다.
현재 FOTA는 휴대폰 산업뿐만 아니라 차량에도 적용하고자 연구되고 있습니다.

최근 자동차 산업에서 S/W의 비중이 높아지고 있고 S/W결함도 자주 발견되면서
A/S비용과 RECALL 비용이 증가하고 있습니다. 그래서 앞서의 비용을 줄여보고자 FOTA가 많이 연구되고 있습니다.

현재 S/W를 업데이트하는 방법에 대한 장단점과 FOTA 도입 시 장단점을 알아보도록 하겠습니다.

[현재방법의 장단점]
현재 자동차의 S/W 교체는 유선으로 하고 있습니다. 간략한 절차를 먼저 소개하고 장단점을 알아보도록 하겠습니다.

 (간략한 절차)
 - 업데이트된 소프트웨어를 물리적인 매체에 담아 배포
 - 업데이트 기기와  차량 유선 연결
 - 전문가가 수동적으로 직접 업데이트

 (장점)
 - 전문가가 직접 수동으로 업데이트 하므로 차량에 대한 문제 발생 시 바로 확인 가능

 (단점)
 - S/W를 물리적인 매체에 담아 배포하므로 배달시간이 필요하고 비용 발생
 - 차량과 업데이트 기기를 유선으로 연결하는 시간 필요
 - 한 번에 한 개의 차량 그리고 한 개의 ECU에만 업데이트가 가능하므로 여러 개를 동시에 처리하기는 힘듦

[FOTA 도입시 장단점]
FOTA 도입시 장단점에 대해 설명합니다. 먼저 간략한 절차에 대해 소개하고 장단점을 알아보도록 하겠습니다.

 (간략한 절차)
 - 중앙 서버에 업데이트된 S/W를 넣어 놓음
 - 중앙 서버와 무선으로 연결 가능한 위치에서 사용자 혹은 전문가에 의해 업데이트

 (장점)
 - 기존 방법보다 업데이트 시간 절감(물리적인 연결시간이 필요 없고 준비시간이 크게 줄어듦)
 - 소비자 만족도 증가(기존 방법보다 빠른 시간 안에 업데이트가 가능하므로)
 - 업데이트된 소프트웨어 배포 비용 불필요
 - 여러 대의 차량을 동시에 업그레이드 가능(물리적 연결이 불필요하고 업데이트 기기 불필요 하므로)
 - 중앙 서버와 연결 가능한 위치이면 어디서든 업데이트 가능
 - A/S 비용과 RECALL 비용 감소

 (단점)
  - 무선으로 업그레이드시 사용되는 프로토콜이 알려질 경우 보안에 취약

후킹(Hooking)이란?

사전적 단어 그대로의 뜻은 '가로채다'라는 뜻 입니다. 지금 사용하는 후킹이란 용어는 '기존의 정상적으로 행동하는 프로세스나 기타 무엇인가를 살짝 가로채서 원하는 바대로 살짝쿵 바꾼다' 라는 뜻이라고 보시면 됩니다.

가상화 프로그램의 개요대로 처음에 후킹 대상 프로세스를 위해

// 후킹 대상 프로세스 추가
VOID AttachProcess (IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp);

// 후킹 대상 프로세스 제거
VOID DetachProcess (IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp);

DeviceObject에서 PID를 이용하여 후킹 대상 프로세스를 정하고 후킹을 시작합니다.
시스템콜 후킹을 위하여 사용하는 함수는 아래와 같습니다.

// 시스템콜 인덱스
#define SYSCALL_INDEX(Function)  *(PULONG)((PUCHAR)Function + 1)

// 시스템콜 후킹
#define SYSCALL_HOOK(Function, Hook, Real)  \
 Real = (PVOID) InterlockedExchange((PLONG) \
  &KeServiceDescriptorTable.ServiceTableBase[SYSCALL_INDEX(Function)], (LONG)Hook)

// 시스템콜 복원
#define SYSCALL_UNHOOK(Function, Hook, Real) \
 InterlockedExchange((PLONG)     \
  &KeServiceDescriptorTable.ServiceTableBase[SYSCALL_INDEX(Function)], (LONG)Real)

만드려는 가상화 시스템에서 현재 만들고 있는 Scanning Module에서 필요한 함수는 ZwCreateFile, ZwCreateKey, ZwSetValueKey 세가지 시스템콜 함수를 후킹 서비스를 시작함과 동시에 아래와 같이 사용하여 Real 동작을 Hook동작으로 바꾸게 합니다. (물론 그전에 Zw시리즈 시스템콜들을 Hook시리즈 시스템콜들로 바꿀 수 있도록 미리 Hook시리즈 함수를 Zw시리즈들을 이용하여 바꿔놨어야 겠죠)

SYSCALL_HOOK(ZwCreateFile,   HookCreateFile,  DeviceExt->RealCreateFile);
SYSCALL_HOOK(ZwCreateKey,   HookCreateKey,  DeviceExt->RealCreateKey);
SYSCALL_HOOK(ZwSetValueKey,  HookSetValueKey, DeviceExt->RealSetValueKey);

기본이 되는 DeviceExt는 프로세스 정보를 얻기 위해 선언한 구조체로 아래와 같습니다.
필요한 정보들만 샥샥 빼서 만든 필요하면 인자가 계속 추가되는 맘대로 구조체입니다.

// 디바이스 익스텐션
typedef struct _DEVICE_EXTENSION
{
 PDEVICE_OBJECT  DeviceObject;
 ULONG  RecentPID;
 ULONG  TargetCount;
 ULONG  TargetPID [MAX_PROCESS];
 LONG  DriverState;

 PVOID  RealCreateFile;
 PVOID  RealCreateKey;
 PVOID  RealSetValueKey;

} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

이와 같은 방식을 사용해 후킹 시스템의 기본이 되는 틀을 만들었습니다.
후킹을 통해 받아온 내부적인 정보는 다음 포스팅에서~

안녕하세요. 17기 김대욱입니다.
저는 ARTS라는 프로젝트에서 UI 디자인과 UI 구현 부분을 담당하고 있습니다.
이번 글에서는 제가 지금까지 제작된 ARTS 와 관련된 디자인 결과물들에 대해 소개해 드리겠습니다.



먼저 맨처음 디자인했던 UI입니다. 본격적인 디자인에 들어가기전, 컨셉 수준의 디자인이라, 버튼들의 그림이나 이런건 전혀 매칭이 안되지만,, 전체적으로 밝은 분위기와 가벼운 분위기를 위해 만들어 보았습니다.

그리고 팀원들에게 보여줬더니 반응이...... 그닥 좋진 못했죠 ㅠ (병들어보인다, 해골이 탓다, 눈이부시다등 ㅋ)
대부분 이번 프로젝트 "의료영상"이라는 이미지가 강해서 밝은 느낌 보단 어두운 느낌을 원햇던것 같더라구요.

그래서 2번째 컨셉을 잡아보았습니다.



전체적으로 어두운 분위기로 잡아보았는데 반응이 나쁘지 않았습니다. 메뉴와 관련된 부분은 컨셉을 정하기 위해서 ZBrush 프로그램에서 캡쳐해서 사용했는데, PL은 저 메뉴들이 무척이나 마음에 들었었다봅니다..

그래도 다른 프로그램의 메뉴를 가따 빼낄 수는 없는일!

그래서 메뉴 부분들을 새롭게 만들어 보았습니다. 배경이 검정색인지라 어설플 색갈으로 하면 버튼들이 묻혀 버리는 현상때문에 흰색으로 해봤는데 대부분 버튼들이 너무 튄다는 반응이였습니다.


그래서 검정색으로 바꿧죠, 흰색보다는 괜찮다는 반응이였습니다. (개인적으로 만족했구요)
화면 중앙에 완전 검정색부분이 실제 ART Image가 포함될 부분이며 옆부분은 ARTS File 에 대한 정보가 포함될 부분입니다.

이렇게 전체적인 UI컨셉이 잡히고 이제 세부적인 부분을 만들기로했습니다.
가장먼저 파일을 열기 위한 Open 창인데요. 아래와 같습니다.


서버측에서 파일을 가져오면 파일에 대한 정보가 표시되고 파일을 열 수 있도록 UI를 구성했습니다.
그런데 여기서 한가지 문제가 발생했는데, PACS System의 특성상 수많은 결과물들을 검색할 수 있는 기능이 필요하기 때문에, Open 창을 없애고, 검색및 열기 등의 기능을 Client Page에 Database검색과 관련된 UI를 집어 넣기로 결정했습니다.

일단 현재 작업된 부분은 여기까지이며 내일부터 지금까지 디자인된 부분을 WPF를 사용하여 실제 UI로 구현하는 작업을 시작할 계획입니다. 작업이 진행되는데로 블로그에 포스팅하도록하겠습니다.

3D Projection은 3차원 입체영상을 2차원의 평면에 매핑하는 것으로 Orthographic Projection과 Perspective Projection이 있다. ART View는 X-Ray로 촬영한 피사체를 훨씬 입체감 있게 관찰하기 위하여 Perspective Project