1. 실시간 시스템(real-time system)
시스템에 의해 생성되는 결과(results)나 이벤트(events)에 반응해서 주어진 시간내에 올바른 기능을 수행할 수 있어야 한다. 그렇기 때문에 실시간 시스템을 자극/반응 시스템(stimulus/response system)이라고도 한다. 주어진 특정 입력 자극에 대해 관련된 반응을 보여야 하기 때문이다.
1) 실시간 시스템의 종류
① 연성 실시간 시스템("soft" real-time system): 명시된 시간 요구사항(timing requirements)에 따라 결과가 얻어지지 못했을 경우 품질이 저하되는(degraded) 시스템
② 경성 실시간 시스템("hard" real-time system): 명시된 시간 요구사항(timing requirements)에 따라 결과가 얻어지지 못했을 경우 오동작으로 처리되는 시스템
※ 경성 실시간 시스템(“hard" real-time system)의 경우는 시간 요구사항을 지키는 것이 상당히 중요하며, 필수적이다.
2) 자극(stimuli)의 종류
실시간 시스템의 행위는 자극/반응/응답시간의 리스트로 정의할 수 있다. 자극은 센서가 발생시키 며 시스템 환경의 상태 정보이다.
① 주기적 자극(Periodic stimuli)
- 일정 시간 간격을 두고 주기적으로 발생한다.
- (예) 시스템은 매 50밀리초(milliseconds)마다 센서(sensor)를 검사하고 센서값에 따라서 적 절한 조치를 취한다.
② 비주기적 자극(Aperiodic stimuli)
- 불규칙적으로 발생한다.
- 주로 컴퓨터 인터럽트 방식을 통해 이루어진다.
- (예) 입출력 완료 인터럽트, 버퍼에 사용가능한 데이터가 축적된 경우의 인터럽트
(센서/작동기 제어 프로세스)
1. 센서 제어 프로세스(Sensor control processes): 센서로부터 정보를 수집한다.
2. 데이터 처리기(Data processor): 수집된 정보를 처리하고, 시스템의 반응을 계산한다.
3. 작동기 제어(Actuator control): 엑츄에이터에 대한 제어 신호를 생성한다.
2. 시스템 설계(System design)
1) 개요
- 시스템과 관련한 하드웨어와 소프트웨어 모두 설계한다. 이때, 시스템의 기능을 하드웨어로 구 할 것인지 소프트웨어로 구현할 것인지를 구분한다.
- 설계에 대한 판단은 비기능적 시스템 요구사항 (non-functional system requirements)를 기반으로 해야 한다. 예를 들어 시간 제약 조건은 신호 처리와 같은 기능이 특수 목적의 하드 웨어로 구현해야 함을 의미한다.
- 하드웨어가 훨씬 좋은 성능을 제공해주지만 개발 시간이 오래 걸리고, 변화에 대해 적응하기 어렵다.
2) 소프트웨어/하드웨어 설계
3) 설계 프로세스(design process)
시스템 반은 시간이 초기에 고려되어야 하므로 다른 소프트웨어 설계와 다르다.
1. 처리되어야할 자극(stimuli)과 이 자극이 요구하는 반응(response)을 찾는다.
2. 각각의 자극과 반응에 대해 시간 제약사항(timing constraints)을 찾는다.
3. 자극과 반응을 모아서 몇 개의 병행 프로세스(concurrent processes)로 묶는다. 각각의 프로세 스는 자극과 반응들의 분류된 묶음과 관련된다.
4. 분류된 자극, 반응들의 묶음을 처리하기 위한 알고리즘을 설계한다. 이 알고리즘은 주어진 시간 제약사항을 만족시켜야 한다.
5. 프로세스(processes)가 재시간에 시작해서 최종기한(deadline)안에 마칠 수 있도록 보장해주 는 스케쥴링 시스템(scheduling system)을 설계한다.
6. 실시간 실행환경(executive)이나 운영체제(operating system)을 사용하여 통합시킨다.
4) 시간 제약사항(Timing constraints)
-실제로 시스템이 시간 제약사항을 만족하는지를 확인하기 위해서 상당한 평가와 실험이 반복적 으로 수행되어야 한다.
-객체 지향 설계(object-oriented design)같은 특정 설계 전략은 성능 문제와 같은 부가적인 오버 헤드(overhead)가 발생하기 때문에 설계 방법으로 적당하지 못할 수도 있다.
-성능 향상을 위해서는 저급 프로그래밍 언어(low-level programming language)가 사용되어야 할 지도 모른다.
5) 실시간 시스템 모델링(Real-time system modeling)
- 실시간 시스템에서의 자극(stimuli)은 시스템의 상태(state)를 전이(transition)시킨다.
- 유한 상태 머신(Finite state machines)이 실시간 시스템을 모델링하는데 필수적이다.
- 하지만, 유한 상태 머신(Finite state machine)은 구조가 부족하다. (lack of structure) 아주 단순한 시스템이라도 복잡한 모델을 가질 수 있기 때문이다. Statecharts는 상태 모델을 구조화 한 것으 로 상태의 구룹핑이 가능하다.
- UML을 이용하여 상태 머신 모델(state machine model)을 표기할 수 있다.
6) 실시간 프로그래밍(Real-time programming)
- 엄격한 실시간 시스템(Hard real-time system)은 시간제약사항을 만족시키기 위해 어셈블리 언어 (assembly language)로 프로그래밍 되어야 할 경우도 있다.
- C와 같은 언어는 효율적인 프로그램을 작성할 수 있도록 해주지만 병행(concurrency)이나 공유 자원 관리(shared resource management)를 지원하도록 구조화되어 있지 않다.
- Ada와 같은 언어는 실시간 시스템을 지원하기 위해 설계되었으며, 범용 목적의 병행 메커니즘 (general purpose concurrency mechanism)을 포함하고 있다. 그러나 경성 실시간에는 충분치 않다.
※ 실시간 언어로서의 자바(Java)
- 자바는 threads나 synchronized method와 같은 간단한 병행 (lightweight concurrency)을 지원하기 때문에 그다지 엄격하지 않은 실시간 시스템(soft real-time system)에 사용될 수 있다.
- Java2.0은 경성 실시간 프로그래밍(hard RT programming)이나 시간제약의 정확한 제어가 요구되는 프로그래밍에는 적합하지 않다.
> 쓰레드 실행시간(thread execution time)을 명세할 수 없다.
> garbage collection을 제어(또는 예측)할 수 없다.
> 공유 자원에 대한 큐의 크기를 알 수 없다.
> 가상 머신의 구현이 고정적이지 않다.(variable virtual machine implementation)따라서 같은 프 로그램이라도 다를 수 있다.
> 상세한 공간(space)이나 시간(time) 분석이 가능하지 않다.
3. 실시간 실행환경(Real-time executives)
1) 개요
- 실시간 실행환경(real-time executive)는 범용 컴퓨터에서의 운영체제(operating system)와 유사하며, 실시간 시스템에서의 프로세스 관리와 자원 할당을 관리한다.
- 특별한 제약 조건 때문에 표준 RTE 커널은 힘들며 응용 분야마다 다르다.
- 파일 관리 시스템과 같은 복잡한 운영 체제 시스템 기능은 포함하지 않는다.
2) 실행환경의 구성요소
시스템의 크기와 복잡도에 따라 다르나 대개의 경우 다음과 같다.
① 실시간 클럭(A real-time clock): 주기적으로 스케쥴 프로세스에게 정보를 제공한다.
② 인터럽트 처리기(An interrupt handler): 서비스에 대한 비주기적 요청(request)를 관리한다.
③ 스케쥴러(A scheduler): 실행가능한 프로세스를 조사하고, 실행시킬 프로세스를 선택한다.
④ 자원 관리기(A resource manager): 실행을 위한 스케쥴된 프로세스가 주어졌을 경우, 자원 관리 기는 필요한 메모리와 프로세서 자원을 할당한다.
⑤ 처리기(A dispatcher): 프로세스를 실행시킨다.
※ 통신(telecommunication)이나 모니터링 시스템과 같이 높은 신뢰성이 필요하며 계속적으로 서비스 를 제공하여야 하는 시스템의 경우는 다음과 같은 추가적인 실행 구성요소가 필요하다.
□ 환경 관리기(A configuration manager)
- 시스템 하드웨어에 대한 동적 환경 재설정(dynamic reconfiguration)을 담당한다
- 시스템을 끄지 않고도 하드웨어 모듈이나 시스템을 업그레이드 가능하다.
□ 오류 관리기(A fault manager)
- 하드웨어나 소프트웨어의 오류를 감지하여, 오류를 복구하기 위한 적절한 조치를 취한다.
( fault tolerance, fault recovery )
3) 시스템 프로세스의 우선순위 레벨
실시간 시스템에서 처리되는 자극의 처리는 다양한 레벨(적어도 2가지)의 우선순위를 가지게 된다.
□ 인터럽트 레벨(Interrupt level)
- 가장 높은 우선순위 레벨이다.
- 아주 빠른 반응이 요구되는 프로세스에 할당된다.
- 예) 실시간 클럭 프로세스(real-time clock process)
□ 클럭 레벨(clock level)
- 주기적 프로세스(periodic processes)에 할당된다.
* 지정된 시간 내에 처리되어야 하는가 아니면 보다 중요한 프로세스에 의해 safely delay가 가능한 가를 따져야하며, 실시간 요건이 필요 없는 백그라운드 프로세스도 있다.
4) 프로세스 관리(Process management)
- 병행 프로세스들(concurrent processes)의 집합을 관리한다.
- 실행을 위한 프로세스를 선택하고, 메모리와 프로세서 자원을 할당한 후 프로세서에서 실제 프로 세스를 실행시킨다.(figure 13.5 참고)
- 주기적 프로세스들(Periodic processes)은 미리 명시된 시간 간격으로 실행된다.
-실행환경은 프로세스를 실행시켜야할 시간을 결정하기 위해 실시간 클럭(real-time clock)을 사용 한다.
5) 스케쥴 전략(Scheduling strategies)
특정 시점에는 다양한 프로세스들이 동시에 서로 다른 우선순위를 가지고 실행되어야 할 경우가 생긴다. 이 경우 어떤 순서로 각 프로세스를 실행시킬지는 스케쥴러(scheduler)에게 달려있다. 시스템에 대한 실시간 요구사항이 지켜지기 위해서는 효과적인 스케쥴링이 필수적이다.
□ 비선점형 스케쥴링(Non pre-emptive scheduling)
- 일단 프로세스가 실행되면, 완료(completion)되거나 입력대기(waiting for input)와 같은 특별한 이유 때문에 블로킹(blocking)을 당하기 전까지는 계속 실행된다.
- 문제점: 다양한 우선순위(priorities)를 가지는 프로세스들이 많을 경우 높은 우선 순위의 프로세
- 스가 낮은 우선순위의 프로세를 기다려야하는 경우가 발생한다.
□ 선점형 스케쥴링(Pe-emptive scheduling)
- 높은 다른 우선순위 프로세스가 보다 낮은 우선순위의 프로세스를 멈출 수 있고, 이때 프로세 서에는 높은 우선순위의 프로세스가 할당된다.
- 문제점: 낮은 우선순위의 프로세스는 계속적으로 실행할 수 없는 기아문제(starvation)가 발생할 수 있다.
4. 감시/제어 시스템(Monitoring and control systems)
1) 개요
시스템을 개발할 때 표준 유형으로부터 개발 시스템의 아키텍쳐를 유도할 수 있는데, 감시시스 템, 데이터 획득 시스템, 명령 및 제어 시스템과 같이 다양한 종류의 실시간 시스템이 존재한다. 그 중 감시/제어 시스템에 대해서 살펴본다.
2) 감시/제어(Monitoring and Control) 시스템
- 센서가 시스템의 환경에 대한 정보를 제공하고, 시스템이 이를 확인해서 센서 값의 결과에 따라 반응한다.
- 감시 시스템 : 센서에 의해 이상 값이 탐지될 때 행동을 함
- 제어 시스템 : 센서 값에 따라 계속적으로 하드웨어를 제어함
(예) 도둑 경고 시스템(burglar alarm system)
도둑 경고 시스템은 건물에 구현된다. 여러 종류의 센서가 사용되고, 문에서의 움직임을 감지 하고, 문이 열렸거나 창문이 깨졌는지를 확인한다. 센서가 도둑의 침입을 감지하면, 음성 합 성기와 전화를 이용하여 자동적으로 경찰서에 신고하며, 도둑의 위치를 보고하고, 해당 위치 건물의 불을 켠다. 주로 주전력으로 동작하지만, 백업용 배터리를 장착하고 있다.
※ 도둑 경고 시스템은 감시 시스템으로 연성 실시간 시스템이다(soft real-time system). 그러므로, 시간 제약 요구사항을 지키지 못하더라도 치명적인 오류가 발생한 것은 아니다.
► 도둑 경고 시스템에서 처리해야할 자극(stimulus)
-전력 오류(Power failure): 회로 감시기에서 발생한다. 요구되는 반응(response)는 백업 배터 리를 켜는 것이다.
-침입자 경고(Intruder alarm): 시스템 센서에서 발생한다. 센서가 감지한 침입자의 방번호를 찾 고, 경찰에 연락을 취해서, 음성 합성기를 동작시킨 후, 그 지역 건물의 불을 켜는 것이다.
※ 그림 설명 ※
- 움직임 감지 프로세스(Movement detector process)는 400Hz(즉 1초에 400번)로, 문 감지 프로세스(Door sensor process)는 60Hz로, 창문 감지 프로세스(Window sensor process)는 100Hz로 동작해야한다. 마찬가지로, 건물 감시 프로세스(Building monitor process)는 560Hz 로 동작해야한다.
- 각 감지 프로세스로부터의 상태가 건물 감시 프로세스로 정해진 시간 간격으로 전달된다. (주기 적 프로세스에는 실선 입력)
- 건물 감시 프로세스는 침입이 일어난 방 번호(Room number)를 경고 시스템 프로세스(Alarm s system process)에 전달한다. (화살표 위에 자료흐름 표시)
- 경고 시스템은 방번호를 조명 제어 프로세스(Lighting control process)에 전달하여 해당 위치의 불을 켜고, 음성 합성 프로세스(Voice synthesiser process)를 동작시킨다. (작동기 프로세스 는 명시적 신호에 의해 작동함, 비주기적 프로세스는 점선 입력)
- 음성 합성 프로세스는 통신 프로세스(communication process)에게 경고 메시지를 전달하여 경 찰에게 연락하게 된다.
- p.298 Figure 13.8. Java implementation of the building monitor process(자바를 이용한 건물 감시 프로세스 구현) 참고하기.
※ 그림 설명 ※
- 센서 프로세스(sensor process), 자동 온도 조절 프로세스(Thermostat process), 히터 제어 프로 세스(Heater control process)는 모두 500Hz 로 동작한다. (1초에 500번)
- 즉, 500Hz로 센서 프로세스는 온도조절 프로세스에게 센서값(Sensor value)를 보내고, 마찬가지 로 온도조절 프로세스는 히터 제어 시스템에게 스위치 명령과 방번호(Switch command, Room
number)를 보내게 된다.
- 히터 제어 프로세스는 방 온도에 맞게 히터의 세기가 변하게 된다.
[정리하기]
▣ 실시간 시스템(Real-time system)의 정확성은 시스템이 무엇을 하는가(what the system does) 뿐 아니라 얼마나 빨리 반응하는가(how fast it reacts)에 달려있다.
▣ 일반적인 실시간 시스템은 센서(sensor)와 엑츄에이터(actuator)를 사용한다.
▣ 실시간 실행환경(Real-time executives)는 프로세스 또는 자원을 관리한다.
▣ 실시간 시스템의 스케줄 전략에는 선점형(pre-emptive)과 비선점형(non pre-emptive)이 있다.
▣ 감시 제어 시스템은 센서(Sensor)로부터 정보를 얻어서 엑츄에이터(Actuator)에게 신호를 보낸다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
| 신뢰성 (1) | 2023.11.28 |
|---|---|
| 재사용을 통한 설계 (1) | 2023.11.28 |
| 분산 시스템 아키텍쳐 (1) | 2023.11.26 |
| 아키텍쳐 설계 (1) | 2023.11.25 |
| 시스템 모델 (1) | 2023.11.25 |
