소프트웨어 공학: 임베디드 소프트웨어 타이밍 분석

 

임베디드 소프트웨어에서 실시간성은 아주 중요한 속성입니다.

그래서 이번 포스팅에서는 임베디드 소프트웨어에서의 타이밍 분석에 대해 알아보겠습니다.

 

 

 

임베디드 소프트웨어에서의 타이밍 분석 (Timing Analysis)

임베디드 소프트웨어의 정확성은 출력의 정확성뿐만 아니라 출력이 생성된 시점에도 크게 영향을 받습니다. 이는 임베디드 실시간 소프트웨어 개발 과정에서 타이밍 분석이 중요한 활동임을 의미합니다. 타이밍 분석에서는 시스템의 각 프로세스가 얼마나 자주 실행되어야 모든 입력이 적시에 처리되고, 시스템 응답이 제때 생성되는지를 계산합니다. 타이밍 분석의 결과는 각 프로세스가 얼마나 자주 실행되어야 하는지, 그리고 실시간 운영체제에 의해 이러한 프로세스들이 어떻게 스케줄링되어야 하는지를 결정하는 데 사용됩니다.

 

임베디드 실시간 소프트웨어의 타이밍 분석은 특히 주기적 자극과 비주기적 자극 및 응답이 동시에 발생할 때 매우 어려워집니다. 이때 비주기적 자극은 예측할 수 없기 때문에 이러한 자극이 발생할 확률과 특정 시간에 서비스가 필요할 확률을 가정해야 합니다. 그러나 이러한 가정이 잘못될 수 있으며, 시스템이 실제로 가동된 후 성능이 불충분할 수 있습니다. 

 

그러나 컴퓨터 성능이 향상되면서 많은 시스템에서 주기적 자극만을 사용해 설계하는 것이 가능해졌습니다. 프로세서가 느렸을 때는 비주기적 자극을 사용하여 중요한 이벤트가 기한(Deadline) 내에 처리되도록 해야 했습니다. 예를 들어, 임베디드 시스템의 전원 공급 장치가 고장나면, 매우 짧은 시간(예: 50밀리초) 안에 연결된 장비를 제어된 방식으로 종료해야 합니다. 이는 ‘전원 고장’ 인터럽트로 구현할 수 있습니다. 그러나 주기적으로 매우 자주 실행되는 프로세스를 사용하여 전원을 점검할 수도 있습니다. 프로세스 호출 간의 시간이 짧다면, 전원 부족으로 인한 손상을 방지하기 위한 제어된 종료를 수행할 시간이 여전히 충분합니다. 이러한 이유로 이 글에서는 주기적 프로세스의 타이밍 문제에 중점을 둡니다.

 

임베디드 실시간 소프트웨어의 타이밍 요구 사항을 분석하고 시스템이 이러한 요구 사항을 충족하도록 설계할 때는 세 가지 주요 요소를 고려해야 합니다.

1. 기한 (Deadline): 자극이 처리되고 시스템이 응답을 생성해야 하는 시간입니다. 하드 실시간 시스템에서는 기한(Deadline)을 놓치면 시스템 오류로 간주되며, 소프트 실시간 시스템에서는 시스템 성능이 저하됩니다.
2. 빈도 (Frequency): 프로세스가 기한(Deadline)을 항상 충족할 수 있도록 보장하기 위해 초당 몇 번 실행되어야 하는지를 나타냅니다.
3. 실행 시간 (Execution Time): 자극을 처리하고 응답을 생성하는 데 필요한 시간을 말합니다. 종종 프로세스의 평균 실행 시간과 최악의 실행 시간을 모두 고려해야 합니다. 코드의 조건부 실행, 다른 프로세스 대기 등으로 인해 실행 시간이 항상 같지 않기 때문입니다. 하드 실시간 시스템에서는 기한(Deadline)을 놓치지 않기 위해 최악의 실행 시간을 기준으로 가정해야 할 수 있으며, 소프트 실시간 시스템에서는 평균 실행 시간을 기준으로 계산할 수 있습니다.

전원 공급 장치 고장을 예로 알아 보겠습니다. 고장 이벤트가 발생한 후 공급 전압이 장비에 손상을 줄 수 있는 수준으로 떨어지는 데 50ms가 걸린다고 가정합니다. 따라서 전원 고장 이벤트 발생 후 50ms 이내에 장비 종료 프로세스가 시작되어야 합니다. 이 경우, 장비의 물리적 변동을 고려하여 40ms의 더 짧은 기한(Deadline)을 설정하는 것이 바람직합니다. 이는 연결된 모든 장비에 대한 종료 명령이 40ms 내에 발행되고 처리되어야 한다는 것을 의미합니다.

 

전압 수준을 모니터링하여 전원 고장을 감지하는 경우, 전압이 떨어지는 것을 감지하려면 여러 번의 관찰이 필요합니다. 초당 250회 프로세스를 실행하면, 프로세스는 4ms마다 실행되며 전압 강하를 감지하는 데 최대 두 번의 주기가 필요할 수 있습니다. 따라서 문제를 감지하는 데 최대 8ms가 소요됩니다. 결과적으로, 종료 프로세스의 최악의 실행 시간은 16ms를 넘지 않아야 합니다. 이는 기한(40ms)에서 프로세스 주기(8ms)를 뺀 값을 두 번의 프로세스 실행으로 나눈 값입니다.

 

실제로는 계산이 잘못될 가능성을 대비해 16ms보다 훨씬 짧은 시간을 목표로 삼는 것이 일반적입니다. 사실, 센서를 점검하고 전압 강하 여부를 확인하는 데는 16ms보다 적은 시간이 소요되어야 합니다. 평균적으로 전원 모니터링 프로세스는 1ms 미만의 시간이 걸립니다.

 

전압 수준을 모니터링하여 전원 고장을 감지하는 경우, 전압이 떨어지는 것을 감지하기 위해 여러 번의 관찰이 필요합니다. 프로세스를 초당 250회 실행하면, 이 프로세스는 4ms마다 실행되며, 전압 강하를 감지하는 데 두 번의 주기가 필요할 수 있습니다. 따라서 문제를 감지하는 데 최대 8ms가 소요됩니다. 결과적으로, 종료 프로세스의 최악의 실행 시간은 16ms를 넘지 않아야 합니다. 이 값은 기한(40ms)에서 프로세스 주기(8ms)를 뺀 후 그 값을 두 번의 프로세스 실행으로 나눈 것입니다.

 

실제로는 계산이 잘못될 가능성에 대비하여 16ms보다 훨씬 짧은 시간을 목표로 삼는 것이 일반적입니다. 사실, 센서를 점검하고 전압 강하 여부를 확인하는 데 걸리는 시간은 16ms보다 적어야 합니다. 이는 단순히 두 값을 비교하는 작업에 불과하므로 전원 모니터링 프로세스의 평균 실행 시간은 1ms 미만이어야 합니다.

 

임베디드 실시간 소프트웨어에서 타이밍 분석의 시작점은 타이밍 요구 사항입니다. 타이밍 요구 사항은 시스템에서 필요한 각 응답에 대한 기한(Deadline)을 명시해야 합니다. 다음 표는 사무실 건물의 도난 경보 시스템에 대한 가능한 타이밍 요구 사항을 보여줍니다. 이 예제를 간단히 하기 위해, 시스템 테스트 절차 및 잘못된 경보 발생 시 시스템을 재설정하는 외부 신호로 인한 자극은 무시하도록 하겠습니다. 따라서 이 시스템에서 처리해야 하는 자극은 두 가지뿐입니다:

자극/반응 (Stimulus/Response)	타이밍 요구사항 (Timing Requirements)
전원 고장 (Power Failure)	백업 전원으로의 전환은 50ms 이내에 완료되어야 합니다.
도어 알람 (Door Alarm)	각 도어 알람은 1초에 두 번 폴링(polling) 되어야 합니다.
창문 알람 (Window Alarm)	각 창문 알람은 1초에 두 번 폴링(polling) 되어야 합니다.
동작 감지기 (Movement Detector)	각 동작 감지기는 1초에 두 번 폴링(polling) 되어야 합니다.
경보음 (Audible Alarm)	센서가 알람을 감지한 후 0.5초 이내에 경보음이 울려야 합니다.
조명 스위치 (Light Switch)	센서가 알람을 감지한 후 0.5초 이내에 조명이 켜져야 합니다.
통신 (Communications)	센서가 알람을 감지한 후 2초 이내에 경창에 대한 전화가 시작되어야 합니다.
음성 합성기 (Voice Synthesizer)	센서가 알람을 감지한 후 2초 이내에 합성된 메시지가 준비되어야 합니다.

 

1. 전원 고장: 전압이 20% 이상 떨어지는 것을 감지하여 전자 전원 전환 장치를 통해 회로를 백업 전원으로 전환하는 것이 필요합니다. 이 장치는 주 전원을 배터리 백업으로 전환합니다.
2. 침입자 경보: 시스템의 센서 중 하나에 의해 생성된 자극입니다. 이 자극에 대한 응답으로 활성 센서의 방 번호를 계산하고, 경찰에 전화를 걸어 통화 관리를 위한 음성 합성기를 시작하며, 침입 경보 소리와 건물의 해당 지역의 조명을 켜는 작업을 수행합니다.

위 표에서와 같이, 각 센서 유형에 대한 타이밍 제약 사항을 개별적으로 나열해야 합니다. 이 방식으로 처리하면, 동일한 경우라도 개별적으로 고려하여 미래의 변화에 대비할 수 있고, 제어 프로세스가 초당 몇 번 실행되어야 하는지 계산하기가 더 쉽습니다.

 

시스템 기능을 동시 실행 프로세스에 할당하는 것이 다음 설계 단계입니다. 위 타이밍 요구사항에서 제시된 바와 같이 주기적으로 폴링해야 하는 네 가지 유형의 센서가 있으며, 각각 관련된 프로세스가 있습니다. 이 센서들은 전압 센서, 문 센서, 창문 센서 및 움직임 감지기입니다. 일반적으로 센서와 관련된 프로세스는 매우 빠르게 실행됩니다. 이는 단순히 센서 상태(예: 꺼짐에서 켜짐으로의 변화)를 확인하는 작업이기 때문입니다. 하나의 센서 상태를 확인하고 평가하는 데 걸리는 실행 시간은 1ms를 넘지 않는 것이 합리적입니다.

 

타이밍 요구사항에서 정의된 기한(Deadline)을 충족하기 위해 관련 프로세스가 얼마나 자주 실행되어야 하는지, 그리고 각 프로세스 실행에서 몇 개의 센서를 확인해야 할지를 결정해야 합니다. 여기에는 빈도와 실행 시간 간의 명백한 상충관계가 존재합니다:

 

1. 각 프로세스 실행 시 하나의 센서를 확인한다면, 특정 유형의 센서가 N개 있을 경우, 상태 변화가 0.25초 이내에 감지되도록 하기 위해 해당 프로세스를 초당 4N회 스케줄링해야 합니다.

2. 각 프로세스 실행 시 네 개의 센서를 확인하면, 실행 시간이 4ms로 증가하지만, 타이밍 요구 사항을 충족하기 위해 해당 프로세스를 초당 N회만 실행하면 됩니다.

 

이 경우, 시스템 요구 사항이 두 개 이상의 센서가 양성일 때 조치를 정의하기 때문에, 물리적 근접성을 기준으로 센서 그룹을 나누어 그룹별로 센서를 확인하는 것이 합리적일 수 있습니다. 건물에 침입자가 진입했다면 인접한 센서가 양성일 가능성이 높기 때문입니다.

그림 20.16 알람 프로세스 타이밍

 

타이밍 분석이 완료되면, 프로세스 모델에 실행 빈도와 예상 실행 시간에 대한 정보를 추가할 수 있습니다(예시로 그림 20.16 참조). 여기에서 주기적 프로세스는 실행 빈도로, 자극에 의해 시작되는 프로세스는 R로, 테스트 프로세스는 B로 주석이 달립니다. 이는 프로세서 시간이 사용할 수 있을 때만 실행되는 배경 프로세스임을 의미합니다. 일반적으로 적은 수의 프로세스 빈도로 시스템을 설계하는 것이 더 간단합니다. 실행 시간은 프로세스의 최악의 실행 시간을 기준으로 합니다.

 

설계 프로세스의 마지막 단계는 프로세스가 항상 기한(Deadline)을 맞출 수 있도록 스케줄링 시스템을 설계하는 것입니다. 이를 위해서는 사용하는 실시간 운영 체제에서 지원하는 스케줄링 방식에 대한 지식이 필요합니다(Burns와 Wellings, 2009). 실시간 OS의 스케줄러는 프로세스를 일정 시간 동안 프로세서에 할당합니다. 이 시간은 고정되어 있을 수도 있고, 프로세스의 우선순위에 따라 달라질 수도 있습니다.

 

프로세스 우선순위를 할당할 때는 각 프로세스의 기한(Deadline)을 고려해야 합니다. 기한(Deadline)이 짧은 프로세스는 해당 기한(Deadline)을 맞추기 위해 프로세서 시간을 우선적으로 할당받아야 합니다. 예를 들어, 도난 경보 시스템의 전압 모니터링 프로세스는 전압 강하를 감지하고 시스템이 고장 나기 전에 백업 전원으로 전환할 수 있도록 스케줄링되어야 합니다. 따라서 전압 모니터링 프로세스는 센서 값을 확인하는 다른 프로세스들보다 높은 우선순위를 가져야 합니다. 이는 센서 값 확인 프로세스는 예상 실행 시간에 비해 비교적 느슨한 기한을 가지고 있기 때문입니다.