Foundations for Model-based Systems Engineering: From Patterns to Models
2: Scarecrow Consultants Ltd, UK
3: Atkins, UK
The practice of Model-based Systems Engineering is becoming more widely adopted in industry, academia and commerce and, as the use of modelling matures in the real world, so the need for more guidance on how to model effectively and efficiently becomes more prominent. This book describes a number of systems-level 'patterns' (pre-defined, reusable sets of views) that may be applied using the systems modelling language SysML for the development of any number of different applications and as the foundations for a system model. Topics covered include: what is a pattern? Interface definition pattern; traceability pattern; test pattern; epoch pattern; life cycle pattern; evidence pattern; description pattern; context pattern; analysis pattern; model maturity pattern; requirements modelling; expanded requirements modelling; process modelling; competence modelling; life cycle modelling; defining patterns; and using patterns for model assessment, model definition and for model retro-fitting. This book forms a companion volume to both 'SysML for Systems Engineering - a model-based approach' and 'Model-based Requirements Engineering', both published by the IET. Whereas the previous volumes presented the case for modelling and provided an in-depth overview of SysML, this book focusses on a set of 'patterns' as the basis of an MBSE model and their use in today's systems engineering community.
Inspec keywords: ontologies (artificial intelligence); systems engineering
Other keywords: PaDRE process; pattern definition and realisation process; model-based systems engineering; MBSE ontology; MBSE patterns
Subjects: General and management topics; Software engineering techniques; Knowledge engineering techniques
- Book DOI: 10.1049/PBPC014E
- Chapter DOI: 10.1049/PBPC014E
- ISBN: 9781785610509
- e-ISBN: 9781785610516
- Page count: 418
- Format: PDF
-
Front Matter
- + Show details - Hide details
-
p.
(1)
-
Part I: Introduction and approach
1 Introduction
- + Show details - Hide details
-
p.
3
–9
(7)
This book discusses the use of MBSE patterns that can be used to enhance and augment existing MBSE approaches.
2 Approach
- + Show details - Hide details
-
p.
11
–18
(8)
Systems Engineering defines an approach for realising successful Systems (INCOSE, 2014). Model-based Systems Engineering provides an approach for using Models to realise the artefacts of a System based on a set of modelling Views (Holt and Perry, 2013). This section introduces the main concepts that comprise the MBSE Metamodel that will be used throughout this book. The first step is to define exactly what we mean when we refer to `Systems' and `Models'.
3 What is a Pattern?
- + Show details - Hide details
-
p.
19
–27
(9)
This chapter defines what we mean by a Pattern and gives a (very) brief history of the use of Patterns in software and systems engineering. This is followed by a discussion of the key questions that must be considered when defining a Pattern. In order to address these questions the Framework for Architectural Frameworks (FAF) is introduced. The use of the FAF in the definition of Patterns leads naturally to a generic structure for the description of Patterns. This structure is introduced and will be used for all the Pattern definitions in Part II of the book.
-
Part II: The fundamental enabling Patterns
4 Interface Definition Pattern
- + Show details - Hide details
-
p.
31
–54
(24)
The Interface Definition Pattern provides three viewpoints that enable the identification and definition of interfaces to be specified in terms of the structural aspects of the interfaces: the Interface Identification Viewpoint identifies each Interface, the Interface Connectivity Viewpoint shows the connection between Interfaces and the Interface Definition Viewpoint defines what is transferred across each Interface. The Pattern also provides two Viewpoints that enable the behaviour of Interfaces to be specified: the Interface Behaviour Viewpoint identifies typical scenarios showing how Interfaces are used and the Protocol Definition Viewpoint defines any Protocols to which Interfaces or Ports must conform. When using the Interface Definition Pattern, as a minimum at least one ICV and one IDV are needed to specify Interfaces, their associated Ports and the connections between them. Where the information on the IIVs is not a subset of that on the ICVs, then at least one IIV must also be produced. In practice, however, multiple IIVs, ICVs and IDVs would be produced along with Interface Behaviour View and, where necessary, Protocol Definition Views. Note here the use of View rather than Viewpoint. When using the Interface Definition Pattern, Views are created that conform to the Viewpoints.
5 Traceability Pattern
- + Show details - Hide details
-
p.
55
–77
(23)
The Traceability Pattern defines four Viewpoints that allow aspects of traceability to be captured. The Relationship Identification Viewpoint defines the possible types of traceability relationships that may be used. The Traceability Identification Viewpoint defines the types of model elements that can be the sources and targets of traceability and the relationships (from the Relationship Identification Viewpoint) that can hold between them. The Traceability Viewpoint shows the actual traceability relationships that hold between model elements that conform to the allowed types for traceability (as defined on the Traceability Identification Viewpoint). Finally, the Impact Viewpoint allows a traceability impact tree to be produced for a selected root model element, aiding in the identification of those model elements that may be impacted by changes to the selected root element.
6 Test Pattern
- + Show details - Hide details
-
p.
79
–102
(24)
The Testing Pattern provides a template for testing that can be applied to almost any aspect of a System Model. This Pattern may also be used as a basis for automating the tests using modelbased testing techniques using an MBSE tool. This Pattern also lends itself to non-SysML modelling such as the use of formal methods and simulation techniques.
7 Epoch Pattern
- + Show details - Hide details
-
p.
103
–120
(18)
This section has introduced and defined the set of Viewpoints that that make up the Epoch Pattern. The Epoch Pattern allows modellers to define a set of Measures and Metrics that may then be applied to a Model, or sub-set of a Model. It should be noted that the Epoch Pattern provides a mechanism that allows modellers to define Measures and Metrics, but the pattern itself does not define any Metrics or Measures. The pattern itself is purely definitional in nature. An example set of Metrics is shown here based on previous work on applying Metrics and Measures to Models. The main aims of this Pattern are shown in the Architectural Framework Context View (AFCV) in Figure 7.1.
8 Life Cycle Pattern
- + Show details - Hide details
-
p.
121
–138
(18)
The Life Cycle Pattern defines four Viewpoints that allow the aspects of a System's Life Cycle to be captured. The Life Cycle Viewpoint identifies the Stages that exists in a Life Cycle. The Life Cycle Model Viewpoint describes how each Stage behaves over time in relation to the other Stages. The Interaction Identification Viewpoint identifies the Life Cycle Interaction Points between a number of Life Cycles. Finally, the Interaction Behaviour Viewpoint describes the behaviour of each Life Cycle Interaction Point in relation to other Life Cycle Interaction Points as identified in an Interaction Identification Viewpoint. The Life Cycle Model Viewpoint presented here is the minimal version of the Viewpoint - it can be extended to show the Process Execution Groups that are executed in each Stage of a Life Cycle Model as well as the processes executed within each Process Execution Group. This allows the use of the Life Cycle Pattern to bridge the gap often found in Systems Engineering between the defined Systems Engineering processes followed by the systems engineers developing a System and the project plans produced by project managers tasked with managing the development of the System. For a full discussion of this, see Holt and Perry (2013).
9 Evidence Pattern
- + Show details - Hide details
-
p.
139
–154
(16)
The Evidence Pattern defines four Viewpoints for the definition of Evidence-Argument-Claim chains. The Claim Definition Viewpoint allows Claims to be defined for a particular Subject to show who made the Claims. The Argument Viewpoint allows the Arguments that support a Claim to be identified. The Evidence Viewpoint allows any supporting Evidence that reinforces Arguments to be identified. Finally, the Counter-Claim Viewpoint allows Counter-Claims (or supporting Claims) to be made about any type of Claimable Item.
10 Description Pattern
- + Show details - Hide details
-
p.
155
–166
(12)
The Description Pattern defines two Viewpoints for the description of Elements. The Element Structure Viewpoint is used to describe an Element in term of its Properties and Behaviours, relationship to other Elements (including relationships in a type taxonomy) and breakdown into parts. The Element Description Viewpoint is used to show extended Element Descriptions for an Element; this can also be used to support “localisation”of an Element, where consistent descriptions in multiple languages are needed.
11 Context Pattern
- + Show details - Hide details
-
p.
167
–176
(10)
The Context Pattern defines two Viewpoints that allow aspects of context to be captured. The Context Definition Viewpoint defines the contexts to be considered and the CDVp defines the Focus, Boundary and Environmental elements. The Context enables a focal aspect related to a system to be considered and is key to ensuring work to be carried out can be understood and bounded.
12 Analysis Pattern
- + Show details - Hide details
-
p.
177
–192
(16)
The Analysis Pattern defines four Viewpoints that allow aspects of analysis to be captured. The Issue Identification Viewpoint captures the issues to be considered, the Risk Definition Viewpoint defines the risk associated with the issues, the Analysis Viewpoint provides the analysis of risks considered worthy of analysing and finally the Feedback Viewpoint provides recommendations based on the results of the analysis. It is key to ensure that although experts may be used to carry out analysis and that their expertise can also be used to make decisions that these two aspects are not conflated. Analysis provides an understanding of a system associated with a set of recommendations to improve the system. The `Recommendation' allows an expert to interpret the `Result' of the `Analysis' and provide a focused response from their point of view, this of course may result in different `Recommendation' from different experts for the same analysis which in themselves will have to be balanced out. The key here is not to fall into the trap of paralysis by Analysis.
13 Model Maturity Pattern
- + Show details - Hide details
-
p.
193
–208
(16)
The Model Maturity Pattern provides a mechanism for assessing the maturity of a Model. This assessment may be applied to a whole Model or a specific set of Views that comprise part of the Model. The Pattern defines four Viewpoints which allow the specification of the Maturity Levels, Factors, Indicators and their associated States. The resulting Views are relatively simple being represented by block diagrams and a bar chart. This Pattern provides a useful and powerful input to MBSE Project Management activities. When combined with the Epoch Pattern that can be used to define baselines, this Pattern enables the evolution of the Model over time to be plotted. The Maturity Level Views also provide a good input into risk assessment activities for the management of the project.
-
Part III: Applications of the Patterns
14 Requirements Modelling
- + Show details - Hide details
-
p.
211
–217
(7)
This chapter discusses a Framework for Requirements modelling and shows the enabling Patterns that exist within the Framework. The Approach to Context-based Requirements Engineering (ACRE) Framework has been in use since its early incarnations as far back as 2001 (Holt, 2001) and has, over the years, been extensively published including a complete book describing the approach (Holt et al., 2011; Holt and Perry, 2013). The Framework itself has evolved since its first applications and has been used widely in industry, academia and government for many years.
15 Expanded requirements modelling - SoSACRE
- + Show details - Hide details
-
p.
219
–224
(6)
This chapter discusses the SoSACRE Framework for modelling requirements for Systems of Systems. This Framework is an extension of the ACRE Framework that was described in the previous chapter. The SoSACRE Framework allows the context of both Systems of Systems and their associated Constituent Systems and allows them to be analysed in terms of consistency between them. The SoSACRE Framework also extends the Validation Views so that they encompass Systems of Systems. The SoSACRE was developed in 2011 and has been in use ever since on a variety of industry projects.
16 Process Modelling
- + Show details - Hide details
-
p.
225
–230
(6)
This chapter discusses the “seven views” Framework for Process modelling and shows the enabling Patterns that exist within the Framework. The “seven views”Framework has been in use since 1999 and was first specified in 2004. The Framework itself has evolved since its first applications and has been used widely in industry, academia and government for many years. The existence of the “seven views”Framework pre-dates the patterns presented in this book, but was used as one of the source to identify and define a number of patterns.
17 Competence Modelling
- + Show details - Hide details
-
p.
231
–237
(7)
This chapter discusses an approach for competency modelling and assessment, known as the Universal Approach to Competence Assessment and Modelling (UCAM). The UCAM Framework has been in use since 2009 and was first formally published in 2011 (Holt and Perry, 2011) and has been expanded upon since (Holt and Perry, 2013). The Framework itself has evolved since its first applications and has been used widely in industry, academia and government for many years. The existence of the UCAM Framework pre-dates the patterns presented in this book, but was used as one of the source to identify and define a number of patterns.
18 Life Cycle Modelling
- + Show details - Hide details
-
p.
239
–244
(6)
The Life Cycle Framework has clear and obvious links to the Life Cycle Pattern, as one would expect. The Framework also shows, however, how baselines may be defined for the Model based on the Life Cycle. The use of the Epoch Pattern here to establish baselines is a simple, yet powerful, addition to the Framework. Note that not all of the Epoch Pattern Viewpoints are used, as there is no measurement taking place in this example. Of course, it is perfectly possible to include the missing Viewpoints from the Epoch Pattern depending on the underlying need.
-
Part IV: Using the MBSE Patterns
19 Defining Patterns
- + Show details - Hide details
-
p.
247
–271
(25)
Like all aspects of model-based systems engineering, successful pattern definition takes practice. However, the pattern definer is not alone. This chapter will discuss the practice of pattern definition, and will provide the novice pattern definer with useful guidance on the practice of pattern definition After a brief recapitulation of the Framework for Architectural Frameworks (FAF) in the next section, an in-depth discussion of pattern definition follows in Section 19.3. This attempts to show some of the thought processes involved and issues that have to be covered when defining a pattern. This is done using the Description Pattern from Chapter 10 as an example. Section 19.4 then turns to the importance of how Viewpoints are realised, discussing the importance of and giving guidance on examples in pattern definition. The chapter concludes with a summary and references.
20 Using Patterns for model assessment
- + Show details - Hide details
-
p.
273
–286
(14)
Patterns can be used in many ways, one of these is as an assessment tool considering the extent of existing Frameworks. This chapter will discuss the practice of model assessment by applying a simple set of metrics to different aspects of a Framework. This chapter will provide two example assessments before describing the application of the Epoch Pattern which has been used to carry them out. The examples are not defined using the FAF as this is likely to make the assessment too easy to deliver and will not show the benefit of applying assessments to any model. The examples will take an existing ontology from a partially defined Framework and a set of Viewpoints from another partial Framework. In each assessment a number of Patterns from Part 2 will be selected and compared with the example model, the results of this comparative assessment and discussion of the meaning and effect will follow.
21 Using Patterns for model definition
- + Show details - Hide details
-
p.
287
–313
(27)
Model-based Systems Engineering best practice advises the use of an Architectural Framework (AF) when developing a model of a System.
22 Using Patterns for model retro-fitting
- + Show details - Hide details
-
p.
315
–324
(10)
Whatever the day, week or year there will be models and designs which haven't been defined or formalised using an Architecture Framework (AF). We know that Model-based Systems Engineering best practice advises the use of an AF when developing a model of a System - but this doesn't mean it will always happen. Where organisations or industries don't have the necessary experience or maturity to carry out MBSE properly, all too often models will be developed without a Framework to guide them. In some cases these models maybe no more than unconnected representations and pictures which are described as “The design.”Even in cases where AFs are used in new projects, people often cite issues such as the AF stifling thinking or the level of rigour and rules, meaning people spend more time on thinking about the AF rather than the design. In these situations we need to find ways to bring the value of the AF without the pain which is perceived. This chapter discusses examples of these situations, focusing on how to take unconnected/uncontrolled pictures and bringing them together using Patterns, it also addresses pragmatic ways to approach this for those who want an unconstrained approach but recognise they need a formalised output.
-
Part V: Annex
Summary of SysML notation
- + Show details - Hide details
-
p.
327
–345
(19)
Summary of the Framework for Architectural Frameworks
- + Show details - Hide details
-
p.
347
–366
(20)
MBSE Ontology and glossary
- + Show details - Hide details
-
p.
367
–373
(7)
The 'Pattern Definition and Realisation (PaDRe)' Processes
- + Show details - Hide details
-
p.
375
–385
(11)
-
Back Matter
- + Show details - Hide details
-
p.
(1)