선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 본 논문에서는 대표적인 실시간 임베디드 리눅스인 RTAI와 Xenomai를 IPC(Inter Process Communication) 관점에서 시간적 성능 분석한다. 성능 분석은 실시간 시스템 구현의 기본이 되는 실시간 타스크의 주기성을 분석하고, 실시간 메커니즘으로 타스크 간 동기화와 통신에 가장 많이 사용되는 세마포어(Semaphore), 실시간 FIFO(First-In First Out), 메일박스(Mailbox) 및 메시지큐(Message Queue)의 시간적 성능을 분석한다.
- . 본 논문에서는 선행 연구결과를 바탕으로 타스크의 주기가 변화할 경우에 실시간 메커니즘의 시간적 성능을 분석한다. 대부분의 실시간 시스템에서 사용되는 실시간 타스크가 주기적인 특성을 갖는다는 점에서 다양한 주기에서의 실시간 메커니즘의 성능 변화에 대한 연구가 필요하다.
- 대부분의 실시간 시스템에서 사용되는 실시간 타스크가 주기적인 특성을 갖는다는 점에서 다양한 주기에서의 실시간 메커니즘의 성능 변화에 대한 연구가 필요하다. 본 연구는 실시간 시스템을 구현하기 위해 다양한 주기의 실시간 타스크를 구현하여야 한다는 점에서 처음 시도 되는 매우 유용한 결과이다. 추후, 결과에 따른 오픈 소스 분석을 수행한다면 최적의 실시간 메커니즘을 가지는 실시간 임베디드 리눅스 구현이 가능할 것으로 기대된다.
제안 방법
- 실험은 위의 일련의 과정을 수행하는데 걸린 시간을 측정하였다. FIFO 는 읽기와 쓰기를 모두 지원하는 모드로 사용이 불가능하여 양방향 자료 전송을 위해 두 개의 FIFO를 사용하였다. Xenomai의 경우 FIFO가 메시지 파이프 (Message Pipe)로 정의 되어있다.
- 6은 세마포어의 시간적 성능 분석을 위한 의사코드이다. Task1이 세마포어를 양도한 시점부터 Task2가 세마포어를 획득한 시점까지 걸린 시간을 측정하였다. 즉, Task1이 세마포어를 양도하고 Task2로 Context Switch가 일어나고 Task2가 세마포어를 획득하기까지 걸린 시간을 측정하여 결과를 Fig.
- 타스크가 처음 실행되면 원하는 주기를 설정하고 타스크가 주기적으로 실행되게 만든다. 그 다음 각각의 실시간 임베디드 리눅스가 제공하는 API를 이용하여 타스크가 처음 설정한 주기에 정확히 실행되는지 보기 위해 시간을 측정한다. 각각의 주기에 대한 실험 결과는 Fig.
- 본 실험은 커널 공간에서 프로그램을 작성하였고, 실험의 용이성을 위하여 모듈 구조를 이용하여 구현하였다. 그리고 모든 성능 분석은 커널 메시지 함수를 이용하여 수행 후 확인하는 절차를 거쳤다. 따라서 데이터 처리에 따른 지연 시간을 배제하였다.
- 데이터 전송에 사용되는 메일박스와 메시지큐의 경우 RTAI는 메일박스, Xenomai는 메시지큐만 API를 제공하고 있다. 따라서 본 논문에서는 성능 분석을 RTAI에서는 메일박스로 그리고 Xenomai에서는 메시지큐를 이용하여 Fig. 14와 같은 구조의 데이터 전송에 사용되는 실시간 메커니즘의 성능을 분석하였다.
- 실시간 시스템은 다양한 주기로 구현되며 일반적인 RTOS의 경우 10[ms]를 기본으로 하여 이에 정수 배의 주기로 실시간 타스크를 구현한다. 따라서 본 논문에서는 타스크의 주기에 따른 실시간 메커니즘의 성능 차이를 보기 위해 타스크의 주기를 10[ms], 30[ms], 50[ms]로 변경하며 실시간 메커니즘의 응답 시간을 측정하였다. 타스크의 주기가 변경되어도 실험 구조는 동일하다.
- 따라서 데이터 처리에 따른 지연 시간을 배제하였다. 또한 스케 줄링에 의한 지연을 방지하기 위하여 항상 하나의 모듈을 커널에 구동하여 실험하였다. 그러나 이와 같이 진행하여도 리눅스에 기본적으로 동작하는 프로세스가 존재하기 때문에 성능의 비교를 파악할 수 있도록 50 번의 실험을 반복하였다.
- 14에 나타낸 의사코드와 같은 구조로 Task1이 Task2에 메시지를 전달하고, 다시 Task2로부터 메시지를 받는 데까지 소요된 시간을 측정하였다. 또한 주기를 변경하며 주기에 따른 시간적 성능 차이를 분석하였다. 실험 결과는 Fig.
- 성능 분석은 실시간 시스템 구현의 기본이 되는 실시간 타스크의 주기성을 분석하고, 실시간 메커니즘으로 타스크 간 동기화와 통신에 가장 많이 사용되는 세마포어(Semaphore), 실시간 FIFO(First-In First Out), 메일박스(Mailbox) 및 메시지큐(Message Queue)의 시간적 성능을 분석한다. 본 논문에서 수행한 실시간 메커니즘의 시간적 성능 분석은 상용 RTOS 및 최근에 개발된 uC/OS-III의 성능 분석 방식과 동일한 방식으로 수행되었다 [14].
- 본 논문에서는 선행 연구 결과를 바탕으로 타스크의 주기에 따라 데이터 전송 및 동기화에 사용되는 실시간 메커니즘을 다양한 주기적 타스크에 대하여 시간적 성능을 분석하였다. 본 연구의 결과는 실시간 시스템의 타스크가 주기적 타스크로 구현되며 그 안에서 실시간 메커니즘을 사용한다는 관점에서 실시간 시스템의 성능을 예측하는 가장 기초적인 자료를 제공하고 있어서 매우 유용한 정보이다.
- 따라서 RTAI나 Xenomai를 사용하기 위해서는 운영체제가 필요하다. 본 논문에서는 호환성 검토와 실험을 통하여 아래와 같은 개발 환경에서 최신 리눅스 커널을 활용하여 RTAI와 Xenomai를 구현하였다. 자세한 구현 과정은 선행 연구에서 다뤘다 [13].
- 본 실험은 커널 공간에서 프로그램을 작성하였고, 실험의 용이성을 위하여 모듈 구조를 이용하여 구현하였다. 그리고 모든 성능 분석은 커널 메시지 함수를 이용하여 수행 후 확인하는 절차를 거쳤다.
- 본 논문에서는 대표적인 실시간 임베디드 리눅스인 RTAI와 Xenomai를 IPC(Inter Process Communication) 관점에서 시간적 성능 분석한다. 성능 분석은 실시간 시스템 구현의 기본이 되는 실시간 타스크의 주기성을 분석하고, 실시간 메커니즘으로 타스크 간 동기화와 통신에 가장 많이 사용되는 세마포어(Semaphore), 실시간 FIFO(First-In First Out), 메일박스(Mailbox) 및 메시지큐(Message Queue)의 시간적 성능을 분석한다. 본 논문에서 수행한 실시간 메커니즘의 시간적 성능 분석은 상용 RTOS 및 최근에 개발된 uC/OS-III의 성능 분석 방식과 동일한 방식으로 수행되었다 [14].
- 그러나 이와 같이 진행하여도 리눅스에 기본적으로 동작하는 프로세스가 존재하기 때문에 성능의 비교를 파악할 수 있도록 50 번의 실험을 반복하였다. 실시간 메커니즘들의 수행시간 측정은 각각 RTOS들이 제공해주는 API를 이용하여 시간을 측정하였다.
- 실험은 Fig. 14에 나타낸 의사코드와 같은 구조로 Task1이 Task2에 메시지를 전달하고, 다시 Task2로부터 메시지를 받는 데까지 소요된 시간을 측정하였다. 또한 주기를 변경하며 주기에 따른 시간적 성능 차이를 분석하였다.
- 10은 커널공간의 Task1이 실시간 FIFO를 통하여 사용자 공간의 타스크로 데이터를 전달하고 다시 사용자 공간에서 커널 공간의 타스크로 데이터를 전달하는 구조를 의사코드로 나타내었다. 실험은 위의 일련의 과정을 수행하는데 걸린 시간을 측정하였다. FIFO 는 읽기와 쓰기를 모두 지원하는 모드로 사용이 불가능하여 양방향 자료 전송을 위해 두 개의 FIFO를 사용하였다.
이론/모형
- 일반적으로 임베디드 시스템에 사용되는 범용 운영 체제는 실시간 시스템이 요구하는 성능을 보장하지 못하여 제어에 어려움을 겪게 된다. 따라서 실시간 시스템이 요구하는 비동기적인 반응에 대하여 미리 정해진 시간에 예측 가능한 방법으로 신뢰성 있는 출력을 보장하기 위해 RTOS를 사용한다. 실시간 운영체제는 임베디드 운영체제 중에서 시간을 제어할 수 있는 기능이 포함된 운영체제로 상용 RTOS와 오픈 소스로 진행 중인 실시간 임베디드 리눅스로 구분지을 수 있다 [1-4].
성능/효과
- 또한 스케 줄링에 의한 지연을 방지하기 위하여 항상 하나의 모듈을 커널에 구동하여 실험하였다. 그러나 이와 같이 진행하여도 리눅스에 기본적으로 동작하는 프로세스가 존재하기 때문에 성능의 비교를 파악할 수 있도록 50 번의 실험을 반복하였다. 실시간 메커니즘들의 수행시간 측정은 각각 RTOS들이 제공해주는 API를 이용하여 시간을 측정하였다.
- 실험 결과를 보면 타스크의 주기가 짧아질수록 RTAI와 Xenomai 모두 수행시간이 감소하였다. 또한 모든 주기에서 RTAI가 제공하는 실시간 FIFO가 Xenomai에서 제공하는 메시지 파이프에 비해 모든 주기에서 짧은 응답 시간 특성을 나타내었고, 더 낮은 최악의 응답 시간을 보장하고 있다.
- 본 논문에서는 선행 연구 결과를 바탕으로 타스크의 주기에 따라 데이터 전송 및 동기화에 사용되는 실시간 메커니즘을 다양한 주기적 타스크에 대하여 시간적 성능을 분석하였다. 본 연구의 결과는 실시간 시스템의 타스크가 주기적 타스크로 구현되며 그 안에서 실시간 메커니즘을 사용한다는 관점에서 실시간 시스템의 성능을 예측하는 가장 기초적인 자료를 제공하고 있어서 매우 유용한 정보이다. 또한 실시간 임베디드 리눅스의 경우 사용을 위한 노력에 집중되고 성능 분석에 대한 연구가 없었다는 점에서 매우 귀중한 결과이다.
- 실험 결과를 보면 타스크의 주기가 짧아질수록 RTAI와 Xenomai 모두 수행시간이 감소하였다. 또한 모든 주기에서 RTAI가 제공하는 실시간 FIFO가 Xenomai에서 제공하는 메시지 파이프에 비해 모든 주기에서 짧은 응답 시간 특성을 나타내었고, 더 낮은 최악의 응답 시간을 보장하고 있다.
- 실험 결과를 살펴보면 Xenomai가 세마포어를 양도하고 다른 타스크가 이를 획득하는데 걸리는 시간이 모든 주기에서 RTAI보다 짧게 소요되는 모습을 볼 수 있다. 또한 RTAI의 경우 주기가 짧을수록 Fig.
- 실험결과는 Fig. 15~17에서 볼 수 있듯이 RTAI에서 제공하는 실시간 메커니즘인 메일박스에 비해 Xenomai의 메시지큐가 데이터 전송에 우수한 시간적 반응 특성을 나타내었고, 타스크의 주기에 따른 수행시간의 차이는 거의 나타나지 않았다. 다만 RTAI의 메일박스의 경우 타스크의 주기가 감소할수록 Fig.
- 실험결과를 요약하면 타스크의 주기성은 주기에 따라 RTAI와 Xenomai가 성능차이를 보였으며, 실시간 메커니즘의 경우 FIFO는 RTAI가 세마포어 및 메시지 전달 메커니즘은 Xenomai가 모든 주기에서 우수한 시간적 응답 특성을 나타내었다.
- 30[ms] 주기에서는 RTAI와 Xenomai의 오차의 평균이 비슷하게 나타났고 10[ms]주기에서는 50[ms]와는 달리 RTAI가 Xenomai에 비해 오차의 평균값이 2배 가까이 줄어드는 모습을 볼 수 있다. 즉 타스크의 주기가 짧을수록 RTAI가 Xenomai 에 비해 정확한 시간에 타스크가 실행되었고 주기가 길수록 Xenomai가 RTAI에 비해 정확한 시간에 타스크가 실행되었다. 또한 RTAI의 경우 타스크의 주기가 감소할수록 오차가 현저하게 줄어드는 모습을 볼 수 있다.
후속연구
- 향후 오픈 소스로 구현된 실시간 시스템의 메커니즘 분석을 통하여 앞선 실험 결과에 대한 원인을 정확히 파악하고자 한다. 또한 최적의 실시간 메커니즘을 구현한다면 우수한 성능의 실시간 임베디드 리눅스를 구현할 수 있을 것으로 기대된다.
- 본 연구는 실시간 시스템을 구현하기 위해 다양한 주기의 실시간 타스크를 구현하여야 한다는 점에서 처음 시도 되는 매우 유용한 결과이다. 추후, 결과에 따른 오픈 소스 분석을 수행한다면 최적의 실시간 메커니즘을 가지는 실시간 임베디드 리눅스 구현이 가능할 것으로 기대된다.
- 향후 오픈 소스로 구현된 실시간 시스템의 메커니즘 분석을 통하여 앞선 실험 결과에 대한 원인을 정확히 파악하고자 한다. 또한 최적의 실시간 메커니즘을 구현한다면 우수한 성능의 실시간 임베디드 리눅스를 구현할 수 있을 것으로 기대된다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.