본문으로 이동

실시간 컴퓨팅

위키백과, 우리 모두의 백과사전.

실시간 컴퓨팅(real-time computing, RTC)은 이벤트에서 시스템 응답에 이르기까지 "실시간 제약"을 받는 하드웨어 및 소프트웨어 시스템을 일컫는 컴퓨터 과학 용어이다.[1] 실시간 프로그램은 지정된 시간 제약 내에 응답을 보장해야 하며, 이를 흔히 "마감 기한(deadline)"이라고 부른다.[2]

"실시간"이라는 용어는 시뮬레이션에서 시뮬레이션의 클록이 실제 시계와 같은 속도로 작동함을 의미할 때도 사용된다.

실시간 응답은 대개 밀리초 또는 마이크로초 단위로 이해된다. 실시간으로 작동하도록 지정되지 않은 시스템은 일반적으로 어떠한 시간 프레임 내에서의 응답도 보장할 수 없으며, 일반적이거나 예상되는 응답 시간만 제공될 수 있다. 실시간 처리는 이벤트와 관련된 지정된 마감 기한 내에 완료되지 않으면 실패한 것으로 간주된다. 마감 기한은 시스템 부하와 상관없이 항상 준수되어야 한다.

실시간 시스템은 "데이터를 수신하고, 처리하며, 그 시점에 환경에 영향을 미칠 만큼 충분히 빠르게 결과를 반환함으로써 환경을 제어하는 시스템"으로 설명된 바 있다.[3] "실시간"이라는 용어는 공정 제어 및 전사적 시스템 분야에서 "상당한 지연 없이"라는 의미로 사용된다.

실시간 소프트웨어는 병행 프로그래밍 언어, 실시간 운영체제(RTOS), 실시간 네트워크 중 하나 이상을 사용할 수 있다. 이들 각각은 실시간 소프트웨어 애플리케이션을 구축하는 데 필요한 필수 프레임워크를 제공한다.

플라이 바이 와이어 항공기 제어나 인공 심박동기와 같은 많은 안전 필수 애플리케이션에 사용되는 시스템은 실시간이어야 하며, 이 둘 모두 즉각적이고 정확한 기계적 응답을 요구한다.[4]

역사

[편집]

실시간이라는 용어는 초기 시뮬레이션에서 파생되었는데, 이때 실제 프로세스가 실제 프로세스와 일치하는 속도로 시뮬레이션되었다(모호함을 피하기 위해 현재는 실시간 시뮬레이션이라 부른다). 아날로그 컴퓨터가 초기에 실시간 시뮬레이션에 사용되었다.

미니컴퓨터는 특히 1970년대 이후 디지털 온스크린 그래픽(DOG) 스캐너와 같은 전용 임베디드 시스템에 내장되면서, 들어오는 데이터와의 중요한 상호작용에 대해 낮은 지연 시간의 우선순위 기반 응답이 필요해졌다. 데이터 제너럴의 RDOS(Real-Time Disk Operating System) 및 백그라운드-포그라운드 스케줄링을 갖춘 RTOS, 그리고 디지털 이큅먼트 코퍼레이션의 RT-11과 같은 운영체제가 이 시대부터 시작되었다. 백그라운드-포그라운드 스케줄링은 포그라운드 작업이 실행될 필요가 없을 때 낮은 우선순위 작업에 CPU 시간을 할당하고, 포그라운드 내에서는 가장 높은 우선순위를 가진 스레드/작업에 절대적인 우선순위를 부여했다. 실시간 운영체제는 시분할 시스템 다중 사용자 작업에도 사용되었다. 예를 들어, 데이터 제너럴 비즈니스 베이직(Data General Business Basic)은 RDOS의 포그라운드나 백그라운드에서 실행될 수 있었으며, 더미 터미널을 통해 상호작용하는 사용자들에게 더 적합하도록 스케줄링 알고리즘에 추가적인 요소를 도입했다.

초기 개인용 컴퓨터도 때때로 실시간 컴퓨팅에 사용되었다. 다른 인터럽트를 비활성화할 수 있었기 때문에 정의된 타이밍을 가진 하드코딩된 루프가 가능했고, 낮은 인터럽트 지연 시간 덕분에 사용자 인터페이스와 디스크 드라이브의 우선순위를 실시간 스레드보다 낮게 설정하여 실시간 운영체제를 구현할 수 있었다. 이와 비교하여 인텔 X86 계열 CPU의 프로그래머블 인터럽트 컨트롤러는 매우 큰 지연 시간을 발생시키며, 윈도우 운영체제는 실시간 운영체제가 아닐 뿐더러 네이티브 기계어 코드를 사용하여 모든 인터럽트 윈도우 코드를 우회하지 않는 한, 프로그램이 CPU를 완전히 점유하여 독자적인 스케줄러를 사용하는 것을 허용하지 않는다. 그러나 다양한 운영체제에서 고급 언어로 실시간 기능을 제공하는 몇몇 코딩 라이브러리가 존재하며, 예를 들어 실시간 자바(Real-time Java)가 있다. 모토로라 68000 및 그 후속 계열(68010, 68020, 콜드파이어(ColdFire) 등)과 같은 후기 마이크로프로세서들도 산업 제어 시스템 제조업체들 사이에서 인기를 얻었다. 이 애플리케이션 영역은 실시간 제어가 공정 성능과 안전성 측면에서 실질적인 이점을 제공하는 분야이다.

실시간 컴퓨팅의 기준

[편집]

운영의 전체적인 정확성이 논리적 정확성뿐만 아니라 수행되는 시간에도 의존할 경우 해당 시스템을 실시간 시스템이라고 한다.[5] 실시간 시스템과 그 마감 기한은 마감 기한을 놓쳤을 때의 결과에 따라 분류된다.[6]

  • 하드(Hard) – 마감 기한을 놓치면 전체 시스템 장애가 발생한다.
  • 펌(Firm) – 드물게 마감 기한을 놓치는 것은 허용되지만 시스템의 서비스 품질이 저하될 수 있다. 마감 기한 이후 결과의 유용성은 0이다.
  • 소프트(Soft) – 마감 기한 이후 결과의 유용성이 점차 감소하여 시스템의 서비스 품질이 저하된다.

따라서 하드 실시간 시스템의 목표는 모든 마감 기한을 준수하는 것이지만, 소프트 실시간 시스템의 목표는 특정 애플리케이션 기준을 최적화하기 위해 마감 기한의 일부를 준수하는 것으로 바뀐다. 최적화되는 특정 기준은 애플리케이션에 따라 다르지만, 전형적인 예로는 마감 기한을 준수한 작업 수 최대화, 작업의 지연 시간 최소화, 마감 기한을 준수한 우선순위가 높은 작업 수 최대화 등이 있다.

하드 실시간 시스템은 엄격한 마감 기한 내에 이벤트에 반응하는 것이 필수적일 때 사용된다. 이러한 강력한 보장은 특정 시간 간격 내에 반응하지 않을 경우 어떠한 방식으로든 큰 손실을 초래하거나, 특히 환경에 물리적 피해를 주거나 인명에 위협이 되는 시스템에 요구된다(엄격한 정의는 단순히 마감 기한을 놓치는 것이 곧 시스템의 실패라는 것이다). 하드 실시간 시스템의 몇 가지 예는 다음과 같다.

  • 자동차 내연기관 제어 시스템은 지연된 신호가 엔진 고장이나 손상을 일으킬 수 있기 때문에 하드 실시간 시스템이다.
  • 인공 심박동기와 같은 의료 시스템. 심박동기의 작업은 간단하지만 인명에 대한 잠재적 위험 때문에, 이러한 의료 시스템은 일반적으로 철저한 테스트와 인증을 거쳐야 하며, 이는 실패 가능성이 낮거나 불가능하다는 것을 증명하기 위해 하드 실시간 컴퓨팅을 필요로 한다.
  • 조립 라인의 기계와 같은 산업 공정 제어기. 기계가 지연되면 조립 라인의 품목이 기계의 도달 범위를 벗어나거나(제품이 처리되지 않음), 잘못된 시간에 로봇이 작동하여 기계나 제품이 손상될 수 있다. 실패가 감지되면 두 경우 모두 조립 라인이 멈추게 되어 생산이 느려진다. 실패가 감지되지 않으면 결함이 있는 제품이 생산 단계를 통과하거나 이후 생산 단계에서 손상을 유발할 수 있다.
  • 하드 실시간 시스템은 일반적으로 임베디드 시스템에서 물리적 하드웨어와 낮은 수준에서 상호작용한다. 아타리 2600이나 Cinematronics 벡터 그래픽과 같은 초기 비디오 게임 시스템은 그래픽과 타이밍 하드웨어의 특성 때문에 하드 실시간 요구 사항을 가지고 있었다.
  • 소프트모뎀은 컴퓨터의 CPU에서 실행되는 소프트웨어로 하드웨어 모뎀을 대체한다. 소프트웨어는 출력할 다음 오디오 데이터를 생성하기 위해 밀리초마다 실행되어야 한다. 데이터가 늦어지면 수신 모뎀은 동기화를 잃게 되고, 동기화가 재설정되는 동안 긴 중단이 발생하거나 연결이 완전히 끊길 수 있다.
  • 많은 유형의 프린터는 하드 실시간 요구 사항을 가진다. 예를 들어 잉크젯(프린트 헤드가 페이지를 가로지를 때 정확한 시간에 잉크가 분사되어야 함), 레이저 프린터(빔이 회전 드럼을 가로질러 스캔할 때 정확한 시간에 레이저가 활성화되어야 함), 그리고 도트 매트릭스 및 다양한 유형의 라인 프린터(출력물과 정렬될 때 정확한 시간에 충격 메커니즘이 활성화되어야 함) 등이 있다. 이 중 하나라도 실패하면 출력이 누락되거나 잘못 정렬된다.

다중작업 시스템의 맥락에서 스케줄링 정책은 일반적으로 우선순위 기반(다중 처리 기반 스케줄러)이다. 어떤 상황에서는 작업 세트와 그 우선순위를 미리 알 수 있는 경우 등에 한해 하드 실시간 성능을 보장할 수 있다. 범용 시스템에서는 흔하지 않으나 비율 단조 스케줄링과 같은 다른 하드 실시간 스케줄러도 존재하는데, 이는 작업을 스케줄링하기 위해 추가 정보, 즉 작업이 실행되는 데 걸리는 시간에 대한 경계나 최악의 경우 추정치가 필요하다. 하드 실시간 작업을 스케줄링하기 위한 특정 알고리즘으로는 Earliest deadline first가 존재하며, 이는 문맥 교환 오버헤드를 무시하면 100% 미만의 시스템 부하에서 충분하다.[7] 적응형 파티션 스케줄러와 같은 새로운 오버레이 스케줄링 시스템은 하드 실시간 및 비 실시간 애플리케이션이 혼합된 대규모 시스템을 관리하는 데 도움을 준다.

펌 실시간 시스템은 다소 모호하게 정의되며, 일부 분류에서는 하드 및 소프트 실시간 시스템만 구별하고 펌 실시간 시스템을 포함하지 않기도 한다. 펌 실시간 시스템의 몇 가지 예는 다음과 같다.

  • 앞에서 하드 실시간으로 설명한 조립 라인 기계는 대신 펌 실시간으로 간주될 수 있다. 마감 기한을 놓치면 여전히 해결해야 할 오류가 발생한다. 불량품으로 표시하거나 조립 라인에서 배출하는 기계 장치가 있을 수 있고, 운영자가 문제를 해결할 수 있도록 조립 라인을 멈출 수도 있다. 그러나 이러한 오류가 드물게 발생한다면 허용될 수 있다.

소프트 실시간 시스템은 일반적으로 병행 액세스 문제와 변화하는 상황에 맞춰 연결된 다수의 시스템을 최신 상태로 유지해야 하는 필요성을 해결하는 데 사용된다. 소프트 실시간 시스템의 예는 다음과 같다.

  • 상업용 항공사의 비행 계획을 유지하고 업데이트하는 소프트웨어. 비행 계획은 합리적으로 최신 상태를 유지해야 하지만, 수 초의 지연 시간으로도 작동할 수 있다.
  • 라이브 오디오-비디오 시스템도 일반적으로 소프트 실시간이다. 늦게 재생되는 오디오 프레임은 짧은 오디오 글리치를 일으킬 수 있지만(후속 오디오가 모두 그에 맞춰 지연되어 오디오가 정상보다 느리게 재생되는 것처럼 느껴질 수 있음), 이는 침묵, 잡음, 이전 오디오 프레임 또는 추정 데이터를 계속 재생하는 것보다 나을 수 있다. 지연된 비디오 프레임은 시청자에게 보통 더 적은 방해를 준다. 시스템은 계속 작동할 수 있으며 작업 부하 예측 및 재구성 방법론을 사용하여 향후 복구할 수도 있다.[8]
  • 마찬가지로, 비디오 게임도 종종 소프트 실시간이며, 특히 목표 프레임 레이트를 맞추려 할 때 그렇다. 다음 이미지는 플레이어의 입력에 따라 달라지기 때문에 미리 계산할 수 없으며, 비디오 프레임을 표시하기 전에 해당 프레임을 생성하는 데 필요한 모든 컴퓨팅을 수행하는 데 짧은 시간만이 주어진다. 마감 기한을 놓치면 게임은 더 낮은 프레임 레이트로 계속될 수 있다. 게임에 따라 그래픽에만 영향을 미치거나(게임 플레이는 정상 속도로 유지됨), 게임 플레이 자체가 느려질 수도 있다(이는 초기 3세대 및 4세대 게임기에서 흔했다).

디지털 신호 처리에서의 실시간

[편집]

실시간 디지털 신호 처리(DSP) 프로세스에서 분석(입력) 및 생성(출력)된 샘플은 처리 지연과 관계없이 동일한 샘플 세트를 입력하고 출력하는 데 걸리는 시간 동안 연속적으로 처리(또는 생성)될 수 있다.[9] 이는 처리 시간이 무제한으로 계속되더라도 처리 지연이 제한되어야 함을 의미한다. 오버헤드를 포함한 샘플당 평균 처리 시간은 샘플링 속도의 역수인 샘플링 주기보다 크지 않다. 이는 샘플들을 큰 세그먼트로 묶어 블록 단위로 처리하는지, 개별적으로 처리하는지, 그리고 긴, 짧은, 또는 존재하지 않는 데이터 버퍼가 있는지 여부에 대한 기준이 된다.

오디오 신호 처리 예를 고려해 보자. 만약 어떤 프로세스가 2.00초의 사운드를 분석, 합성 또는 처리하는 데 2.01초가 걸린다면 그것은 실시간이 아니다. 그러나 1.99초가 걸린다면, 그것은 실시간 DSP 프로세스이거나 실시간으로 만들 수 있다.

일상적인 삶의 비유로는 식료품점에서 계산을 기다리는 줄이나 대기열에 서 있는 것을 들 수 있다. 만약 줄이 제한 없이 점근적으로 길어진다면 계산 프로세스는 실시간이 아니다. 줄의 길이가 제한되어 있고 고객들이 대기열에 합류하는 속도만큼 평균적으로 빠르게 서비스된다면, 그 프로세스는 실시간이다. 식료품점은 계산 프로세스를 실시간으로 만들지 못하면 손님을 잃게 될 것이므로, 이 프로세스가 실시간이라는 것은 근본적으로 중요하다.

입력 데이터 흐름을 따라가지 못하고 출력이 입력보다 계속해서 뒤처지는 신호 처리 알고리즘은 실시간이 아니다. 무제한으로 작동하는 프로세스에 관하여 출력의 지연(입력 대비)이 제한되어 있다면, 처리량 지연이 매우 길더라도 해당 신호 처리 알고리즘은 실시간이다.

라이브와 실시간

[편집]

실시간 신호 처리는 라이브 이벤트 지원과 같은 곳에서 요구되는 라이브 신호 처리를 위해 필요하지만 그 자체만으로는 충분하지 않다. 라이브 오디오 디지털 신호 처리는 실시간 동작과 처리량 지연에 대한 충분한 제한이 모두 필요하며, 이는 스테이지 모니터나 인이어 모니터를 사용하는 연주자에게 견딜 수 있고, 연주자를 직접 보는 관객에게 립싱크 오류로 느껴지지 않을 정도여야 한다. 라이브 실시간 처리에 대한 허용 가능한 지연 시간의 한계는 조사와 토론의 대상이지만, 6~20 밀리초 사이로 추정된다.[10]

실시간 양방향 전기 통신 지연이 300 밀리초 미만("왕복" 또는 단방향 지연의 두 배)인 경우, 대화 중 원치 않는 "말 끊김"을 피하기 위해 "허용 가능한" 것으로 간주된다.

실시간과 고성능

[편집]

실시간 컴퓨팅은 때때로 고성능 컴퓨팅으로 오해되기도 하지만, 이는 정확한 분류가 아니다.[11] 예를 들어, 과학 시뮬레이션을 실행하는 거대한 슈퍼컴퓨터는 인상적인 성능을 제공할 수 있지만 실시간 컴퓨팅을 수행하는 것은 아니다. 반대로, 안티락 브레이크 시스템을 위한 하드웨어와 소프트웨어가 마감 기한을 충족하도록 설계되고 나면, 더 이상의 성능 향상은 의무적이거나 유용하지도 않다. 게다가 네트워크 서버에 네트워크 트래픽이 많이 몰리면 응답 시간이 느려질 수 있지만, (대부분의 경우) 시간 초과(마감 기한 도달) 전에 성공할 것이다. 따라서 그러한 네트워크 서버는 실시간 시스템으로 간주되지 않는다. 시간적 실패(지연, 시간 초과 등)는 일반적으로 작고 구획화되어(영향이 제한됨) 있으며 치명적 장애는 아니다. FTSE 100 지수와 같은 실시간 시스템에서는 한계를 넘어서는 둔화는 종종 애플리케이션 맥락에서 치명적인 것으로 간주된다. 실시간 시스템의 가장 중요한 요구 사항은 높은 처리량이 아니라 일관된 출력이다.

많은 컴퓨터 체스 프로그램과 같은 일부 소프트웨어는 두 범주 모두에 해당할 수 있다. 예를 들어, 시계가 있는 토너먼트에서 게임을 하도록 설계된 체스 프로그램은 특정 마감 기한 전에 수를 결정해야 하며 게임에서 지지 않아야 하므로 이는 실시간 컴퓨팅이다. 하지만 움직이기 전에 무기한으로 실행되도록 허용된 체스 프로그램은 그렇지 않다. 두 경우 모두 고성능은 바람직하다. 토너먼트 체스 프로그램은 주어진 시간에 더 많은 작업을 수행할수록 더 나은 수를 두게 되고, 제약이 없는 체스 프로그램은 더 빨리 실행될수록 더 빨리 수를 둘 수 있다. 이 예는 실시간 컴퓨팅과 다른 컴퓨팅 사이의 본질적인 차이를 보여준다. 토너먼트 체스 프로그램이 주어진 시간 내에 다음 수에 대한 결정을 내리지 못하면 게임에서 지게 된다(실시간 컴퓨팅으로서 실패함). 반면, 다른 시나리오에서는 마감 기한을 맞추는 것이 필요하지 않다고 가정한다. 고성능은 주어진 시간에 수행되는 처리량을 나타내는 반면, 실시간은 사용 가능한 시간 내에 유용한 출력을 얻기 위해 처리를 끝낼 수 있는 능력이다.

준 실시간

[편집]

전기 통신 및 컴퓨팅에서 "준 실시간(near real-time)" 또는 "거의 실시간"이라는 용어는 이벤트 발생과 처리된 데이터의 사용(디스플레이, 피드백 및 제어 목적 등) 사이에 자동화된 데이터 처리 또는 통신 네트워크 전송으로 인해 발생하는 시간 지연을 의미한다. 예를 들어, 준 실시간 디스플레이는 현재 시간에서 처리 시간을 뺀 시점에 존재했던 상황이나 이벤트를 라이브 이벤트 시간에 가깝게 묘사한다.[12]

"준 실시간"과 "실시간" 용어의 구분은 다소 모호하며 상황에 맞게 정의되어야 한다. 이 용어는 상당한 지연이 없음을 의미한다.[12] 많은 경우, "실시간"으로 묘사되는 처리는 사실 "준 실시간"으로 묘사하는 것이 더 정확할 것이다.

준 실시간은 음성 및 비디오의 지연된 실시간 전송을 의미하기도 한다. 이는 전체 대용량 비디오 파일이 다운로드될 때까지 기다릴 필요 없이 비디오 이미지를 대략 실시간으로 재생할 수 있게 한다. 호환되지 않는 데이터베이스는 다른 데이터베이스가 예약된 방식으로 가져오기/내보내기를 할 수 있는 일반적인 플랫 파일로 내보내기/가져오기를 하여 "준 실시간"으로 공통 데이터를 동기화/공유할 수 있다.

설계 방법

[편집]

실시간 시스템 설계를 돕기 위해 여러 방법이 존재하며, 그 예로 시스템의 병행성 구조를 표현하는 성공적인 오래된 방법인 MASCOT이 있다. 다른 예로는 HOOD, 실시간 UML, AADL, 레이븐스카 프로파일, 실시간 자바(Real-time Java) 등이 있다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “FreeRTOS – Open Source RTOS Kernel for small embedded systems – What is FreeRTOS FAQ?” (미국 영어). 《FreeRTOS》. 2021년 3월 8일에 확인함.
  2. ↑ Ben-Ari, Mordechai; "Principles of Concurrent and Distributed Programming", ch. 16, Prentice Hall, 1990, ISBN 0-13-711821-X, p. 164
  3. ↑ Martin, James (1965). 《Programming Real-time Computer Systems》 (미국 영어). Englewood Cliffs, New Jersey: Prentice-Hall Incorporated. 4쪽. ISBN 978-0-13-730507-0.
  4. ↑ Kant, Krishna (May 2010). 《Computer-Based Industrial Control》. PHI Learning. 356쪽. ISBN 9788120339880. 2015년 1월 17일에 확인함.
  5. ↑ Shin, Kang G.; Ramanathan, Parameswaran (Jan 1994). “Real-time computing: a new discipline of computer science and engineering” (PDF). 《Proceedings of the IEEE》 82 (1): 6–24. Bibcode:1994IEEEP..82....6S. CiteSeerX 10.1.1.252.3947. doi:10.1109/5.259423. ISSN 0018-9219.
  6. ↑ Kopetz, Hermann (1997). 《Real-Time Systems: Design Principles for Distributed Embedded Applications》 [en] (PDF). Kluwer Academic Publishers. 12–14쪽. ISBN 0-306-47055-1.
  7. ↑ Liu, Chang L.; and Layland, James W.; "Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment", Journal of the ACM, 20(1):46-61, January 1973, http://citeseer.ist.psu.edu/liu73scheduling.html
  8. ↑ Menychtas, Andreas; Kyriazis, Dimosthenis; Tserpes, Konstantinos (July 2009). “Real-time reconfiguration for guaranteeing QoS provisioning levels in Grid environments”. 《Future Generation Computer Systems》 25 (7): 779–784. doi:10.1016/j.future.2008.11.001.
  9. ↑ Kuo, Sen M.; Lee, Bob H.; and Tian, Wenshun; "Real-Time Digital Signal Processing: Implementations and Applications", Wiley, 2006, ISBN 0-470-01495-4, Section 1.3.4: Real-Time Constraints.
  10. ↑ Kudrle, Sara; Proulx, Michel; Carrieres, Pascal; Lopez, Marco 외 (July 2011). “Fingerprinting for Solving A/V Synchronization Issues within Broadcast Environments”. 《SMPTE Motion Imaging Journal》 120 (5): 36–46. doi:10.5594/j18059XY. Appropriate A/V sync limits have been established and the range that is considered acceptable for film is +/- 22 ms. The range for video, according to the ATSC, is up to 15 ms lead time and about 45 ms lag time
  11. ↑ Stankovic, John (1988), “Misconceptions about real-time computing: a serious problem for next-generation systems”, 《Computer》 (IEEE Computer Society) 21 (10), 11쪽, Bibcode:1988Compr..21j..10S, doi:10.1109/2.7053, S2CID 13884580
  12. 1 2 “Federal Standard 1037C: Glossary of Telecommunications Terms”. Its.bldrdoc.gov. 2014년 4월 26일에 확인함.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=실시간_컴퓨팅&oldid=42394021"