This handbook provides a consolidated, comprehensive information resource for engineers working with mission- and safety-critical embedded systems. Principles, regulations, and processes common to all critical design projects are introduced in the opening chapters. Expert contributors then offer development models, process templates, and documentation guidelines from their own core critical application fields that will help guide your own projects.
This book provides you with in-depth knowledge of how to avoid common pitfalls and meet the strictest certification standards. Particular emphasis is placed on best practices, design tradeoffs, and testing procedures.
Muu info
Avoid mistakes in saftey and mission critical designs with advice from these experts!
About the EditorAbout the ContributorsChapter 1 Best Practices in
Mission-Assured, Mission-Critical, and Safety-Critical Systems 1 Roadmap
to This Book 1.1 Systems Engineering 1.2 Important Issues
1.3 Material Covered 2 Best Practices 2.1 What and Why?
2.2 Rationale 2.3 Standards and Guidelines for a QMS 3
Project Management and Systems Engineering 3.1 Project Management
3.2 Systems Engineering 3.3 Mission Assurance 4 Process
Flows for Developing Products 4.1 Plan, Execute, Review, Report, and
Update (PERRU) 4.2 Development Processes 4.3 Processes vs.
Procedures 4.4 General Process Models 4.5 An Example of
Phases, Processes, and Procedures 5 Standards 5.1 General
Standards Organizations 5.2 Industry-Based Standards Organizations
5.3 Military Standards Organizations 5.4 Aviation and
Aerospace Standards Organizations 6 Potential Procedures, Checklists, and
Documents 7 Review of Procedures and Processes 7.1 Difference
between Procedures and Processes 7.2 Why Review Procedures and
Processes? 7.3 Types of Review 7.4 Frequency of Review
7.5 Review Content 7.6 Course of Action, Changes, and Updates
Following Review 7.7 Review Responsibilities 8 Configuration
Management 8.1 Rationale for Configuration Management 8.2
Configuration Management Coverage 8.3 Records Responsibility
8.4 System and Location 8.5 Version Control 8.6 Design
Repository 8.7 File Structure 8.8 Obsolete Documents
8.9 Training for Use of the System 9 Documentation 9.1
Rationale for Documentation 9.2 Coverage and Responsibility for
Documentation 9.3 Types of Documentation 9.4 Best Practices
for DocumentationAppendix A: Example Document Outlines Work Order (WO)
Minutes Problem Report/Corrective Action (PRCA) Engineering Change
Request (ECR) Engineering Change Notice (ECN) Project Management Plan
(PMP) Interface Control Documents (ICDs) Development Plans
Requirements Risk Management Plan Configuration Management Plan
Documentation Plan Analysis Reports Design Description Test Plan
Operation Plan Metrology Concerns and Procedures Appendix B: Program
Management Documents for Project Development Appendix C: Technical Project
Documents for Project DevelopmentChapter 2 Failsafe Software Design: Embedded
Programming in a Fail-Certain World 1 Software Matters 2 The
Essence of Process 3 Three Principles for Design and Coding 3.1
What Does It Mean to Be Failsafe? 3.2 Safety (and Mission) First
3.3 Verification and Redundancy in the Implementation Process 4 The
User Interface 5 Rolling Your Own 6 Hardware as Software: A Thought
Exercise in Crossover Thinking 7 ConclusionsChapter 3 Compliance Concerns
for Medical Equipment 1 Introduction 2 National and International
Requirements 2.1 U.S. Requirements 2.2 European
Requirements 2.3 Other Countries 3 Medical Device Certification
4 Philosophy of the Standards 5 Evaluation Process 5.1
Preliminary Evaluation 5.2 Testing 5.3 Compliance Reports
5.4 Common Noncompliances 6 Conclusion
Chapter 4 Software for
Medical Systems 1 Introduction 1.1 Verification and Validation
1.2 Life Cycle Model 2 The Medical Regulatory Environment
2.1 Worldwide Quality System Requirements 2.2 Subpart A: General
Provisions 2.3 Subpart B: Quality System Requirements 2.4
Subpart CDesign Controls 2.5 Subpart DDocument Controls
2.6 Subpart EPurchasing Controls 2.7 Subpart FIdentification and
Traceability 2.8 Subpart GProduction and Process Controls
2.9 Subpart HAcceptance Activities, and Subpart INonconforming Product
2.10 Subpart JCorrective and Preventive Action 2.11 Subpart
KLabeling and Packaging Control 2.12 Subpart LHandling, Storage,
Distribution, and Installation 2.13 Subpart MRecords 2.14
Subpart NServicing and Subpart O Statistical Techniques 2.15
Post-Market Activities 3 Design Control Explained 3.1 Purpose
of Design Control 3.2 Project Planning 3.3 Design Input
3.4 Design Output 3.5 Design Review 3.6 Design
Verification and Validation 3.7 Design Changes 3.8 Design
History File 3.9 Change Control 3.10 Software Change
Control in the Medical Environment 3.11 Software Configuration
Management Methods 3.12 Software Problem Resolution 3.13
Problem Evaluation 3.14 Outcomes of the Evaluation Phase
3.15 Corrective Action Process 3.16 Outcomes of the System Test
Phase 3.17 Reports 3.18 Software Observation Reporting
and Version Control 4 Risk Management 5 Software Verification and
Validation in the Context of Design Control 5.1 Software
Verification Methods 5.2 Software System Testing 5.3 System
Validation (Acceptance Tests) 5.4 Traceability 5.5 Metrics
5.6 FDA Regulatory Approval Process 5.7 Device Risk
Classes 5.8 Software Level of Concern 5.9 Software
Documentation Requirements for Premarket Submissions 5.10 The
Review Process and What to Expect from the FDA 6 Special Topics
6.1 Software of Unknown Provenance 6.2 Security and PrivacyHIPAA
7 Summary 8 FAQS
Chapter 5 Best Practices in Spacecraft Development
1 Regulations and Standard Practices 1.1 Government Regulations
1.2 Industry Standards 1.3 Commercial Off-the-Shelf 2
Company Processes 2.1 Project Management 2.2 Systems
Engineering 2.3 Fault Protection 2.4 Mission Assurance
and Safety 2.5 Integration and Test 2.6 Mission Operations
3 Documentation 3.1 Project Documentation 3.2
Corporate Documentation 3.3 Documentation Tools 4 Case
StudyNew Horizons 4.1 Pluto-Kuiper Belt Announcement of Opportunity
4.2 Mission Concept Overview 4.3 Project Management
4.4 Systems Engineering 4.5 Fault Protection 4.6
Mission Assurance and Safety 4.7 Assembly, Integration, and
TestFabrication and Assembly of Circuit Boards 4.8 Subsystem Tests
and TestingNotable Anomalies and Lessons Learned 4.9 Launch and
Mission Operations 5 Future Directions 6 Summary of Good Practices
Acknowledgments Appendix A Example of a Systems Engineering Plan Appendix B
Example of a Small Requirements Document for a SubsystemAppendix C Example of
a Small Test Plan
Chapter 6 Systems Engineering in Military Projects 1
Introduction 2 Historical Background 2.1 JCIDS 2.2
Defense Acquisition 2.3 Where Is JCIDS Now? 2.4 Recent
History of Systems Engineering 2.5 Evolution of Standards for
Systems Engineering 3 Processes, Procedures, and Tasks 3.1
MIL-STD-499B: Systems Engineering Planning and Implementation 3.2
Systems Engineering Input Information 3.3 Technical Objectives
3.4 Systems Engineering Process Requirements 3.5 Requirements
Analysis 3.6 Functional Analysis and Functional Allocation
3.7 Design 3.8 Systems Analysis and Control 3.9 Tradeoff
Studies 3.10 System/Cost-Effectiveness Analysis 3.11
Configuration Management 498 3.12 Interface Management 3.13
Data Management 3.14 Integrated Master Plan 3.15 Technical
Performance Measurement 3.16 Technical Reviews 3.17
Response to Change 4 U.S Department of Defense Resources 5 Military
Standards and Handbooks 6 Other Military Standards and Specifications
6.1 Specifications 6.2 Standards 6.3 Handbooks
6.4 Current Guidance 7 Avionics Standards: DO-178 and DO-254
7.1 DO-178B/C 7.2 DO-254 8 Test and Evaluation 8.1
Inspection 8.2 Peer Review 8.3 Subsystem Tests
8.4 Integration 8.5 Environmental 8.6 EMC 8.7
Field Tests, Final Acceptance Tests, Builders Trials, and Commissioning
8.8 Manufacturing 8.9 BIT, BITE, and ATE 9 Obsolescence and
Legacy Systems 10 Case StudiesIndex
Kim 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. Kim co-founded Stimsoft, a medical products company, in 1998 and sold it in 2003. He has also 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. Kim 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. Kim currently is a graduate student in Electrical and Computer Engineering at Kansas State University to finally get his PhD to teach and research.
Lisainfo e-raamatute kohta