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