Better Embedded System Software

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. 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