실시간 운영 체제가 필요한 솔루션을 개발할 때 QNX 또는 VxWorks와 같은 운영 체제가 Linux에 비해 어떤 이점이 있습니까?
즉, 이러한 운영 체제는 실시간 사용을 위해 사용자 정의할 수 있는 보다 일반적인 시스템인 Linux와 달리 실시간 임베디드 사용을 위해 특별히 설계되었으므로 언제 출시할 예정입니까?필요Linux 대신 이러한 운영 체제 중 하나를 사용하고 계십니까?
답변1
일부 임베디드 시스템은 (a) 어려운 실시간 요구 사항을 충족해야 하지만 (b) 하드웨어가 매우 제한되어 있어 이러한 요구 사항을 충족하기가 더 어렵습니다.
하드웨어를 변경할 수 없는 경우 Linux를 제외하고 다른 하드웨어를 사용해야 하는 경우도 있습니다.
- 아마도 CPU에 MMU가 없어 Linux를 실행하는 것이 불가능할 수도 있습니다(내가 아는 한 실시간이 아닌 uClinux는 제외).
- 어쩌면 CPU가 상대적으로 느리고 Linux의 최악의 인터럽트 대기 시간이 일부 엄격한 요구 사항을 충족할 수 없는 반면, 매우 낮은 최악의 인터럽트 대기 시간에 맞게 조정된 다른 RTOS는 요구 사항을 충족할 수 있습니다.
- 시스템에 RAM이 거의 없을 수도 있습니다. 몇 년 전만 해도 최소 Linux 설정에는 약 2MB의 RAM이 필요했고, 최소 eCos 설정(원래 Linux에서 실행되도록 설계된 일부 애플리케이션을 실행할 수 있는 호환성 계층 포함)에는 약 20kB의 RAM이 필요했습니다.
- 하드웨어에 Linux 포트가 없을 수도 있고, 시스템을 부팅(말장난 의도!)하기 전에 Linux를 포팅할 시간이 충분하지 않을 수도 있습니다. 많은 단순한 RTOS는 Linux보다 새로운 하드웨어로 이식하는 데 훨씬 더 적은 시간이 필요합니다.
답변2
저는 실시간 작업을 전혀 해본 적이 없으니 가볍게 생각하세요...
"실시간"에는 하드 실시간과 소프트 실시간이라는 두 가지 범주가 있다고 들었습니다.
"소프트 실시간"은 비공식적으로 "최대한 빠르게"를 의미합니다. 나는 현대 CPU의 Linux가 이런 종류의 작업에 적합하다고 생각합니다.
"하드 실시간"은 비공식적으로 "필요한 시간 내에 완료"를 의미합니다. 이 기간은 몇 밀리초 정도로 매우 작을 수 있습니다. 순항미사일이나 위성발사체의 비행제어시스템이 대표적인 예인 것 같다. 산업 공정 제어 시스템에도 이것이 필요할 수 있습니다. Stuxnet 웜은 이러한 제어를 수행하는 시스템을 방해하는 것으로 보입니다.
후자의 경우 RTOS를 사용할 수 있습니다. RTOS는 일반적으로 이 많은 명령어나 클럭 사이클 등보다 적은 시간 내에 인터럽트가 전달되도록 보장합니다.
또 다른 고려 사항은 RTOS가 제한 없이 스택 공간을 소비하지 않도록 설계, 테스트 및/또는 "입증"되었다는 점입니다. 일정한 최소량의 메모리 내에서 존재할 수 있으며, "OOM Killers"와 같은 것들은 결코 필요하지 않다는 것이 입증되었기 때문에 존재하지 않습니다. 초기 FORTRAN의 어리석은 기능 중 일부는 이러한 유형의 요구 사항에서 비롯되었습니다. FORTRAN II 프로그램을 컴파일할 때 재귀할 수 없고 동적으로 아무것도 할당할 수 없기 때문에 필요한 스택과 힙의 양을 정확히 알 수 있습니다.
실제로 일부 안전이 중요한 애플리케이션에서는 두 번째 고려 사항(최대 메모리 소비 보장)이 "0.001초의 인터럽트 대기 시간 보장"보다 더 중요할 수 있습니다.
또한 이를 지원하는 무화과 잎 선택 프로세스를 제거하면 엔지니어가 "필요 이론" 때문에 RTOS를 선택한다는 것을 알게 될 것이라고 상상할 수도 있습니다.