Andrew P. Sage, Founding Editor
A complete list of the titles in this series appears at the end of this volume.
Copyright © 2016 by John Wiley & Sons, Inc. All rights reserved
OMG SysML, OMG Systems Modeling Language, UML, Unified Modeling Language, Model Driven Architecture, MDA, Business Motivation Model, BMM and XMI are trademarks or registered trademarks of the Object Management Group, Inc. in the United States, the European Union and other countries.
Cameo is a registered trademark of No Magic, Inc.
FAS is a registered trademark of oose Innovative Informatik eG in Germany.
SYSMOD is a registered trademark of Tim Weilkiens in Germany.
V-Modell is a registered trademark of Bundesrepublik Deutschland in Germany.
TOGAF® is a trademark of The Open Group.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada.
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, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
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. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Weilkiens, Tim.
Model-based system architecture / Tim Weilkiens, Jesko G. Lamm, Stephan Roth, Markus Walker.
pages cm. – (Wiley series in systems engineering and management)
Includes index.
ISBN 978-1-118-89364-7 (hardback)
1. System design. 2. Computer simulation. 3. SysML (Computer science) I. Lamm, Jesko G., 1976- II. Roth, Stephan, 1968- III. Walker, Markus, 1965- IV. Title. TA168.W4338 2016
620′.0042–dc23
2015024774
Contrary to popular myth, models are not new to systems engineering. Models are the way engineers analyze both problems and solutions, so systems models are as old as systems engineering itself. With the traditional focus on written specifications as the “source of truth,” models were secondary and descriptive – sometimes reflected as simple sketches, sometimes shown in formal diagrams, partially captured in analysis packages, and often trapped in the mind of the chief engineer. The transformation of systems engineering from document-centric to model-centric practices is not about the introduction of models. It is about making models explicit and moving them to the foreground where they serve as the authoritative tool for design, analysis, communication, and system specification.
Organizations today are investing heavily in representations, standards, methodologies, and technologies to transform the practice of systems engineering through model-driven paradigms. To manage the complexity of today's problems; to keep pace with today's rapidly evolving technologies; to capture the required knowledge regarding the problem, solution, and rationale; to respond effectively to change – all require that systems engineering join the other engineering disciplines in moving beyond document-centric techniques and embracing the power of a model-based foundation. With energy and focus over the last ten years has come notable progress. The industry has advanced in the area of representations with the development of SysML as a standardized set of diagrams to complement traditional systems representations. Numerous books – including a frequently cited guide by Tim Weilkiens – explain the details of using this notation to capture and communicate system designs to improve explicitness and alignment within the systems team. Alongside these representations have emerged countless standards and frameworks to help engineering teams develop high-fidelity models reflecting key systems dimensions.
However, for all the industry discussion regarding SysML, representations, standards, and tools, there remains a great deal of confusion. Understanding SysML notation and drawing SysML diagrams do not equate to doing model-based systems engineering. The use of disjoint models and simulation in systems engineering is also not equivalent to integrated model-based systems engineering.
Effectively moving forward with the transition to model-centric techniques requires that we step back to understand the bigger picture. Diagrams and other representations do not live in isolation but are interrelated and overlapping, communicating key aspects of the system model from specific viewpoints. System architecture and detailed analytical models are not disjoint, nor is there a single grand unified model to capture all dimensions of interest for all systems problems. To move forward, we must embrace the holistic systems perspective and apply it to model-based systems engineering, seeking out the interrelationships and developing a robust toolbox of supporting practices.
In this book, Tim Weilkiens, Jesko Lamm, Stephan Roth, and Markus Walker broaden our vision and expose us to a rich set of perspectives, processes, and methods so that we can develop an effective unified framework for model-based systems architecture. Building upon the existing industry library of textbooks on SysML, this book looks beyond the representation to address models, viewpoints, and views as part of a modern approach addressing requirements, behavior, architecture, and more. It connects to a larger framework of processes, methods, and tools key to enabling model-centric practices. And it looks beyond the technical space to the critical cultural dimensions because the transformation to model-centric techniques is far less a technical challenge than one of organizational change. Addressing the broader framework, Tim, Jesko, Stephan, and Markus bring model-centric practices together to help practitioners develop cohesive system architectures – our one chance in the life of a program to manage complexity, develop resilience, and design in critical concerns such as system security.
There is no doubt that the future of systems engineering is model-based. Document-centric techniques simply are not enough as we grapple with the challenges of today and tomorrow. Those practitioners and organizations who are early adopters in developing a cohesive model-centric framework of processes, methods, and tools will certainly be at a competitive advantage – whether producing products themselves or delivering systems services for others. If, as a profession, we can transform from document-centric to model-based systems engineering and do so with the vision of enabling model-based engineering, we can help transform the larger product lifecycle delivering radical improvements in quality, cost, and time to market for the benefit of all.
David Long
President, Vitech Corporation
INCOSE President (2014 and 2015)
Reacting to market needs on time with systems of high quality and marketable costs is a strong competitive advantage. Once a market need has been identified, multiple disciplines are involved in developing a system toward it. They need to collaborate closely and each according to a precise understanding of the own contribution to the system development. Effective communication and the creation of understanding for the whole system of interest are keys for the success. Organizations are facing a more and more dynamic environment, and at the same time, an increasing organizational complexity of distributed teams and stakeholders, and an increasing technical complexity of more heterogeneous relationships between system components and their environment. This context requests an explicit and sustainable system architecture.
Each of the engineering disciplines contributing to system development needs specific views for obtaining the needed insight. System models enable the creation of consistent sets of stakeholder-specific views. People using them gain a fast and comprehensible understanding of the system they are developing, which can help them choose appropriate solutions for fulfilling the market needs. All the views look on the same data baseline. There is no effort to consolidate redundant data or to clarify misunderstandings of inconsistent information and the costs of resulted errors.
A system architect needs to shape the system architecture well for realizing a successful system. Multiple tasks have to be carried out, each using an effective approach. This book provides a toolbox for the architect for his daily challenges. The scope of the book is a model-based environment, either it is already established and running or planned. The book explains how to use the SysML modeling language in obtaining model-based architecture descriptions. Nevertheless, the concepts are independent of SysML and could also be performed with other modeling languages.
This book is about people, models, and better products, based on our belief that model-based systems architecting produces better products by creating communication and insight for people involved in system development. The book presents a collection of methods and approaches which we see as ingredients for getting the system architecture work done successfully. We present model-based system architecting, which we see as a required backbone for excellent systems architecture work together with the stakeholders. We will show that involving the stakeholders means much more than running through a formalized review process.
A fundamental principle in system architecture is simplification. Without simple concepts to be communicated to the stakeholders, the system architect will not be understood and thus will fail. We advise you, dear reader, to adopt the principle of simplification and apply it to the multitude of approaches presented in the book. Feel free to only choose the approaches that are most suitable for your daily work and disregard the others, until you are in a situation where they turn out to be useful. The book is a well-stocked toolbox and not a rigid all-or-nothing process for system architects.
Our experience tells us that each organization will have a different focus area and will need different approaches. This is why we have bundled a variety of approaches we have observed being applied successfully in the industry, in the hope that you will find some pieces of information that are suitable exactly to your current activities. We have selected those approaches that we find easy to apply in daily work and are important for common model-based system architectures. We do not claim to provide a complete set. Every system architect loves to go to a hardware store to extend her toolbox. And from time to time, she has to discard one of her tools when it is no longer appropriate.
The book addresses system architects and their managers as well as engineers who are involved or interested in systems architecting. It is the first comprehensive book that combines the emergent discipline systems architecting with model-based approaches with SysML and puts together puzzle pieces to a complete picture. Highlighted puzzle pieces are
As a typical reader of this book, you may have no time to read all chapters in sequential order. Therefore, we have made the chapters as independent from each other as we could, in order to enable you to read them individually or out of a dedicated sequence when you like inspiration about a certain topic. You can find on-demand reference about particular topics and get inspiration for directly using the presented approaches in your daily business. The topics are demonstrated using a fictitious robot-based solution for virtual museum visits as an example system.
We like to write texts using gender-fair language. On the other hand, we avoid to clutter the flow of reading by using always both genders in the same sentence. Therefore, we have only used one gender where it was not appropriate to use gender-neutral language. Feel free to replace he by she and she by he wherever it is appropriate.
We like to thank the “FAS” and “MkS” working groups of GfSE, the German chapter of INCOSE. The work in these groups has provided us with new ideas that can now be found in this book. We thank NoMagic for their support in working with the Cameo tool family that we used to create the SysML models and diagrams we used in multiple chapters of this book. We also thank Erik Solda for allowing us to use the robot example, Martin Ruch for contributing ideas about the assessment of organizational interfaces and all the colleagues at works, who have influenced our way of thinking, helped us with foreign languages in both reading and writing or recommended literature that is today part of the foundations of this book. We furthermore thank numerous people who provided us with advice after we had shown or explained them little fragments of this book to hear a second opinion.
We like to thank all the supporters of MBSE who believe that MBSE enables the successful development of complex systems. In particular, David Long, who is a great expert of MBSE from the very beginning and has written the foreword.
Finally, we like to thank Brett Kurzman, editor at Wiley, his assistants Alex Castro and Kathleen Pagliaro, and Bhargavi Natarajan for their support.
Tim Weilkiens,
Jesko G. Lamm,
Stephan Roth,
Markus Walker
Contributor
Matthias DÄnzer,
Bernafon AG
February 2015
This book is accompanied by a companion website:
The website includes:
Model-based system architecture (MBSA) combines the two key technologies: model-based and system architecting. Both are major parts of the future state of systems engineering [57].
Many systems result from an evolutionary development. They are driven by their parts and do not emerge from the architecture. The parts could be anything that in combination are assembled to a man-made technical system. System architecture is exhibited by a complete system. Often system architecture is referred to the architecture from the perspective of a software architecture in combination with the hardware or the architecture of software-intensive systems [20]. We understand system architecture is more holistic and also consider systems without any software. Although systems without any software that are handled with systems engineering processes and model-based system architecture concepts like described in this book are very rare, a system architecture is always present. In today's and future systems engineering, it is crucial to apply explicit system architecting for the success of the system project [57]. Chapter 4 defines the term system architecture within its context.
Studies clearly show that system architecting is critical for the performance and success of the system [34]. This is particularly evident for projects that require significant architectural work or rework. Due to more and more dynamic and complex markets and environments, the system architecture must more and more withstand the changing requirements and requests for radical changes. Chapter 3 lists the benefits of system architecting.
System architecture is about establishing solutions that are checked for feasibility by the corresponding experts, about designing interfaces that are agreed from both sides, and about ensuring that the people who should know the architecture of a system have a common understanding of it. MBSA uses models for enabling the creation of healthy communication around the architecture of the system and for ensuring that the architecture is validated from different points of view. Models are a key tool to be capable of developing complex systems on time and in a feasible quality. Chapter 5 defines the term model and MBSA and discusses the related terms.
Models are more than graphics. There are even models without any graphical representations. Just the graphics is not modeling, but drawing. To create a model you need semantics, which you find in a modeling language. We use the international standard Systems Modeling Language (SysML) as language for the system requirements and architecture models. Appendix A gives an overview about SysML. Although we extensively use SysML in this book, our methods and concepts are independent on SysML and could also be implemented by other modeling languages.
The system architect is the one in charge of shaping the system architecture. This is a big responsibility and a big challenge. The organizations dependent on the system should carefully select the people who are allowed to architect the system—and these people's work results will be tightly monitored by stakeholders everywhere in the organization. Chapter 19 describes how system architecting could be embedded in an organization and Chapter 10 discusses the interfaces to the stakeholders of system architecting. In particular Chapter 8 introduces the adjacent discipline requirements engineering that closely collaborates with the system architecting. The SYSMOD zigzag pattern presented in Chapter 7 shows the relationship between requirements and architecture and clearly demonstrates the need for a close collaboration. Artifacts of the model-based requirements and use case analysis are important inputs for the system architects especially to elaborate a functional architecture using the so-called FAS method.
Chapter 14 is a comprehensive presentation of the Functional Architectures for Systems (FAS) method. Functional architectures are built of functions only and are independent of the physical components that implement the functions. The functional architecture is more stable than a physical architecture that depends on the steadily changing technologies. The architecture principle to separate stable from unstable parts is covered in Chapter 7 about architecture patterns and principles.
Besides the functional architecture we define and discuss further system architecture kinds: the base architecture that fixes the preset technologies and adjusts the scope for innovation, the logical architecture that specifies the technical concepts and principles, and the product architecture that finally specifies the concrete system. All three architecture kinds are physical architectures. The layered architecture is an orthogonal aspect to these architecture kinds and is presented in Chapter 9.
Another orthogonal aspect is the modeling of variants. Variability is increasingly important. The markets are no longer satisfied by commodity products. The market requests customized products that fit to personal demands of the customers. In addition, global markets with different local environments and policies require different configurations of a system. Chapter 15 presents a model-based concept to specify different product configurations.
The architecture concepts are presented with a consistent example system. The “Virtual Museum Tour” system provides virtual visits by driving with camera-equipped robots through a real museum. The system is easy to understand and at the same time is sufficiently complex to demonstrate the system architecting concepts. The system is introduced in Chapter 2.
The system architect who thinks that his job is to make a diagram and save it on a shared network drive will most probably fail. Same for the system architects who think they are the bosses of the development staff and can instruct the other engineers. It is neither an archeological job nor a chief instructor job. System architecting is a collaborative work that requires communication and soft skills. The basics for a good communication is a common language and media to transport the information. Chapter 6 covers the artifacts of the architecture documentations. In Chapter 16, we extend our scope to system of systems and architecture frameworks.
Typically, engineers are focused on the technology challenges of their job. Nowadays, communication and more general soft skills are getting more and more important capabilities. The engineering disciplines are growing together. For instance, that could be seen by the modern discipline mechatronic. And the worldwide mankind is growing together due to the Internet, other communication, and transportation technologies. In consequence, an engineer has an increasing number of communication relationships. She is no longer successful when she only manages her technology tasks. It is also important to collaborate well with team members, stakeholders, communities, and so on. Chapter 20 gives an introduction about soft skills for engineers.
We need an example system for the demonstration of various techniques to be presented in this book. The example of our choice is based on robotics work that one of us (Jesko G. Lamm) started doing as a leisure activity during his time at university, together with his fellow student Erik Solda who had the initial idea. During the course of this work, different robots were built. One of them is shown in Figure 2.1. It is the one that inspired the authors of this book in developing a fictitious example system to be presented in the following.
Figure 2.1 One of the robots that was built during the robotics work by J.G. Lamm and E. Solda. © 2007, 2014 Jesko G. Lamm, reproduced with permission.
For this book, we thought of a robot according to Figure 2.2. The robot would drive through a museum. A live video stream from a camera on the robot would be broadcasted. People with access to the live video stream could thus see the exposition, even when the museum is closed.
Figure 2.2 The fictitious museum robot with the purpose of enabling virtual museum tours.
When we had completed the first chapters of this book based on this example system, we noticed that we were not the only ones who had this idea: an organization called “The Workers” actually had this idea prior to us and invented a museum robot system that is called “After Dark”, because it is intended to run during the night when the museum is closed and dark. The Workers' idea of the After Dark system won the so-called “IK Prize”—including a budget that allowed them to actually build the system and offer the first virtual tour through the gallery Tate Britain on August 13, 2014 [74].
The After Dark system came to our attention quite late during the process of writing this book. Therefore, the system we use as an example here is mainly based on our own imagination and may thus be quite different from the After Dark system, for example, regarding its architecture. Still, the After Dark system has become an important source of inspiration after Tate's press release about it [17] had been discovered by one of the authors.
In our fictitious system according to Figure 2.2, one user can log in for controlling the robot via a web application on a computer or a hand-held device, like a smart phone. Multiple users can watch the video stream from the camera via a web application. The camera can zoom and move up and down. Roughly speaking, the system-of-interest is composed of the robot itself together with the infrastructure and remote control software that is needed to operate it. We call this system the “Virtual Museum Tour system (VMT)”. Chapter 9 will provide example architecture descriptions that provide a more precise definition of the system.
A little story may help understanding the capabilities of the example system: Currently, John is controlling a museum robot to drive it through a museum of arts. He has to write a report about modern art as a homework for school, and he has not had time to go to the museum during its opening hours. John types “Andy Warhol” on his smart phone and the robot starts driving to the pop arts division of the museum. Once there, it stops in the middle of a room. John now selects a painting showing a soup can. The robot moves toward the painting and stops in front of it. The camera on the robot now transmits a picture of the painting to John's smart phone. A little notification box on the smart phone displays the title of the painting. John needs to analyze the artist's way of working in more detail. Via commands entered on his smart phone, he moves the camera down. Then he zooms in on a particular area of the painting. Now he can see the necessary details via the video stream on his smart phone. This enables John to complete his homework for school.