Transcript Module Architecture for DRAGON Kernel

Embedded Systems
2001. 4. 4
최병주
http://home.ewha.ac.kr/~bjchoi
(숭실대학교 컴퓨터 학부 양승민 교수
realtime.ssu.ac.kr)
Table of Contents
Embedded Systems and Characteristics
Real-time-ness in Embedded Systems
Robust-ness in Embedded Systems
Various-ness in Embedded Systems
Epilogue
http://realtime.ssu.ac.kr/
Some Research Issues
2
정보가전
멀티미디어 방송
정보가전이란?
유무선의 정보통신망에 연결되어
데이터 송수신이 가능한
차세대 네트워크 가전제품
선풍기
냉장고
감시용
카메라
오디오
인터넷
정보가전
원격제어
셋탑박스
또는
게이트웨이
조명
TV
비디오
전기밥솥
http://realtime.ssu.ac.kr/
전자상거래
3
PDA와 이동통신 단말기 로드맵
PDA
(Bluetooth
내장)
무선인터넷단말기
(CDMA+Bluetooth)
카메라폰
홈네트워크
연동 PDA
온라인게임
PDA
군사 지령
시스템 단말기
물류용 PDA
바코드 스캐너
+ Bluetooth
GPS
네비게이션
TV폰
복합무선단말기
CDMA스마트폰
MP3폰 (OS: Linux,Java
Web 가능)
2000년
2001년
IMT2000
복합무선단말기
단말기
(PDA+IMT2000)
2002년
http://realtime.ssu.ac.kr/
복합무선단말기
(PDA+IMT2000+GPS
+고속 온라인
(PDA+IMT2000
+GPS+카메라
+화상회의
+전자화폐
+온라인게임)
동영상카메라
+화상회의+무선 VOD
+전자화폐+온라인 게임
+홈네트웍+방송수신기)
2003년
2004년
4
- ㈜에이치엔티 단말기 사업계획서 참고
http://realtime.ssu.ac.kr/
Vending Machine : An Example
5
Flows in Embedded Systems
동전입력
품목선택
Analysis &
Decision
Actuators
금액확인 및
구매 가능 품목 결정
구매가능
품목표시
물품 재고 확인
물품출력
거스름돈 계산
거스름돈 출력
물품 수량 DB
물품 보충 요청
http://realtime.ssu.ac.kr/
Sensors
6
Which One is Correct ?
1. Embedded System  Real-Time System
2. Embedded System is Real-Time System
3. Real-Time System is Embedded System
4. Embedded System <> Real-Time System
http://realtime.ssu.ac.kr/
5. None of the Above
7
Embedded Real-Time Applications
Embedded system
“… a standard programming language for embedded-system
applications, in which one or more computers are part of a
larger system such as an aircraft, ship, or a communications
system.”
“the correctness of the system depends not only on the
logical result of the computations but also on time at which
the results are produced”
http://realtime.ssu.ac.kr/
Real-time system
8
Embedded (Real-time) System
Characteristics and Related Issues
Kernel
Support
System
Architecture
Characteristics
• Real-time-ness (실시간성)
• Various-ness (다양성, 특수성)
Software Engineering
http://realtime.ssu.ac.kr/
• Robust-ness (견고성)
9
Real-time-ness
in Embedded System
Hard Real-Time vs. Soft Real-Time
Time Specification and Verification
http://realtime.ssu.ac.kr/
Schedulability
10
Hard Real-Time vs. Soft Real-Time
Time Value Function
“Reward value” of the system when the task terminates
HRT task
SRT task
Time
http://realtime.ssu.ac.kr/
Reward
Value
11
Times in Real-Time Systems
Times associated with Devices
Frequency
Tardiness
Times associated with Tasks
Invocation time
Execution period (or interval)
Sleep and wake-up time
Time associated with Messages and Data
Delivery deadline (event message)
Validity time (state message)
http://realtime.ssu.ac.kr/
Execution deadline
12
Specification and Verification of Times
In real-time systems, time are associated with devices (i.e.,
sensors and actuators), tasks (i.e., analysis and decision),
data and messages (i.e., interactions between device and
task, and between tasks)
times throughout the life cycle of real-time system
development
• Requirement specification level, e.g., Real-Time Logic
• Design description level, e.g., Timed Petri Nets
• Programming language level, e.g., Ada
http://realtime.ssu.ac.kr/
 Need mechanisms to specify(or represent) and verify
13
Time Specification with RTL : An example
Producer-Consumer with a single buffer
Actions
 i @(S, i ) = i * T
 i @(P, i )  i * T ^ @( P, i )  (i+1) * T
 i @(P, i )  @( P, i ) + C
Where
X : beginning of action X
X : completion of action X
@(E, i) : time of the i-th occurrence of event E
http://realtime.ssu.ac.kr/
• S: Sending device which puts a message into the buffer
every T seconds
• P: Processing task which gets a message from the buffer
every T seconds with C seconds processing time
14
Time Verification with RTL an Example
Safety Assertion (SA)
 i @(P, i)  @(S, i+1)
(P should consume a message before S overwrites it)
Verification (by contradiction)
@(S, i ) = i * T
@(P, i )  i * T
@(P, i )  (i+1) * T
@(P, i )  @(P, i ) + C
¬ SA : @(P, i ) > @(S, i+1)
Step 2 : @(S, i+1) = (i+1) * T
(i+1) * T  @(P, i)
@(P, i )  @(P, i ) + C
@(P, i ) > @(S, i+1)
Step 3 : Consequently we can derive the following formula which is false.
@(S, i+1) > @(S, i+1) + C
http://realtime.ssu.ac.kr/
Step 1 : Remove quantifier from the specification
15
Two Aspects of Verification
Check if the specified times reflect all the original
requirements correctly
Completeness: All necessary timing constraints are specified
Check if the specified timing requirements are
feasible for implementation on a given environment
(Validation)
Task allocation / Task scheduling
Execution time estimation
Real-time protocol (or real-time message scheduling)
http://realtime.ssu.ac.kr/
Consistency: All specified times are not conflict
16
Schedulability Analysis
Given properties of processes and target architecture
( including execution time, request interval and deadline )
• Can tasks be scheduled ?
(Can all tasks be completed within deadlines ?)
OR
• How can we maximize the reward value ?
(How can we minimize the penalty ?)
Performance Criteria
• Optimality
• Complexity
• Run-time overhead
http://realtime.ssu.ac.kr/
Scheduling discipline chosen
17
What Makes
Schedulability Analysis Difficult ?
Precedence among tasks
Resource sharing
Communication delay (distributed systems)
Sporadic tasks (or aperiodic tasks)
 Optimal scheduling strategies are known mostly for
a single processor system with independent tasks
 Are estimated execution times of tasks correct ?
http://realtime.ssu.ac.kr/
Task allocation (multiprocessor systems)
18
Robust-ness
in Embedded Systems
Definitions of Faults
Redundancy
http://realtime.ssu.ac.kr/
Software Fault Tolerance
19
Fault
A physical defect
- a gateway always produces 0 or 1
- mistakes within software
Error
Manifestation of faults
- deviation from required operation
System Failure
Incorrect performance of system
(or System malfunctioning)
Not all faults manifest (i.e., become error)
Not all errors lead to failures or system malfunctioning
http://realtime.ssu.ac.kr/
Faults, Errors, Failures
20
Fault Avoidance vs. Fault Tolerance
Fault avoidance
Better specification/verification
Better quality component
• Hardware components
• Programmers
Premise
It is not possible to completely avoid faults
 Fault tolerance is needed
http://realtime.ssu.ac.kr/
• Debugging, testing
21
Software Errors (1)
(by Robert L. Glass )
Thoughts
Not all software errors can be found by known error-removal
techniques
Not all software errors are found EVER
Not all software errors are equal
http://realtime.ssu.ac.kr/
Not all software error-finders are equal
22
Software Errors (2)
Conclusions
There is not now a process answer to the problem of
software errors
The most important element in software error removal is not
the nature of the process, but the choice of people
Both error removal and fault tolerance must concentrate on
the worst of the errors-the ones that can result in unsafe
systems
http://realtime.ssu.ac.kr/
Software in critical systems must take precautions beyond
error removal for defense against software errors
23
Redundancy
Fault tolerance requires redundancy
Hardware redundancy
Software redundancy
Information redundancy
 Time redundancy
Forms of redundancy
Multiple versions
Diversity
Specification diversity
Design diversity
Implementation diversity
http://realtime.ssu.ac.kr/
Multiple identical copies
24
Information Flow
in Embedded Systems
Software
Input
Actuator
Sensor
Communication System
Output
http://realtime.ssu.ac.kr/
Hardware
25
Software Fault Tolerance
Communication
Fault
Software
Fault
Hardware
Fault
Software
Error
Software Fault Tolerance
System
Failure
http://realtime.ssu.ac.kr/
Wrong
Information
26
Software Fault Tolerance
Historical View
Computers will be used more and more for control of critical embedded
real-time applications.
Not all software errors are found EVER!
“True” parallel systems are available.
http://realtime.ssu.ac.kr/
70’s : Concepts in redundancy and atomic actions;
NVP, RB, Conversation scheme, PTC Scheme, etc :
“Pseudo” parallel systems
80’s : Theoretical study and empirical study ;
Reliability modeling and performance modeling;
Design and implementation approach;
“limited” parallel system
90’s : Clinical study, I.e., FT in “real” systems, esp. for real-time
distributed/parallel systems;
“True” parallel systems.
Encouraging Factors
27
Software Fault Tolerance Technique
Redundancy
 Fault by ageing(or by hardware fault)
 Identical copy may work
 Design/Implementation fault
 Identical copy does not work
N-version Programming, Recovery Block, and
Conversation Scheme
http://realtime.ssu.ac.kr/
Multiple identical copies
Multiple versions
28
Design and Implementation Problem
Cost
Design diversity
Any systematic approach ?
Error detection
Consensus(e.g., Comparison)
 Totally application dependant
Timing constraints and timeout, esp. in distributed
systems
http://realtime.ssu.ac.kr/
Approval(e.g., Acceptance Test)
29
Various-ness
in Embedded Software
Various Applications
http://realtime.ssu.ac.kr/
Various Requirements / Equipment / Services
30
2001년의
어느날
Embedded (Real-time) System
Characteristics and Related Issues
Kernel
Support
System
Architecture
Characteristics
• Real-time-ness (실시간성)
• Various-ness (다양성, 특수성)
Software Engineering
http://realtime.ssu.ac.kr/
• Robust-ness (견고성)
32
Some Research Issues
시간 요구 사항의 명세 및 표현  Good Languages
실시간 보장  Time analysis and scheduling
Overload 상황에 대한 처리  “Best effort” scheduling
시스템 감시  Monitoring and diagnosis
다양성 처리  Polymorphic Kernel and component
Embedded System을 위한 개발 방법론 및 Testing 방법
http://realtime.ssu.ac.kr/
결함 처리  Fault tolerance techniques and implementation
33
Epilogue
Computer systems will be used more and more for
“intelligent” embedded systems
From “computer-aided” to “computer-controlled”
society
Dependability is the Key Factor
• Robust
 기반 기술 포기할 것인가?
• 실시간 커널 개발 시급
http://realtime.ssu.ac.kr/
• Temporal as well as logical correctness
34