Medical Instrument Design and Development E-Book

Claudio Becchetti

• Herausgeber: John Wiley & Sons
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 999

Veröffentlichungsjahr: 2013

Beschreibung

This book explains all of the stages involved in developing medical devices; from concept to medical approval including system engineering, bioinstrumentation design, signal processing, electronics, software and ICT with Cloud and e-Health development. 

Medical Instrument Design and Development offers a comprehensive theoretical background with extensive use of diagrams, graphics and tables (around 400 throughout the book). The book explains how the theory is translated into industrial medical products using a market-sold Electrocardiograph disclosed in its design by the Gamma Cardio Soft manufacturer.

The sequence of the chapters reflects the product development lifecycle. Each chapter is focused on a specific University course and is divided into two sections: theory and implementation. The theory sections explain the main concepts and principles which remain valid across technological evolutions of medical instrumentation. The Implementation sections show how the theory is translated into a medical product.  The Electrocardiograph (ECG or EKG) is used as an example as it is a suitable device to explore to fully understand medical instrumentation since it is sufficiently simple but encompasses all the main areas involved in developing medical electronic equipment. 

Key Features:

• Introduces a system-level approach to product design
• Covers topics such as bioinstrumentation, signal processing, information theory, electronics, software, firmware, telemedicine, e-Health and medical device certification
• Explains how to use theory to implement a market product (using ECG as an example)
• Examines the design and applications of main medical instruments
• Details the additional know-how required for product implementation: business context, system design, project management, intellectual property rights, product life cycle, etc.
• Includes an accompanying website with the design of the certified ECG product (www.gammacardiosoft.it/book)
• Discloses the details of a marketed ECG Product (from Gamma Cardio Soft)  compliant with the ANSI standard AAMI EC 11 under open licenses (GNU GPL, Creative Common)

This book is written for biomedical engineering courses (upper-level undergraduate and graduate students) and for engineers interested in medical instrumentation/device design with a comprehensive and interdisciplinary system perspective.

Leseprobe

Contents

Cover

Title Page

Copyright

Dedication

Foreword

Preface

Acknowledgment

Chapter 1: System Engineering

Chapter Organization

Part I: Theory

1.1 Introduction

1.2 Problem Formulation in Product Design

1.3 The Business Context for Design

1.4 The Engineering Product Design Process

1.5 System-subsystem Decomposition

1.6 The Product Development Life Cycle

1.7 Project Management in Product Design

1.8 Intellectual Property Rights and Reuse

Part II: Implementation

1.11 The ECG: Introduction

1.12 The ECG Design Problem Formulation

1.13 The ECG Business Plan

1.14 The ECG Design Process

1.15 ECG System–subsystem Decomposition

1.16 ECG Product Life Cycle

1.17 The ECG Development Plan and Project Management

1.18 IPR and Reuse Strategy for the ECG

References

Chapter 2: Concepts and Requirements

Chapter Organization

Part I: Theory

2.1 Introduction

2.2 The Medical Instrumentation Approach

2.3 Extraction of Physiological Parameters

2.4 Pressure and Flow

2.5 Biopotential Recording

2.6 Electroencephalography

2.7 Electromyography

Part II: Implementation

2.8 Introduction

2.9 Requirements Management

2.10 Medical Instruments Requirements and Standards

2.11 ECG Requirements

2.12 The Patient Component

2.13 The ECG Method for Observation

2.14 Features of the Observations

2.15 Requirements Related to Measurements

2.16 Safety Requirements

2.17 Usability and Marketing Requirements

2.18 Environment Issues

2.19 Economic Requirements

References

Chapter 3: Biomedical Engineering Design

Chapter Organization

Part I: Theory

3.1 Design Principles and Regulations

3.2 General Design System Model

3.3 Pressure and Flow Instruments

3.4 Biopotential Instruments

3.5 The Design Process

Part II: Implementation

3.6 ECG-wide Decisions

3.7 The ECG System Architectural Design

3.8 Gamma Cardio CG Technical File Structure

References

Chapter 4: Signal Processing and Estimation

Chapter Organization

Part I: Theory

4.1 Discrete Representations of Analog Systems

4.2 Discrete Fourier Transform

4.3 Estimation Theory Framework

4.4 Performance Indicators

Part II: Implementation

4.5 Analog to Digital Conversion

4.6 Signal Denoising

4.7 Time of Arrival Estimation

References

Chapter 5: Applied Electronics

Chapter Organization

Part I: Theory

5.0 Architectural Design

5.1 Sensors

5.2 Circuit Protection Function

5.3 Buffer Stage

5.4 Analog Signal Processing

5.5 Interference and Instrumentation Amplifiers

5.6 Analog Filtering

5.7 ADC Conversion

5.8 Programable Devices

5.9 Power Module

5.10 Baseband Digital Communication

Part II: Implementation

5.20 Gamma Cardio CG Architecture

5.21 ECG Sensors

5.22 Gamma Cardio CG Protection

5.23 Gamma Cardio CG Buffer Stage

5.24 The Lead Selector

5.25 ECG Amplification

5.26 Analog Filtering

5.27 The ADC Circuit

5.28 Programable Devices

5.29 Power Module

5.30 Communication Module

Conclusion

References

Chapter 6: Medical Software

Chapter Organization

Part I: Theory

6.1 Introduction

6.2 The Process: a Standard for Medical Software

6.3 Risk Management Process

6.4 Software Development Process

6.5 Software Configuration Management Process

6.6 Software Problem Resolution Process

6.7 Software Maintenance Process

6.8 Guidelines on Software Design

Part II: Implementation

6.9 System Decomposition

6.10 Risk Management

6.11 Software Application

6.12 Firmware

References

Chapter 7: c-Health

Chapter Organization

Part I: Theory

7.1 Introduction

7.2 The Cloud Computing Model

7.3 e-Health

7.4 Electronic Health Record (EHR)

7.5 c-Health

Part II: Implementation

7.6 Telecardiology

7.7 Telecardiology Technology

7.8 Workflow in Telecardiology

7.9 Risks of Telecardiology

References

Chapter 8: Certification Process

Chapter Organization

Part I: Theory

8.1 Certification Objectives and Processes

8.2 Regulations, Standards and Organizations

8.3 Basic Protection Concepts

8.4 Verification of Constructional Requirements

8.5 Medical Equipment Safety Tests

8.6 Electromagnetic Compatibility

Part II: Implementation

8.11 The Process

8.12 Regulatory Approaches to Medical Device Market Placement

8.13 Basic Concepts in Device Implementation

8.14 Verification on Design Performance

8.15 Safety Tests

8.16 Electromagnetic Compatibility

References

Summary of Regulations and Standards

Index

This edition first published 2013

© 2013 JohnWiley & Sons Ltd.

Registered office

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com.

The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

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, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. It is sold on the understanding that the publisher is not engaged in rendering professional services and neither the publisher nor the author shall be liable for damages arising herefrom. If professional advice or other expert assistance is required, the services of a competent professional should be sought

Library of Congress Cataloging-in-Publication Data

Becchetti, Claudio.

Medical instrument design and development : from requirements to market placements / Claudio Becchetti, Alessandro Neri.

p. ; cm.

Includes bibliographical references and index.

ISBN 978-1-119-95240-4 (cloth)

I. Neri, A. (Alessandro) II. Title.

[DNLM: 1. Electrocardiography–instrumentation. 2. Equipment Design–methods. 3. Electrical Equipment and Supplies. 4. Equipment Safety. 5. Software. WG 140]

R856.A1

610.28–dc23

2013002809

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

ISBN: 9781119952404

To those who share the key toknowledge and shed light forthose who want to enter

in memory ofMy Father and of Italo Corti, MD, Cardiologist

Foreword

This book fills a gap in the technical literature, because it approaches, as a whole, the design and implementation process necessary to build and to put on the market a piece of medical instrumentation. Even if many good books deal with the design of biomedical equipment, and others discuss the signal processing that is implied or the problems related to certification, no one links all these steps together in the ingenious way that the authors have devised here.

The book presents an integrated view of the whole process involved from the first phases of the conception, through the design, realization and signal processing and on to the hardware realization and certification. This approach is made possible by means of a unique feature of the book: a manufacturer has revealed its know-how and the structure of a commercially available instrument (the Gamma Cardio CG from Gamma Cardio Soft, which complies with the ECG technical standard ANSI AAMI EC 11). Therefore, the integrated view that this book provides is done with reference to the technical details of the design of a marketed instrument; here, concepts and tools find their practical application. This hands-on approach is extremely useful, in that the electrocardiograph is a product that is both sufficiently easy to deal with for a prospective biomedical engineer, but encompasses all the main areas involved, thus helping in understanding medical instrumentation design. In this way, not only will the readers be familiar with the basic concepts, principles and analytical tools needed to design a medical instrument but they will also have the clear idea of how all these concepts and tools are translated into practice.

The field of medical instrumentation shares with industrial product implementation the knowledge of various engineering methodologies and techniques, and these aspects must be combined with specific requirements, such as the medical device certification, a point that is crucial in order to put an instrument onto the market. Moreover, the scenario has evolved, in that an increasing number of medical instruments are being conceived to be closely linked into a hospital information system and/or to be integrated in a distributed management in the context of a virtual (distributed) health record. Part of the book is thus devoted to seeing medical instrumentation in the context of cloud computing, for which the authors introduced the new term of c-Health, thus also helping in understanding future developments.

The book is self-contained because in every chapter it presents the theoretical concepts, on signal and information theory, digital signal processing, electronics, software engineering and digital communications, which remain valid across technological evolutions of medical instrumentation. Moreover, the book explores the additional know-how required for product implementation such as the business context, system design, project management, intellectual property rights and the project life cycle.

Readers can thus use the book in many ways: they can pick up a chapter to refresh some concepts (on electronics, software, algorithms, etc.) or go through the book in order to view the whole design process. Therefore, this book is addressed to upper-level undergraduate and graduate students in engineering, and to engineers interested in medical instrumentation design with a comprehensive and interdisciplinary perspective.

From my experience, I'm convinced that this book will give the reader a clear idea of the whole process involved in the design of medical instrumentation from conception to marketing and beyond.

Tommaso D'Alessio

Professor of Biomedical EngineeringUniversity Roma TRE

Preface

A technology is a true progress when it is in everyone's hands

H. Ford

This book is written for biomedical engineering courses for undergraduate or graduate level. The book shows how medical devices and instruments are designed from conception to market placement. As shown in the figure, this implies an interdisciplinary system approach where mainstream engineering courses provide the know-how of the associated development stages. More specifically, system engineering in Chapter 1 looks at how product design is performed considering project management, the intellectual property rights and the business context. Chapter 2 deals with the concepts and requirements of bioinstrumentation. The other development stages that have their associated courses are: biomedical design (Chapter 3), signal processing and estimation (Chapter 4), applied electronics (Chapter 5), medical software (Chapter 6), e-Health, telecommunications and medical informatics (Chapter 7) and the certification/approval process (Chapter 8).

In addition, the book discloses all the electronic details of a marketed product, the Gamma Cardio CG, which complies with the ECG technical standard ANSI AAMI EC 11. Each chapter is divided into two parts: theory and implementation. The implementation part shows how theory is translated into the ECG device disclosed by the Gamma Cardio Soft Company.

The ECG is a suitable device because it is sufficiently simple to be addressed in a book at university level, but it is also adequate to show the main components required for any complex medical device design. The ECG also has a crucial impact on society since it is the main prevention and diagnostic tool for cardiovascular diseases, currently the prime cause of death in the world.

The book is also addressed to practitioners interested in medical device design, since this text shows the theory and its relationship with the implementation details of a marketed ECG, in terms of requirements, specifications, software, hardware and certification documents. As shown in the previous figure, the book embraces a medical instrumentation model that includes an electronic part (discussed in Chapter 5) in contact with the patient, managed by medical firmware and software (Chapter 6) that is integrated into the e-Health medical systems through telecommunication networks (Chapter 7). This product model is applicable to most medical devices and electronic equipment. More recent social needs, and advances in ICT, have fostered the need for alternative, cost-effective solutions for accessing and sharing medical data and services. Cloud computing technology is expected to have a large market share in distributed medical solutions. This issue is addressed in Chapter 7 where we introduce the new term “c-Health” referring to “the set of healthcare services supported by cloud computing”. Medical electronic devices are usually modeled with the signal processing concepts addressed in Chapter 4, and they have to be certified according to applicable regulations and standards. Chapter 8 covers the medical instrumentation approval by regulatory bodies referred to around the world as ‘certification’, ‘approval-clearance’, or with other terms according to local regulation.

Pedagogy

Through this book, we emphasize the system-wide technical design approach that encompasses the basic theory, the associated implementation techniques – disclosed for a market product – and the application of regulations and standards.

A good background in mathematics and electronics is helpful for using this book, but undergraduates will be helped by the various checklists, recap tables and notes that summarize the main technical background.

The book has 250 figures and 145 tables; most of them offering a schematic representation of the main concepts. Text in bold is used to communicate concepts in speed reading. Figures have been designed with different graphic aspects to help readers' memorization. The implementation part is organized to offer a didactic perspective, starting from a general medical device and arriving at the ECG details.

Organization

Chapters are self-contained, addressing the relevant biomedical engineering courses. At the same time, chapters are logically linked as they describe the design process from conception to certification (from Chapter 1 to Chapter 8) with increased technical details.

The sections of each chapter are introduced following the sequential and logical process of the design. For example, in the electronics chapter, the paragraphs are organized according to the flow of the input signal. Each chapter begins with a conceptual map showing the relations among the sections and the associated topics.

Regulations, standards and technologies are critical elements of product design. We have addressed the main concepts and principles of these topics avoiding specific regulations, standard versions or technological implementations as possible. Regarding references, we have preferred a selected list of public domain material and tutorials that are helpful to further investigations. References to standards are placed at the end of the book.

Disclaimer

This book contains the details of a certified medical instrument (the Gamma Cardio CG) sold in the European market and released under an open source license as specified below.

The Gamma Cardio CG is an electrocardiograph owned by the Gamma Cardio Soft Company certified under European rules (CE certification), compliant to the US recognized standard for ECG (AAMI EC 11).

The Gamma Cardio Soft Company discloses its product through an open source license to support ECG diffusion worldwide and to open the associated know-how for universities since the ECG is the main prevention diagnostic tool for cardiovascular diseases, which are now the prime cause of death in the world.

The product is composed by a hardware board containing firmware controlled by a software application running over Windows® platforms. The Gamma Cardio CG hardware, firmware and software (see www.gammacardiosoft.it/book) are licensed under a Creative Commons license called Attribution-Non-Commercial-ShareAlike 3.0 Unported available at http://creativecommons.org/licenses/by-nc-sa/3.0/ and the GNU GPL License for software and firmware.

You are free:

1. to share – to copy, distribute and transmit the work

2. to remix – to adapt the work

But this is under the following conditions:

a. Attribution – You must attribute the work in the manner specified as follows (but not in any way that suggests that authors, editors or the manufacturer endorse you or your use of the work): “The whole work (hardware, software, firmware, design, ideas, novelties, projects) is owned by Gamma Cardio Soft S.r.l. – Italy. In no way are you allowed to suggest that Gamma Cardio Soft endorses you or your use of the work.”

b. Non-commercial – You may not use this work for commercial purposes.

c. Share Alike – If you alter, transform or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

d. Waiver – Any of the above conditions can be waived if you get permission from the copyright holder (Gamma Cardio Soft).

The Gamma Cardio Soft name is a trademark that can be used only after approval from the Company.

Warning: only approved medical devices may be placed in the market and used for medical purposes. The approval procedure must be performed under the regulation applicable in the target market (e.g., Medical Device Directive in the European Union, or under FDA approval-clearance procedures in the USA).

The product is disclosed as it is; Gamma Cardio Soft, the authors, the contributors, the editor, Wiley and anyone involved in the book, can in no way be deemed liable for any damage through the use of the information contained in this book or for the products described or derived from this book.

The Gamma Cardio Soft hardware, software and firmware is provided to you ‘as is’ and we make no express or implied warranties whatsoever with respect to its functionality, operability or use, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose or infringement. We expressly disclaim any liability whatsoever for any direct, indirect, consequential, incidental or special damages, including, without limitation, lost revenues, lost profits, losses resulting from business interruption, loss of data or any damage to health, regardless of the form of action or legal theory under which the liability may be asserted, even if advised of the possibility or likelihood of such damages.

NO INFORMATION contained in this book or in the associated material SHALL CREATE ANY WARRANTY.

This book does not provide medical advice.

The contents of the book and the accompanying material, such as text, graphics, image and software are for informational purposes only. The content is not intended to be a substitute for professional medical advice, diagnosis or treatment. Always seek the advice of your physician or other qualified health provider with any questions you may have regarding a medical condition. Never disregard professional medical advice or delay in seeking it because of something you have read in this book.

If you think you may have a medical emergency, call your doctor or the emergency telephone number of your area immediately. The authors, the publisher, the Gamma Cardio Soft do not recommend or endorse any specific medical test, procedure, opinion or other medical information that may be mentioned on the book. Reliance on any information provided by the book is solely at your own risk.

By using this book, you agree to the specified terms.

Acknowledgment

The book is the result of 20 years of professional and teaching activity that could never have matured without the work, the suggestions, the constructive criticism and the contributions of many people.

A special mention to Gamma Cardio Soft Company (www.GammaCardioSoft.it) that has disclosed all the hardware and most firmware, software and certification documents of their electrocardiograph product. ‘True progress is that which places technology in everyone's hands’. They intend by this action to support an open source hardware–software ECG, increasing device availability. The ECG is the main prevention and diagnostic tool for cardiovascular diseases, currently the prime cause of death in the world. An increased availability of ECGs translates into fewer casualties.

The open knowledge model of this book is derived from a previous book (Speech Recognition: Theory and C++ Implementation, 1999) where the approach of showing theory and disclosing all the details of an industrial product was first implemented.

We wish to thank the biomedical engineering department of the University of Roma TRE with Professor Tommaso D'Alessio for the support. We wish to thank the reviewers who have helped improving the book.

Going back ten years, we wish to thank students who started with the first dissertations on medical devices and Professor Fabio Frattale Masciolli for his support of this project. We wish to thank the engineering design laboratory course students who, for four years, have given didactic suggestions translated into this book. The interaction with them helped us to improve the clarity of our lectures and of the general exposition of technical issues.

Some colleagues have contributed to specific sections; we wish to thank them all for their fruitful collaboration and acknowledge chapter contribution shown in the following table:

ChapterTopicContribution1System EngineeringClaudio Becchetti2Concepts and requirementsTheory: Maurizio Schmidt, Claudio Becchetti Implementation: Claudio Becchetti3Biomedical designTheory: Maurizio Schmidt, Claudio Becchetti Implementation: Claudio Becchetti4Signal processingAlessandro Neri5ElectronicsClaudio Becchetti6Medical softwareAngeloluca Barba, Claudio Becchetti7Medical informaticsSection 7.1: Alessandro Neri, Marco Leo, Claudio Becchetti Theory: Marco Leo, Claudio Becchetti, Implementation: Stefano Giordano, Claudio Becchetti8CertificationTheory: Lorenzo Spinelli, Claudio Becchetti, Implementation: Claudio Becchetti

A special mention to our families: writing a book requires a huge amount of time stolen from our lovely wives and children.

1

System Engineering

Give a man a fish, feed him for a day. Teach a man to fish, feed him for a lifetime.

Chapter Organization

Less than one-third of medical device development projects succeed in getting to the marketing stage (Kelleher, 2003). Table 1.1 adapted from (Kelleher, 2003) summarizes the main reasons forfailure in medical device development. Certification is also added as a possible critical issue since it is a significant barrier especially for new companies (CB, 2004; Anast, 2001; EEC, 2007).

Table 1.1 Problems, solutions and tools in medical design.

The application of engineering methods and processes may significantly reduce the risk of failures from the problems in Table 1.1. With this in mind, the theory part of this chapter introduces main engineering approaches here defined as ‘tools’ described in the sections indicated in the final column of Table 1.1. These widely used tools are described here and applied to the design and development of medical instruments.

The tools and the corresponding paragraphs are introduced in a logical sequence as shown in Figure 1.1, where blocks represent sections indicated in the circled number. The main stream of product design starts from problem formulation (Section 1.2) to the product life cycle (Section 1.6). Any unique temporary activity such as design can be considered as a project that require specific management (Section 1.7). During and after design, intellectual property right (IPR) has to be faced with care to avoid infringing existing patents and to eventually protect the own product innovation as discussed in 1.8.

Figure 1.1 Chapter 1 structure.

The implementation part of this chapter applies theory to a medical instrument example: the electrocardiogram (ECG/EKG). This book fully discloses a commercially available ECG product: the Gamma Cardio CG (CGV model) from the Gamma Cardio Soft company. The product's details are used to explain how theoretical concepts are translated into real marketable medical instruments. The implementation describes the ‘know-how’ of design and the ‘know-why’ of design decisions and rationales. The know-why has a general validity beyond ECG, since the rationale is common to medical devices generally. This design-oriented approach is useful in understanding the main concepts related to physiology, the principles underlying medical instruments and the applications of these instruments.

The book organization follows the design process as outlined in Figure 1.2. Chapter 1 addresses the tools required to design electronic products applying the concepts to medical instrumentation. The development process starts with product concepts and requirements (Chapter 2) that feed the design stage (Chapter 3). Signal processing and estimation is pervasive in all the conceptual blocks of a medical instrument. Chapter 4 introduces the mathematical framework required to handle signals and to assess performance through the whole medical system including electronics (Chapter 5), software (Chapter 6) and telecommunications/ICT components such as the e-Health products. Advances in medical device technology are increasing the need for alternative, simpler solutions for accessing and sharing medical data and services. Cloud computing is gaining prominence as a technological solution for distributing medical solutions. This issue is addressed in Chapter 7, where we introduce the new term ‘C-Health’ referring to ‘the set of healthcare services supported by cloud computing’. Chapter 8 covers medical instrumentation approval by regulatory bodies referred to as certification, clearance or other terms, according to specific authority.

Figure 1.2 Book structure.

Part I: Theory

1.1 Introduction

This chapter outlines the engineering tools and methodologies that are introduced in a logical order. Referring to Figure 1.1, design is first a problem that has to be formulated (Section 1.2). A systematic approach to describing a problem helps greatly in solving the problem itself. The business context (Section 1.3) has to be assessed at all the design stages to avoid technology-driven market failures. Design has to be performed in a systematic process. In Section 1.4, a simplified model of product design is introduced. This model is similar to the problem solving processes used in many other applications.

Any design of non-trivial devices has a high level of complexity given by the wide set of design details that have to be addressed and solved coherently. Unfortunately, the human mind is only able to cope with a very limited problem size at one time, with limited details. Techniques for reducing and decomposing complexity are therefore compulsory for non-trivial product design. So, Section 1.5 introduces the system-subsystem decomposition techniques used in software and in general at system level.

Product development implies a life cycle process that encompasses the various steps required for creating new products (plan, analysis, design etc.). These steps can be structured using various approaches to suit the specific constraints, the features of the product and the context, as discussed in Section 1.6. The design of a medical product is a typical project activity and therefore it is worth analyzing major aspects and risks in managing projects (Section 1.7). Finally, during and after design, intellectual property rights (IPR) have to be faced with care to avoid infringing existing patents and to eventually protect the developers' own product innovation (1.8).

1.2 Problem Formulation in Product Design

Product design is first a problem to be defined and solved. It is therefore worth focusing on the main aspects of problem solving and in particular on problem classification based on its formulation and solutions (see Figure 1.3). Problem formulation is the set of inputs and constraints available for problem solution. Effective formulation is critical to the outcome, especially considering that problems are usually ill-defined, multidimensional and with a wide constraining context. Effective formulation often requires an iterative approach: ‘First find out what the question is – then find out what the real question is.’ (Vince Roske)

Figure 1.3 Problem classification.

Problem classification based on the characteristics of the input formulation and on the solution helps in analyzing the problem characteristics and results in more effective problem-solving strategies. Problems may be divided into puzzles, dilemmas and messes (Pidd, 2002). Problems given to students are usually just ‘puzzles’ because both formulations and solutions are well defined. At the other extreme, product design is usually a ‘messy’ or ‘wicked’ problem: there are many different ambiguous solutions based on tradeoffs, and formulation is usually ill-defined. Often, requirements become clear only when the problem (e.g., the design project) is close to being finished.

In these messy problems, the traditional step-by-step logic useful for solving puzzles may not be sufficient, but here other techniques such as ‘abstraction’ and ‘divide and conquer’ may help.

In product design, a simplified model of the product is derived through abstraction. From this first model, other more detailed models are derived, each getting closed to the real system to be implemented. This technique is exploited also for system-subsystem decomposition (Section 1.5) using the ‘divide and conquer’ technique. In this paradigm, a complex problem can be faced when it is broken down into smaller solvable components.

A systematic approach to defining a problem helps greatly in solving the problem itself:

‘If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.’ (Albert Einstein).

In a simplified approach, problem management may be schematized as depicted in Figure 1.4. A customer assigns to the executors a problem to be solved with a clear goal. The customer then identifies the output to be delivered when problem is solved.

Figure 1.4 The problem framework.

The customer itself usually defines the input and constraints to be considered. Within constraints, the customer may include time-scheduling, milestones, budget, resources, expected quality, expected organizational interfaces and testing procedures and minimum results. The input may include at first level: customer needs, technological environment and preferred standards. The executor has to provide the output, given the input and constraints. During the execution of the task, the executor generates the assumptions required to solve the problem and the possible risks. The problem-solving activity in more complex cases will be performed through a project using techniques encompassed in the project management area (Section 1.7).

All the previous elements should be agreed between the customers and the executors before the project initialization phase so that all the stakeholders are committed to solving the problem with the same elements. The executor has to define the problem formulation in as much detail as possible before starting, to avoid misunderstandings during the task execution.

Complex problems usually involve social and psychological issues. The definition may not be simple and negotiation on the various constraints probably has to take place with all the stakeholders, who are conditioned by their own background. If problem definition does not take into account all the stakeholders' perspectives, people involved in the task may possibly not cooperate (Pidd, 2002). In product design, a company may outsource the development of a new device. The main negotiation may start with budget, time and performance. The customer will tend to reduce budget and time and try to obtain the maximum quality for the outcome. Executors have the opposite goal. The customer will also impose other constraints for problem-solving. Negotiation will end in some sort of compromise, frozen in a formal agreement. Errors in this step will result in project failure, with extra cost, delays or lack of quality.

A mistake in problem formulation will probably end in project failure. In Table 1.2, a simple checklist outlines the main steps of problem formulation.

Table 1.2 Problem formulation checklist .

1. Real problems, such as product design, are messy, so adopt proper strategies.2. Take proper time to define the problem, specifying the goal, outcome, input, assumptions, risks and constraints (scheduling, budget, resources, quality).3. Negotiate the problem definition with the customer to obtain a contract.4. Promises have to be kept.

1.3 The Business Context for Design

Scientific literature has systematically investigated the reasons for failure and the best practices to facilitate the success of new product development. There is quite good agreement in identifying two main reasons for failure (De Brentani, 1989; Timmons, 2004):

1. product development outside market needs

2. product development too late to exploit windows of opportunity.

Regarding the first error, there are two points of view. On one hand, it is recognized that products should be market-driven. On the other hand, literature recognizes from the empirical evidence that technology-driven products prevail (Brown, 1991). This probably suggests that technology-driven approaches should be the impulse for a new product development but it must then be market-validated and market-designed (Johnson, 1997). Business literature generally agrees that some sort of primary data are compulsory for designing and validating products (CB, 2004). The design of the marketing is also another issue that is quite commonly thought to be a critical success factor in literature (Bailetti and Litva, 1995).

This section aims to show how business and marketing considerations usually included in the product business plans impact on product design. A deeper coverage of business plans may be found in (Bygrave, 2004). For our scope, a business plan is mainly a document explaining:

1. the business goals for the specific products (sales, revenues, profits etc.)

2. the way to achieve those goals

3. the arguments that explain the feasibility of goal achievement through a specific set of actions.

A first question that the business plan must respond to is

Why should customers buy our product and not those of our competitors?

In marketing terms, this is referred to as ‘differential competitive advantage’ (Kotler, 2002); that is, the customers' perceived advantage of our product over our competitors' products.

Assuming a marketplace where only product features determine buyers' behavior, the two main product parameters become price and ‘performance’ where the latter encompasses many factors (implemented functions, quality, robustness, aesthetic design and service).

In this context, the business plan must define the required set of product performance and features to achieve the proper sales target.

More specifically, the business plan must include market research of the target customers that identifies the perceived performances and features that customers are willing to pay for and that they prefer when choosing one specific product instead of another. This is translated into a set of mandatory and suggested features, which are included in the business plan.

It is market analysis that often identifies critical success factors (Johnson, 1997), and this may be far from what is expected by engineers involved in product design. The key element is the ‘perceived performance’. Let us consider, for example, a doctor buying a medical instrument. This doctor does not usually have the proper know-how to assess technical performances although the performance is normally clearly evidenced in the technical specifications of the product. For example, a cardiologist may have no knowledge of sample rate, resolution or ‘common mode rejection rate’, which are main factors for assessing real ECG performance. In this context, doctors will use proxies to assess product performance (Kotler, 2002): brand, colleagues' suggestions, expected service or even the esthetic design, on the instinctive assumption that ‘the quality of the packaging relates to the quality of the product itself’.

For many products, it would be expected that price and technical performance should rise together in a competitive product. Unfortunately, for medical products this is not always true due to the limited customer capability of technically evaluating products.

The market product analysis will then contain a set of features that are perceived by potential customers to differentiate the product. These features are an input for the product design problem.

Performance, cost and price are strictly related. In a simplified framework, each performance has an associated ‘product marginal cost’, that is, an increase of the production cost of the equipment due to the implementation of the specific feature. This is true especially for features implemented in hardware. The implemented features also have an associated ‘feature investment’ that is the additional investment required to develop the feature.

Let us suppose that our product will implement M features; the total cost to produce n items of equipment has a which can be expressed as:

(1.1)

where is the product marginal cost to produce the i-th feature (e.g., the cost of raw materials, labor and sales commissions) and is the product investment required to develop the i-th feature.

Revenues from selling n units are:

(1.2)

Finally, the profit is given by the difference between revenues, production costs and investment:

(1.3)

The profit graph in Figure 1.5 is interesting, because it shows that when a certain quantity of product has been sold (i.e., the break-even point), the business becomes profitable. In this simplified framework, the fixed costs are neglected. Fixed costs are those costs that do not change with volume of production (facility, equipment, salaries) and are apportioned to the product. Those fixed costs may be simply added to the investment cost in the previous formulas.

Figure 1.5 Gross profit versus number of products sold.

It is easily shown that the threshold quantity referred to as the break-even point is then equal to:

(1.4)

Business profitability is achieved when the product quantity sold is greater than the break-even value. When sales forecast cannot achieve break-even, the previous formula suggests approaches to ensure business sustainability (i.e. quantity sold > break-even value):

Reduce the implemented features.

This will reduce both the product costs and the investment , but may have a negative impact on sales.

Increase the sales price, again with a negative impact on sales.Reduce fixed costs.

The first bullet is of particular interest for product design and development. Often, the majority of users use only a minority of the product's features. Therefore, the selection of the features to be implemented has to be particularly accurate to avoid including features that are expensive in implementation/production but of less interest to the target market.

In the previous formulas, the markup value can be derived as the difference between the selling price and the cost:

(1.5)

Markup evaluation is critical because the higher the price, the faster the break-even. Unfortunately, markup generally has an inverse effect on sales because customers are generally less willing to buy more expensive products. This concept is explained in economics with the so-called ‘price elasticity of demand’ (Kotler, 2002). For some goods, demand and price are related by an inverse proportionality (perfectly elastic curve). For medical instruments, this is less true due to the nature of the product. Physicians use medical instrumentation to decide on patient health, and therefore price considerations seem less relevant. Also, physicians only give considered attention to innovations after extensive clinical trials that guarantee effectiveness. In addition, since price is a proxy for quality, too low a price may even reduce sales because product is then perceived to be of poor quality.

The previous discussion is somewhat simplified with respect to real market dynamics, where other factors have to be considered (Kotler, 2002). In any case, it allows for drawing some useful considerations on product design:

1. product developers may focus on technical excellence

2.but ... product technical superiority and innovation do not yield a clear and automatic market advantage

3.and ... feature implementations increase costs and development time

4.therefore ... selection of features to be included in a product should be carried out after market research and after cost/technical considerations have been used so as to reduce costs/risks and increase the probability of market success

Considering also that ‘what is not implemented will not cost anything and go wrong’, product designers should carefully reduce performance to a minimum set of ‘must have’ features to obtain a successful market product. Such performance should be implemented with investment cost that is not higher than that included in the business plan. In addition, during design, final expected production cost has to be monitored during each stage because exceeding production marginal cost or investment cost may make the business plan unprofitable. For this purpose, program management techniques should be carried out in order to avoid such risk. Table 1.3 shows some main points related to this paragraph.

Table 1.3 Business context for design checklist .

1. Define and select perceived features that guarantee product competitive advantage, using data either from the customer or from market research.2. For such distinctive features evaluate the marginal production cost and the investment required for development.3. With the customer, perform a benefit-analysis for the implementation of such features.4. Reduce features to be implemented basing on the previous item.

1.4 The Engineering Product Design Process

Engineering design is the process that includes activities required to place products on the market. The scientific industrial literature offers many different models for product design since different models can be used according to the nature of the product and the context. In this section, a simplified model will be introduced with the aim of highlighting the rationale for development process activities. In this way, readers may find it easier to adapt models to their specific development.

The general process of product design is similar to procedures for systematic problem-solving used in many other fields of application. This may be explained since any solution obtained through a systematic rational process requires answers to the general questions indicated in the first column of Table 1.4.

Table 1.4 General activities in product development.

General questions for product developmentCorresponding activity name in the proposed model1. Why the product?Mission-concept2. What is the plan?Project planning3. What product is needed according to the customer/beneficiary?Requirement analysis4. How will the product implement these requirements?Design specification5. How should the product be implemented and integrated?Implementation and system integration6. How can it be tested according to the criteria:

a. Has the right thing been done?

b. Have the things been done right? (i.e. Does it work?)

TestValidationVerification

In the second column of Table 1.4, there is a possible definition adapted from the MIL-STD 498 standard (MIL, 1994). This standard although substituted by newer standards is still often preferred due to its advantages: free availability of templates and guides, flexibility in terms of development strategy, methods and tools and system-orientation that encompasses hardware–software integration.

A more frequently quoted source of errors in project management is that of embracing a process standard as is, without adequate analysis of the real needs of the product development. Every item of the standard (e.g., documentation) requires extra time, and some may be an unnecessary waste of time. The MIL-STD 498 standard is helpful here since it contains most of the ‘components’ required for usual projects and it is conceived so as to be easily tailored for specific goals.

The process model in Table 1.4 is still quite simple for handling real products and therefore it should be completed, introducing stages that address the most recurring problems of development. Product developments are characterized by many errors in every step of Table 1.4, but errors at different stages have different costs for fixing. Figure 1.6 summarizes some studies on errors in software projects (adapted from Davis, 1993).

Figure 1.6 Cost of repairing errors at different design stages.

The cost of fixing errors grows exponentially with the time interval from the start of the project and the time when the error is fixed, as shown in Figure 1.6. Boehm (1981) identifies a cost escalation in the range from 40 to 1000 times for fixing an error when the software is delivered, compared to fixing it at requirement stage. Errors at requirement or design specification stages are only ‘paper errors’, in that they just need time to analyse and correct the changes to the documentation. At the implementation stage, software errors have to be solved through debugging and fixing that requires much more time than at the previous stage. After formal tests, things get even harder because software has to be generally retested from scratch and a formal procedure has to be performed (e.g., problem report, change request). After certification, apart from administrative procedures, the main risk is of product withdrawal and damage compensation.

Even hardware has similar cost escalations. According to a NASA study (NASA, 2010), hardware fixing has on the whole an exponential behavior similar to that of software, with specific differences at specific stages. In medical devices, as well as in all safety-critical fields where rigorous product certification holds, the cost may be even higher considering also the consequences of the errors.

The obvious conclusion is that ‘the project design process should include activities to detect errors as early as possible’.

A frequent strategy consists of estimating performance of the product at the early stages. This can be done through three approaches:

1. analytical models

2. low fidelity simulations (e.g., not using the final software)

3. high fidelity simulations (e.g., using the final software in a simulated environment).

Analytical models are powerful and rapid for estimating performance over many parameters. A product model may be derived using formulas in the context of signal-information theory, signal processing, digital signal processing, circuit theory, electronics and software engineering. The product performance may be also simulated through proper tools that handle hardware, signals and software behavior at various levels of complexity. This topic is now extremely relevant for product development; performance estimation will be outlined in Chapter 4.

It is therefore suggested to add a stage of performance evaluation to the activities included in product development. Figure 1.7 depicts a possible product development life cycle.

Figure 1.7 Product development life cycle.

The first step is the product concept that generally is included in the plan. The concept should outline briefly the scope and the content of the project. Then a plan is recommended as discussed in Section 1.7. Requirement analysis defines what the product must do according to customer/buyer needs.

Requirements contents are usually generated by practitioners in the field. Analysts and marketing experts usually generate these requirements from physicians, nurses and other stakeholders working where the product will be used. The output of this process is a set of requirements: characteristics that the product must possess in order to be acceptable to the customer.

A requirement should have these attributes:

1. It is uniquely identified by an identity code.

2. It is feasible and it can be verified through inspection, demonstration, test or analysis. (i.e., a test can be written to ensure that the requirement is met).

3. It must not conflict with other requirements.

4. It can be translated into a technically and economically feasible design specification.

5. It is mandatory and it identifies a real business need/opportunity.

6. It is unambiguous and complete and it addresses only one specific feature.

An example of requirements on an ECG may be (adapted from AAMI, 1991):

Req 1.1The ECG shall be able to display differential voltages of ±5 mV.

Req 1.2A 20 μV peak-to-peak sinusoidal signal shall yield a visible ECG trace.

All the previous conditions are satisfied by these two requirements: the business need is related to the fact that cardiologists must have such performance to detect specific pathologies.

In a more focused and efficient approach, requirement analysis should limit strictly to what the customer considers as a condition for product acceptance (MIL 498 Guide, 1994). To this end, company internal marketing should help product development. The analysts should bear clearly in mind which are the technology and cost constraints, because, at this stage, it is common to introduce requirements that are expensive or even unfeasible. Every requirement normally determines an increase in both product marginal cost and product development cost that cannot be estimated clearly at this early stage. Therefore, in the requirement review, we must take into consideration if each requirement is really necessary. Additional requirements will increase the cost, the development time and the risks considering the trivial rule that: ‘What does not exist cannot fail’.

To simplify the requirement analysis, use cases are usually employed. These are a descriptive method of defining the behavior of a system when achieving the business goals required by customers. A use case describes informally how users will practically handle the system to achieve their intended goals in different operative scenarios. The use case will contain the set of actions that the product will perform in response to users' input. The use case will then include the corresponding expected output of the product ignoring the real product implementation. From a set of use cases, a coherent set of requirements may be defined.

Every requirement must be translated into at least one design specification. So a traceability matrix is used where the first column contains all the requirements, one per row, and the second column includes a reference to the associated specifications introduced to implement the specific requirement.

The design step is the process of developing a set of specifications that explains how the product is implemented in response to requirements. The design specifications are performed by developers, who are expert in implementation also referred to as the ‘solutions domain’. The analyst, in turn, should be expert in the domain of the problems, although competences are required in implementation to avoid unfeasible requirements.

A typical specification in response to the previous requirements is

Req 1.1The ECG shall be able to display differential voltages of ±5 mV.

Req 1.2a 20 μV peak-to-peak sinusoidal signal shall yield a visible ECG trace.

Spec. 1 the ECG A/D converter shall have at least 10-bit real resolution, assuming that 0.01 mV is the minimum vertical excursion that produces a vertical modification on the display.

This is because the minimum resolution should allow us to detect less than 0.01 mV to display a 0.02 mV = 20 μV peak-to-peak signal and therefore we need at minimum (5 + 5 mV)/0.01 = sample intervals = 1000 < 1024 = 210corresponding to a 10-bit resolution.

Spec 1 obviously does not cover completely the two corresponding requirements since other specifications are required on all components that handle the signal (i.e., hardware, firmware and software). The complete design will also include what is required to obtain the product, such as software diagrams, hardware circuits diagrams, and mechanical components drawings.

After this stage, performance evaluation may test the requirements and specifications. Analytical models may validate some target performance such as: sensitivity, frequency response, resolution, power requirement, cost and so on.

Hardware design is performed using proper tools (e.g., CAD – computer aided design) that allow the evaluation of electronic, mechanical, thermal and radiation behavior through high quality simulations. This evaluation can be assessed at the performance evaluation stage. These evaluations may be helpful also for the risk analysis and certification stage. Other tools may validate signal processing or the software algorithms.

After performance evaluation, the implementation can take place at various levels of complexity using demonstrators, prototypes and the final sample products. All the components (software, hardware, mechanical objects, sensors) are then integrated within the system. Manufacturing issues have to be considered at earlier stages to avoid expensive reworking.

The final stage of this simplified life cycle is the test that will include validation of all requirements, and verifications of the functions of the product with clinical trials usually being required by certification (EEC, 2007). This testing stage is critical because, after certification, error fixing becomes much more expensive. Errors are managed through proper processes as explained in Chapter 6 and, in safety-critical cases, they require proper notifications to the regulatory bodies.

The proposed cascade model of Figure 1.7, usually referred to as ‘waterfall model’, is still too simple for a real environment. There are two further topics to be addressed:

1. the lack of system decomposition

2. the limits of the ‘waterfall’ approach life cycle.

System decomposition is required because the system itself is generally too complex to be handled as a single unit. The divide et impera (divide and conquer) approach is a major strategy for handling the product complexity by decomposition into smaller units as explained in Section 1.5.

The life cyclewaterfall model considers a sequential development strategy where each stage starts at the end of the previous: first planning, then requirement analysis, design and so on. Unfortunately, this model is critical because in innovative projects like new product design, some details only become clear at the later stages of implementation. This may invalidate the previous development stages that then have to be reworked (Parnas et al., 1986). This topic will be addressed in Section 1.6. Table 1.5 shows a simple checklist including the suggestions discussed in this section.

Table 1.5 Engineering design process checklist .

1. Apply an engineering product development process (basic steps: planning, requirement analysis, design specification, implementation, testing).2. Since the cost of fixing errors increases exponentially toward the end of the project, define a strategy to discover errors as early as possible.3. To do so, consider performance evaluation that allows assessing product performance at earlier stage.4. Also consider system design decomposition (Section 1.5), and product life cycle consideration (Section 1.6).

1.5 System-subsystem Decomposition

Divide and conquer

Any design of non-trivial products has a high level of complexity given by the set of the design details that have to be addressed and solved coherently. Unfortunately, the human mind is only able to deal with a very limited problem size at one time with restricted details. The problem refers to when Romans were facing enemies but they had insufficient forces. The Roman strategy may be summarized by the phrase ‘divide and conquer’, that is, to try to divide the enemy forces into small components until the component size could be faced alone by the Romans' forces, as shown in Figure 1.8. The components should be as ‘independent’ as possible, so that the Romans could fight against one component, hoping that the other components would not arrive and change the balance of power.

Figure 1.8 Divide and conquer strategy

.

The strategy then consists in fighting one component at time (from one to six in Figure 1.8), hoping that the other components do not join in the battle.This strategy is effective for design problems as well. Project design forces have limited capacity to solve simultaneously all the design details (the enemy). The strategy then consists of breaking the system down into smaller subsystems until subsystem sizes can be faced by the project designers' capability. In this section, the term ‘subsystem’ will be used. When dealing with decomposition, other equivalent terms are also used according to the context: modules, components, packages, configuration items, classes, boards and so on.

The subsystems should be as ‘independent’ as possible so that each subsystem can be designed without considering side effects on and from the other subsystems. In the end, the design of all subsystems must cover all of the system design, since missing design elements will be probably be a source of errors in the product implementation.

The strategy can be implemented as follows. The first step consists of defining level one (L1), that is, the system itself with its external interacting entities (usually termed ‘actors’) and the interfaces between the system and the actors (see Figure 1.9). An interface may be defined as the point of interaction between subsystems where the method of interaction is defined.

Figure 1.9 System-subsystem decomposition

.

The system is then decomposed into subsystems at L2 level that inherits L1 interfaces and introduces other L2 interfaces (I2.1 and I2.2 in Figure 1.9). Each L2 subsystem in turn has its interfaces, and can be decomposed into subsystems that constitute the L3 level. Other levels can be defined until the appropriate level of detail is reached. However, all the L2 subsystems must partition L1 completely, that is, the set of subsystem interfaces at any level decomposes exactly each upper level.

The final level should contain the appropriate degree of complexity and design detail for the subsystems and interfaces. Figure 1.10 shows the first level diagram related to a biopotential-based medical instrument.

Figure 1.10 Medical instrument system diagram.

This level is complete in terms of interfaces (I1.1, I1.2) and actors, although it is rather generic. The subsequent levels will specify the design in more detail. The system of Figure 1.10 can then be decomposed into a second level that includes the decomposition of the elements of the first level as shown in Figure 1.11.

Figure 1.11 Medical instrument subsystem decomposition

.

This hierarchical approach is also suited for structuring the overall design job so that different subsystems can be worked on in parallel. Figure 1.11 can be easily organized into a work breakdown structure (WBS) that is required to organize tasks for the working team in the project plan. The levels of the WBS (Figure 1.12) mainly coincide with system-subsystem decomposition.

Figure 1.12 Product breakdown structure for a medical instrument.

The project team can then address in parallel the activities and, at the end of subsystem implementation, an integration/testing step will yield the overall product.

A product breakdown structure is also easily derived using Figure 1.12. This is helpful for product implementation and production.

Given that some decomposition is required, the question of how to select a suitable subsystem decomposition arises. Many different solutions are available for system-subsystem decomposition; that is, many system partitions are possible and some criteria are needed to select a good partition.

The left-hand side Figure 1.13 shows a possible system, where lines denote interactions between functions (the boxes). A subsystem decomposition consists of aggregating functions into different subsystems. An effective decomposition criterion may consist of minimizing the complexity of subsystems. Complexity mainly arises because a modification in one subsystem causes effects on other subsystems and this effect may even be cyclical. This means that a single subsystem cannot generally be analyzed without taking into account the effects on/of other subsystems.

Figure 1.13 System example (left) and its subsystem decomposition (right).

In Figure 1.13 the decomposition is performed minimizing interactions among subsystems: this yields a second level with three subsystems and four interfaces evidenced with green dotted lines. The functional decomposition of Figure 1.13 is roughly obtained by minimizing the ‘coupling’ between subsystems and aggregating the functions that are strongly related in the same subsystem. This approach is referred to as ‘cohesion’. The overall paradigm is usually referred as maximal cohesion and minimal coupling and although it is a rather old idea (Stevens, 1974), it still remains the major guideline for defining software and hardware architectures.

The degree of cohesion of a subsystem may be expressed in how much the functions are related within a specific subsystem. Cohesion may be qualitatively measured using concepts of the upper part of Figure 1.14 (adapted from Stevens, 1974).

Figure 1.14 Metrics for coupling and cohesion.

The lowest degree of cohesion is achieved when functions are casually grouped within a subsystem. Figure 1.14 shows other intermediate steps toward high cohesion: functions may be grouped according to better criteria (logically similar, executed at a similar time etc.).

Figure 1.14 bottom shows also a metric for measuring coupling. Coupling may be defined as the level of interdependency between subsystems. Low coupling is a preferred approach since it reduces system complexity and therefore it improves subsystem design test reusability, as well as system integration and maintenance.

The best approach is ‘no coupling’ at all. In this way, subsystems may be handled independently. A good approach is message coupling where a subsystem offers its services with message exchanges through a defined public interface. In this case, there is no direct dependency between subsystems. In data coupling, subsystems share some data, and data modifications in one subsystem may affect the others. In control coupling, the control flow of one subsystem is handled by another module. External coupling occurs when subsystems depend on external entities.

In common coupling, subsystems share global data. The worst coupling (content coupling) applies when one subsystem accesses and modifies internal elements (data, flow...) of other subsystems that heavily affect their behavior.

The approach for maximal cohesion and minimal coupling is a design guideline to be preferred. If this guideline is ignored, the following disadvantages are to be expected:

Subsystems will be harder to design and test because of side effects in the subsystems.System integration will be more time-consuming since the behavior of the system is affected by the behavior of the subsystems and their more complex interactions.Subsystems will be less reusable since they are strongly connected to other subsystems.

It is worth noting that the criterion of cohesion and coupling also has some disadvantages:

Extra effort is required to design and develop proper subsystems.Since proper architecture may not be clear at beginning, design reworking is to be expected.Efficiency may be reduced due to the introduction of extra interfaces.

A good architecture solution may imply the design of subsystems that offer well-defined services through simple defined standard interfaces. In hardware, plug-in modules using standard buses are examples. In software, similar concepts may be applicable using virtual software bus architectures or CORBA (common object request broker architecture). Even more, in software, many new development environments embed service-oriented plug-in components that can be easily combined to obtain the required application with minimal coding (Becchetti, 2001). The system architecture shown in Figure 1.15 is always more considered in electronic and medical product design because

1. PC based hardware is highly efficient and low cost due to wide distribution (economies of scale),

2. the software marginal cost is almost zero,

3. software designed for PC based platforms has a much lower development cost with respect to firmware owing to better tools and know-how and the wide availability of software components, and

4. by contrast, custom hardware is expensive to develop and maintain.

Costs, risks and development time may be reduced by reducing custom hardware to those functions that cannot be performed with PC based platforms for various reasons (insufficient computational power, stringent real-time requirements, certification requirements, hardware-specific functions). Functions associated to custom hardware could include signal acquisition, high data rate signal processing, electrical isolation and specific actuators. It should be noted that in medical devices, PC based platforms are often used but masked to users that do not feel to be in front of usual PCs. The wide use of PCs also has some disadvantages: operating systems and the hardware itself change more rapidly than custom hardware. This means that more upgrading has to be performed within the product life cycle. System subsystem decomposition is a powerful tool for any designer whatever the non-trivial problem. Table 1.6 below summarizes the main concepts.

Figure 1.15 General product architecture.

Table 1.6