많은 사람들이 페라리를 꿈꾸지만 마트 쇼핑에는 어울리지 않고 유지비가 비싸다는 것을 알고 있습니다. 이 문제가 임베디드 운영체제와 어떤 연관이 있을까요? 일반적으로 임베디드 운영체제 벤치마킹을 담당하는 엔지니어는 다음과 같은 항목들에 관해 관심을 가집니다.
▶ 네트워크를 통한 데이터 전송 속도가 얼마나 빠른가
▶ 주어진 시간에 얼마나 많은 수학적 계산을 수행할 수 있는가
▶ 이벤트에 반응하는 데 걸리는 시간(latency)이 얼마나 짧은가
▶ 프로세서 간 통신 속도는 얼마나 빠른가
이러한 종류의 테스트를 수행하는 일반적인 방법은 일정 시간 동안 운영체제의 기능을 지속적으로 실행하는 작은 프로그램을 작성하는 것입니다. 이 측정 방식의 가장 큰 문제는 실제 프로그램에서 사용하는 방식과 다르다는 것입니다. 예를 들어 운영체제는 소프트웨어 컴포넌트들 간의 통신을 지원합니다. 실제 개발하는 컴포넌트들이 구동 시간의 대부분을 다른 컴포넌트와 데이터를 주고받는 데 사용하나요? 아니면 설계한 업무를 수행하는 중 가끔 통신을 하나요?데이터를지속적으로송/수신하는 표준 네트워크 벤치마킹의 경우를 고려해보면 데이터 처리량보다 더 중요하게 보아야 할 것이 있습니다.
Safety를 위해 소프트웨어 구성 요소를 분리하여 안전성을 높인 운영체제의 경우, 벤치마킹 프로그램을 캡슐화된 프로세스로 취급하고 네트워크 스택도 별도의 프로세스로 취급합니다. 이러한 접근 방식은 벤치마킹 프로그램에서 전송하려는 데이터가 운영체제 코어(커널)에 의해 네트워크 프로세스로 이동(복사)되어야 하므로 네트워킹 작업에 더 많은 시간을 소요할 수 있습니다. 그러나 최대 성능을 위해 네트워크 스택이 운영체제 커널에 포함되도록 설계된운영체제의경우에는벤치마킹 프로그램의 메모리에 직접 접근하여 전송할 데이터를 획득할 수 있습니다. 이 방식은 네트워크 전송 속도는 더 빠를 수 있지만 네트워크 패킷에 오류가 있거나 프로그래밍 오류로 인해 발생하는 문제가 전체 운영체제 커널을 손상시킬 수 있다는 문제가 있습니다.
여기서 궁금한 점은 실제 어플리케이션 구동 시 이 두 접근 방식의 운영체제에서 발생하는 속도의 차이를 자각할 수 있는 정도인가 하는 것입니다. 소프트웨어 실제 구동시간 중 운영체제의 기능을 사용하는데 소요되는 시간이 얼마나 되나요? 심층 분석 없이 쉽게 대답할 수 없는 질문이긴 하지만, 경험상 대부분 운영체제의 기능을 사용하는데 소요되는 시간은 극히 제한적입니다. 이상적으로 실제 필요한 속도를 알고 있거나, 모르는 경우에도 최댓값은 참고해야할값이아니라는 것은 확실합니다. 운영체제의 속도는 제품의 안정성을 낮추거나 복잡도를 높이거나, Safety를 줄이거나 보안을 낮추거나 하는 희생을 필요로 합니다.
경험에 따르면 응용 프로그램에 대한 명확한 디자인이 뛰어난 성능을 가진 시스템의 원동력이 됩니다. 빠른 운영체제가 잘못 설계된 응용 프로그램의 균형을 맞출 수는 없지만, 좋은 운영체제는 응용 프로그램을 보다 안정적이며 안전하고 쉽게 유지 관리해줄 수 있습니다.
이는 하드웨어의 성능이 운영체제의 속도보다 훨씬 중요하다는 의미입니다. 하드웨어는 운영체제도 구동하지만 더 중요한 것은 하드웨어 리소스의 대부분을 소비하는 응용 프로그램도 구동하기 때문입니다. 필요한 성능보다 약간 여유가 있는 하드웨어 플랫폼을 선택하면 약간의 비용은 더 발생하겠지만 개발 시간을 절약하고 성능 저하를 피할 수 있으며 향후 기능 추가를 위한 여유를 확보할 수 있습니다.
실수 #7 - 미리 계획하지 않기. 일명 "우린 그 기능 필요 없어요." 증후군
QNX 소개 자료를 보면 다음과 같은 기능들이 제공된다는 것을 알 수 있습니다.
▶ 결정론적 기능을 위한 매우 정교한 Real time 기능 제공
▶ 산업용, 자동차용 및 의료용 기기를 위한 안전 인증 획득
▶ 시스템의 안정성을 위해 추가 컴포넌트나 별도로 구매한 컴포넌트를 포함하는 모든 컴포넌트를 격리하는 기능
▶ 심층적인 시스템 분석이 가능한 포괄적인 개발 도구 모음
경험이 부족한 의사 결정권자에게는 이러한 기능들이 실제로 필요하진 않은 좋은 기능들이라고 생각할 수 있습니다. 임베디드 운영체제와 관련하여 자주 언급되는 주요 기능은 "Real time" 입니다. 대중적인 인식과는 달리, 이 용어는 "실제 빠름"의 의미가 아니라 항상 정해진 시간 내에 설계된 기능을 수행해야 하는 결정론적 행동을 제공할 수 있음을 의미합니다. 예를 들어 키를 누르면 일정 시간 내에 특정 반응이 발생하게 됩니다. 가끔 웹브라우저의주소창에 무언가를 입력했을 때 화면에 출력되기까지 일정 시간이 소요되기도 합니다. 이 짧은 시간이 제트 엔진의 오작동으로 연료를 끊어야 하는 상황에서는 치명적일 수 있습니다. 운영체제 레벨에서 중요한 차이는 "Real time" 자격으로 만들어졌는지, 확장 기능으로 "Real time" 기능이 제공되는지에 대한 여부입니다. 둘 다 "Real time 가능"이라고 부르지만 반응 시간의 차이는 클 수 있습니다. 하지만 당신의장비가 이 차이를감당할수 있다하더라도 "Real time 운영체제는 필요 없어요."라고 단정짓지 마십시오. Real time 운영체제는 미션 크리티컬한 장치에 적용되어 짧은 반응 시간을 요구하며, 이 조건을 충족시키지 못할 경우 치명적인 고장, 사람의 부상, 주위의 위험 또는 손상된 제품의 생산을 야기할 수 있는 시스템에 사용됩니다.
그 외에도 이런 시스템들은 안정성, 신뢰성, 가용성, 인증 가능성 및 최소 10년 이상의 유지 관리 가능성 등의 기능들도 필요합니다. 지금 계획 중인 프로젝트가 있다면, 이 특성 중 여러 가지는 아니더라도 하나 이상의 기능은 필요할 것이라고 확신합니다. Real time으로 설계되었다는 것은 가장 까다로운 어플리케이션 사용 시나리오를 위해 설계되었다는 의미이므로, Real time으로 설계된 임베디드 운영체제를 선택하는 것이 좋습니다.