Better Embedded System Software

✍ Scribed by Philip Koopman

• Publisher: Drumnadrochit Education
• Year: 2010
• Tongue: English
• Leaves: 516
• Category: Library

✦ Synopsis

This book distills the experience of more than 90 design reviews on real embedded systems into a set of bite-size lessons learned in the areas of software development process, requirements, architecture, design, implementation, verification & validation, and critical system properties.

Each chapter describes an area that tends to be a problem in embedded system design, symptoms that tend to indicate you need to make changes, the risks of not fixing problems in this area, and concrete ways to make your embedded system software better. Each of the 29 chapters is self-sufficient, permitting developers with a busy schedule to cherry-pick the best ideas to make their systems better right away.

If you are relatively new to the area but have already learned the basics, this book will be an invaluable asset for taking your game to the next level. If you are experienced, this book provides a way to fill in any gaps. Once you have mastered this material, the book will serve as a source of reminders to make sure you haven't forgotten anything as you plan your next project. The product image of the back of the book lists the chapters.

✦ Table of Contents

Chapter List
Preface
Book Organization
Acknowledgments
Author notes for the e-book edition:
Chapter 1 Introduction
Contents:
1.1. Overview
1.2. Using this book
1.3. Chapter organization
1.3.1. Chapter sections
1.3.2. Getting more information
1.4. What do you do first?
Chapter 2 Written Development Plan
Contents:
2.1. Overview
2.1.1. Importance of a written development plan
2.1.2. Possible symptoms
2.1.3. Risks of an inadequate development plan
2.2. Development plan overview
2.2.1. Benefits of a development plan
2.2.2. Creating a development plan
2.2.3. Risk management and success criteria
Chapter 3 How Much Paper Is Enough?
Contents:
3.1. Overview
3.1.1. Importance of creating enough paper
3.1.2. Possible symptoms
3.1.3. Risks of insufficient amounts of paper
3.2. Good ideas for creating paper
3.2.1. What paper should I create?
3.2.2. How much paper should I create?
Chapter 4 How Much Paper Is Too Much?
Contents:
4.1. Overview
4.1.1. Importance of keeping useful paper
4.1.2. Possible symptoms
4.1.3. Risks of creating useless paper
4.2. How to avoid useless paper
4.2.1. Make paper useful
4.2.2. Keep paper up to date
4.2.3. Eliminate paper that can’t be made useful
4.3. Pitfalls
4.4. For more information
4.4.1. General topic search keywords
4.4.2. Recommended reading
Chapter 5Written Requirements
Contents:
5.1. Overview
5.1.1. Importance of written requirements
5.1.2. Possible symptoms
5.1.3. Risks of inadequate requirements
5.2. What to put in written requirements
5.2.1. The big picture on requirements
5.2.2. Types of requirements
Chapter 6 Measurable Requirements
Contents:
6.1. Overview
6.1.1. Importance of having measurable requirements
6.1.2. Possible symptoms
6.1.3. Risks of unmeasurable requirements
6.2. Successful quantification of requirements
6.2.1. Avoid a requirement for perfection
6.2.2. Being precise
Chapter 7 Tracing Requirements To Test
Contents:
7.1. Overview
7.1.1. Importance of tracing requirements
7.1.2. Possible symptoms
7.1.3. Risks of inadequate traceability
7.2. Traceability
7.2.1. Requirement to test traceability
7.2.2. Exploratory testing and traceability
7.2.3. Other uses of traceability
7.3. Pitfalls
7.4. For more information
7.4.1. General topic search keywords
7.4.2. Recommended reading
Chapter 8 Non-Functional Requirements
Contents:
8.1. Overview
8.1.1. Importance of meeting non-functional requirements
8.1.2. Possible symptoms
8.1.3. Risks of inadequate non-functional requirements
8.2. Common non-functional requirements
8.2.1. Performance
8.2.2. Resource usage
8.2.3. Dependability
8.2.4. Fault handling
8.2.5. Security and intellectual property protection
8.2.6. Safety and critical functions
8.2.7. Usability
8.2.8. Conformance to standards and certification requirements
8.3. Pitfalls
8.4. For more information
8.4.1. General topic search keywords
Chapter 9 Requirement Churn
Contents:
9.1. Overview
9.1.1. Importance of minimizing requirement churn
9.1.2. Possible symptoms
9.1.3. Risks of frequent requirement changes
9.2. Tracking requirement churn
9.2.1. Tracking the requirement change rate
Chapter 10 Software Architecture
Contents:
10.1. Overview
10.1.1. Importance of a well defined software architecture
10.1.2. Possible symptoms
10.1.3. Risks of an inadequately defined software architecture
10.2. Representing software architecture
10.2.1. Common architectural representations
10.2.2. Multiple architectural diagrams
Chapter 11 Modularity
Contents:
11.1. Overview
11.1.1. Importance of modular systems
11.1.2. Possible symptoms
11.1.3. Risks of non-modular systems
11.2. Evaluating modularity
11.2.1. Small size
11.2.2. High cohesion
11.2.3. Low coupling
11.2.4. Information hiding
11.2.5. Composability
11.2.6. Low complexity
11.2.6.1. LOC (lines of code)
11.2.6.2. McCabe cyclomatic complexity
11.2.6.3. Short term memory chunks
11.2.6.4. Function points
11.2.6.5. Using complexity metrics
Chapter 12 Software Design
Contents:
12.1. Overview
12.1.1. Importance of having a good design
12.1.2. Possible symptoms
12.1.3. Risks of not having a concrete design
12.2. The role of design
12.2.1. The right level of design abstraction
12.2.2. Going straight to implementation
Chapter 13 Statecharts and Modes
Contents:
13.1. Overview
13.1.1. Importance of using statecharts
13.1.2. Possible symptoms
13.1.3. Risks of not using statecharts
13.2. Statecharts
13.2.1. Statechart construction
13.2.2. Statechart implementation
13.3. Pitfalls
13.4. For more information
13.4.1. General topic search keywords
13.4.2. Recommended reading
Chapter 14 Real Time
Contents:
14.1. Overview
14.1.1. Importance of getting real time operation right
14.1.2. Possible symptoms
14.1.3. Risks of inadequate real time design
14.2. Real time analysis overview
14.2.1. Assumptions and terminology for analysis and scheduling
14.2.1.1. All tasks Ti are perfectly periodic
14.2.1.2. All tasks Ti are completely independent
14.2.1.3. Worst case execution time Ci for each task is known
14.2.1.4. The deadline Di is greater than or equal to the period Pi
14.2.1.5. There is zero overhead to switch between tasks
14.2.1.6. Meeting the assumptions
14.2.2. Selecting an approach
14.3. Pure static scheduling (non-preemptive)
14.3.1. Pure static scheduling strengths
14.3.2. Pure static scheduling weaknesses
14.3.3. Scheduling analysis
14.3.4. Embellishments
14.3.5. Pure static scheduling pitfalls
14.4. Static scheduling with small helper interrupts
14.4.1. Strengths
14.4.2. Weaknesses
14.4.3. Scheduling analysis — the easy case
14.4.4. Scheduling analysis — the difficult case
14.4.5. Pitfalls
14.5. Rate monotonic scheduling with harmonic periods
14.5.1. Strengths
14.5.2. Weaknesses
14.5.3. Scheduling analysis
14.5.4. Embellishments
14.5.5. RMS pitfalls
14.6. Overarching pitfalls
14.6.1. Don’t bend the rules
14.6.2. Don’t write your own RTOS
14.6.3. Don’t use EDF scheduling
14.6.3. Don’t use big ISRs
14.6.4. Don’t just rely on testing to ensure deadlines are met
14.7. Knowing when to get help
14.8. For more information
14.8.1. General topic search keywords
14.8.2. Recommended reading
14.8.3. Additional reading
Chapter 15 User Interface Design
Contents:
15.1. Overview
15.1.1. Importance of good usability
15.1.2. Possible symptoms
15.1.3. Risks of a bad user interface
15.2. User interface design process
15.2.1. Identifying the user population
15.2.2. Identifying the task
Chapter 16 How Much Assembly Language Is Enough?
Contents:
16.1. Overview
16.1.1. Importance of avoiding assembly language
16.1.2. Possible symptoms
16.1.3. Risks of too much assembly language
16.2. Why avoid using assembly language?
16.2.1. Higher cost and longer development time
16.2.2. Poor portability
16.3. Techniques for avoiding assembly language
16.3.1. Buying a bigger, faster CPU
16.3.2. Profiling and optimizing
16.3.3. Tuning source code for the compiler
16.3.4. Giving more information to the compiler
16.3.5. Rewriting code to make optimization easier
16.4. When is it OK to use assembly language?
16.4.1. Really tiny processors
16.4.2. Small, frequently used routine
16.4.3. Extended precision math
16.4.4. Specialized hardware resources
16.5. Pitfalls
16.6. For more information
16.6.1. General topic search keywords
16.6.2. Recommended reading
16.6.3. Additional reading
Chapter 17 Coding Style
Contents:
17.1. Overview
17.1.1. Importance of a consistent coding style
17.1.2. Possible symptoms
17.1.3. Risks of not having a written coding style guideline
17.2. Good coding style
17.2.1. Style issues
17.2.2. Source file templates
17.2.3. Commenting guidelines
17.2.3.1. Traceability comments
17.2.3.2. Assertions
17.3. Language usage rules
17.3.1. Formatting guidelines
17.3.2. Language usage rules
17.3.3. MISRA C
17.4. Naming conventions
17.5. Pitfalls
17.5.1. So-called self-documenting code
17.6. For more information
17.6.1. General topic search keywords
17.6.2. Recommended reading
Chapter 18 The Cost of Nearly Full Resources
Contents:
18.1. Overview
18.1.1. Importance of having slack in resources
18.1.2. Possible symptoms
18.1.3. Risks of too-full resources
18.2. How full is too full?
18.3. An example of hardware/software cost tradeoffs
Chapter 19 Global Variables Are Evil
Contents:
19.1. Overview
19.1.1. Importance of avoiding globals
19.1.2. Possible symptoms
19.1.3. Risks of using globals
19.2. Why are global variables evil?
19.2.1. Definition of global variables
19.2.2. Quasi-global variables
19.2.3. Global variable problem: implicit coupling
19.2.4. Global variable problem: bugs due to interference
19.2.5. Global variable problem: lack of mutex
19.2.6. Pointers to globals
Chapter 20 Mutexes and Data Access Concurrency
Contents:
20.1. Overview
20.1.1. Importance of using data access concurrency techniques
20.1.2. Possible symptoms
20.1.3. Risks of incorrect concurrency management
20.2. Data sharing hazards
20.2.1. Data updated in mid-read
20.2.2. Updates of data held in registers
20.2.3. Multiple writers
20.3. Data protection strategies
20.3.1. Volatile keyword
20.3.2. Atomic modifications and disabling interrupts
20.3.2.1. Atomic operations for multiple threads
20.3.2.2. Atomic operations for hardware access
20.3.2.3. Atomic operations within ISRs
20.3.3. Queues
20.3.3.1. Queues to avoid concurrency problems
20.3.3.2. Double buffering
20.3.4. Mutexes
20.4. Reentrant code
20.5. Pitfall
20.6. For more information
20.6.1. General topic search keywords
20.6.2. Recommended reading
Chapter 21 Static Checking and Compiler Warnings
Contents:
21.1. Overview
21.1.1. Importance of performing static checks
21.1.2. Possible symptoms
21.1.3. Risks of omitting static checks
21.2. The role of compiler warnings
21.2.1. Example warnings
21.2.1.1. Uninitialized variable
21.2.1.2. Suspicious language use
21.2.1.3. Risky type conversions
Chapter 22 Peer Reviews
Contents:
22.1. Overview
22.1.1. Importance of doing peer reviews
22.1.2. Possible symptoms
22.1.3. Risks of not doing peer reviews
22.2. Peer review effectiveness
Chapter 23 Testing and Test Plans
Contents:
23.1. Overview
23.1.1. Importance of testing and test plans
23.1.2. Possible symptoms
23.1.3. Risks of inadequate test efforts
23.2. Overview of testing
23.2.1. When can we test?
23.2.2. What styles of testing can be used?
23.2.2.1 Smoke testing
23.2.2.2 Exploratory testing
23.2.2.3 White box testing
23.2.2.4 Black box testing
23.2.3. How much testing is enough?
23.3. Why do we test?
23.3.1. Testing to fix bugs (debug-oriented testing)
23.3.2. Testing to verify development process quality
23.3.3. The spectrum of testing goals
23.4. Test plans
23.4.1. What to test
23.4.2. How to test
23.4.3. How thoroughly do you test?
23.4.4. Test automation
23.4.5. Test result reporting
23.5. Pitfalls
23.6. For more information
23.6.1. General topic search keywords
23.6.2. Recommended reading
Chapter 24 Issue Tracking & Analysis
Contents:
24.1. Overview
24.1.1. Importance of tracking issues
24.1.2. Possible symptoms
24.1.3. Risks of not tracking issues
24.2. Issue tracking
24.2.1. Why track issues?
24.2.2. What information should be tracked ?
24.3. What’s a bug, really?
24.3.1. Is it a bug or an issue?
24.3.2. When does an issue count for reporting?
24.4. Defect and issue analysis
24.4.1. Issue reporting
24.4.2. Identification of bug farms
24.4.3. Identification of process problems
24.5. Pitfalls
24.6. For more information
24.6.1. General topic search keywords
24.6.2. Recommended reading
Chapter 25 Run-Time Error Logs
Contents:
25.1. Overview
25.1.1. Importance of run-time error logs
25.1.2. Possible symptoms
25.1.3. Risks of not keeping error logs
25.2. Error logging
25.2.1. How to log
25.2.2. What to log
25.2.3. Recording system reset
25.3. Error log analysis
25.3.1. Identifying failure causes
25.3.2. Identifying latent defects
25.4. For more information
25.4.1. General topic search keywords
25.4.2. Recommended reading
Chapter 26 Dependability
Contents:
26.1. Overview
26.1.1. Importance of achieving dependability
26.1.2. Possible symptoms
26.1.3. Risks of dependability gaps
26.2. Hardware dependability
26.2.1. Faults and failures
26.2.2. Reliability
26.2.2.1. Computing reliability
26.2.3. Reliability vs. MTBF
26.2.3.1. Serial component reliability
26.2.3.2. Redundancy and parallel component reliability
26.2.4. Availability
26.2.5. Dispatchability
26.2.6. Support for computing hardware reliability
26.3. Software dependability
26.3.1. High quality software
26.3.2. Software state scrubbing
26.3.3. Diverse software
26.3.3.1. Use different versions of third party software
26.3.3.2. Have a simple version as a fallback plan
26.3.3.3. Other approaches
26.4. Dependability plan
26.4.1. Dependability goal
26.4.2. Anticipated faults
26.4.3. Planned dependability approaches
26.5. Pitfalls
26.6. For more information
26.6.1. General topic search keywords
26.6.2. Recommended reading
26.6.3. Additional resources
26.6.4. References
Chapter 27 Security
Contents:
27.1. Overview
27.1.1. Importance of adequate security
27.1.2. Possible symptoms
27.1.3. Risks of inadequate security
27.2. Embedded security overview
27.2.1. Aspects of security
27.2.2. Embedded-specific attacks
27.2.3. Attack probability and motivation
27.2.4. Elements of typical countermeasures
27.3. Attack vectors (network and otherwise)
27.3.1. Internet connection
27.3.2. Factory-installed malware
27.3.3. Off-line spreading of malware
27.3.4. Indirectly Internet connected
27.3.5. Modem connected
27.3.6. Unauthorized users
27.4. Intellectual property protection
27.5. Security plan
27.5.1. Security plan elements
27.5.2. The no security plan
27.6. Pitfalls
27.7. For more information
27.7.1. General topic search keywords
27.7.2. Recommended reading
27.7.3. References
Chapter 28 Safety
Contents:
28.1. Overview
28.1.1. Importance of ensuring an appropriate level of safety
28.1.2. Possible symptoms
28.1.3. Risks of insufficient attention to safety
28.2. Embedded safety
28.2.1. Terminology
28.2.2. What, exactly, is safe software?
28.2.3. How big an issue is safety in your system?
28.2.4. Safety Integrity Levels
28.3. Safety analysis techniques
28.3.1. HAZOP (HAzard and OPerability)
28.3.2. PHA (Preliminary Hazard Analysis)
28.3.3. FTA (Fault Tree Analysis)
28.4. Avoiding safety critical software
28.4.1. Hardware implementation of critical functions
28.4.2. Hardware gating of critical functions
28.4.3. Hardware safety shutdown
28.4.4. Human oversight
28.5. Creating safety critical software
28.5.1. Safety plan
28.6. Pitfalls
28.7. For more information
28.7.1. General topic search keywords
28.7.2. Suggested reading
28.7.3. References
Chapter 29 Watchdog Timers
Contents:
29.1. Overview
29.1.1. Importance of using a watchdog
29.1.2. Possible symptoms
29.1.3. Risks of not using a watchdog
29.2. Watchdog timer overview
29.2.1. Watchdog timer operation
29.2.2. Watchdog effectiveness
29.2.3. Variations on watchdog timers
29.2.3.1. Software-settable watchdog parameters
29.2.3.2. Unlock sequence
29.2.3.3. Watchdog activated during startup
29.2.3.4. Windowed watchdog
29.2.4. Software watchdog
Chapter 30 System Reset
Contents:
30.1. Overview
30.1.1. Importance of a good system reset strategy
30.1.2. Possible symptoms
30.1.3. Risks of poor reset behavior
30.2. Ways to reset a system
30.2.1. External system resets
30.2.2. Internal system resets
30.3. Well behaved resets
30.3.1. Behavior during the reset
30.3.2. Behavior after the reset
30.3.3. Repeated resets
30.4. For more information
30.4.1. Recommended reading
Chapter 31 Conclusion
31.1 Selected best practices
31.1.1 Best practice summary from this book
31.1.2 Additional best practices
31.2 For More Information
31.2.1. Blogs and author’s papers
31.2.2. Lectures and slides
31.2.3 About the author
1.5. It’s printed in a book, so it must be true, right?
1.6. For more information
1.6.1. General topic search keywords
1.6.2. Other resources
2.3. Starting point for a development plan
2.3.1. Process steps and paper generated
2.3.2. Risk management
2.3.2.1. Peer reviews
2.3.2.2. Gate reviews
2.3.3. Success criteria
2.4. Pitfalls
2.5. For more information
2.5.1. General topic search keywords
2.5.2. Recommended reading
2.5.2.1. General project management
2.5.2.2. Software development plans
2.5.2.3. Software development models
2.5.2.4. Software risk management
3.3. A starting point for what paper to create
3.3.1. Customer requirements
3.3.2. Engineering requirements
3.3.3. Architecture
3.3.4. Design
3.3.5. Implementation
3.3.6. Test plan
3.3.7. Bug list
3.3.8. User Guide
3.3.9. Marketing materials
3.3.10. Schedule and staffing plan
3.3.11. A software development plan
3.4. Pitfalls
3.5. For more information
3.5.1. General topic search keywords
3.5.2. Suggested reading
3.5.3. Examples of documentation standards
3.5.4. Additional reading
5.3. Good requirement practices
5.3.1. Measurement
5.3.2. Tolerance
5.3.3. Consistency
5.3.4. Use of should and shall
5.3.5. Trackability
5.3.6. Readability
5.4. Pitfalls
5.5. For more information
5.5.1. General topic search keywords
5.5.2. Recommended reading
5.5.3. Suggested standards
6.3. Measuring the unmeasurable
6.3.1. Don’t ignore unmeasurable topics when writing requirements
6.3.2. Create a proxy measurement
6.3.3. Get testers involved up front
6.3.4. Create an engineering feedback system
6.3.5. Rely upon process
6.3.6. Formal methods
6.4. Pitfalls
6.5. For more information
6.5.1. General topic search keywords
6.5.2. Recommended reading
9.3. Controlling requirement churn
9.3.1. The Change Control Board
9.3.2. Requirement freezes
9.3.3. Assessing the cost of changes
9.4. Pitfalls
9.5. For more information
9.5.1. General topic search keywords
9.5.2. Recommended reading
10.3. What makes an architecture good?
10.3.1. Architectural patterns
10.4. Pitfalls
10.5. For more information
10.5.1. General topic search keywords
10.5.2. Recommended reading
11.3. Improving modularity
11.3.1. Factoring
11.3.2. Aggregation
11.4. Pitfalls
11.4.1. Using performance as an excuse for poor modularity
11.4.2. Over-aggressive simplification
11.5. For more information
11.5.1. General topic search keywords
11.5.2. References
12.3. Different design representations
12.3.1. Pseudocode
12.3.2. Flowcharts
12.3.3. Statecharts
12.3.4. Other design representations
12.3.5. Code synthesis and model-based design
12.4. Pitfalls
12.5. For more information
12.5.1. General topic search keywords
12.5.2. Recommended reading
15.3. Good user interface design
15.3.1. User interface design principles.
15.3.2. Testing the design for usability
15.3.3. Reviewing the design
15.3.4. Iterated design efforts
15.4. Pitfalls
15.5. For more information
15.5.1. General topic search keywords
15.5.2. Recommended reading
15.5.3. References
18.4. Fixing overly full resources
18.5. Pitfalls
18.5.1. Optimizing to increase slack capacity
18.5.2. Over-zealous avoidance of optimization
18.6. For more information
18.6.1. General topic search keywords
18.6.2. References
19.3. Ways to avoid or reduce the risk of globals
19.3.1. Get a more capable processor
19.3.2. Move the global inside the procedure that needs it
19.3.3. Make a shared variable quasi-global instead of global.
19.3.4. Make the global an object, and provide access methods
19.3.5. If you must use a global, document it well
19.4. Pitfalls
19.5. For more information
19.5.1. General topic search keywords
19.5.2. Recommended reading
19.5.3. Additional reading
21.3. Lint and static analysis tools
21.4. Pitfalls — working around warnings
21.4.1. Warning pragmas
21.4.2. Switch statement default cases
21.5. For more information
21.5.1. General topic search keywords
21.5.2. Recommended reading
22.3. Conducting peer reviews
22.3.1. What can be reviewed?
22.3.2. How do you perform peer reviews?
22.3.3. Review productivity
22.4. Pitfalls
22.5. For more information
22.5.1. General topic search keywords
22.5.2. Recommended reading
22.5.3. References
29.3. Good watchdog practices
29.4. Pitfalls
29.5. For more information
29.5.1. General topic search keywords
29.5.2. Recommended reading