Software Design Basics

1
Overview

 Concurrency
 How do we make things happen at the right times?

 Software Engineering for Embedded Systems

 How do we develop working code quickly?

2
 CONCURRENCY

3
 MCU Hardware & Software for Concurrency
 CPU executes instructions from one or
more threads of execution

 Specialized hardware peripherals add

dedicated concurrent processing
 DMA - transferring data between
memory and peripherals
 Watchdog timer
 Analog interfacing
 Timers
 Communications with other devices
 Detecting external signal events

 Peripherals use interrupts to notify

CPU of events

4
Concurrent Hardware & Software Operation
Software Hardware Software Hardware Software

Time

 Embedded systems rely on both MCU hardware peripherals and software to get
everything done on time
5
 CPU Scheduling
 MCU’s Interrupt system provides a basic scheduling approach for CPU
 “Run this subroutine every time this hardware event occurs”
 Is adequate for simple systems

 More complex systems need to support multiple concurrent independent threads of

execution
 Use task scheduler to share CPU
 Different approaches to task scheduling

 How do we make the processor responsive? (How do we make it do the right things at the
right times?)
 If we have more software threads than hardware threads, we need to share the processor.

6
Definitions
TRelease Other
processing
Ttask
Scheduler
Task or ISR Code
Latency
Response
Time
Time

 TRelease(i) = Time at which task (or interrupt) i requests service/is released/is ready to run
 TLatency (i) = Delay between release and start of service for task i
 TResponse(i) = Delay between request for service and completion of service for task i
 TTask(i) = Time needed to perform computations for task i
 TISR(i) = Time needed to perform interrupt service routine i

7
Scheduling Approaches

 Rely on MCU’s hardware interrupt system to run right code

 Event-triggered scheduling with interrupts
 Works well for many simple systems

 Use software to schedule CPU’s time

 Static cyclic executive
 Dynamic priority
◦ Without task-level preemption
◦ With task-level preemption

8
 Event-Triggered Scheduling using Interrupts
 Basic architecture, useful for simple low-power devices
 Very little code or time overhead
 Leverages built-in task dispatching of interrupt system
 Can trigger ISRs with input changes, timer expiration, UART data reception, analog input level crossing
comparator threshold
 Function types
 Main function configures system and then goes to sleep
◦ If interrupted, it goes right back to sleep
 Only interrupts are used for normal program operation
 Example: bike computer
 Int1: wheel rotation
 Int2: mode key
 Int3: clock
 Output: Liquid Crystal Display

9
 Bike Computer Functions
ISR 1: ISR 2: ISR 3:
Reset
Wheel rotation Mode Key Time of Day Timer
Configure timer rotations++; mode++; cur_time ++;
inputs and if (rotations> mode = mode % lcd_refresh--;
outputs R_PER_MILE/10) { NUM_MODES; if (lcd_refresh==0) {
tenth_miles++; return from interrupt; convert tenth_miles
cur_time = 0; rotations = 0; and display
rotations = 0; } convert speed
tenth_miles = 0; speed = and display
circumference/ if (mode == 0)
while (1) { (cur_time – prev_time); convert cur_time
sleep; compute avg_speed; and display
} prev_time = cur_time; else
return from interrupt convert avg_speed
and display
lcd_refresh =
LCD_REF_PERIOD
}

10
 A More Complex Application

 GPS-based Pothole Alarm and Moving Map

 Sounds alarm when approaching a pothole
 Display’s vehicle position on LCD
 Also logs driver’s position information
 Hardware: GPS, user switches, speaker, LCD, flash memory

11
Application Software Tasks
 Dec: Decode GPS sentence to find current vehicle position.
 Check: Check to see if approaching any pothole locations. Takes longer as the
number of potholes in database increases.
 Rec: Record position to flash memory. Takes a long time if erasing a block.
 Sw: Read user input switches. Run 10 times per second
 LCD: Update LCD with map. Run 4 times per second

Dec
Check
Rec
Sw
LCD
Time

12
How do we schedule these tasks?
 Task scheduling: Deciding which task should be run
Dec now
Check  Two fundamental questions
 Do we run tasks in the same order every time?
Rec ◦ Yes: Static schedule (cyclic executive, round-robin)
◦ No: Dynamic, prioritized schedule
Sw  Can one task preempt another, or must it wait for
completion?
LCD
◦ Yes: Preemptive
◦ No: Non-preemptive (cooperative, run-to-completion)

13
 Static Schedule (Cyclic Executive)
Dec Check Rec Sw LCD Dec

 Pros while (1){

 Very simple Dec();
 Cons Check();
 Always run the same schedule, regardless of changing Rec();
conditions and relative importance of tasks. Sw();
 All tasks run at same rate. Changing rates requires adding LCD();
extra calls to the function. }
 Maximum delay is sum of all task run times. Polling/execution
rate is 1/maximum delay.

14
 Static Schedule Example
GPS Data Arrives Checking
complete
Response Time

Rec Sw LCD Dec Check

 What if we receive GPS position right after Rec starts running?

 Delays
 Have to wait for Rec, Sw, LCD before we start decoding position with Dec.
 Have to wait for Rec, Sw, LCD, Dec, Check before we know if we are approaching a pothole!

15
Dynamic Scheduling

 Allow schedule to be computed on-the-fly

 Based on importance or something else
 Simplifies creating multi-rate systems

 Schedule based on importance

 Prioritization means that less important tasks don’t delay more important ones

 How often do we decide what to run?

 Coarse grain – After a task finishes. Called Run-to-Completion (RTC) or non-preemptive
 Fine grain – Any time. Called Preemptive, since one task can preempt another.

16
 Dynamic RTC Schedule
GPS Data Arrives Checking
complete
Response Time

Rec Dec Check

 What if we receive GPS position right after Rec starts running?

 Delays
 Have to wait for Rec to finish before we start decoding position with Dec.
 Have to wait for Rec, Dec, Check before we know if we are approaching a pothole

17
 Task State and Scheduling Rules
 Scheduler chooses among Ready tasks for
execution based on priority
 Scheduling Rules
 If no task is running, scheduler starts the Ready
highest priority ready task Task is released
 Once started, a task runs until it completes (ready to run)
 Tasks then enter waiting state until triggered
or released again Start
highest
Waiting priority
ready task

Task complete Running

18 18
 Dynamic Preemptive Schedule
GPS Data Arrives Checking
complete
Response Time

Dec Check Rec

 What if we receive GPS position right after Rec starts running?

 Delays
 Scheduler switches out Rec so we can start decoding position with Dec immediately
 Have to wait for Dec, Check to complete before we know if we are approaching a pothole

19
 Comparison of Response Times
Static
Rec Sw LCD Dec Check

Dynamic Run-to-Completion
Rec Dec Check
Dynamic Preemptive
Dec Check

 Pros
 Preemption offers best response time
◦ Can do more processing (support more potholes, or higher vehicle speed)
◦ Or can lower processor speed, saving money, power

 Cons
 Requires more complicated programming, more memory
 Introduces vulnerability to data race conditions
20
Common Schedulers

 Cyclic executive - non-preemptive and static

 Run-to-completion - non-preemptive and dynamic

 Preemptive and dynamic

21
 Cyclic Executive with Interrupts
BOOL DeviceARequest, DeviceBRequest,
 Two priority levels DeviceCRequest;
 main code – background void interrupt HandleDeviceA(){
 Interrupts – foreground /* do A’s urgent work */
 Example of a foreground / background ...
DeviceARequest = TRUE;
system }
 Interrupt routines run in foreground void main(void) {
(high priority) while (TRUE) {
 Run when triggered if (DeviceARequest) {
FinishDeviceA();
 Handle most urgent work
}
 Set flags to request processing by main if (DeviceBRequest) {
loop FinishDeviceB();
 Main user code runs in background }
 Uses “round-robin” approach to pick if (DeviceCRequest) {
tasks, takes turns FinishDeviceC();
}
 Tasks do not preempt each other
}
}
22
 Run-To-Completion Scheduler
 Use a scheduler function to run task functions at the right rates
 Table stores information per task
◦ Period: How many ticks between each task release
◦ Release Time: how long until task is ready to run
◦ ReadyToRun: task is ready to run immediately
 Scheduler runs forever, examining schedule table which indicates tasks which are ready to run (have been
“released”)
 A periodic timer interrupt triggers an ISR, which updates the schedule table
◦ Decrements “time until next release”
◦ If this time reaches 0, set the task’s Run flag and reload its time with the period

 Follows a “run-to-completion” model

 A task’s execution is not interleaved with any other task
 Only ISRs can interrupt a task
 After ISR completes, the previously-running task resumes

 Priority is typically static, so can use a table with highest priority tasks first for a fast, simple
scheduler implementation.
23
Preemptive Scheduler
 Task functions need not run to completion, but can be interleaved with each other
 Simplifies writing software
 Improves response time
 Introduces new potential problems

 Worst case response time for highest priority task does not depend on other tasks,
only ISRs and scheduler
 Lower priority tasks depend only on higher priority tasks

24
24
 Task State and Scheduling Rules
 Scheduler chooses among Ready tasks
for execution based on priority

 Scheduling Rules What the Ready

 A task’s activities may lead it to waiting task needs
(blocked) happens
 A waiting task never gets the CPU. It must
This is This isn’t
be signaled by an ISR or another task.
highest highest
 Only the scheduler moves tasks between
ready and running Waiting priority priority
ready task ready task

Task needs
something Running
to happen

25 25
 What’s an RTOS?
 What does Real-Time mean?
 Can calculate and guarantee the maximum response time for each task and interrupt service routine
 This “bounding” of response times allows use in hard-real-time systems (which have deadlines which must
be met)

 What’s in the RTOS

 Task Scheduler
◦ Preemptive, prioritized to minimize response times
◦ Interrupt support
 Core Integrated RTOS services
◦ Inter-process communication and synchronization (safe data sharing)
◦ Time management
 Optional Integrated RTOS services
◦ I/O abstractions?
◦ memory management?
◦ file system?
◦ networking support?
◦ GUI??

26
 Comparison of Timing Dependence
Non-preemptive Non-preemptive Preemptive
Static Dynamic Dynamic
Device A ISR
Device A ISR Device A ISR
Device B ISR
Device B ISR Device B ISR
Device ... ISR
Device ... ISR
Device ... ISR
Device Z ISR Device Z ISR
Device Z ISR

Slowest Task
Task 1 Code
Task 5 Code Task 1 Code
Task 1 Code Task 4 Code
Task 2 Code Task 6 Code
Task 3 Code Task 2 Code
Task 2 Code

Task 3 Code Task 3 Code

 Code can be delayed by everything at same Task 4 Code Task 4 Code

level (in oval) or above
Task 5 Code Task 5 Code

Task 6 Code Task 6 Code

27
 Task 3 Max S
Comparison of RAM Requirements
Non-preemptive Non-preemptive Preemptive
Static Dynamic Dynamic

Task 2 Max Stack

Task 1 Max Stack

Task 3 Max Stack

Task 4 Max Stack

Task 1 Max Stack

Task 2 Max Stack
Task 3 Max Stack
Task 4 Max Stack
Task 2 Max Stack

Task 1 Max Stack

Task 1 Statics Task 1 Statics
Task 2 Statics Task 2 Statics
Task 3 Statics Task 3 Statics
Task 4 Statics Task 4 Statics
Task 1 Statics
 Preemption requires space for each stack* Task 2 Statics
 Need space for all static variables (including globals) Task 3 Statics

*except for certain special cases Task 4 Statics

28
 SOFTWARE ENGINEERING FOR
EMBEDDED SYSTEMS

29
 Good Enough Software, Soon Enough
 How do we make software correct enough without going bankrupt?
 Need to be able to develop (and test) software efficiently
 Follow a good plan
 Start with customer requirements
 Design architectures to define the building blocks of the systems (tasks, modules, etc.)
 Add missing requirements
◦ Fault detection, management and logging
◦ Real-time issues
◦ Compliance to a firmware standards manual
◦ Fail-safes
 Create detailed design
 Implement the code, following a good development process
◦ Perform frequent design and code reviews
◦ Perform frequent testing (unit and system testing, preferably automated)
◦ Use revision control to manage changes
 Perform post-mortems to improve development process

30
What happens when the plan meets reality?

 We want a robust plan which considers likely risks

 What if the code turns out to be a lot more complex than we expected?
 What if there is a bug in our code (or a library)?
 What if the system doesn’t have enough memory or throughput?
 What if the system is too expensive?
 What if the lead developer quits?
 What if the lead developer is incompetent, lazy, or both (and won’t quit!)?
 What if the rest of the team gets sick?
 What if the customer adds new requirements?
 What if the customer wants the product two months early?

 Successful software engineering depends on balancing many factors, many of which are
non-technical!
31
Risk Reduction

 Plan to the work to accommodate risks

 Identify likely risks up front

 Historical problem areas
 New implementation technologies
 New product features
 New product line

 Severity of risk is a combination of likelihood and impact of failure

32
Software Lifecycle Concepts

 Coding is the most visible part of a software development process but is not the only
one

 Before we can code, we must know

 What must the code do? Requirements specification
 How will the code be structured? Design specification
◦ (only at this point can we start writing code)

 How will we know if the code works? Test plan

 Best performed when defining requirements

 The software will likely be enhanced over time - Extensive downstream modification and
maintenance!
 Corrections, adaptations, enhancements & preventive maintenance
33
 Product Development Lifecycle

Coding

Coding

Coding

Coding
Diagram: Phil Koopman,
Coding Carnegie Mellon
Coding University

 With all this code development and modification, it is worth putting extra effort into
simplifying code development activities: understanding, maintaining, enhancing, testing

34
Requirements
 Ganssle’s Reason #5 for why embedded projects fail: Vague Requirements

 Types of requirements
 Functional - what the system needs to do
 Nonfunctional - emergent system behaviors such as response time, reliability, energy efficiency, safety, etc.
 Constraints - limit design choices

 Representations
 Text – Liable to be incomplete, bloated, ambiguous, even contradictory
 Diagrams (state charts, flow charts, message sequence charts)
◦ Concise
◦ Can often be used as design documents

 Traceability
 Each requirement should be verifiable with a test

 Stability
 Requirements churn leads to inefficiency and often “recency” problems (most recent requirement change is
assumed to be most important)

35
 Design Before Coding
Architectural Detailed
Coding Test the Code
Design Design

 Ganssle’s reason #9: Starting coding too soon

 Underestimating the complexity of the needed software is a very common risk
 Writing code locks you in to specific implementations
 Starting too early may paint you into a corner
 Benefits of designing system before coding
 Get early insight into system’s complexity, allowing more accurate effort estimation and scheduling
 Can use design diagrams rather than code to discuss what system should do and how. Ganssle’s reason #7:
Bad Science
 Can use design diagrams in documentation to simplify code maintenance and reduce risks of staff turnover

36
 Design Before Coding
 How much of the system do you design before coding?
AD DD C T

AD DD C T
AD DD C T

AD DD C T

AD DD C T

AD DD C T

AD Prototyping DD C T

AD DD C T

AD DD C T

37
 Development Models
 How do we schedule these pieces?

 Consider amount of development risk

 New MCU?
 Exceptional requirements (throughput, power, safety certification, etc.)
 New product?
 New customer?
 Changing requirements?

 Choose model based on risk

 Low: Can create detailed plan. Big-up-front design, waterfall
 High: Use iterative or agile development method, spiral. Prototype high-risk parts first

38
 Waterfall (Idealized)
 Plan the work, and then
work the plan
 BUFD: Big Up-Front Design
 Model implies that we and the
customers know
 All of the requirements up front
 All of the interactions between components, etc.
 How long it will take to write the software and debug it

Diagram: Jon McCormack, Monash University

39
 Waterfall (As Implemented)
 Reality: We are not omniscient,
so there is plenty of
backtracking

Diagram: Jon McCormack, Monash University

40
 Agile Development: SCRUM
 http://www.mountaingoatsoftware.com/topics/scrum
 http://www.codeproject.com/KB/architecture/scrum.aspx

Diagram: Wikipedia
41
 V Model Overview
Requirements
Analysis
Requirements Validation provided by testing Functional
Specification Testing
Review
Architectural Integration
Design Testing
Review
Detailed Integration
Design Testing
Review
S/W Unit
Coding
Testing
Review
Code
 Themes:
 Link front and back ends of life-cycle for efficiency
 Provide “traceability” to ensure nothing falls through the cracks

42
1. Requirements Specification and Validation Plan

 Result of Requirements Analysis

 Should contain:
 Introduction with goals and objectives of system
 Description of problem to solve
 Functional description
◦ provides a “processing narrative” per function
◦ lists and justifies design constraints
◦ explains performance requirements
 Behavioral description shows how system reacts to internal or external events and situations
◦ State-based behavior
◦ General control flow
◦ General data flow
 Validation criteria
◦ tell us how we can decide that a system is acceptable. (Are we done yet?)
◦ is the foundation for a validation test plan
 Bibliography and Appendix refer to all documents related to project and provide supplementary
information
43
2. Architectural (High-Level) Design

 Architecture defines the structure of the system

 Components
 Externally visible properties of components
 Relationships among components

 Architecture is a representation which lets the designer…

 Analyze the design’s effectiveness in meeting requirements
 Consider alternative architectures early
 Reduce down-stream implementation risks

 Architecture matters because…

 It’s small and simple enough to fit into a single person’s brain (as opposed to comprehending the
entire program’s source code)
 It gives stakeholders a way to describe and therefore discuss the system

44
3. Detailed Design

 Describe aspects of how system behaves

 Flow charts for control or data
 State machine diagram
 Event sequences

 Graphical representations very helpful

 Can provide clear, single-page visualization of what system component should do

 Unified Modeling Language (UML)

 Provides many types of diagrams
 Some are useful for embedded system design to describe structure or behavior

45
State Machine for Parsing NMEA-0183
Any char. except *, \r or \n
$ Append char to buf.
Start Append char to buf. Talker + Inc. counter
*, \r or \n, Sentence
non-text, or Type
buf==$SDDBT, $VWVHW, or
counter>6 $YXXDR
Enqueue all chars. from buf
/r or /n
Sentence
Body Any char. except *
Enqueue char
*
Enqueue char

Checksum
1
Any char.
Save as checksum1
Checksum
2
Any char.
Save as checksum2

46
Flowcharts

47
Sequence of Interactions between Components

48
4. Coding and Code Inspections

 Coding driven directly by Detailed Design Specification

 Use a version control system while developing the code
 Follow a coding standard
 Eliminate stylistic variations which make understanding code more difficult
 Avoid known questionable practices
 Spell out best practices to make them easier to follow
 Perform code reviews
 Perform unit testing on modules as appropriate

49
Peer Code Review

 Inspect the code before testing it

 Extensive positive industry results from code inspections

 IBM removed 82% of bugs
 9 hours saved by finding each defect
 For AT&T quality rose by 1000% and productivity by 14%

 Finds bugs which testing often misses

 80% of the errors detected by HP’s inspections were unlikely to be caught by testing
 HP, Shell Research, Bell Northern, AT&T: inspections 20-30x more efficient than testing

50
 5. Software Testing
 Testing IS NOT “the process of verifying the program works correctly”
 The program probably won’t work correctly in all possible cases
◦ Professional programmers have 1-3 bugs per 100 lines of code after it is “done”

 Testers shouldn’t try to prove the program works correctly (impossible)

◦ If you want and expect your program to work, you’ll unconsciously miss failure because human beings are
inherently biased

 The purpose of testing is to find problems quickly

 Does the software violate the specifications?
 Does the software violate unstated requirements?

 The purpose of finding problems is to fix the ones which matter

 Fix the most important problems, as there isn’t enough time to fix all of them
 The Pareto Principle defines “the vital few, the trivial many”
◦ Bugs are uneven in frequency – a vital few contribute the majority of the program failures. Fix these first.

51
 Approaches to Testing
 Incremental Testing
 Code a function and then test it (module/unit/element testing)
 Then test a few working functions together (integration testing)
◦ Continue enlarging the scope of tests as you write new functions
 Incremental testing requires extra code for the test harness
◦ A driver function calls the function to be tested
◦ A stub function might be needed to simulate a function called by the function under test, and which
returns or modifies data.
◦ The test harness can automate the testing of individual functions to detect later bugs
 Big Bang Testing
 Code up all of the functions to create the system
 Test the complete system
◦ Plug and pray

52
Why Test Incrementally?

 Finding out what failed is much easier

 With Big Bang, since no function has been thoroughly tested, most probably have bugs
 Now the question is “Which bug in which module causes the failure I see?”
 Errors in one module can make it difficult to test another module
◦ Errors in fundamental modules (e.g. kernel) can appear as bugs in other many other dependent modules
 Less finger pointing = happier SW development team
 It’s clear who made the mistake, and it’s clear who needs to fix it
 Better automation
 Drivers and stubs initially require time to develop, but save time for future testing

53
Example Test Plan

54
6. Perform Project Retrospectives
 Goals – improve your engineering processes
 Extract all useful information learned from the just-completed project – provide “virtual
experience” to others
 Provide positive non-confrontational feedback
 Document problems and solutions clearly and concisely for future use

 Basic rule: problems need solutions

 Often small changes improve performance, but are easy to forget

55
Example Postmortem Structure

 Product  Support
 Bugs  Tools
 Software design  Team burnout
 Hardware design  Change orders
 Personnel availability
 Process
 Code standards
 Code interfacing
 Change control
 How we did it
 Team coordination

56