de Laar / Punter Views on Evolvability of Embedded Systems

1. Auflage 2010
ISBN: 978-90-481-9849-8
Verlag: Springer Netherlands
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 316 Seiten

Reihe: Embedded Systems

Evolvability, the ability to respond effectively to change, represents a major challenge to today's high-end embedded systems, such as those developed in the medical domain by Philips Healthcare. These systems are typically developed by multi-disciplinary teams, located around the world, and are in constant need of upgrading to provide new advanced features, to deal with obsolescence, and to exploit emerging enabling technologies. Despite the importance of evolvability for these types of systems, the field has received scant attention from the scientific and engineering communities. Views on Evolvability of Embedded Systems focuses on the topic of evolvability of embedded systems from an applied scientific perspective. In particular, the book describes results from the Darwin project that researched evolvability in the context of Magnetic Resonance Imaging (MRI) systems. This project applied the Industry-as-Laboratory paradigm, in which industry and academia join forces to ensure continuous knowledge and technology transfer during the project's lifetime. The Darwin project was a collaboration between the Embedded Systems Institute, the MRI business unit of Philips Healthcare, Philips Research, and five Dutch universities. Evolvability was addressed from a system engineering perspective by a number of researchers from different disciplines such as software-, electrical- and mechanical engineering, with a clear focus on economic decision making. The research focused on four areas: data mining, reference architectures, mechanisms and patterns for evolvability, in particular visualization & modelling, and economic decision making. Views on Evolvability of Embedded Systems is targeted at both researchers and practitioners; they will not only find a state-of-the-art overview on evolvability research, but also guidelines to make systems more evolvable and new industrially-validated techniques to improve the evolvability of embedded systems.

Piërre van de Laar studied at the Catholic University of Nijmegen and was awarded his master degree (cum laude) in both theoretical and computational physics in 1994 and his PhD on 'Selection in Neural Information Processing' in 1999. He was a senior researcher at Philips Research in Eindhoven. Since 2006, he is a Research Fellow of the Embedded Systems Institute. After performing a study for DaimlerChrysler, he joined the Darwin project.Teade Punter received a M.Sc (Ir.) from University of Twente in 1991 and a Ph.D. from Eindhoven University of Technology in 2001. He worked at the Open University of the Netherlands, Kema Nederland B.V., Fraunhofer IESE and Eindhoven University of Technology. He has dealt with a variety of topics in software and systems engineering, e.g., software measurement and assessment. Teade is a Knowledge Manager at ESI for multiple projects, including the Darwin project. Teade's interests are in model driven engineering, integration & test and technology transfer.

Autoren/Hrsg.

Punter, Teade

de Laar, Pierre van

Inhaltsverzeichnis

1;Foreword;6
2;Preface;8
3;Acknowledgements;10
4;Contents;12
5;Chapter 1Researching Evolvability;14
5.1;1.1 Introduction;14
5.2;1.2 Evolvability;15
5.2.1;1.2.1 What Are the Sources of Change?;15
5.2.2;1.2.2 When to Respond to Change?;16
5.2.3;1.2.3 How to Respond to Change?;17
5.2.4;1.2.4 What Makes Responding Difficult?;17
5.2.5;1.2.5 How to Respond Effectively?;19
5.2.6;1.2.6 What Is the Value of Being Evolvable?;20
5.3;1.3 Magnetic Resonance Imaging;20
5.3.1;1.3.1 MRI Principles and System;21
5.3.1.1;1.3.1.1 MRI Principles;21
5.3.1.2;1.3.1.2 The MRI System – General;22
5.3.1.3;1.3.1.3 The MRI System – Practical Considerations;25
5.4;1.4 Darwin: Evolvability Research in the Medical Domain;25
5.5;1.5 Structure of the Book;27
5.5.1;1.5.1 Focus;27
5.5.2;1.5.2 Technical Vision;28
5.5.2.1;1.5.2.1 Mining the Existing Realization;28
5.5.2.2;1.5.2.2 Reference Architecture;29
5.5.2.3;1.5.2.3 Mechanisms, Patterns, and Guidelines;30
5.5.2.4;1.5.2.4 Economic Decision Making;31
5.5.3;1.5.3 Reflections;31
5.6;1.6 Summary;32
5.7;References;33
6;Chapter 2Architecting for Improved Evolvability;34
6.1;2.1 Introduction;35
6.2;2.2 Main Causes of Evolvability Problems;35
6.2.1;2.2.1 Lack of Shared Understanding;35
6.2.2;2.2.2 Insufficient Motivation to Invest in Evolvability;36
6.2.3;2.2.3 Large Effort and High Cost of Architecture Improvements;37
6.3;2.3 General Guidelines for Improving Evolvability;37
6.3.1;2.3.1 How to Create Shared Understanding?;38
6.3.2;2.3.2 How to Motivate Investments in Evolvability?;39
6.3.3;2.3.3 How to Reduce Implementation Effort and Cost of Architecture Improvements?;40
6.3.3.1;2.3.3.1 Simplicity;40
6.3.3.2;2.3.3.2 Size Reduction;40
6.3.3.3;2.3.3.3 Supplier Support;41
6.3.3.4;2.3.3.4 Incremental Change;42
6.4;2.4 Examples;42
6.4.1;2.4.1 System Cooling;42
6.4.2;2.4.2 Protection Against Hazardous Output: Heat;44
6.5;2.5 Conclusions;46
6.6;References;48
7;Chapter 3Complementing Software Documentation;50
7.1;3.1 Introduction;51
7.2;3.2 Exploring Software for Maintenance;52
7.2.1;3.2.1 Recovering Concerns;53
7.3;3.3 Overview of the Approach;53
7.3.1;3.3.1 Input Selection;54
7.3.2;3.3.2 Preprocessing and Indexing;54
7.3.3;3.3.3 Latent Semantic Indexing;57
7.3.4;3.3.4 Computing Similarities and Clustering;58
7.3.5;3.3.5 Visualisation;58
7.4;3.4 Case Study: Diffusion Processing;59
7.4.1;3.4.1 Diffusion Processing Application;59
7.4.2;3.4.2 Design of the Experiment;59
7.4.3;3.4.3 Evaluation of the Results;60
7.5;3.5 Case Study: Application Development Environment;61
7.5.1;3.5.1 Application Development Environment;61
7.5.2;3.5.2 Design of the Experiment;62
7.5.3;3.5.3 Evaluation of the Results;62
7.6;3.6 Conclusion;62
7.7;References;64
8;Chapter 4 Identifying and Investigating Evolution Type Decomposition Weaknesses;65
8.1;4.1 Introduction;65
8.2;4.2 Approximating Change Sets;68
8.3;4.3 Identifying Evolutionary Clusters;72
8.4;4.4 Characterizing Evolutionary Clusters;74
8.5;4.5 Visual Exploration of Evolutionary Clusters;77
8.6;4.6 Conclusion;79
8.7;References;79
9;Chapter 5Transferring Evolutionary Couplingsto Industry;81
9.1;5.1 Introduction;81
9.2;5.2 Changes;82
9.3;5.3 Summarizing and Visualizing Changes;83
9.4;5.4 Case Study;85
9.4.1;5.4.1 Philips Healthcare MRI Repository;85
9.4.2;5.4.2 CouplingViewer;87
9.4.3;5.4.3 Industrial Validation;89
9.4.3.1;5.4.3.1 Pilot Study;89
9.4.3.2;5.4.3.2 Quantitative Experiment;90
9.5;5.5 Lessons Learned;91
9.5.1;5.5.1 Not All Modules Changed Are Related;91
9.5.2;5.5.2 Couplings Are Directed;93
9.5.3;5.5.3 Hierarchy of Changes;94
9.5.4;5.5.4 Minimizing Overhead;94
9.5.5;5.5.5 Different Kinds of Change;95
9.5.6;5.5.6 Conceptual Model of Couplings;96
9.6;5.6 Discussion;97
9.7;5.7 Conclusions;97
9.8;5.8 Future Work;98
9.9;References;99
10;Chapter 6An Execution Viewpoint Catalogfor Software-Intensive and Embedded Systems;101
10.1;6.1 Introduction;101
10.2;6.2 The Execution Viewpoint Catalog;103
10.3;6.3 Execution Profile Viewpoint;104
10.3.1;6.3.1 Concerns and Stakeholders;104
10.3.2;6.3.2 Model Kinds;105
10.3.3;6.3.3 Guidelines to Construct an Execution Profile View;106
10.3.4;6.3.4 Guidelines to Use an Execution Profile View;107
10.4;6.4 Resource Usage Viewpoint;108
10.4.1;6.4.1 Concerns and Stakeholders;108
10.4.2;6.4.2 Model Kinds;108
10.4.3;6.4.3 Guidelines to Construct a Resource Usage View;111
10.4.4;6.4.4 Guidelines to Use a Resource Usage View;111
10.5;6.5 Execution Concurrency Viewpoint;112
10.5.1;6.5.1 Concerns and Stakeholders;112
10.5.2;6.5.2 Model Kinds;113
10.5.3;6.5.3 Guidelines to Construct an Execution Concurrency View;114
10.5.4;6.5.4 Guidelines to Use an Execution Concurrency View;115
10.6;6.6 Application of the Execution Viewpoint Catalog;116
10.7;6.7 Discussion;117
10.8;References;118
11;Chapter 7Researching Reference ArchitecturesGerrit Muller;119
11.1;7.1 Introduction;119
11.2;7.2 Reference Architectures and Other Architectural Concepts;120
11.2.1;7.2.1 System Architectures and Product Family Architectures;120
11.2.2;7.2.2 Architecture Frameworks and Architecting Methods;121
11.2.3;7.2.3 Reference Architectures;122
11.2.4;7.2.4 Comparing Reference Architectures;123
11.3;7.3 Research in the Darwin Project;124
11.3.1;7.3.1 Analysis Tools (Approaches 1 and 2);124
11.3.2;7.3.2 Reflection on Analysis Tools in Relation to Reference Architectures;127
11.3.3;7.3.3 Interviewing, Reading Documentation, and Workshops (Approaches 3 – 5);128
11.3.4;7.3.4 Reflection on Current Research Status;129
11.4;7.4 Summary and Conclusion;130
11.5;References;130
12;Chapter 8A3 Architecture Overviews;132
12.1;8.1 Introduction;132
12.2;8.2 System Evolution and Architecture Descriptions;133
12.2.1;8.2.1 System Evolution Barriers;133
12.2.2;8.2.2 Architecture Descriptions;134
12.3;8.3 Making Knowledge Explicit: Reverse Architecting;135
12.3.1;8.3.1 Information Extraction;135
12.3.2;8.3.2 Abstraction;136
12.3.3;8.3.3 Presentation;137
12.4;8.4 A3 Architecture Overviews;138
12.4.1;8.4.1 Structure and Elements of an A3 Architecture Overview;140
12.5;8.5 A3 Architecture Overviews as Repository of Architectural Knowledge;143
12.6;8.6 Study Case: Philips MRI New Style SDS;144
12.6.1;8.6.1 SDS Acceptance and Use Within Philips MRI;144
12.6.2;8.6.2 New Style: A3 Architecture Overview SDS;145
12.7;8.7 Benefits and Concerns;145
12.8;References;146
13;Chapter 9Linking Requirements and Implementation;148
13.1;9.1 Introduction;148
13.2;9.2 System Documentation Abstraction Classification;149
13.2.1;9.2.1 Related Work;149
13.2.2;9.2.2 Our Industrial Observations;151
13.2.3;9.2.3 Opportunities for System Evolvability;152
13.3;9.3 Experiences with Combining Links;154
13.3.1;9.3.1 Introduction to the Use Case;155
13.3.2;9.3.2 From Requirements to Implementation in Use Case;156
13.3.3;9.3.3 Experiences from Use Case;159
13.4;9.4 Conclusions;160
13.5;References;162
14;Chapter 10Workflow Modelling of Intended System Use;163
14.1;10.1 Introduction;163
14.2;10.2 User Centric Design in Engineering Design;165
14.2.1;10.2.1 User Perspective;165
14.2.2;10.2.2 Professional Equipment vs. Consumer Good Users;166
14.2.3;10.2.3 Related Work;167
14.3;10.3 System Architecting;167
14.3.1;10.3.1 Complexity in Architecting;167
14.3.2;10.3.2 New Products;168
14.3.3;10.3.3 Hierarchical Models;168
14.4;10.4 Workflow Modelling Method;169
14.4.1;10.4.1 Global Method;169
14.4.1.1;10.4.1.1 Product and Process;170
14.4.1.2;10.4.1.2 Iterations and Early Workflow Validation;170
14.4.2;10.4.2 Step 1: Creating Workflow Models;171
14.4.2.1;10.4.2.1 Set Up Hierarchical Workflow Structure;171
14.4.2.2;10.4.2.2 Workflow Review by Stakeholders;172
14.4.2.3;10.4.2.3 Workflow in Literature;173
14.4.3;10.4.3 Steps 2, 3 and 4: Workflow Model to Function Model;173
14.4.3.1;10.4.3.1 Workflow as a Recipe for the System;173
14.4.3.2;10.4.3.2 Function Decomposition of the System;174
14.4.4;10.4.4 Steps 5 and 6: Real Workflow and Validation;175
14.5;10.5 Case Study: Intra Operative MR;175
14.5.1;10.5.1 Case Characteristics;175
14.5.2;10.5.2 Intra Operative MR Workflows;176
14.5.3;10.5.3 Discussion;178
14.6;10.6 Conclusions;179
14.7;References;180
15;Chapter 11Supervisory Control Synthesis in the MedicalDomain;181
15.1;11.1 Introduction;181
15.2;11.2 Synthesis-Based Engineering;184
15.2.1;11.2.1 Model-Based Engineering;184
15.2.2;11.2.2 Supervisory Control Theory;185
15.2.3;11.2.3 Integrating MBE and SCT;185
15.3;11.3 Introduction to the Case-Study;187
15.4;11.4 Step A: Plant and Requirement Models;188
15.4.1;11.4.1 Vertical Axis;189
15.4.1.1;11.4.1.1 Plant Model (VAxis);189
15.4.1.2;11.4.1.2 Control Requirements (VReq);191
15.4.2;11.4.2 Horizontal Axis;192
15.4.2.1;11.4.2.1 Plant Model (HAxis);192
15.4.2.2;11.4.2.2 Control Requirements (HReq);193
15.4.3;11.4.3 Horizontal and Vertical Axis;195
15.4.3.1;11.4.3.1 Plant Model (HVInternal);195
15.4.3.2;11.4.3.2 Control Requirements (HVReq);195
15.4.4;11.4.4 User Interface;196
15.4.4.1;11.4.4.1 Plant Model (UI);196
15.4.4.2;11.4.4.2 Control Requirements (UIReq);197
15.5;11.5 Step B: Supervisor Generation;198
15.6;11.6 Step C: Untimed Simulation;198
15.7;11.7 Step H: Real-Time Control;199
15.8;11.8 Evaluation of Evolvability;200
15.9;11.9 Conclusions and Future Work;200
15.10;References;201
16;Chapter 12Creating High-Quality Behavioural Designsfor Software-Intensive Systems;202
16.1;12.1 Introduction;202
16.2;12.2 Problems with Natural Language Text in Behavioural Designs;204
16.3;12.3 Data-flow Diagrams: Input–Output Relation Between Actions;205
16.4;12.4 Control-flow Diagrams: Sequences of Action Executions;206
16.5;12.5 Consistency Between Data- and Control-flow Diagrams;208
16.6;12.6 Vibes Diagrams: Constraints on Action Executions;210
16.6.1;12.6.1 Behavioural Constraints that Prevent Race Conditions;211
16.6.2;12.6.2 Behavioural Constraints Derived from a Domain;213
16.6.3;12.6.3 Behavioural Constraints Derived from Quality Requirements;213
16.6.4;12.6.4 Consistency Between Vibes, Data- and Control-flow Diagrams;215
16.7;12.7 Summary;215
16.8;References;216
17;Chapter 13Verifying Runtime ReconfigurationRequirements on UML Models;217
17.1;13.1 Introduction;217
17.1.1;13.1.1 State of the Art in Reconfiguration Verification Tools;219
17.1.2;13.1.2 Our Solution: Simulation of UML Models;220
17.1.3;13.1.3 Reconfiguration Mechanisms and Running Example;220
17.2;13.2 Runtime Reconfiguration Mechanisms;221
17.3;13.3 Graph-Based Model Checking of Reconfiguration Requirements;223
17.3.1;13.3.1 Specialization of Graph-Based Model Checking;223
17.3.2;13.3.2 Simulation in Detail;223
17.3.3;13.3.3 Specification and Verification of Execution Sequences;225
17.3.4;13.3.4 Feedback Mechanism;227
17.4;13.4 Evaluation of the Approach;227
17.4.1;13.4.1 Case Study with the Designer from Industry;228
17.4.2;13.4.2 Experiment with Students;231
17.5;13.5 Conclusions;232
17.6;References;232
18;Chapter 14Scheduling in MRI Scans processing;234
18.1;14.1 Introduction;234
18.2;14.2 MRI Examinations with ExamCards Approach;235
18.3;14.3 Duty Cycle Limitations in MRI Systems;237
18.3.1;14.3.1 Specific Absorption Rate limitations;238
18.3.2;14.3.2 Temperature Limitations of Gradient Amplifiers;239
18.3.3;14.3.3 Temperature Limitations of Gradient Coils;239
18.3.4;14.3.4 Intermixing Segments of Scans;240
18.4;14.4 Evolvability Aspects;241
18.5;14.5 Problem Statement;242
18.5.1;14.5.1 SAR Specific Problem Statement;243
18.5.2;14.5.2 Gradient System Specific Problem Statement;244
18.6;14.6 Algorithms Overview for Solving the Scan Segments Intermixing Problem;245
18.7;14.7 Results;246
18.7.1;14.7.1 Results for SAR Limitations;246
18.7.2;14.7.2 Results for Gradient Temperature Limitations;248
18.8;14.8 Conclusions;249
18.9;References;250
19;Chapter 15Strategy-Focused Architecture Decision Making;251
19.1;15.1 Introduction;251
19.2;15.2 Methodology;253
19.3;15.3 Case Study: Independent Sensor Release;254
19.4;15.4 Strategy-Focused Architecture Decision Making;255
19.4.1;15.4.1 Step 1: Make Strategy Map and Identify Scorecards;255
19.4.2;15.4.2 Step 2: Propose Business-Distinct Architecture Scenarios;257
19.4.3;15.4.3 Step 3: Estimate scorecards;260
19.4.4;15.4.4 Step 4: Decide;262
19.5;15.5 StArch Evaluation;262
19.5.1;15.5.1 Evaluation of StArch Characteristics ;263
19.5.2;15.5.2 Evaluation of Possible Decision-Making Improvements;264
19.6;15.6 Conclusions;265
19.7;References;266
20;Chapter 16Balancing Time-to-Market and Qualityin Evolving Embedded Systems;267
20.1;16.1 Introduction;267
20.2;16.2 Software Challenges in the Medical Device Industry;269
20.2.1;16.2.1 Dealing with Challenges;270
20.3;16.3 The Basic Data;271
20.3.1;16.3.1 Usability of the Data;273
20.3.2;16.3.2 Characteristics of the Data;274
20.4;16.4 Rayleigh Model;276
20.5;16.5 Estimating Time-to-Market;277
20.6;16.6 Estimating Quality;279
20.6.1;16.6.1 Limitations of the Rayleigh Model;280
20.6.2;16.6.2 Monitoring Quality Level;281
20.7;16.7 Concluding Remarks;283
20.8;References;283
21;Chapter 17Industrial Impact and Lessons Learned;285
21.1;17.1 Introduction;285
21.2;17.2 Industrial Impact;287
21.2.1;17.2.1 Mining;287
21.2.2;17.2.2 Reference Architecture;289
21.2.3;17.2.3 Mechanisms;290
21.2.4;17.2.4 Economic Decision Making;291
21.3;17.3 Factors that Impact Research and Transfer;292
21.4;17.4 Lessons Learned on Industry-as-Laboratory;295
21.4.1;17.4.1 Project Activities;295
21.4.2;17.4.2 Diagnosing the Problem;297
21.4.3;17.4.3 Project Supervision and Management;298
21.4.4;17.4.4 Building a Research Team and Learning a Domain;299
21.4.5;17.4.5 Cross Disciplinary Research;300
21.4.6;17.4.6 Proof of Concept and Transfer Results;301
21.4.7;17.4.7 Consolidation, Dissemination and Writing;303
21.5;17.5 Summary;303
21.6;References;304
22;Chapter 18Conclusions;306
22.1;18.1 Collaborative Research;306
22.2;18.2 Researching Evolvability;307
22.2.1;18.2.1 Mining the Existing Realization;307
22.2.2;18.2.2 Reference Architecture;308
22.2.3;18.2.3 Mechanisms, Patterns, and Guidelines;309
22.2.4;18.2.4 Economic Decision Making;309
22.3;18.3 Wrapping Up;309
23;Annex;311
23.1;I Darwin Publications;311
23.2;II List of Darwin Partners;315
24;Index;316