Developing and Managing Embedded Systems and Products: Methods, Techniques, Tools, Processes, and Teamwork

Developing and Managing Embedded Systems and Products

Methods, Techniques, Tools, Processes, and Teamwork

Kim R. Fowler

Craig L. Silver

Table of Contents

Cover image

Title page

Copyright

List of Contributors

About the Editor

Co-Author Biography

Author’s Biographies

Chapter Authors

Case Study Authors

Developing and Managing Embedded Systems and Products: The Roadmap

Chapter 1: Introduction to Good Development

Chapter 2: Drivers of Success in Engineering Teams

Chapter 3: Project Introduction

Chapter 4: Dealing with Risk

Chapter 5: Documentation

Chapter 6: System Requirements

Chapter 7: Analyses and Tradeoffs

Chapter 8: The Discipline of System Design

Chapter 9: Mechanical Design

Chapter 10: Electronic Design

Chapter 11: Software Design and Development

Chapter 12: Security

Chapter 13: Review

Chapter 14: Test and Integration

Chapter 15: Manufacturing

Chapter 16: Logistics, Distribution, and Support

Chapter 17: Agreements, Contracts, and Negotiations

Chapter 18: Dealing with the Government

Chapter 19: Agency and Getting Paid

Chapter 20: Intellectual Property etc.

Chapter 21: Open Source Software

Chapter 22: Laws That Can Nail Embedded Engineers

Chapter 23: Corporate Operations, Export, and Compliance

Chapter 24: Case Studies

List of Acronyms

Chapter 1. Introduction to Good Development

About this book

Focus

Team attributes

Systems engineering

Various approaches to development processes

Life cycle phases

Case Study: Disastrous engineering processes fixed

Conclusion

Acknowledgments

References

Suggested reading

Chapter 2. Drivers of Success in Engineering Teams

Overview of organizational and psychological drivers

The role of the team member

The role of the team leader

Self-awareness and assessment

Establishing essential relationships

Team development

Engagement and the motivational environment

The power of dialogue

Enhancing success with emotional intelligence

Handling conflict

Further development

References

Chapter 3. Project Introduction

Overview

Establishing the vision, mission, goals, and objectives

Establish the team

Communications

Business case

Business administration and concerns

Effort to introduce a project

Acknowledgement

Recommended reading

References

Chapter 4. Dealing with Risk

Overview

Definitions

Risk analysis and management

Hazard analysis

Types of problems

Failure

Disasters and catastrophes

Intrusion, sabotage, theft, and destruction

Contingency planning

Effort to manage risk

Acknowledgement

References

Chapter 5. Documentation

Overview and rationale

Function

Types and content

When, who, and what

Document formats

Document contents

Summary and parting thoughts

Appendix A: Examples from a test plan

Integration test procedures

Some test plans have a manufacturing section—here is an example

Acceptance test procedures

Installation test procedures

Appendix B: Examples of test procedures

Mechanical, packaging, and cabling test scripts

Software processes test scripts

Hardware test scripts

Recommended reading

References

Chapter 6. System Requirements

Definitions

Developing and managing requirements

Customer interpretation of requirements

Requirement categories

Common risks in setting requirements

Process and QA

Domains and properties

Setting boundaries

Framing the system for requirements definition

Use cases

Prioritizing requirements

Recommendations to reduce requirements’ risks

Mike Gard: thoughts on developing requirements

Oshana’s Maxim—estimating requirements’ efforts

Acknowledgments

References

Recommended reading

Chapter 7. Analyses and Tradeoffs

Introduction

The business case

Tradeoffs

Use cases

Design analyses

Physical forms of analysis

Formal analysis techniques

Root cause analysis (RCA)

Final case study

Acknowledgment

References

Recommended reading

Chapter 8. The Discipline of System Design

What to expect in this chapter

Basic definitions

Human elements in system design

Business concerns

The art of system design

System design choices

Approaching a design

Finding parts

System analysis and test

References

Chapter 9. Mechanical Design

What to expect from this chapter

Materials

Fasteners

Fabrication

Finishes

Packaging

Thermal design

Mechanisms

Analysis and test

References

Suggested reading

Chapter 10. Electronic Design

Overview of electronic design

Circuit design

Components

Semiconductors

Visual displays

Integrated circuits

Circuit boards

Connectors, cables, and conductors

Operating life (MTBF)

Power and power consumption

Cooling

Environmental extremes

RFI, EMI, and EMC compliance

Analysis methods

Testing, qualifications, and conflicts

Built-in self-test

Acknowledgment

References

Chapter 11. Software Design and Development

Distinguishing characteristics

The framework for developing embedded software

Tools and techniques

Conclusion

References

Chapter 12. Security

Overview

Correctness, safety, and security

Security engineering

Building a secure system

Chapter references

Suggested reading

Chapter 13. Review

Introduction to review

General processes and procedures

Components of a review

Peer review and inspection

Internal review

Formal design review

Change control board

Failure review board

Audits and customer reviews

Static versus dynamic analysis

Debrief

Acknowledgments

References

Chapter 14. Test and Integration

Introduction

General processes and procedures

Test plan

Verification

Validation

Field trial and testing

Integration

Calibration and alignment checks

Environmental tests

Highly accelerated life test

Compliance testing

Other issues to consider

Acknowledgment

References

Suggested reading

Chapter 15. Manufacturing

Overview of manufacturing

Some philosophical issues with manufacturing

General processes and procedures

Specifics of fabrication and assembly

Production test

Considerations in manufacturing

Acknowledgments

References

Chapter 16. Logistics, Distribution, and Support

Overview of logistics, distribution, and support

Market release

Distribution and delivery

Packaging

Inventory

Sales support

Technical support

Training

Maintenance and replenishment

Diagnosis and repair

Recalls, patches, and updates

Reverse and green logistics and disposal

Acknowledgment

References

Suggested reading

Chapter 17. Agreements, Contracts, and Negotiations

Interpretation of contracts generally

The signing of agreements

The ubiquitous NDA

MOU means IOU

A word on negotiations of contracts

Humble negotiations with the Big Guy (reprinted with permission from the September 2001 IEEE Instrumentation and Measurement Magazine, by Craig Silver)

Chapter 18. Dealing with the Government

Considerations in US federal government contracts

The government’s right to change

The government’s right to terminate

Ethical issues in government contracts

Some criminal statutes relevant to government contracting

The government contractor defense

Chapter 19. Agency and Getting Paid

Agency

Why are agency relations so important?

Getting paid

Bankruptcy—what does his problem have to do with me?

Chapter 20. Intellectual Property, Licensing, and Patents

Software licensing, source code, and somebody going broke

Protection of intellectual property

Copyrights and the embedded engineer

Protection of trade secrets

Trademarks

Patents

Chapter 21. Open-Source Software

Best read in a Volkswagen minibus

Top 20 most commonly used licenses in open-source projects

Most recent projects to convert to GPLv3, LGPLv3, or AGPLv3

Public domain and shareware

Litigation and an open-source license

Chapter 22. Laws That Can Nail Embedded Engineers

The Digital Millennium Copyright Act

Stored Communications Act

The Computer Fraud and Abuse Act 18 USC § 1030

Torts and the engineer

Chapter 23. Corporate Operations

The charter

Shares and stocks

Hiring or contracting with foreigners

So you want to export

Antiboycott considerations (ignoring, I told you not to play with her!)

Arbitration clauses under international contracts

Insurance

Compliance—or why won’t you comply?

Chapter 24. Case Studies

Introduction

Two case studies from the Oak Ridge National Laboratory: development of real-time instrumentation systems

Case study 3: design of a parallel computer-based, streaming digital video instrument

Case study 4: troubleshooting a boiler points out the need for good, comprehensive design and development

Case study 5: debugging of electromagnetic compatibility issues

References

Appendix A. Dependability Calculations

Brief overview

Observed failure rates

First approximation: simplified failure rates

Experimental analysis

Recommended Reading

References

Index

Copyright

Newnes is an imprint of Elsevier

The Boulevard, Langford Lane, Kidlington, Oxford OX5 1GB, UK

225 Wyman Street, Waltham, MA 02451, USA

Copyright © 2015 Elsevier Inc. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of the publisher.

Permissions may be sought directly from Elsevier’s Science & Technology Rights Department in Oxford, UK: phone (+44) (0) 1865 843830; fax (+44) (0) 1865 853333; email: permissions@elsevier.com. Alternatively you can submit your request online by visiting the Elsevier web site at http://elsevier.com/locate/permissions, and selecting Obtaining permission to use Elsevier material.

Notice

No responsibility is assumed by the publisher for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein. Because of rapid advances in the medical sciences, in particular, independent verification of diagnoses and drug dosages should be made.

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloging-in-Publication Data

A catalog record for this book is available from the Library of Congress

ISBN: 978-0-12-405879-8

For information on all Newnes publications visit our website at http://store.elsevier.com/

Printed and bound in the United States of America

15 16 17 18 19 10 9 8 7 6 5 4 3 2 1

List of Contributors

Kim R. Fowler,     IEEE Fellow, Consultant

Allison Fritz,     Organization Development and Training Consultant, The Johns Hopkins HealthCare LLC

Michael F. (Mike) Gard,     Senior Product Design Engineer The Charles Machine Works Perry, OK, USA

Robert Oshana,     Director, Software Research and Development, Digital Networking, Freescale Semiconductor

Geoff Patch,     CEA Technologies Pty. Ltd.

Craig L. Silver,     Director–Strategic Initiatives/General Counsel, Amches, Inc.

Eugene Vasserman,     Kansas State University

Tim Wescott,     IEEE Senior Member, Owner, Wescott Design Services

Steve Zeise,     Aerospace Electronics Industry

About the Editor

Kim R. Fowler has spent over 30 years in the design, development, and project management of medical, military, and satellite equipment. His interest is the rigorous development of diverse, mission-critical, embedded systems. He co-founded Stimsoft, a medical products company, in 1998 and sold it in 2003. He also has worked for JHU/APL designing embedded systems, for a company now part of Curtiss-Wright Embedded Computing that built digital signal processing boards, and consulted for both commercial companies and government agencies. He is a Fellow of the IEEE and lectures internationally on systems engineering and developing real-time embedded products. He has been president of the IEEE Instrumentation & Measurement society and an adjunct professor for the Johns Hopkins University Engineering Professional Program. He has published widely and has written three textbooks—this book is his fourth. He has 18 patents—granted, pending, or disclosed. He is currently a graduate student in Electrical Engineering at Kansas State University to finally get his PhD.

Co-Author Biography

Craig L. Silver has over 30 years of diverse legal experience for private, commercial, start-ups, and nonprofit entities, serving as litigation counsel for complex commercial disputes, constitutional law claims, aviation torts, and criminal defense. Having served as a general counsel, general manager, and president for defense electronic firms and telecommunications companies, he is experienced with technology companies dealing with software licensing issues, IP protection, and international transactions. He has previously published for the IEEE—Silver Bullets and has worn various hats in high technology companies that include business development and technical liaison with field application engineers. He holds a BA degree from the Universityof Maryland and a JD degree from George Mason University Law School. He is a licensed pilot and ham radio operator. He is married and resides in Maryland, USA.

Author’s Biographies

Chapter Authors

Allison Fritz is an Organization Development and Facilitation professional with over 20 years’ experience in a variety of industries. Presently working as a Sr. Organization Development and Training Consultant with the Johns Hopkins Health System, she has also worked within higher education, the petroleum industry, and independent consulting, serving both Fortune 100 and small business, designing and facilitating processes. Allison’s expertise is in team development, change management, leader development, strategic visioning, and coaching. With 14 years in management roles, she applies her experience to her work. Allison has a doctoral degree in Organization and Staff Development from the University of Maryland College Park, a Master’s degree in Counseling and Student Personnel, and a Bachelor’s degree in Communications and Psychology from the University of Delaware; as well as holds several certifications including, Emotional Intelligence (EQ2.0, 360), Crucial Conversations, Strong Interest Inventory, and MBTI. Allison focuses her work on encouraging leaders, teams and organizations to realize positive change.

Michael F. (Mike) Gard, received his BSEE from Kansas State University, MSEE (Interdepartmental Program in Biomedical Engineering) from Washington University in St. Louis, and PhDEE (Geophysics minor) from Southern Methodist University. He has over 40 years of industrial experience in aircraft, medical equipment, clinical engineering, petroleum, and construction industries. He is presently Sr. Product Design Engineer at The Charles Machine Works, Perry, OK. An adjunct professor, he occasionally teaches at Oklahoma State University. He is a registered professional engineer, patent agent, inventor (34 US patents), author, member of the IEEE Instrumentation and Measurement Society’s Administrative Committee, and editor-in-chief of IEEE Instrumentation and Measurement Magazine. His technical interests include real-time data acquisition and precision analog and analog/digital systems for low power and hostile environments.

Robert Oshana has 30 years of experience in the software industry, primarily focused on embedded and real-time systems for the defense and semiconductor industries. He has BSEE, MSEE, MSCS, and MBA degrees and is a senior member of IEEE. He is a member of several Advisory Boards including the Embedded Systems group, where he is also an international speaker. He has over 200 presentations and publications in various technology fields and has written several books on Embedded software technology including Software Engineering for Embedded Systems. He is an adjunct professor at Southern Methodist University where he teaches graduate software engineering courses. He is a distinguished member of Technical Staff and Director of Global Software R&D for Digital Networking at Freescale Semiconductor.

Geoff Patch has over 30 years experience as a software engineer. He has worked for the Australian government, in academia, and for a number of engineering companies. Since 1987, he has specialized in embedded systems, primarily in the areas of radar target tracking, radar signal processing, and command and control systems. He is also keenly interested in software process improvement, technical team leadership, and technical management. He has developed software for numerous commercially successful radar systems ranging from conventional maritime surveillance, through specialized applications such as submarine periscope detection and up to large air defense systems. He is currently the manager of a team of nearly 30 software engineers involved in the development of new radar systems at CEA Technologies in Canberra, Australia.

Eugene Vasserman received his PhD and master’s degrees in Computer Science in 2010 and 2008, respectively, from the University of Minnesota. His BS, in Biochemistry and Neuroscience with a Computer Science minor, is also from the University of Minnesota (2003). In 2013, he received the NSF CAREER award for work on secure next generation medical systems.

Tim Wescott has 25 years of real-world experience in embedded systems design, with roles ranging from software designer to circuit designer to systems architect. Tim has worked on small, inexpensive hand-held instruments, on large airborne imaging systems, and on nearly everything in between. He has experience in all phases of system life cycles, ranging from designing new systems from a clean sheet of paper to extending the useful lives of systems that are on the verge of obsolescence. Tim is author of Applied Control Theory for Embedded Systems, aimed at engineers who slept through control theory class in University, and who now need to design a system that must successfully implement a feedback control loop. Tim is the owner of Wescott Design Services, which provides analysis, design, and troubleshooting of embedded control systems, with a particular emphasis on control of dynamic systems, low-level communications systems, and metrology. Wescott Design Systems has helped customers of all sorts of problems ranging from drives for 1/2-inch diameter brushless motors to implementing communications systems for deep-well drilling platforms.

Steve Zeise is a mechanical engineer and designer with 30 years’ experience in all things mechanical. He received a BS in Mechanical Engineering from Rose-Hulman Institute of Technology and immediately went to work for Westinghouse Defense and Electronics Systems Center designing mechanisms, structures, and cooling systems supporting embedded systems in night vision cameras. With positions at Northrop-Grumman and Lockheed Martin, he gained experience in structural analysis and environmental testing. He is currently with FLIR Systems where he helped to setup a small R&D facility in Orlando, FL and for the past 15 years has worked to help FLIR Systems solve complex vibration problems.

Case Study Authors

David von Oheimb received his PhD in computer science in 2001 from the Munich University of Technology, where he focused on machine-assisted formal modeling and verification of the programming language Java. He joined Siemens Corporate Technology, where he became a senior researcher, developer, and key expert consultant on IT security. His specific areas of expertise are security architecture, formal analysis, and IT security certification according to the Common Criteria. He has been involved as participant and leader of various Siemens-internal and EU-funded R&D projects on security protocol and information flow analysis using model checkers and theorem provers and of various industrial projects dealing for instance with Infineon smart cards, software update mechanisms for Boeing and Continental Automotive, and German and Austrian smart metering systems.

Kenneth W. Tobin is the Director of the Electrical and Electronics Systems Research (EESR) Division at the Oak Ridge National Laboratory (ORNL), Oak Ridge, Tennessee, USA, where he has been working in various R&D and leadership capacities since 1987. The EESR Division is composed of 150 staff who perform R&D in electronics, sensors, communications, and controls for energy efficiency, resiliency, and security. His personal research areas encompass photonics, neutronics, x-ray, SEM, electronic imaging and microscopy coupled with signal processing and machine learning. Science and technology specialty in computational imaging, image metrology, object segmentation, and feature generation from multi-spectral, multi-source imagery for inverse imaging, robust human-level classifiers, image archival and retrieval applications, and image-based informatics. Dr. Tobin was named an ORNL Corporate Research Fellow in 2003 for his contributions to the field of applied computer vision research. He has authored and co-authored over 164 publications and he currently holds fourteen U.S. Patents in areas of computer vision, photonics, radiography, and microscopy. Dr. Tobin is a Fellow of the Institute of Electrical and Electronics Engineers (IEEE) and a Fellow of the International Society for Optics and Photonics (SPIE), where he is currently an Associate Editor for the Journal of Electronic Imaging. Dr. Tobin has a Ph.D. in Nuclear Engineering from the University of Virginia, an M.S. in Nuclear Engineering from Virginia Tech, and a B.S. in Physics also from Virginia Tech.

Dwight A. Clayton is the group leader of the Electronic and Embedded Systems group at the Oak Ridge National Laboratory (ORNL), Oak Ridge, TN. The mission of the Electronic and Embedded Systems (EESG) group is to apply modern electronic methods to provide solutions to challenges that are important to the ORNL, the Department of Energy, other federal agencies, and private industry. He joined ORNL in 1983 as a development staff member in the Instrumentation and Controls Division. In 1994, he was named leader of the Electronic and Embedded Systems Group. Since 2000, the innovative efforts of the Electronic and Embedded Systems group have resulted in the receipt of four R&D 100 awards. He has an MS and BS in electrical engineering from Tennessee Technological University.

Bogdan Vacaliuc is a research and development staff member in the Electronic and Embedded Systems Group of the Oak Ridge National Laboratory’s Measurement Science and Systems Engineering Division. His entrepreneurial career has spanned several small and medium-size startup companies developing products in signal intelligence, telecommunications, visual image processing, and consumer electronics manufacturing. Prior to joining Oak Ridge National Laboratory in 2009, he served as Chief Technical Officer for Sundance DSP, Inc., a maker of modular hybrid signal processing computing hardware for portable and military applications. He emigrated to the United States in 1973 from Romania and earned bachelor and master’s degrees in Electrical Engineering from Northwestern University in 1990 and 1992, respectively.

Lee Barford is master scientist at Keysight Laboratories and professor of Computer Science and Engineering (adjunct) at the University of Nevada, Reno, NV. He leads Keysight’s efforts in applying parallel computing to speed electronic measurements. He also leads research to identify and apply emerging technologies in software and applied mathematics to enable new kinds of measurements and increase measurement accuracy and speed. His work has been used to improve R&D productivity and reduce manufacturing cost in the leading companies in the technology and transportation industries, including Apple, Boeing, Cisco, Ford, HP, Microsoft, and NASA. Previously, he managed a number of research projects at Agilent and Hewlett-Packard Laboratories, for example, in visible light and X-ray imaging systems, calibration methods for nonlinear and dynamical disturbances, and fault isolation from automatic test equipment results. He is an author of over 40 peer-reviewed publications and an inventor of approximately 60 patents.

Hong-Liang Xu is a senior research engineer at Keysight Laboratories. He joined Agilent Laboratories in 2007 after earning a master’s degree from Beijing University of Posts and Telecommunications. In the field of parallel computing, he focuses on the methods to accelerate DSP and measurement algorithms on common platforms, like multicore CPUs and general-purpose GPUs. His recent work has included a demo of a purely software defined LTE base station with industry partners, including IBM and China Mobile Research Institute, demonstrating the DSP capabilities of multicore CPUs in the handling of wideband wireless communication protocols.

Chun-Hong Zhang is a scientific research staff member at Keysight Laboratories. He focuses on how to efficiently parallelize digital signal processing algorithms on heterogeneous computing platforms and optimize the parallel algorithms based on the advanced parallel computing features provided by different platforms. Previously, he did research projects on high-efficiency, nonreference digital voice and video quality assessment at Agilent Laboratories.

Jake Brodsky has been practicing the art of Control Systems and SCADA Engineering at the Washington Suburban Sanitary Commission for over 28 years. He intends to continue practicing until he gets it right. He is a registered professional engineer of control systems, a ham radio enthusiast, an instrument rated private pilot, a firearms instructor, and an amateur beer brewer—but not all at the same time. He co-founded and moderates the SCADASEC email list, he is co-author and co-editor of the Handbook of Control System/SCADA Security, published by CRC Press, and was recently re-elected Chair of the DNP Users Group.

Daryl Beetner is a professor of Electrical and Computer Engineering at the Missouri University of Science and Technology (formerly called the University of Missouri—Rolla). He received his BS degree in Electrical Engineering from Southern Illinois University at Edwardsville in 1990. He received an MS and DSc degree in Electrical Engineering from Washington University in St. Louis in 1994 and 1997, respectively. He conducts research with the Electromagnetic Compatibility Laboratory at Missouri S&T on a wide variety of topics including EMC of integrated circuits, EMC within embedded systems, and detection and neutralization of explosive devices. He is an associate editor for the IEEE Transactions on Instrumentation and Measurement.

Natalia Bondarenko received the BSc degree in Computer Science from Tbilisi State University, Georgia, Europe, in 2006, and received the MSc degree in Electrical and Electronics Engineering from the same university in 2009. Since 2009, she has been pursuing her PhD degree in Electrical Engineering in the EMC Laboratory at the Missouri University of Science and Technology, Rolla, MO. From 2005 to 2009, she was with EMCoS, Ltd., working on various research/consulting projects for automotive EMC. Her research interests include EM modeling and EMC/EMI measurements methods.

Peng Shao received the BS degree in Physics from Nanjing University, China, in 2006, received the MS degree in Physics from Missouri University of Science and Technology, USA in 2008, and received the MS degree in Electrical Engineering with the EMC Laboratory from the same university in 2011. Since 2011, he has been working with Cisco Systems as a hardware engineer in the signal integrity area.

Tom Van Doren has conducted research and education in electromagnetic compatibility for the past 31 years. More than 19,000 engineers and technicians from 108 companies and government agencies have attended his Grounding and Shielding and Circuit Board Layout courses. He has received two Outstanding Teacher Awards from Missouri S&T, the Richard R. Stoddard award from the IEEE EMC Society for contributions to EMC technology and education, and he is a life fellow of the IEEE and Honored Life member of the EMC Society. Much of his professional work has been devoted to helping engineers understand, diagnose, and reduce signal integrity and electrical interference problems. He can be contacted at vandoren@mst.edu or at 573-578-4193. The Van Doren Company website is www.emc-education.com.

Developing and Managing Embedded Systems and Products: The Roadmap

Kim R. Fowler

This book is for the entire project team! The book’s material contains best practices for developing embedded systems, which includes technical design, teamwork, collaboration, management attitudes, development processes, and legal liabilities. The book addresses these various topics because project development is not just a technical endeavor; it is a human endeavor.

The chapters present in a sequential fashion, but development of an embedded system is anything but sequential. Figure 1, below, is a repeat of Figure 1.2 from Chapter 1 and placed here for your convenience. The figure lists the chapters and when they might be most useful within a project. The multiple paths and connections indicate the parallel and concurrent nature of design and development efforts.

Figure 1 Book organization and a suggested approach to reading it.

Chapter 1: Introduction to Good Development

Chapter 1 describes the book’s purpose to identify important issues in developing and managing embedded systems. The material outlines the technical aspects, the teamwork, the effort, and the cost you encounter in developing an embedded system. It reveals how technical issues impact business and schedules, how personal interactions are just as important as technical breakthroughs, and the interplay of various disciplines to realize the final product. Consequently, this book is not solely for managers, it is written for every member of the project team.

Chapter 2: Drivers of Success in Engineering Teams

While technical work and knowledge are at the core of the engineering team, its success can rest equally on how well the team addresses the human aspects of daily activity. Organizational culture, team dynamics, and individual responses play significant roles in the outcomes of the team’s efforts. This chapter offers an overview of concepts and theories that relate to the functioning of the engineering team. It addresses the role of the team member, the role of the team leader, engagement, team development, dialogue, emotional awareness, and handling conflict to encourage leaders and members to pursue further study and skills training.

Chapter 3: Project Introduction

What you do in the beginning of a project, sets precedence for the remainder of the project. Start on the right foot.

This chapter focuses on how you begin the long process of designing and building a successful project. It emphasizes the following:

• communicate the vision, mission, goals, and objectives;

• establish the who, what, when, where, why, and how…;

• define the roles of the team and within the team;

• provide a clear communications plan;

• make the business case; and

• then establish the project plan, the administration, and the resources for the project.

Chapter 4: Dealing with Risk

Risk is the potential to stray outside the defined cost, schedule, performance, or safety constraints. Every project is risky to some degree but risk can be managed. The chapter follows this format:

• first, identify the various risks and analyze them;

• then control risks by reducing, constraining, or transferring them;

• assess the state of the risks by analyzing them again; and

• repeat this cycle throughout the project’s development.

Chapter 5: Documentation

Documentation conveys the right information to the right person at the right time. Documentation is corporate communication and memory. Everyone working on a technical project spends 50–80% of their time preparing documentation.

This chapter has a number of suggested outlines and templates of documents. It also has examples of content within important documents.

Chapter 6: System Requirements

This chapter will give readers a number of best practices to improve the quality of the requirements elicitation and development process in their organization. Formulation of high-quality requirements (complete, concise, accurate, modular, prioritized, analyzed, verified, and testable) reduce project risk, improve product quality, and allow for effective control of requirements volatility, which increases the likelihood of a successful project.

Chapter 7: Analyses and Tradeoffs

Analyses and tradeoffs are absolutely necessary to the success of product design and development. Analyses form the feedback between requirements and design. Analyses gauge how well a design meets the requirements. If a design does not match the requirements, then either the design or the requirements need modification.

This chapter provides the motivation for analyses with the business case. It then discusses tradeoffs you might make to produce a design concept. Finally, it discusses a number of different analyses that you might use to refine a design.

Chapter 8: The Discipline of System Design

This chapter shows you how to design the whole system by starting with goals in plain language that a business person might use. Then it proceeds through detailed system design by the team, a process that avoids either redundant effort or missing pieces.

Areas of particular focus in this chapter include:

• how to communicate effectively with nonengineering personnel,

• how to partition a large system into manageable subsystems,

• how to partition system requirements into requirements for individual disciplines, i.e., software, electronics, and mechanical engineering, and

• how to control costs for projects of various sizes and production volumes.

Chapter 9: Mechanical Design

The chapter reviews basics of mechanical design to help nonmechanical staff communicate more effectively with their mechanical engineering colleagues. It addresses the fundamentals of packaging and thermal design so that the project manager may guide product development. The chapter goes on to discuss mechanisms; it focuses on robust design and methods for calculating loads and forces. The chapter looks at analysis and test, discusses how to use Finite Element Analysis effectively, and ends with a simplified approach to solving vibration problems.

Chapter 10: Electronic Design

The chapter considers basics of electronic design allowing project leaders or nonelectrical engineers to communicate effectively with their colleagues in the electrical and electronic arena. Electronic circuit design involves the selection and interconnection of physical devices in a variety of topologies to meet performance specifications, environmental requirements, power and cost budgets, operating life requirements, and other design constraints in agreement with an overall schedule.

The chapter begins with basic components—resistors, capacitors, inductors, transistors, and display devices. Then it moves on to integrated circuits, in particular processors and controllers, and then moves on to more complex modules like solid-state relays. It covers circuit boards, connectors, cables, and conductors, topics often viewed with some disdain. It also discusses some issues with power supplies because so many folks get these wrong so often. It presents some analysis methods and test considerations and finishes with tradeoffs between various concerns.

Chapter 11: Software Design and Development

Software development for embedded systems is not like software development for desktop systems. This chapter provides detailed descriptions of the key differences between the two domains. It examines operating system support, real-time requirements, resource constraints, and safety. It then provides advice about tools and techniques to develop embedded system software, with the primary emphasis on processes that help the embedded system developer to reliably and repeatedly produce high-quality embedded systems. The advice is based upon techniques that have developed over many years, and have been proven to work effectively in highly complex real-world military and industrial applications.

Chapter 12: Security

Historically, system security has received little attention in embedded systems. Now embedded systems play a huge role in the operation of our modern world; many of these devices expose their presence on the Internet or through other means. Security in embedded devices is a daunting task—the challenging problem of security is compounded by resource limits which are far more restrictive in embedded systems than in desktop systems.

Security is defined according to the application. This chapter points to aspects of those applications and their security concerns.

Chapter 13: Review

Review is a feedback path within system development. The act of review has two primary objectives: (1) to confirm correct design and development, and (2) to expose and identify problems with design, development, or processes.

This chapter outlines the processes and procedures for various types of reviews, provides the formats for review, and describes when to conduct reviews. It gives examples and templates for minutes, action items, and agendas. It has a checklists for preparing and debriefing a formal review and for basic topics to cover in formal design reviews.

Chapter 14: Test and Integration

Test and integration, in this chapter, refer to verifying and validating the design and the development effort. Test and integration, coupled with design review, are the primary feedback activities to assure the project goals. The goals for test and integration are to analyze for design readiness, discover and characterize system behaviors, discover the product’s limits, and prevent and constraint defects.

Chapter 15: Manufacturing

Manufacturing is the transformation of design concept into physical realization. It converts energy, materials, labor, and thought into tangible products. Manufacturing is arguably the most obvious and necessary step for ideas to make money.

This chapter aims to make you aware of some the aspects of manufacturing that affect embedded systems. It will introduce manufacturing issues in the following areas:

• Circuit boards

• Wiring and cabling

• Enclosures

• Mechanisms

It will also give examples of how materials, fabrication of components, and assembly of systems interact within manufacturing. These examples should illuminate some of the time and effort involved in producing embedded systems.

Chapter 16: Logistics, Distribution, and Support

Logistics manages the flow of product and information from manufacturing to the customer. Logistics integrates packaging, inventory, transportation, warehousing, delivery, and technical sales support. Everyone of these arenas fold into the ultimate management of the development of embedded systems; their operations and parameters directly affect the final cost of the system.

The chapter addresses distribution logistics, support, maintenance and repair, and disposal. Distribution logistics considers the delivery of the finished products to the customer and focuses on order processing, warehousing, and transportation. Support is the timely distribution of correct information to implement or fix the function of the embedded system. It also is the intangible perception that the supplier knows the situation and is there to help customer.

Chapter 17: Agreements, Contracts, and Negotiations

This chapter addresses some salient ways that contracts are interpreted, gives particular attention to the conduct of the parties, and mentions the details associated with the signing of agreements. It mentions several types of contracts germane to the embedded engineer, such as NDAs and MOUs. Some consideration is given to various styles of negotiation and some suggested best ways to negotiate, such as the role of humility in negotiations.

Chapter 18: Dealing with the Government

This chapter outlines the basics of government contracting and touches upon the important Christian Doctrine as it applies to the government. Additionally, it addresses changes to contracts, as well as termination procedures as they are uniquely applied in the government contracting context. It covers ethical concerns, as well as relevant statutes with a mention of the government contracting defense as it applies to possible tort litigation.

Chapter 19: Agency and Getting Paid

This chapter outlines the concepts around creation of agency, agents operating outside the scope of their agency, and the duties of the principal once he learns of an agent exceeding the scope of the agency. The Getting Paid section highlights concerns about getting paid and gives practical advice regarding how larger companies manage their accounts payable. The chapter also outlines methods for getting paid on international accounts such as using Letters of Credit. Lastly, it has a section that discusses the esoteric way that imminent debtor bankruptcy can interfere with payment for services rendered.

Chapter 20: Intellectual Property etc.

This chapter discusses source code licenses and rights of the bankruptcy trustee to interfere with the license. It addresses the scope of a software license in general is. The chapter also addresses the protection of intellectual property and copyrights; what constitutes a trade secret as well as the protection of thereof; what is a trademark and the enforcement of a trademark under the Lanham Act. Regarding patents, the chapter addresses what is patentable especially in regard to software patents and how the patent office is acting on software patents. There is a section on patent trolls and how to deal with them, as well.

Chapter 21: Open Source Software

This chapter gives a history behind the open source initiative and describes the general licensing arrangement associated with open source software. It describes the various attributes of the GPL, as well as the various types of open source licenses that are in use. It describes considerations of the DMCA, as well as public domain and shareware licensing concerns and litigation that can possibly ensue.

Chapter 22: Laws That Can Nail Embedded Engineers

This chapter outlines concerns of the DMCA and how it can be applied to the embedded engineer. It also discusses various criminal statutes that can be applied to the embedded engineer’s activities. Moreover, the chapter addresses civil liability that can be charged to the engineer in the form of negligence or products liability and further addresses the way the engineer can protect himself from liability such as employing the use of indemnification agreements.

Chapter 23: Corporate Operations, Export, and Compliance

This chapter addresses ways to maintain your corporate charter, the issuance of shares of stock, aspects of LLCs, and the hiring of out of state persons. The chapter also addresses some aspects of exporting particular to embedded devices, such as high-performance computing, as well as the antiboycott laws. It mentions the Foreign Corrupt Practices Act and various export controls on Cryptography. It addresses international arbitration clauses along with insurance and the international CB Scheme as it applies to compliance issues.

Chapter 24: Case Studies

Case Study 1: Describes the development of a portable chemical and biological mass spectrometer for use on the battlefield.

Case Study 2: Describes a real-time radar simulation environment designed to test and validate radar systems for the U.S. Army. Staff at Oak Ridge National Laboratory integrated commercial off-the-shelf technologies with unique components, software, and control strategies to produce one-of-a-kind solutions to challenging measurement environments.

Case Study 3: Manufacturing test of digital television equipment and commissioning and maintenance of digital television systems requires instrumentation specialized for each transmission standard. This instrument measures both RF and the quality of the specific digital modulation. The instrument operates in a streaming mode, that is, the incoming video signal is processed without any temporal gaps.

Case Study 4: This is a tale of diagnosing a failed boiler control board. The board had erratic firmware behavior, the company had poor Internet presence, and the boiler manufacturer had a bad manual. This is the hazard of modern controls: unless you give a control narrative and define exactly what a system is supposed to do at every step of the way and what stimuli it expects, there is no way to know that anything you have is in specification or that it is even broken.

Case Study 5: Electromagnetic compatibility (EMC) problems must be solved before they hit the market. Debugging these issues can be challenging. This case study follows a problem on a display module used in transportation systems. Even very low emissions from the display module could prevent a GPS receiver in the vehicle from receiving a strong signal. The study showed how they found and eliminated the primary source of 1.2 GHz noise emissions.

List of Acronyms

AC Alternating current

AFD Arc fault detection

API Application programming interface

APP Adjusted peak performance

ASR Alternative systems review

ASTD American Society for Training and Development

ATE Automatic test equipment

ATM Automated teller machine

BIST Built-in-self-test

BIT Built-in-test

BITE Built-in-test-equipment

BOM Bill of materials

CAN Controller area network

CB Competent body

CBMS Chemical and biological mass spectrometer

CBTL Competent body test lab

CCB Change control board

CDR Critical design review

CE Conformite Europeene

CEB Corporate Executive Board

CMMI Capability maturity model integration

COGS Cost of goods sold

COTS Commercial-off-the-shelf

CoDR Concept of design review

CPU Central processing unit

C-RES Common radar environment simulator

DAU Defense Acquisition University

DC Direct current

DFM Design for manufacturing (or maintenance)

DFx Design for x

DMCA Digital Millennium Copyright Act

DMM Digital multimeter

EDR Engineering design review

EMC Electromagnetic compatibility

EMI Electromagnetic interference

ESD Electrostatic discharge

ESR Equivalent series resistance

ETA Event tree analysis

FCPA Foreign Corrupt Practices Act

FDA Food and Drug Administration

FEA Finite element analysis

FFT Fast Fourier transform

FMECA Failure modes effects criticality analysis

FRACAS Failure reporting, analysis and corrective action system

FRB Failure review board

FRR Flight readiness review

FTA Fault tree analysis

FTCA Federal Tort Claims Act

FTP File Transfer Protocol

FUS Follow-up service

GFCI Ground-fault circuit interrupter

GeAs Gallium arsenide

GNU G’noo not Unix

GPL General Public License

GPS Global positioning system

GUI Graphical user interface

HALT Highly accelerated life test

HASS Highly accelerated stress screen

HPC High-performance computers

HR Human resources

ICD Interface control document

IEC International Electrotechnical Commission

INCOSE International Council on Systems Engineering

ISO International Organization for Standards

IP Intellectual property

ISR In-service review

IT Information technology

ITAR International Traffic in Arms

ITR Initial technical review

JMRI Java model railroad interface

LED Light emitting diode

LLC Limited liability company

LOC Letters of credit

MBTI Myers–Briggs type indicator

MDB Model-based design

MISRA Motor Industry Software Reliability Association

MOU Memorandum of understanding

MPUs Multiple processing units

MTBF Mean-time-between-failures

MTTF Mean-time-to-failure

MTTR Mean-time-to-repair

NASA National Aeronautics and Space Administration

NDA Nondisclosure agreement

NDIA National Defense Industrial Association

NEMA National Electrical Manufacturers Association

NPE Nonpracticing entity

NRE Nonrecurring engineering

ORNL Oak Ridge National Laboratory

OS Operating system

PACE Password Authenticated Connection Establishment

PCB Printed circuit board

PDR Preliminary design review

PERRU Plan, execute, review, report, and update

PM Project manager

PMBOK Project management book of knowledge

PMP Project management plan

PM-RADARS Project manager—Radars

PNA Petri net analysis

PRA Probabilistic risk assessment

PRR Production readiness review

PSD Power spectral density

PWB Printed wiring board

QA Quality assurance

QMS Quality management system

RCA Root cause analysis

RE Recurring expense

RFI Radio frequency interference

RHA Risk and hazard analysis

RMS Root mean square

RoHS Restriction of hazardous substances

ROI Return on investment

RTES Radar test environment simulator

RTOS Real time operating system

SDK Software developer kit

SEI Software Engineering Institute

SFR System functional review

SRR System requirements review

SSR Solid-state relay

STK Software tool kit

STPA System theoretic process analysis

SVR System verification review

SysDR System design review

SWEBOK Software engineering body of knowledge

TCB Trusted computing base

TLC’ed Think, learn, communicate, enforce discipline

TIR Test and integration review

TPM Trusted platform module

TRR Test readiness review

UCC Uniform Commercial Code

UML Unified modeling language

UL Underwriters laboratories

USPTO United States Patent and Trademark Office

UTSA Uniform Trade Secrets Act

V&V Verification and validation

WEEE Waste electrical and electronic equipment

Chapter 1

Introduction to Good Development

Kim R. Fowler,    IEEE Fellow, Consultant

Chapter 1 describes the book’s purpose to identify important issues in developing and managing embedded systems. The material outlines the technical aspects, the teamwork, the effort, and the cost you encounter in developing an embedded system. It reveals how technical issues impact business and schedules, how personal interactions are just as important as technical breakthroughs, and the interplay of various disciplines to realize the final product. Consequently, this book is not solely for managers, it is written for every member of the project team.

Keywords

Systems engineering; integrity; teamwork; management; development; process; procedure; V-model; spiral model; life cycle; QA

Chapter Outline

About this book 2

Purpose 2

Audience 3

Road map 4

What you can get from this book 4

What you won’t get from this book 7

Definitions and some basic concepts 7

Focus 8

Five guiding principles 9

No silver bullets 9

Feedback stabilizes 9

Interfaces are important 9

All problems have a human origin 10

Good development and engineering require good relationships 10

Reliability, fault avoidance and tolerance, and error recovery 10

The business case 11

Life cycle 11

Types of markets and development 12

Recent research 12

Team attributes 12

Working together 12

Individual assignments 13

Relating together 14

Attributes of a good manager 15

Attributes of good technical and support staff 15

TLC’ed 16

Ethics 16

Success and failure 16

Systems engineering 18

INCOSE Systems Engineering Handbook 21

NDIA and SEI report 22

NASA report on cost escalation 22

NASA Systems Engineering Handbook 22

Various approaches to development processes 23

Process models for development 23

V-Model 23

Spiral model 24

Prototyping model 26

PERRU 26

Quality Assurance 26

ISO 9001 27

Six Sigma 29

Capability Maturity Model Integration 29

Comparison between ISO 9001 and CMMI 30

Life cycle phases 32

Concept 32

Preliminary 32

Critical 32

Test and integration 32

Compliance and system acceptance 33

Production 33

Shipping and delivery 33

Operations and support 33

Disposal 33

Case Study: Disastrous engineering processes fixed 33

The good 35

The bad 35

The ugly 35

The turn around 36

Trials and tribulations 36

The final product 37

Conclusion 37

Acknowledgments 37

References 37

Suggested reading 38

About this book

Purpose

The purpose of this book is to identify important issues in developing and managing an embedded system. It should aid your understanding of both the technical aspects of the project and the teamwork involved. The book provides guidelines and bounds on the effort and cost you might encounter in developing an embedded system. It illustrates principles with examples and case studies.

Much like a good project team, the authors selected to write chapters in this book have specific expertise and understand the interactions within a development team. They know that a good team will knit the various disciplines into a fine tapestry of an excellent project.

Audience

This book is for all members of a project team: program managers, technical staff, administrative staff, and support staff. Every project team member should find insight from this book for understanding the issues—technical, managerial, business, and administrative—within a project. Generally, this book aims at project teams with 6–10 people working on a single, full-time project; it can also address many issues and help project teams up to 30 or more people.

This book examines the interactions and connections within a project and its team. It reveals how technical issues impact business and schedules, how personal interactions are just as important as technical breakthroughs, and the interplay of various disciplines to realize the final product. Consequently, this book is not solely for managers, it is written for every member of the project team (Figure 1.1).

Figure 1.1 An abstract view that indicates many different disciplines are needed for project development. Illustration from iStockPhoto.

Road map

The material in this book presents best practices for developing embedded systems. Best practices include technical design, teamwork, collaboration, management attitudes, and development processes. Consequently, this book is not restricted to technical topics because developing projects is not only a technical endeavor. As in project development, the technical topics in this book intertwine with managerial issues, teamwork concerns, and legal liabilities; they cannot be separated unless artificially done so. The book’s most obvious departures from a traditional engineering text are in Chapter 2, which provides insight into the psychology of the team and personnel dynamics, and in Chapters 17 through 23, which discuss legal concerns.

Though the chapters present in a sequential fashion within this book, development of an embedded system is anything but sequential. Figure 1.2 is a diagram of the chapters and when they might be most useful within a project. The multiple paths and connections should clue you into the parallel and concurrent nature of most design and development. Furthermore, much of the design activity is iterative. Feedback is necessary for refinement of requirements and the design, it is also integral to verification and validation.

Figure 1.2 Suggested approach to reading this book.

What you can get from this book

This book concentrates on the framework that you should use to manage, develop, produce, and support embedded products. It delves into the interactions between disciplines and the potential effort that you might expect to expend. Consequently, most chapters regularly refer to the resulting effects by particular activities on quality, schedule, and budget.

The focus of this book is embedded systems and products. Figure 1.3 illustrates a sampling of products and systems that contain embedded systems. The electric streetcar or tram has numerous embedded systems—motor controls, environmental controls, brakes, power conversion, communications, signboards—to name a few. The coffee maker has a microcontroller-based circuit board that receives button inputs, drives the display, and commands the power control of the heater. The radar system has high frequency signal conversion, digital filtering and tracking, communications, and displays. The custom motorcycle has a flat panel display, a biometric switch in place of a key, and engine control. The electric guitar has a microcontroller-based embedded system that detects the pitch of each string and automatically tunes the strings by small motor driven mechanisms, as shown in cutaway in the next photograph. Finally, the four-legged crawler and crane has embedded systems to control its movements as the crew replaces the store’s heavy glass window.

Figure 1.3 A sample collection of photographs of embedded systems and equipment with embedded systems. © 2007–2014 by Kim R. Fowler. Used with permission. All rights reserved.

The book addresses disciplines for developing products and embedded systems. The disciplines include:

• Program management

• Systems engineering (SE)

• Operations research

• Design and development

– Software

– Electronic hardware

– Mechanics

– Human interface

• Testing and integration

• Manufacturing

• Distribution, logistics, and support

• Legal concerns.

What you won’t get from this book

Important areas not addressed in this book are large system applications, systems of systems, information technology (IT), marketing, business, and accounting. Furthermore, the book does not cover specific techniques or technical advances, except by way of example to address aspects of quality, schedule, and budget. In particular, it does not cover specific components for development tools, coding techniques, designs, manufacturing, or tooling. Finally, while the principles, guidelines, and metrics espoused in this book suffice for embedded systems, they are not sufficient for whole vehicles or large systems—they form a necessary subset but are not a complete set for such systems.

Definitions and some basic concepts

To better understand this book, you will want to understand some definitions used throughout its pages. These definitions may be less than completely rigorous but they will be useful for conveying the necessary concepts:

System: A combination of elements or parts forming a complex or unitary whole composed of components, attributes, and relationships. Typically these elements within a system form definable inputs, processing, and outputs. The interrelated components work together toward a common objective [1].

Systems engineering (SE): An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life cycle balanced set of system, people, product, and process solutions that satisfy customer needs [2].

Project: Development work that has a clear beginning and end and is performed once to produce something unique [3]. This work is different than ongoing operations such as sales, support, and manufacturing—but it does include the insights and input from personnel in these activities to inform development of the product.

Project management: Verzuh claims that project management is art informed by science. He lists five characteristics of a successful project management [3]:

• Agreement among the project team, customers, and management on the goals of the project.

• A plan that shows an overall path and clear responsibilities and will be used to measure progress during the project.

• Constant, effective communications among everyone involved in the project.

• A controlled scope.

• Management support.

Analysis: The examination of a concept or plan to better understand its constraints and limitations.

Tradeoff: A form of analysis that compares one design approach with another, different design approach or approaches.

Synthesis: The act of pulling elements together to create a new system, service, or operation; often new behaviors and functions arise.

Design: The iterative combination of analysis and synthesis to refine a concept into a realized product, which includes creation, modification, and analysis.

Design process: The methodology to implement design and design activities.

Review: A group activity that examines design, development, processes, and procedures for the purpose of comparing plans, operations, or accomplishments with the project’s mission or goals.

Test: A set of physical challenges to a component, subsystem, or system to address a specific metric attached to a requirement.

Integration: The synthesis of subsystems into a larger system with testing to confirm, demonstrate, or clarify system behavior.

Embedded system: A combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function [4]. Or, in other words, a system that depends on a computer as a critical element in its function.

Real time: Completing tasks within specified deadlines; this definition is not defined or limited by a specific execution speed.

Quality: The degree to which the sum total of product characteristics fulfills all of the requirements of customers.

Process: A group of interrelated activities and resources that transform inputs into outputs, often described by a block or flow diagram of events.

Procedure: Specific implementation of the process for a single, focused area of concern, typically step-by-step instructions.

Validation: The confirmation that the design, function, and operation of the final product satisfies the customer’s intent.

Verification: The objective tests of metrics that shows that the final product meets the quantitative requirements.

NRE: The cost associated with nonrecurring engineering effort.

COGS: The cost of goods sold.

Integrity: The seamless whole, which requires a big picture view of how the parts fit into the whole (more on integrity later in the chapter plus the recommended book by Henry Cloud, Integrity.)

Focus

The primary focus of this book is integrity, the seamless whole. Integrity sees that various topics fit together to function properly.

This book concentrates on the following topics: guiding principles, good technical design practices, good development practices, good business practices, life cycle perspective, and teamwork. If you understand and incorporate these concerns within a project, your probability of success will be good. Incorporating these concerns will not guarantee success, but they are very important. If you ignore any of these concerns, your probability of success will drop dramatically.

Five guiding principles

Each of these principles has the overriding directive of integrity. These principles bound all the discussions within this book and should guide successful development of any embedded product:

• There are no silver bullets in development.

• Appropriate feedback stabilizes a defined system.

• All important actions occur at interfaces within systems.

• All problems have a human origin.

• Good development and engineering requires good relationships.

No silver bullets

Every interesting problem is multidimensional and requires the involvement of diverse disciplines. There are no silver bullets.¹ Simply no tool or method or process fits all operations. Don’t look for one. Any silver bullet will narrow your focus and you will overlook important issues and concerns. It would be worth your time to read Fred Brooks’ paper No Silver Bullet—Essence and Accident in Software Engineering [5]. The 20-year retrospective, which is very short, by Mancl, Fraser, and Opdyke is a useful companion paper to Brooks’ original paper [6].

Feedback stabilizes

Development needs closed-loop, feedback processes that regularly use various reviews to inform and adjust development. As in most closed-loop, feedback systems, you can over-control or under-control the feedback causing inappropriate results. Appropriate feedback requires study and experience. You will find more on feedback later in this chapter with the PERRU concept.

Interfaces are important

All, or nearly all, important actions occur at interfaces. If you think about it, you will see that most interesting things happen where two different domains meet. The physical environment certainly demonstrates this with wave propagation, which doesn’t get interesting until it encounters an obstacle, then diffraction, refraction, and reflection take place. Extending the analogy further, semiconductor operations occur at the boundary of different materials. And finally, the interface between human operations and machine functions is interesting and very important.

Consequently, successful development requires you to understand the different types of interfaces (e.g., electrical, material, mechanical, software, signal flow, environmental, human–machine interactions). You use interfaces to define the boundaries and subsystems and then use these partitions to drive development. Good systems engineering (SE) does this well.

All problems have a human origin

All problems have a human origin. Even the very best designs will fail or outlive their usefulness. The human capacity for design cannot account for all possibilities—circumstances that are unexpected or unknown, multiple and simultaneous interactions that lead to failure, and even human abuse from inappropriate, stupid, or malicious operations. Beyond these concerns, finite lifetime will limit normal use over an extended time. Failure, furthermore, can have other causes, such as business climate, socioeconomics, or politics that defy technical solution.

Good development and engineering require good relationships

The best products are derived from fully functional teams that work together. I believe that good interpersonal relationships are absolutely necessary for teams to work together and to develop successful products. Chapter 2 will bear out my contention.

Example: Bad relationships dissolve company

There are good historical examples of companies that thrived because of good relationships. Jim Collins in his books, Good to Great and Built to Last, discusses a number of examples of successful companies built on the right people relating well together [7,8].

Counterexamples to those successful companies are not always as obvious. I worked in a company where several interpersonal relationships were not just bad, but toxic. Gossip, backbiting, defamation of character, and nasty, untrue allegations of fraud ultimately destroyed the company. The disappointing thing was that sharp, capable people comprised the staff and the company’s product designs were outstanding. Bright ideas could not overcome bad relationships! Consequently, we did not finish developing a product and the company foundered.

Reliability, fault avoidance and tolerance, and error recovery

Closely related to problems, interfaces, and SE are the concepts of reliability, fault avoidance and tolerance, and error recovery. The interplay between these concepts is complex; hopefully, the remainder of the book will reinforce that interplay for you. One dimension of that interplay is the priority of consequences that a system displays when encountering a problem; systems can survive and demonstrate increasing robustness by incorporating structures and designs with the ascending order of complexity that follows:

• Reliable—Stands the test of time

• Available—Minimal downtime

• Gold-plated design—No catastrophic errors

• Redundancy with reliable and available attributes—Results are bounded and predictable

• Robust—Recovers gracefully from errors.

The business case

The end result of nearly all projects is to solve problems and make money from the solutions. This book is written with that thought in mind that we are all in business to make money. The technical concerns addressed in the majority of the book ultimately tie back to solutions that make for successful products. While this is not a book on program management per se, some business administration, particularly for program managers is included:

• Configuration management

• Risk management

• Scheduling

• Budgeting

• Contract(s)

• Legal liabilities.

Life cycle

For a product to be successful, we must consider all facets of its life cycle. Problems and failures will inevitably sneak in if your team ignores or overlooks a phase. The major phases of the life cycle follow:

• Concept

• Requirements

• Analyses and tradeoffs

• Design

• Development

• Review

• Test

• Integration

• Manufacturing

• Delivery, commissioning, sales

• Support, maintenance, and repair

• Upgrades and modifications and reuse

• Disposal.