실시간 컴퓨팅

Real-time computing
실시간 통신 또는 실시간 클럭과 혼동하지 마십시오.이 테크놀로지는 종종 RTC로 약칭되기도 합니다.

실시간 컴퓨팅(RTC)은 이벤트부터 시스템 [1]응답까지 "실시간 제약"을 받는 하드웨어 및 소프트웨어 시스템을 가리키는 컴퓨터 과학 용어입니다.실시간 프로그램은 종종 "데드라인"[2]이라고 하는 지정된 시간 제한 내에 응답을 보장해야 합니다.

실시간 응답은 보통 밀리초, 때로는 마이크로초 정도로 이해됩니다.실시간 가동으로 지정되지 않은 시스템은 통상적인 응답시간 또는 예상되는 응답시간을 제공할 수 있지만 일반적으로 어떤 시간 내에 응답을 보장할 수 없습니다.이벤트와 관련하여 지정된 기한 내에 완료되지 않으면 실시간 처리가 실패합니다.시스템 부하에 관계없이 항상 기한을 지켜야 합니다.

실시간 시스템은 "데이터를 수신하고 처리하여 그 결과를 그 당시 환경에 영향을 미칠 만큼 신속하게 반환함으로써 환경을 제어하는 시스템"으로 기술되어 왔다.[3]"실시간"이라는 용어는 시뮬레이션 클럭이 실제 클럭과 동일한 속도로 실행된다는 의미로도 사용되며 프로세스 제어 및 엔터프라이즈 시스템에서는 "큰 지연 없이"라는 의미로도 사용됩니다.

실시간 소프트웨어는 다음 중 하나 이상을 사용할 수 있습니다.동기 프로그래밍 언어, 실시간 운영 체제(RTOS) 및 실시간 네트워크 각각이 실시간 소프트웨어 애플리케이션을 구축하는 데 필수적인 프레임워크를 제공합니다.

많은 안전 중요 애플리케이션에 사용되는 시스템은 플라이 바이 와이어 항공기 또는 ABS(안티 브레이크)의 제어와 같이 실시간이어야 하며, 이 두 가지 시스템은 즉각적이고 정확한 기계적 [4]대응을 요구한다.

역사

실시간이라는 용어는 실제 프로세스가 실제 프로세스와 일치하는 속도로 시뮬레이션되는 초기 시뮬레이션에서 사용되었기 때문에 유래되었습니다(현재는 모호성을 피하기 위해 실시간 시뮬레이션이라고 불립니다).대부분의 경우 아날로그 컴퓨터는 실시간보다 훨씬 빠른 속도로 시뮬레이션할 수 있었습니다. 이러한 상황은 인식되지 않고 설명되지 않으면 느린 시뮬레이션만큼 위험할 수 있습니다.

특히 1970년대 이후에는 DOG(Digital On Screen Graphics) 스캐너와 같은 전용 임베디드 시스템에 내장된 미니컴퓨터가 수신 데이터와의 중요한 상호 작용에 대한 낮은 레이텐시 우선 순위 기반 응답의 필요성을 증가시켰기 때문에 Data General의 RDOS(Real-Time Disk Operating System) 및 RTOS와 같은 운영 체제와 같은이 시대의 Digital Equipment Corporation의 RT-11 날짜뿐만 아니라 백그라운드 및 포그라운드 스케줄 설정.백그라운드 포그라운드 스케줄링을 사용하면 포그라운드 태스크를 실행할 필요가 없을 때 우선순위가 낮은 태스크의 CPU 시간이 허용되며 우선순위가 가장 높은 스레드/태스크에 포그라운드 내의 절대 우선순위가 부여됩니다.실시간 운영체제는 여러 사용자의 시분할 작업에도 사용됩니다.예를 들어 Data General Business Basic은 RDOS의 전경 또는 백그라운드에서 실행할 수 있으며 스케줄링 알고리즘에 추가 요소를 도입하여 멍청한 단말기를 통해 대화하는 사람들에게 더 적합합니다.

한때 MOS Technology 6502(Commodore 64 및 Apple II에서 사용)가 인기를 끌었을 때, 그리고 나중에는 Motorola 68000(Macintosh, Atari ST 및 Commodore Amiga에서 사용)이 인기를 끌었을 때, 누구나 가정용 컴퓨터를 실시간 시스템으로 사용할 수 있었습니다.정의된 타이밍에 하드 코딩된 루프에서는 다른 인터럽트를 비활성화할 수 있으며 인터럽트 지연 시간이 짧기 때문에 실시간 운영 체제를 구현할 수 있으며 사용자 인터페이스와 디스크 드라이브의 우선순위는 실시간 스레드보다 낮습니다.인텔 CPU의 프로그램 가능한 인터럽트 컨트롤러(8086)와 비교합니다.80586)는 매우 큰 레이텐시를 발생시키며, Windows 운영체제는 실시간 운영체제가 아니며, 네이티브 머신 언어를 사용하지 않고 프로그램이 CPU를 완전히 넘겨받아 자체 스케줄러를 사용할 수 없기 때문에 중단되는 모든 Windows 코드를 능가합니다.그러나 Java Real Time과 같은 다양한 운영 체제에서 고급 언어로 실시간 기능을 제공하는 여러 코딩 라이브러리가 있습니다.Motorola 68000과 그 이후의 패밀리(68010, 68020 등)도 산업용 제어 시스템 제조업체에서 인기를 끌었다.이 애플리케이션 영역은 실시간 제어가 프로세스 성능과 [citation needed]안전 측면에서 진정한 이점을 제공하는 영역입니다.

실시간 컴퓨팅 기준

동작의 완전정확성이 논리정확성뿐만 아니라 동작의 [5]실행시간에 좌우될 경우 시스템은 실시간이라고 한다.실시간 시스템은 마감일뿐만 아니라 [6]마감일을 놓친 결과로 분류됩니다.

  • 하드 – 납기를 놓치는 것은 시스템 전체의 장애입니다.
  • 확실한 – 빈번한 기한 미만은 허용되지만 시스템의 서비스 품질을 저하시킬 수 있습니다.결과의 유용성은 마감 후 0이 됩니다.
  • 소프트 – 마감 후 결과의 유용성이 저하되어 시스템의 서비스 품질이 저하됩니다.

따라서 하드 실시간 시스템의 목표는 모든 기한이 충족되도록 하는 것이지만 소프트 실시간 시스템의 경우 애플리케이션 고유의 기준을 최적화하기 위해 일정 부분 기한을 충족시키는 것이 목표입니다.최적화된 특정 기준은 애플리케이션에 따라 다르지만, 몇 가지 전형적인 예로는 충족되는 마감일 수 최대화, 작업 지연 최소화 및 마감일을 충족하는 우선순위가 높은 작업 수 최대화 등이 있습니다.

하드 실시간 시스템은 이벤트가 엄격한 기한 내에 반응해야 할 때 사용됩니다.이러한 강력한 보증은 특정 시간 간격에 대응하지 않으면 특히 주변 환경을 손상시키거나 인간의 생명을 위협할 수 있는 어떤 방식으로든 큰 손실을 초래할 수 있는 시스템에 대해 요구됩니다(단, 엄격한 정의는 단순히 마감 기한을 지키지 않는 것이 시스템의 실패에 해당한다는 것입니다).하드 실시간 시스템의 몇 가지 예는 다음과 같습니다.

  • 차량 엔진 제어 시스템은 지연 신호가 엔진 고장 또는 손상을 일으킬 수 있기 때문에 어려운 실시간 시스템입니다.
  • 심장 박동기와 같은 의료 시스템.심장박동조절기의 작업은 간단하지만 인체 생명에 대한 잠재적 위험이 있기 때문에 이러한 의료 시스템은 일반적으로 철저한 테스트와 인증을 받아야 하며, 이는 장애가 발생할 가능성이 낮거나 불가능하다는 입증 가능한 보증을 제공하기 위해 엄격한 실시간 컴퓨팅을 필요로 합니다.
  • 조립 라인의 기계와 같은 산업 프로세스 컨트롤러.기계가 지연될 경우, 조립 라인의 품목이 기계의 손이 닿지 않는 곳으로 지나가거나(제품이 손대지 않은 채 방치), 잘못된 시간에 로봇을 작동시켜 기계 또는 제품이 손상될 수 있습니다.고장이 검출되면 두 경우 모두 조립 라인이 정지되어 생산이 느려집니다.불량이 검출되지 않는 경우, 불량이 있는 제품은 제조에 합격하거나 제조 후의 단계에서 파손될 수 있습니다.
  • 하드 실시간 시스템은 일반적으로 임베디드 시스템에서 물리적 하드웨어와 낮은 수준에서 상호 작용합니다.Atari 2600이나 Cinemetronics 벡터 그래픽과 같은 초기 비디오 게임 시스템은 그래픽과 타이밍 하드웨어의 특성 때문에 실시간 요구 사항이 까다로웠습니다.
  • 소프트웨어 모듈은 하드웨어 모뎀을 컴퓨터의 CPU에서 실행되는 소프트웨어로 대체합니다.소프트웨어는 출력되는 다음 오디오 데이터를 생성하려면 몇 밀리초마다 실행해야 합니다.데이터가 지연되면 수신 모뎀의 동기화가 손실되고 동기화가 재정립되면 장시간 중단되거나 연결이 완전히 손실됩니다.
  • 잉크젯(인쇄 헤드가 페이지를 통과할 때 잉크가 올바른 타이밍에 퇴적되어야 함), 레이저 프린터(레이저는 회전 드럼을 스캔할 때 적절한 타이밍에 활성화되어야 함), 도트 매트릭스 및 다양한 유형의 라인 프린터(충격 메커니즘이 활성화되어야 함) 등 많은 유형의 프린터에서 실시간 요건이 발생합니다.인쇄 메커니즘이 원하는 출력에 맞춰지는 타이밍에 조정됩니다).이들 중 하나에 장애가 발생하면 출력이 누락되거나 출력이 잘못 정렬될 수 있습니다.

멀티태스킹시스템에서는 보통 스케줄링 정책은 priority driven(프리엠프티브스케줄러)입니다.상황에 따라서는, 이러한 기능에 의해서 리얼 타임의 퍼포먼스가 보증되는 경우가 있습니다(예를 들면, 일련의 태스크와 우선순위를 사전에 알고 있는 경우).그 밖에도 레이트 모노토닉과 같은 하드 실시간스케줄러가 있습니다.이것은 범용 시스템에서는 일반적이지 않습니다.이는 태스크의 스케줄링을 위해서는 추가 정보, 즉 태스크를 실행해야 하는 기간의 제한 또는 최악의 예측이 필요하기 때문입니다.이러한 어려운 실시간태스크를 스케줄링하기 위한 특정 알고리즘이 존재합니다.예를 들어 컨텍스트스위칭의 오버헤드를 무시하면 100%[7] 미만의 시스템 부하에 충분합니다.적응형 파티션 스케줄러와 같은 새로운 오버레이 스케줄링 시스템은 하드 실시간 및 비실시간 애플리케이션이 혼합된 대규모 시스템을 관리하는 데 도움이 됩니다.

기업 실시간 시스템은 보다 분무적으로 정의되며, 일부 분류에서는 이를 포함하지 않고 하드 실시간 시스템과 소프트 실시간 시스템만 구분합니다.기업 실시간 시스템의 몇 가지 예는 다음과 같습니다.

  • 앞에서 하드 실시간이라고 설명한 조립 라인 머신은 대신 견고한 실시간이라고 간주할 수 있습니다.기한을 넘긴 경우에도 에러가 발생합니다.부품을 불량으로 표시하거나 조립라인에서 이젝트하는 기계가 있을 수 있습니다.또, 오퍼레이터가 문제를 해결할 수 있도록 조립라인을 정지할 수도 있습니다.다만, 이러한 에러가 빈발하고 있는 한, 허용될 수 있습니다.

소프트 실시간시스템은 일반적으로 동시접속 문제 및 상황변화를 통해 접속된 다수의 시스템을 최신 상태로 유지해야 하는 문제를 해결하기 위해 사용됩니다.소프트 실시간시스템의 몇 가지 예를 다음에 나타냅니다.

  • 민간 여객기의 비행 계획을 유지하고 업데이트하는 소프트웨어입니다.비행 계획은 최신 상태로 유지되어야 하지만, 몇 초의 지연 시간으로 작동할 수 있습니다.
  • 라이브 오디오 비디오 시스템도 보통 소프트 리얼타임입니다.오디오 프레임이 늦게 재생되면 짧은 오디오 결함이 발생할 수 있습니다(그리고 그에 따라 모든 후속 오디오가 지연되어 오디오가 정상적으로 재생되지 않는 것으로 인식될 수 있습니다). 그러나 이는 계속 무음, 정적, 이전 오디오 프레임 또는 추정 데이터를 재생하는 것보다 나을 수 있습니다.지연된 비디오 프레임은 일반적으로 시청자들에게 더 적은 혼란을 야기합니다.이 시스템은 워크로드 예측 및 재구성 방법을 사용하여 [8]향후에도 계속 작동하고 복구할 수 있습니다.
  • 마찬가지로 비디오 게임도 특히 목표 프레임률을 충족하려고 하기 때문에 실시간 소프트인 경우가 많습니다.다음 화상은 플레이어의 입력에 의존하기 때문에 미리 계산할 수 없기 때문에 그 프레임을 표시해야 할 때까지 비디오 프레임을 생성하는데 필요한 모든 연산을 실행할 수 있는 시간은 짧다.게임에 따라서는 그래픽에만 영향을 주거나(3세대와 4세대 콘솔에서 흔히 볼 수 있는) 게임 속도가 느려질 수 있습니다.

디지털 신호 처리의 실시간

실시간 디지털 신호 처리(DSP) 프로세스에서는 분석된(입력) 샘플과 생성된(출력) 샘플은 처리 [9]지연과는 무관하게 동일한 샘플 세트를 입력 및 출력하는 데 걸리는 시간 내에 연속적으로 처리(또는 생성)할 수 있다.즉, 처리가 무제한으로 계속되더라도 처리 지연은 경계가 되어야 합니다.즉, 오버헤드를 포함한 샘플당 평균 처리 시간이 샘플링 속도의 역수인 샘플링 주기보다 크지 않습니다.이는 샘플이 큰 세그먼트로 그룹화되어 블록으로 처리되거나 개별적으로 처리되는지 여부 및 입력 버퍼와 출력 버퍼가 길지 짧지 않은지 여부를 판단하는 기준입니다.

오디오 DSP의 예를 생각해 봅시다.200초의 사운드를 분석, 합성 또는 처리하는 데 2.01초가 걸리는 프로세스에서는 실시간이 아닙니다.단, 1.99초가 걸릴 경우 실시간 DSP 프로세스로 만들 수 있습니다.

흔한 생활 비유는 식료품점에서 계산대를 기다리며 줄 서 있거나 줄을 서는 것이다.선이 점근적으로 더 길어지고 경계 없이 길어지면 체크아웃 프로세스가 실시간으로 수행되지 않습니다.회선의 길이가 한정되어 있는 경우는, 고객이 입력되고 있는 것과 같은 평균의 속도로 「처리」되어 출력되고 있습니다.그러면, 그 프로세스는 리얼타임입니다.식료품점은 계산 과정을 실시간으로 할 수 없다면 폐업하거나 최소한 사업을 중단해야 한다. 따라서 이 과정이 실시간으로 이루어지는 것이 근본적으로 중요하다.

출력이 입력보다 점점 뒤떨어지는 입력 데이터의 흐름을 따라가지 못하는 신호 처리 알고리즘은 실시간이 아닙니다.그러나 무제한으로 동작하는 프로세스에 관해서 출력의 지연(입력에 대해서 상대적인)이 한정되어 있는 경우, throughput 지연이 매우 길어도, 그 신호 처리 알고리즘은 리얼 타임입니다.

라이브 vs. 실시간 비교

실시간 신호 처리는 필요하지만 라이브 이벤트 지원에 필요한 것과 같은 라이브 신호 처리에는 그 자체만으로는 충분하지 않습니다.라이브 오디오 디지털 신호 처리는 스테이지 모니터 또는 인이어 모니터를 사용하는 연주자가 견딜 수 있도록 실시간 동작과 throughput 지연에 대한 충분한 제한이 필요하며, 연주자를 직접 지켜보는 청중의 립싱크 오류로 인식되지 않는다.실시간 실시간 처리 지연에 대한 허용 가능한 제한은 조사와 논의의 대상이지만 6~20밀리초로 [10]추정됩니다.

300 ms 미만의 실시간 쌍방향 통신 지연("라운드 트립" 또는 단방향 지연의 2배)은 대화에서 바람직하지 않은 "토크 오버"를 피하기 위해 "허용"으로 간주됩니다.

실시간 하이 퍼포먼스

실시간 컴퓨팅은 고성능 컴퓨팅으로 오해될 수 있지만 이는 정확한 [11]분류가 아닙니다.예를 들어, 과학적 시뮬레이션을 실행하는 거대한 슈퍼컴퓨터는 인상적인 성능을 제공할 수 있지만 실시간 연산을 실행하지는 않습니다.반대로 안티 브레이크 시스템을 위한 하드웨어와 소프트웨어가 필요한 기한을 준수하도록 설계되면 더 이상의 성능 향상은 의무적이거나 심지어 유용하지 않습니다.게다가 네트워크 서버에 네트워크트래픽의 부하가 높은 경우는, 응답 시간이 늦어질 가능성이 있습니다만, 타임 아웃이 되기 전에(대부분의 경우), 성공합니다(마감기한을 넘깁니다).따라서 이러한 네트워크 서버는 실시간시스템으로 간주되지 않습니다.시간적 장애(지연, 타임아웃 등)는 일반적으로 작고 구획화되어 있지만(실제로는 한정되어 있지만) 치명적인 장애는 아닙니다.FTSE 100 Index와 같은 실시간 시스템에서 한계를 초과하는 속도 저하는 애플리케이션 컨텍스트에서 치명적인 것으로 간주될 수 있습니다.실시간 시스템의 가장 중요한 요건은 높은 스루풋이 아니라 일관된 출력입니다.

많은 체스 프로그램들과 같은 어떤 종류의 소프트웨어는 어느 하나의 범주에 속할 수 있다.예를 들어, 시계가 있는 토너먼트에서 플레이하도록 설계된 체스 프로그램은 특정 마감일 전에 이동 여부를 결정하거나 게임에서 패할 필요가 있으며, 따라서 실시간 계산이지만 이동하기 전에 무기한 실행이 허용되는 체스 프로그램은 그렇지 않다.그러나 이 두 경우 모두 고성능이 바람직하다: 토너먼트 체스 프로그램이 할당된 시간 내에 더 많은 작업을 할 수 있을수록 더 잘 움직일 수 있고, 구속되지 않는 체스 프로그램이 더 빨리 실행될수록 더 빨리 이동할 수 있다.이 예는 또한 실시간 계산과 다른 계산 사이의 본질적인 차이를 보여준다. 토너먼트 체스 프로그램이 할당된 시간 내에 다음 동작을 결정하지 않으면 게임에서 패하고, 즉 실시간 계산으로 실패하는 반면, 다른 시나리오에서는 마감 시간을 맞출 필요가 없다고 가정한다.하이 퍼포먼스는 주어진 시간 내에 실행되는 처리량을 나타내는 반면, 실시간은 사용 가능한 시간에 유용한 출력을 산출하기 위해 처리를 완료할 수 있는 능력입니다.

실시간에 가깝다

통신 및 컴퓨팅에서 "근실시간" 또는 "근실시간"(NRT)이란 이벤트 발생과 디스플레이, 피드백 및 제어 목적 등 처리된 데이터의 사용 사이에 자동화된 데이터 처리 또는 네트워크 전송에 의해 도입된 시간 지연을 말합니다.예를 들어 실시간에 가까운 디스플레이는 현재 존재하는 이벤트 또는 상황을 처리 시간을 뺀 라이브 [12]이벤트의 거의 시간으로 나타냅니다.

"근실시간"과 "실시간"이라는 용어의 차이는 다소 모호하며, 당면한 상황에 맞게 정의해야 합니다.이 용어는 중대한 [12]지연이 없음을 의미합니다.대부분의 경우, "실시간"으로 기술된 처리는 "근실시간"으로 더 정확하게 기술됩니다.

실시간에 가까운 것은 음성 및 비디오의 실시간 전송 지연을 의미하기도 합니다.대용량 비디오 파일이 다운로드될 때까지 기다릴 필요 없이 거의 실시간으로 비디오 이미지를 재생할 수 있습니다.호환되지 않는 데이터베이스는 다른 데이터베이스가 스케줄에 따라 Import/export할 수 있는 공통 플랫 파일을 내보내거나 Import할 수 있으므로 공통 데이터를 서로 "거의 실시간"으로 동기화/공유할 수 있습니다.

「근실시간」과 「실시간」의 구별은 다양하며, 지연은 전송의 종류와 속도에 따라 다릅니다.실시간에 가까운 지연은 보통 [13]1 ~10초입니다

설계 방법

실시간 시스템 설계를 지원하기 위해 여러 가지 방법이 있습니다. 예를 들어, 시스템의 동시 구조를 나타내는 오래되었지만 매우 성공적인 방법인 MASCOT가 있습니다.다른 예로는 HUD, Real-Time UML, AADL, Ravenscar 프로파일 및 Real-Time Java가 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "FreeRTOS - Open Source RTOS Kernel for small embedded systems - What is FreeRTOS FAQ?". FreeRTOS. Retrieved 2021-03-08.
  2. ^ Mordechai, Ben-Ari; "동시 및 분산 프로그래밍의 원리", 16장, 프렌티스 홀, 1990, ISBN 0-13-711821-X, 164페이지
  3. ^ Martin, James (1965). Programming Real-time Computer Systems. Englewood Cliffs, NJ: Prentice-Hall Inc. p. 4. ISBN 978-0-13-730507-0.
  4. ^ Kant, Krishna (May 2010). Computer-Based Industrial Control. PHI Learning. p. 356. ISBN 9788120339880. Retrieved 2015-01-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. CiteSeerX 10.1.1.252.3947. doi:10.1109/5.259423. ISSN 0018-9219.
  6. ^ Kopetz, Hermann; 실시간 시스템: Kluwer Academic Publishers, 1997년 분산 임베디드 애플리케이션 설계 원칙
  7. ^ Liu, Chang L. 및 Layland, James W; "하드 실시간 환경에서의 멀티프로그래밍 스케줄링 알고리즘", ACM 저널, 20 (1):46-61, 1973년 1월, 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., Tian, Wenshun, "실시간 디지털 신호 처리:구현 및 응용 프로그램", Wiley, 2006년, ISBN 0-470-01495-4, 섹션 1.3.4: 실시간 제약사항.
  10. ^ Kudrle, Sara; Proulx, Michel; Carrieres, Pascal; Lopez, Marco; et al. (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, vol. 21, no. 10, p. 11, doi:10.1109/2.7053, S2CID 13884580
  12. ^ a b "Federal Standard 1037C: Glossary of Telecommunications Terms". Its.bldrdoc.gov. Retrieved 2014-04-26.
  13. ^ "The Difference Between Real-Time, Near Real-Time & Batch Processing". Precisely. 2021-03-24. Retrieved 2021-09-22.

추가 정보

외부 링크