Views on Evolvability of Embedded Systems (eBook)

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.

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