소프트웨어 공학: 임베디드 소프트웨어 모델링

 

소프트웨어 공학 관점에서는 임베디드 소프트웨어를 어떻게 볼 수 있을까요?

임베디드 소프트웨어에는 몇가지 특징이 있기 때문에,

이를 소프트웨어 공학점 관점에서는 고려해야 할 중요한 요소라 할 수 있습니다.

이번 포스팅에서는 소프트웨어 공학 관점에서 임베디드 소프트웨어 모델링에 대해 알아 보겠습니다.   

 

 

출처: PTC

 

임베디드 소프트웨어 개요

오늘날 컴퓨터는 단순한 가정용 기기부터 게임 컨트롤러, 자동차, 비행기, 그리고 대규모 제조 공장까지 다양한 시스템을 제어하는 데 활용됩니다. 이때 컴퓨터는 하드웨어와 직접 상호작용하며, 소프트웨어는 하드웨어에서 발생하는 이벤트에 반응해 적절한 제어 신호를 보내게 됩니다. 이러한 시스템에서 사용하는 소프트웨어를 임베디드 소프트웨어라고 하며, 주로 하드웨어에 내장된 형태로, 읽기 전용 메모리에서 실행됩니다. 또한 이 소프트웨어는 시스템 환경에서 발생하는 이벤트에 실시간으로 반응해야 합니다. 여기서 ‘실시간’이란, 외부 이벤트에 대해 소프트웨어가 정해진 시간 내에 응답을 제공해야 하며, 만약 이를 놓치면 전체 하드웨어-소프트웨어 시스템이 올바르게 작동하지 않을 수 있다는 의미입니다.

 

실시간 반응성은 임베디드 소프트웨어와 정보 시스템, 웹 기반 시스템 또는 주로 데이터 처리를 목적으로 하는 개인용 소프트웨어 시스템 간의 중요한 차이점입니다. 비실시간 시스템에서는 시스템의 정확성이 입력을 처리해 기대하는 출력을 만들어내는지에 따라 정의됩니다. 예를 들어, 환자 정보 시스템에서 새로운 환자 기록을 생성하는 명령을 실행하면, 시스템이 새 환자 데이터를 데이터베이스에 추가하고 이를 확인하는 것이 올바른 응답입니다. 이 과정이 얼마나 시간이 걸리느냐는 큰 문제가 되지 않습니다.

 

하지만 실시간 시스템에서는 응답의 정확성뿐만 아니라 응답을 생성하는 데 걸리는 시간도 중요합니다. 시스템이 응답하는 데 너무 오래 걸리면, 그 응답이 더 이상 효과적이지 않을 수 있습니다. 예를 들어, 자동차 제동 시스템을 제어하는 임베디드 소프트웨어가 너무 느리게 작동한다면, 제때 차를 멈추지 못해 사고가 발생할 수 있습니다.

 

따라서 실시간 소프트웨어 시스템에서는 시간 요소가 필수적입니다. 실시간 소프트웨어 시스템이란, 시스템이 생성한 결과뿐만 아니라 그 결과가 만들어지는 시간에 따라 시스템의 올바른 동작 여부가 결정되는 시스템입니다. ‘소프트 실시간 시스템’은 결과가 지정된 시간 요구 사항을 충족하지 못할 경우 성능이 저하되는 시스템입니다. 반면 ‘하드 실시간 시스템’에서는 결과가 정해진 시간 내에 생성되지 않으면, 이를 시스템 실패로 간주합니다.

 

실시간 반응성은 모든 임베디드 소프트웨어에 중요한 요소이지만, 모든 임베디드 소프트웨어가 매우 빠른 응답을 요구하는 것은 아닙니다. 예를 들어, 이 책에서 여러 번 언급된 인슐린 펌프 소프트웨어는 임베디드 소프트웨어의 예입니다. 주기적으로 혈당 수치를 확인해야 하지만, 외부 이벤트에 즉각적으로 반응할 필요는 없습니다. 마찬가지로 야생 지역에 설치된 기상 관측소 소프트웨어도 임베디드 소프트웨어이지만, 빠른 응답이 필수적인 것은 아닙니다.

 

실시간 반응성 외에도, 임베디드 소프트웨어와 다른 유형의 소프트웨어 시스템 간에는 몇 가지 중요한 차이점이 있습니다:

1. 임베디드 소프트웨어는 일반적으로 계속 실행되며 종료되지 않습니다.
   하드웨어가 켜지면 시작되고, 하드웨어가 꺼질 때까지 실행되어야 합니다. 이 때문에 연속적인 운영을 보장하기 위해 신뢰성 있는 소프트웨어 엔지니어링 기술이 필요할 수 있습니다.
2. 실시간 시스템은 동적 재구성을 지원하는 업데이트 메커니즘을 포함할 수 있어, 서비스 중에도 시스템을 업데이트할 수 있습니다.
3. 시스템 환경과의 상호작용은 예측할 수 없습니다.
   상호작용 시스템에서는 상호작용 속도가 시스템에 의해 제어되고, 사용자 옵션을 제한하여 처리할 이벤트를 미리 알 수 있습니다. 반면, 실시간 임베디드 소프트웨어는 예기치 않은 이벤트에 언제든지 반응할 수 있어야 합니다. 이는 여러 프로세스가 병렬로 실행되는 동시성 기반의 실시간 시스템 설계로 이어집니다.
4. 시스템 설계에 영향을 미치는 물리적 제한이 있을 수 있습니다.
   예를 들어, 시스템에 사용할 수 있는 전력 제한과 하드웨어가 차지하는 물리적 공간의 제한이 있습니다. 이러한 제한은 임베디드 소프트웨어에 전력 절약을 통해 배터리 수명을 연장해야 한다는 요구 사항을 생성할 수 있습니다. 크기와 무게 제한으로 인해 사용되는 칩 수를 제한해야 하는 경우, 소프트웨어가 일부 하드웨어 기능을 대신해야 할 수도 있습니다.
5. 임베디드 소프트웨어는 하드웨어와 직접 상호작용해야 할 수 있습니다.
   상호작용 시스템 및 정보 시스템에서는 소프트웨어 계층(디바이스 드라이버)이 하드웨어를 운영 체제로부터 숨깁니다. 이는 키보드, 마우스, 디스플레이와 같은 소수의 장치만 이러한 시스템에 연결할 수 있기 때문에 가능합니다. 반면 임베디드 소프트웨어는 별도의 디바이스 드라이버가 없는 다양한 하드웨어 장치와 상호작용해야 할 수 있습니다.
6. 안전성과 신뢰성 문제가 시스템 설계를 지배할 수 있습니다.
   많은 임베디드 소프트웨어는 고장이 발생할 경우 높은 인적 또는 경제적 비용이 수반될 수 있는 장치를 제어합니다. 따라서 신뢰성은 매우 중요하며, 시스템 설계는 항상 안전한 동작을 보장해야 합니다. 이는 새로운 오류 모드를 도입할 수 있는 최신 기술보다 검증된 기술을 사용하는 보수적인 설계 접근 방식을 초래할 수 있습니다.

      임베디드 소프트웨어는 반응 시스템으로 간주될 수 있습니다. 즉, 이들은 환경의 속도에 맞춰 이벤트에 반응해야 합니다. 반면, 다른 유형의 소프트웨어에서는 시스템이 상호작용 속도를 제어할 수 있습니다. 예를 들어, 제가 이 책을 작성하는 데 사용하는 워드 프로세서는 철자와 문법을 확인할 수 있으며, 이 작업에 걸리는 시간에는 실질적인 제한이 없습니다.

 

임베디드 소프트웨어 설계

임베디드 소프트웨어의 설계 과정은 시스템 엔지니어링 프로세스로, 소프트웨어 설계자는 시스템 하드웨어의 설계 및 성능을 상세하게 고려해야 합니다. 시스템 설계 프로세스의 일부는 시스템 기능 중 어느 부분을 소프트웨어로 구현하고, 어느 부분을 하드웨어로 구현할지 결정하는 과정이 포함될 수 있습니다. 휴대폰과 같은 소비자 제품에 내장된 많은 실시간 시스템의 경우, 하드웨어의 비용과 전력 소비가 매우 중요합니다. 임베디드 소프트웨어를 지원하도록 설계된 특정 프로세서를 사용할 수 있으며, 일부 시스템에서는 특수 목적의 하드웨어를 설계하고 제작해야 할 수도 있습니다.

 

이러한 이유로 대부분의 실시간 시스템에서 상위 단계부터 추상 모델을 시작하여 단계적으로 분해하고 개발하는 탑다운 소프트웨어 설계 방식은 실용적이지 않습니다. 하드웨어, 지원 소프트웨어, 시스템 타이밍에 대한 저수준 결정이 프로세스 초기에 고려되어야 합니다. 이러한 결정은 시스템 설계자의 유연성을 제한하며, 배터리 및 전력 관리를 포함한 추가 소프트웨어 기능을 시스템에 포함해야 할 수도 있습니다.

 

임베디드 소프트웨어는 환경의 이벤트에 반응하는 반응형 시스템이라는 점을 감안할 때, 가장 일반적인 임베디드 실시간 소프트웨어 설계 접근 방식은 자극-반응 모델을 기반으로 합니다. 자극(stimulus)은 소프트웨어 시스템의 환경에서 발생하여 시스템이 어떤 방식으로든 반응하게 만드는 이벤트이며, 반응(response)은 소프트웨어가 환경에 보내는 신호 또는 메시지입니다.

 

실시간 시스템의 동작은 시스템이 수신한 자극, 그에 따른 반응, 반응이 생성되어야 하는 시간을 나열함으로써 정의할 수 있습니다. 예를 들어, 다음 표는 도난 경보 시스템의 가능한 자극과 시스템 반응을 보여줍니다.

자극 (Stimulus)	반응 (Response)
단일 센서 감지	경보를 울리고, 감지된 센서 주변의 조명을 켬
두 개 이상의 센서 감지	경보를 울리고, 감지된 센서 주변의 조명을 켬; 침입이 의심되는 위치로 경찰에 연락
전압 강하가 10%에서 20% 사이인 경우	배터리 백업으로 전환; 전원 공급 테스트 실행
전압 강하가 20% 이상일 경우	배터리 백업으로 전환; 경보를 울리고, 경찰에 연락; 전원 공급 테스트 실행
전원 공급 실패	서비스 기술자에게 연락
센서 고장	서비스 기술자에게 연락
콘솔 비상 버튼 작동	경보를 울리고, 콘솔 주변의 조명을 켬; 경찰에 연락
경보 해제	모든 활성화된 경보를 끄고, 켜진 모든 조명을 끔

 

자극은 두 가지 유형으로 나뉩니다:

1. 주기적 자극:
   일정한 시간 간격으로 발생하는 자극입니다. 예를 들어, 시스템은 50밀리초마다 센서를 검사하고, 해당 센서 값에 따라 조치를 취할 수 있습니다.
2. 비주기적 자극:
   불규칙하고 예측할 수 없이 발생하며, 일반적으로 컴퓨터의 인터럽트 메커니즘을 통해 신호가 전달됩니다. 예를 들어, I/O 전송이 완료되어 데이터가 버퍼에 준비되었음을 알리는 인터럽트가 이에 해당합니다.

 

그림 20.2 임베디드 실시간 시스템의 일반화된 모델

 

자극은 시스템 환경의 센서에서 발생하며, 반응은 액추에이터로 전달됩니다(그림 20.2 참조). 실시간 시스템 설계의 일반적인 가이드라인은 각 유형의 센서와 액추에이터에 대해 별도의 프로세스를 설정하는 것입니다(그림 20.3). 액추에이터는 펌프와 같은 장비를 제어하며, 이는 시스템 환경에 변화를 일으킵니다. 액추에이터 자체도 자극을 생성할 수 있으며, 이는 시스템에서 처리해야 할 문제를 나타낼 수 있습니다.

그림 20.3 센서 액추에이터 프로세스

 

각 유형의 센서에 대해 데이터를 수집하는 센서 관리 프로세스가 있을 수 있습니다. 데이터 처리 프로세스는 시스템이 수신한 자극에 대한 필요한 반응을 계산하며, 액추에이터 제어 프로세스는 각 액추에이터와 관련되어 그 작동을 관리합니다. 이 모델은 데이터를 신속하게 수집할 수 있도록 하며, 그 데이터를 나중에 처리하고 적절한 반응을 생성할 수 있게 합니다.

 

1. 임베디드 소프트웨어 설계 프로세스

실시간 시스템은 서로 다른 시간에 발생하는 자극에 응답해야 합니다. 따라서 자극이 수신되는 즉시 제어가 올바른 처리기로 전송되도록 시스템 아키텍처를 구성해야 합니다. 이는 순차적 프로그램에서 실현하기 어려우므로, 실시간 소프트웨어 시스템은 일반적으로 동시 실행되는 여러 협력 프로세스로 설계됩니다. 

 

임베디드 소프트웨어 설계에 대한 표준 프로세스는 없습니다. 대신, 시스템의 유형, 가용 하드웨어, 시스템을 개발하는 조직에 따라 다른 프로세스가 사용됩니다. 실시간 소프트웨어 설계 과정에서 포함될 수 있는 활동은 다음과 같습니다:

 

1. 플랫폼 선택: 시스템의 실행 플랫폼(하드웨어 및 실시간 운영 체제)을 선택합니다. 이 선택에는 시스템의 타이밍 제약, 가용 전력의 제한, 개발 팀의 경험, 최종 시스템의 가격 목표 등이 영향을 미칩니다.

2. 자극/반응 식별: 시스템이 처리해야 할 자극과 각 자극에 대한 반응을 식별합니다.

3. 타이밍 분석: 각 자극과 그에 따른 반응에 적용되는 타이밍 제약을 식별합니다. 이는 시스템의 프로세스에 대한 기한을 설정하는 데 사용됩니다.

4. 프로세스 설계: 자극 및 반응 처리를 여러 동시 실행 프로세스로 집합화합니다. 프로세스 아키텍처 설계의 좋은 시작점은 섹션 20.2에서 설명하는 아키텍처 패턴입니다.

5. 알고리즘 설계: 각 자극과 반응에 대한 계산을 수행할 알고리즘을 설계합니다. 계산이 많은 작업, 예를 들어 신호 처리와 같은 경우, 프로세스 초기에 설계가 이루어져야 할 수 있습니다.

6. 데이터 설계: 프로세스 간에 교환되는 정보와 정보 교환을 조정하는 이벤트를 지정하고, 이를 관리하기 위한 데이터 구조를 설계합니다.

7. 프로세스 스케줄링: 프로세스가 기한을 맞추기 위해 적시에 시작되도록 스케줄링 시스템을 설계합니다.

 

이러한 활동의 순서는 개발 중인 시스템의 유형과 요구 사항에 따라 달라질 수 있습니다.

 

실시간 소프트웨어 설계 과정에서 이러한 활동의 순서는 개발 중인 시스템의 유형, 프로세스 및 플랫폼 요구 사항에 따라 달라집니다. 경우에 따라 자극과 관련된 처리로부터 추상적인 접근 방식을 취해, 하드웨어와 실행 플랫폼을 나중에 결정할 수 있습니다. 반면에, 소프트웨어 설계가 시작되기 전에 하드웨어 및 운영 체제를 선택하는 경우도 있습니다. 이 경우 소프트웨어는 하드웨어의 제약을 고려하여 설계되어야 합니다.

 

실시간 시스템 내의 프로세스는 조정되고 정보를 공유해야 합니다. 프로세스 조정 메커니즘은 공유 자원에 대한 상호 배제를 보장합니다. 한 프로세스가 공유 자원을 수정하고 있을 때, 다른 프로세스가 그 자원을 변경해서는 안 됩니다. 상호 배제를 보장하는 메커니즘에는 세마포어(Dijkstra, 1968), 모니터(Hoare, 1974), 그리고 임계 구역(Brinch-Hansen, 1973) 등이 있습니다. 이러한 프로세스 동기화 메커니즘은 대부분의 운영 체제 교과서에서 설명하고 있습니다(Silberschatz et al., 2008; Tanenbaum, 2007).

 

프로세스 간 정보 교환을 설계할 때, 이러한 프로세스가 서로 다른 속도로 실행될 수 있다는 사실을 고려해야 합니다. 한 프로세스는 정보를 생성하고, 다른 프로세스는 그 정보를 소비합니다. 만약 생성 프로세스가 소비 프로세스보다 빠르게 실행된다면, 새로운 정보가 소비 프로세스가 원래 정보를 읽기 전에 덮어씌워질 수 있습니다. 반면에 소비 프로세스가 생성 프로세스보다 빠르게 실행된다면, 동일한 정보를 두 번 읽을 수도 있습니다.

 

이 문제를 해결하기 위해 공유 버퍼를 사용한 정보 교환을 구현하고, 해당 버퍼에 대한 접근을 제어하기 위해 상호 배제 메커니즘을 사용해야 합니다. 이를 통해 정보가 읽히기 전에 덮어쓰여지지 않으며, 동일한 정보가 두 번 읽히지 않도록 보장됩니다. 그림 20.4는 순환형 버퍼의 개념을 설명합니다. 이는 보통 순환 대기열로 구현되어, 생성 프로세스와 소비 프로세스 간 속도 불일치가 발생하더라도 프로세스 실행이 지연되지 않도록 합니다.

그림 20.4 공유 순환 버퍼에 대한 생성/소비 프로세스

 

생성 프로세스는 항상 대기열의 끝부분에 데이터를 입력하고(그림 20.4에서 v10으로 표시), 소비 프로세스는 대기열의 앞부분에서 데이터를 항상 가져옵니다(그림 20.4에서 v1으로 표시). 소비 프로세스가 정보를 가져온 후, 대기열의 앞부분은 다음 항목을 가리키도록 조정되고(v2), 생성 프로세스가 데이터를 추가한 후 대기열의 끝부분은 다음 빈 슬롯을 가리키도록 조정됩니다.

 

물론, 생성 프로세스와 소비 프로세스가 동시에 동일한 항목에 접근하지 않도록 해야 합니다(즉, Head = Tail이 되지 않도록). 또한, 생성 프로세스가 가득 찬 버퍼에 항목을 추가하거나, 소비 프로세스가 비어 있는 버퍼에서 항목을 가져오지 않도록 보장해야 합니다. 이를 위해 순환 버퍼를 Get 및 Put 작업이 포함된 프로세스로 구현해야 합니다. Put 작업은 생성 프로세스에 의해 호출되고, Get 작업은 소비 프로세스에 의해 호출됩니다. 세마포어나 임계 구역과 같은 동기화 원시 기능을 사용하여 Get과 Put 작업이 동일한 위치에 동시에 접근하지 않도록 동기화해야 합니다. 버퍼가 가득 차면 Put 프로세스는 슬롯이 비워질 때까지 기다려야 하며, 버퍼가 비어 있으면 Get 프로세스는 항목이 추가될 때까지 기다려야 합니다.

 

시스템에 대한 실행 플랫폼을 선택하고 프로세스 아키텍처를 설계하며 스케줄링 정책을 결정한 후에는 시스템이 타이밍 요구 사항을 충족하는지 확인할 필요가 있습니다. 이는 구성 요소의 타이밍 동작에 대한 지식을 사용한 정적 분석이나 시뮬레이션을 통해 수행할 수 있습니다. 이 분석은 시스템의 성능이 충분하지 않음을 드러낼 수 있습니다. 그 경우, 프로세스 아키텍처, 스케줄링 정책, 실행 플랫폼 또는 이 모든 요소가 성능 향상을 위해 다시 설계되어야 할 수 있습니다.

 

타이밍 제약 또는 다른 요구 사항으로 인해 일부 시스템 기능, 예를 들어 신호 처리가 하드웨어로 구현되는 것이 최선일 때도 있습니다. FPGA와 같은 현대 하드웨어 구성 요소는 유연하며 다양한 기능에 맞게 적응할 수 있습니다. 하드웨어 구성 요소는 동일한 소프트웨어보다 훨씬 나은 성능을 제공하며, 시스템의 병목 현상을 찾아내고 이를 하드웨어로 대체함으로써 비용이 많이 드는 소프트웨어 최적화를 피할 수 있습니다.

 

2. 실시간 시스템 모델링

실시간 시스템이 반응해야 하는 이벤트는 종종 시스템을 하나의 상태에서 다른 상태로 이동하게 만듭니다. 이러한 이유로 상태 모델이 실시간 시스템을 설명하는 데 자주 사용되며, 이는 5장에서 이미 소개된 바 있습니다. 상태 모델은 시스템이 어느 순간에 여러 가능한 상태 중 하나에 있다는 가정을 기반으로 합니다. 특정 자극이 발생하면, 이 자극이 다른 상태로의 전환을 유도할 수 있습니다. 예를 들어, 밸브를 제어하는 시스템은 ‘밸브 열림’ 상태에서 ‘밸브 닫힘’ 상태로 이동할 수 있으며, 이는 오퍼레이터의 명령(자극)에 의해 발생합니다.

 

상태 모델은 실시간 시스템 설계 방법에서 필수적인 부분이며, 언어에 독립적인 방식으로 시스템의 설계를 나타낼 수 있습니다(Gomaa, 1993). UML은 Statecharts(Harel, 1987; Harel, 1988)를 기반으로 상태 모델 개발을 지원합니다. Statecharts는 계층적 상태를 지원하는 정형 상태 머신 모델로, 여러 상태를 단일 엔티티로 간주할 수 있습니다. Douglass는 실시간 시스템 개발에서 UML의 사용에 대해 설명하고 있습니다(Douglass, 1999). 상태 모델은 모델 기반 엔지니어링에서 시스템의 동작을 정의하는 데 사용되며, 자동으로 실행 가능한 프로그램으로 변환될 수 있습니다.

 

그림 20.5 연료 공급 펌프의 상태기계 모델

 

그림 20.5는 연료 공급 소프트웨어 시스템의 동작을 보여주는 또 다른 상태 머신 모델의 예시입니다. 이 시스템은 주유소 펌프에 내장된 시스템으로, 둥근 직사각형은 시스템 상태를 나타내며, 화살표는 한 상태에서 다른 상태로의 전환을 유발하는 자극을 나타냅니다. 상태 머신 다이어그램에 사용된 이름은 설명적이며, 연관된 정보는 시스템 액추에이터가 수행하는 작업 또는 표시되는 정보를 나타냅니다. 이 시스템은 절대 종료되지 않고, 펌프가 작동하지 않을 때 대기 상태로 머물러 있습니다.

 

연료 공급 시스템은 무인 운전을 허용하도록 설계되었습니다. 사용자는 주유 펌프에 내장된 카드 리더기에 신용카드를 삽입합니다. 이 작업은 Reading 상태로의 전환을 유도하며, 이 상태에서는 카드 정보가 읽히고 사용자는 카드를 제거하라는 메시지를 받습니다. 카드를 제거하면 Validating 상태로 전환되며, 이 상태에서 카드가 유효한지 확인합니다. 카드가 유효하면 시스템은 펌프를 초기화하고, 연료 호스를 고정 장치에서 제거할 때 Delivering 상태로 전환되어 연료를 제공할 준비를 합니다. 노즐의 트리거를 작동시키면 연료가 펌프를 통해 전달되며, 트리거를 해제하면 연료 전달이 중단됩니다(단순화를 위해 연료 누출을 방지하기 위한 압력 스위치는 생략했습니다). 연료 공급이 완료되고 사용자가 호스를 제자리에 고정하면, 시스템은 Paying 상태로 이동하여 사용자의 계정에서 금액을 차감합니다. 결제가 완료되면 펌프 소프트웨어는 다시 Waiting 상태로 돌아갑니다.

 

3. 실시간 프로그래밍

실시간 시스템 개발을 위한 프로그래밍 언어는 시스템 하드웨어에 접근할 수 있는 기능을 포함해야 하며, 이 언어들에서 특정 작업의 타이밍을 예측할 수 있어야 합니다. 하드 실시간 시스템은 여전히 엄격한 마감 시간을 맞추기 위해 어셈블리어로 프로그래밍되기도 합니다. 시스템 수준 언어, 예를 들어 C 언어는 효율적인 코드를 생성할 수 있기 때문에 널리 사용됩니다.

 

C와 같은 시스템 프로그래밍 언어를 사용하는 장점은 매우 효율적인 프로그램을 개발할 수 있다는 것입니다. 그러나 이러한 언어들은 동시성이나 공유 자원 관리를 지원하는 구문을 포함하지 않습니다. 동시성과 자원 관리는 실시간 운영 체제에서 제공하는 기본 프리미티브(예: 세마포어)를 호출하여 구현됩니다. 이러한 호출은 컴파일러에서 검사할 수 없기 때문에 프로그래밍 오류가 발생할 가능성이 높습니다. 또한, 언어가 실시간 기능을 포함하지 않기 때문에 프로그램을 이해하는 것이 더 어렵습니다. 프로그램을 이해하려면 실시간 지원이 어떻게 시스템 호출을 통해 제공되는지에 대한 지식도 필요합니다.

 

실시간 시스템은 타이밍 제약 조건을 충족해야 하기 때문에, 하드 실시간 시스템의 경우 객체 지향 개발을 사용할 수 없을 수도 있습니다. 객체 지향 개발은 데이터 표현을 숨기고 속성 값을 객체에서 정의된 연산을 통해 액세스하는 것을 포함합니다. 이로 인해 속성에 대한 액세스를 중재하고 연산을 처리하기 위한 추가 코드가 필요하므로 성능 오버헤드가 발생합니다. 이로 인한 성능 저하로 실시간 마감 시간을 맞추기 어려울 수 있습니다.

 

Java의 변형 버전이 임베디드 소프트웨어 개발을 위해 설계되었습니다(Dibble, 2008). IBM과 Sun과 같은 여러 회사에서 구현한 이 언어는 쓰레드 메커니즘을 수정하여 Garbage Collection 메커니즘에 의해 쓰레드가 중단되지 않도록 했습니다. 비동기 이벤트 처리와 타이밍 명세도 포함되었습니다. 하지만 작성 시점에서 이 언어는 주로 프로세서와 메모리 용량이 큰 플랫폼(예: 휴대폰)에서 사용되었으며, 리소스가 제한된 더 간단한 임베디드 소프트웨어에서는 여전히 C 언어로 구현되는 경우가 많습니다.