Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Copyright Ā© 2019 University of Colorado
Dr. Sam SiewertElectrical, Computer and Energy EngineeringEmbedded Systems Engineering Program
RTES Design for Mission-Critical and Software Real-Time Applications:
Analysis and Design Process, Methods, and Models
2
Segment Outline
ā Real-Time Service Designā Goals and Objectivesā Requirements, Constraints and Qualities
ā RM Requirements Si, Ti, Ci
ā RM Constraints Di
ā Validation and Verification for Quality (Syslog tracing, gcov, gprof, debug)
ā Structured Analysis and Design approachā C and Assembly programming implementation
ā C++ and when to use OO Analysis and Design
3
Design Elements for Real-Time Embedded Systems (Final Course in Series)
Top N Functional (Major Capability) Requirementsā State and Explain what your solution āmustā do or āshallā doā Hold Q&A and Ask for Reviewer Input on Completeness, Errors and Omissions
Top N Real-Time Constraints and Requirements [Ci, Ti, Di for Si]ā State and Explain Service decomposition Si, request rate Tiā How did you estimate or measure Ci as WCETā Are deadlines assumed to be constrained by Ti? Di=Ti, Di > Ti, or Di < Ti
Single Page High Level Block Diagram of Software System (REQUIRED)ā Show End-to-End Elements (Dataflow overlay possible)ā Source to Sink (Top Left Corner to Bottom Right)
SA/SD Design Models - CFD/DFD, Flow Charts, State Machinesā Data Flow Diagram showing major services REQUIREDā State Machine, Control Flow or Control Flow Graph (Flowchart) PREFERRED
Proof-of-Concept Time-Stamp Tracing Analysis REQUIRED
UML Required if C++ used extensively, HDL if FPGA used
Final Course in Series - Project
ā¢ Peer Review and Syslog file, assessment on Coursera
ā¢ Match internal clock to external physical process (separate clock domain)
ā¢ Computer to real-world synchronization over time
4
Final Course in Series - A look ahead
If you use C, you must provide SA/SD in peer review - RecommendedIf you use C++ significant extensions to C, you must provide OOA/OOD in peer review (not disallowed, but design is required!)Use of OpenCV is allowed, but stick to simple C API rather than C++, or instead, use more efficient and simple direct V4L2 / UVC driver interfacing
Observe periodic physical process (in 2nd clock domain)Synchronize with process and control jitter and driftNo glitches allowed over 30 minutes of observation
ā 1 Hz Target goalā 10 Hz Stretch goal
Glitches for external clock observationā Indicator caught in middle of transition (unclear state)ā Repeated indicator (second hand did not move)ā Missed indicator (second hand skips position)
Learning Objectivesā Analysis - Use of RMA to prove design is feasible and safe (has margin)ā Design (Services as SA/SD models)ā Implementation of RT servicesā Tracing to verify that implementation matches analysis and design
Can extended to creative project like:ā¢ Voice/IP, Robotics, Machine
Vision, etc.ā¢ You still must prove predictable
responseā¢ You must upload a clock
demonstration for the last course in the series
ā¢ Final assessment of learning objectives
5
Final Course in Series -Clock Project
Ticking Second Handā Observe Precision, UTC Clockā Synchronize to Second Handā Analyze Latency and Jitter
Observe Physical Processā With Clock in Viewā Which Clock frame is Correct?ā How Do We Know?
Observation atā 1 Hzā 10 Hzā Max Hz (e.g. 30Hz for webcams)
Off by less than a Second over Hoursā E.g. 230 milliseconds of drift
(accumulation of jitter) by analysisā Camera?ā I/O?ā Processing?
Frame N Frame N+1
Frame 1 Frame 1+1800 = OffFrame 1 + 1799 = OKFrame 1 + 1800 (same sec position)
6
Simple Design - Does Not Work!
1. I/O Blocking - Direct interface to Flash or Disk File System -I/O Bound and/or intermittent blocking latency
2. 2 Clock Domains - Frame Acquisition provides timing from āinterval timerā or ādelay loopā or camera interrupt if custom driver - separate clock domain from clock observed
3. RMA Analysis - All services in one main loop, so hard to adjust specific service rates (e.g. IMSHOW debug, Write-back, and Frame Capture in one loop), so priorities are all the same
7
Beter Design - Works, but Not Fault Tolerant
ā GPS or UTC RF Signal failure or glitch means system failure or glitch
ā Clock distribution (low latency network or receiver required)
ā Use of backup clock source is complex - e.g. GPS primary, UTC backup
ā Needs to add tracing of events (syslog), and services are all best effort
8
Best Design -Works, Stand-alone
Fault Tolerant
ā Dual System or Dual OSC
ā Requires Nothing external
ā Logs and observes at higher rate than required
ā Selects at rate requiredā Does not require
GLOBAL clockā Intelligent and self-
recovers
9
Summary
ā Real-Time Service Designā Goals and Objectivesā Requirements, Constraints and Qualities
ā RM Requirements Si, Ti, Ci
ā RM Constraints Di
ā Validation and Verification for Quality (Syslog tracing, gcov, gprof, debug)
ā Structured Analysis and Design approachā C and Assembly programming implementation
ā C++ and when to use OO Analysis and Design
Copyright Ā© 2019 University of Colorado