How to define interface patterns in model-based system engineering Indraja Elžbieta Germanaitė Prof. dr. Rimantas Butleris Department of Information Systems Centre of Information Systems Design Technology Kaunas University of Technology Kaunas University of Technology Kaunas, Lithuania Kaunas, Lithuania e-mail: indraja.germanaite@ktu.lt e-mail: rimantas.butleris@ktu.lt Abstract–The Patterns help system engineers to create efficient and more consistent System Models faster. Thus the II. WHAT IS THE PATTERN IN MBSE? methodology of quickly defining and describing the Patterns are John Holt et al. give the full picture of what is the MBSE needed. The review of the existing methodology of defining Pattern and describe the main terms that are used for defining Interface Patterns is done in this article. As a result, the need for and describing the Patterns in their book [4]. The Model the new or more detailed ideas concerning the methodologies and abstracts the System and is made of one or more Views that are implementations of the Patterns use could be identified. the fundamental building blocks of the Model. The View uses a Keywords–Model-based System Engineering; MBSE Pattern; Systems Modeling Language (SysML) diagram as a MBSE Framework; FAF; Viewpoint; SysML representation, and is made of the View Elements that in turn use SysML elements as a representation. The View is the I. INTRODUCTION realization of a Viewpoint and the end product of the Pattern. The MBSE Framework provides the basis for the structure of The discipline and practice of Model-based System the Model and defines a number of Viewpoints. The Viewpoint Engineering (MBSE) follows the main concepts of the Systems is a template for the Pattern that forms the basis for the View. Engineering discipline. The Systems Engineering covers a In turn, the Viewpoint element is a template for the View wide range of fundamental concepts such as system thinking, Element. The Ontology is made up of one or more Ontology system science, life cycle management, system of systems, and Elements that define the content of the Viewpoint. The main agile and iterative methods [1]. System thinking captures and entities that participate in Pattern definition and relationships exploits what is common in a set of problems and between those entities are shown in Figure 1. corresponding solutions in the forms of various types. Thus, a pattern is a representation of similarities in a set of problems, solutions, or systems [1]. As already known from the object-oriented programming practice, the design patterns facilitate the reusing of successful designs and architectures, expressing proven techniques as patterns and making them more accessible to developers of new systems [2]. Patterns help to choose design alternatives that make a system reusable, to avoid alternatives that compromise reusability, and to improve the documentation and maintenance of the existing systems [2]. The patterns help the designer (or the system engineer) get the design (or the architecture) “right” faster. The term “pattern” appears repeatedly in the history of Fig. 1. The relationship between the System, the Model, The Framework, design, such as civil architecture, software design, and systems the Ontology, and the Pattern (taken and modified from [4]). engineering [3]. In the MBSE context, a pattern could mean the whole framework that covers entire systems and is used as a re- John Holt et al. [4] explain that a Pattern is a special type of usable, configurable model of whole domains or platform the Framework and is made up of one or more Viewpoints, systems - whether formal platform management is already each of which comprises one or more Viewpoint Elements. The recognized or not - or only as smaller-scale element design Viewpoint and Viewpoint elements are based on the Ontology, patterns within them [3]. The aim of this article is to look into providing consistency with the rest of the Model. The main the methodology of defining and describing subsystem or difference between a Framework and a Pattern is that a component patterns. In this case, the review of Pattern-Based Framework has a single purpose and single application, while a Systems Engineering methodology based on S*Models and pattern has a single purpose but multiple applications. For S*Patterns and dedicated to the complex systems is not in the example, the Interface Pattern may be used as part of several scope of this article. Frameworks, at different level of abstractions, and in different Copyright © 2017 held by the authors 54 aspects of the Model [4]. Thus, the Pattern uses a template IV. THE “INTERFACE DEFINITION PATTERN” EXAMPLE itself – the Viewpoint - and also serves as a template for the John Holt et al. give many examples of MBSE Patterns View. In addition, the Pattern could be understood as a defined according to the FAF method in their book [4]. One of Framework, but the Framework may also use many different the most common examples is the “Interface Definition Patterns for different purposes. So, the intent is to create an Pattern” chosen to illustrate MBSE Pattern definition in this initial 'ontology' of high-level Pattern descriptions that provide article because it can be used in both software and hardware a framework within which Pattern relationships can be systems. More than that, interfaces form an integral part of any discussed [5]. systems model and define a contract between system elements, whether those elements are physical or are realized in software III. DEFINING PATTERNS [4]. Thus, the key aim of the Interfaces Pattern is the Going deeper into the definition of a Pattern, John Holt et identification of interfaces and their relation to the system al. [4] declare that the approach used to define each Pattern is elements that use them and the ports that expose them [4]. the same as the approach used to define the Framework, and According to the FAF method for describing the “Interface uses Framework for Architecture Frameworks (FAF). The FAF Definition Pattern”, the main aims of the “Interface Definition was defined to address the key questions through the MBSE Pattern” should be defined first. These aims are shown in the approach based around the ideas of Ontology, Viewpoints, and Architectural Framework Context View in the form of SysML Framework, and consists of the Ontology, six Viewpoints, and Use Case Diagram in Figure 2. supporting processes [4]. The six Viewpoints directly address one of the six key questions that should be considered in order to approach the Pattern definition in a consistent and repeatable way [4]. These key questions with the attached FAF Viewpoints and Views are shown in Table I. It should also be noted that the Views may be visualized using any notation, text, tables, or formal techniques, and in any way that is appropriate [4]. The SysML is selected as the MBSE Pattern- defining language that is important and useful for its graphical notation. TABLE I. FAF KEY QUESTIONS (TAKEN AND MODIFIED FROM [4]) Key question FAF View Is derived SysML Viewpoint from diagram Fig. 2. Architectural Framework Context View (taken from [4]). used to used answer Second, the main concepts covered by the “Interface What is the Architectur Architectural Use Case Definition Pattern” should be defined in the Ontology purpose of the al Framework Diagram Definition View in the form of the SysML Block Definition Pattern? Framework Context Diagram. John Holt et al. define the main Interface Pattern Context View Viewpoint concepts in their book [4]: an Interface has a Direction, which What concepts Ontology Ontology Architectura Block may take the values “in”, “out”, and “inout”. The Direction must the Pattern Definition Definition l Framework Definitio property shows the direction in which the Interface operates support? Viewpoint View Context n from the point of view of the Port, owned by a System View Diagram Element, which exposes the Interface [4]. Each Interface is What different Viewpoint Viewpoint Ontology Block ways of Relationshi Relationship Definition Definitio described by an Interface Definition that defines the operations considering the ps s View View n of a Service-Based Interface and the items transferred by a identified Viewpoint Diagram Flow-Based Interface [4]. A Port represents the interaction concepts are points between one or more System Elements and may required to fully represent the concept of a software Port or a physical Port, such understand as the connector for the fuel line on a car engine fuel pump [4]. those concepts? What is the Viewpoint Viewpoint Architectura Use Case Ports are connected to each other via a Port Connection. Ports purpose of each Context Context l Framework Diagram and Interfaces may conform to one or more Protocols that Viewpoint? Viewpoint View Context describe and control how the Port and the Interface behave [4]. View What is the Viewpoint Viewpoint Block Third, the Viewpoints that make up the “Interface definition of Definition Definition Definitio Definition Pattern” should be described. This should be done in each Viewpoint Viewpoint View n the Viewpoint Relationships View in a form of the SysML in terms of the Diagram Block Definition Diagram. Types of Pattern relationships are identified concepts? introduced as a mechanism to categorize and standardize basic What rules Rules Rules Block relationship types and range from informal to formal [5]. The constrain the Definition Definition Definitio “Interface Definition Pattern” provides three Viewpoints that use of the Viewpoint View n enable the identification and definition of Interfaces to be Pattern? Diagram specified in terms of the structural aspects of the Interfaces: the 55 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 [4]. The Pattern also provides two Viewpoints that enable the behavior of Interfaces to be specified: the Interface Behavior Viewpoint identifies typical scenarios showing how Interfaces are used, and the Protocol Definition Viewpoint defines any Protocols to which Interfaces or Ports must conform [4]. These Viewpoints will be described in more detail later in this article. Fourth, the Rules that apply to the “Interface Definition Pattern” should be defined in the Rules Definition View in a form of the SysML Block Definition Diagram. The example of Fig. 4. Flow-Based Interface Identification View (taken from [4]) such rule could be the statement: “Any protocol-based Interface or Port must have a corresponding Protocol The second Interface Connectivity Viewpoint identifies Definition View defined” [4]. connections between Ports and the Interface Connections that take place across the Port Connections. Again, two examples of V. THE VIEWPOINTS OF THE “INTERFACE DEFINITION PATTERN” Service-Based and Flow-Based Interface Connectivity Views are shown in Figure 5 and Figure 6, respectively. John Holt et al. in their book provide a detailed description of the Viewpoints that make up the “Interface Definition Pattern” [4]. The “Interface Definition Pattern” consists of five Viewpoints that represent the structural or behavioral aspects of the Interfaces. Each of these Viewpoints consists of the Viewpoint Context View that defines the purpose of the each Viewpoint and a Viewpoint Definition View that covers the definition of each Viewpoint. Only the Viewpoint Definition View diagrams are presented later in this article, and Viewpoint Context Views will be discussed in the text as they Fig. 5. Service-Based Interface Connectivity View (taken from [4]) describe only the aims of each Viewpoint. The first Interface Identification Viewpoint identifies the System Elements, the Ports that they own, and the Ports that expose the Interfaces and the Interfaces that they expose [4]. By using the Interface Identification Viewpoint, it is possible to define both Service-Based and Flow-Based Interfaces. The examples of the Service-Based and Flow-Based Interface Identification Views are shown in Figure 3 and Figure 4, respectively. Fig. 6. Flow-Based Interface Connectivity View (taken from [4]) The third Interface Definition Viewpoint defines the operations or flows of data, material, energy, personnel, etc. of the Interfaces. An example shown in Figure 7 demonstrates the Service-Based Interface Definition (PumpIF), and the Flow- Based Interface Definition (LiquidFS) in one View. Fig. 3. Service-Based Interface Identification View (taken from [4]) 56 Interface Definition Views would be produced along with the Interface Behavior View and Protocol Definition Views [4]. The discussed Viewpoints show that the context and the scope of the Viewpoint that is used for the View generation should be set: every Viewpoint must provide a template for answering some small set of core questions about the System for the customer stakeholders, which could not be otherwise easily answered [6]. The Viewpoint must identify and meet the needs of the target audience and their specific concerns, and must be well scoped and make the generated Views easy to draw inferences from [6]. VI. THE USE OF THE MBSE PATTERNS The main goal of the use of Patterns, as stated by John Holt et al. [4], is to allow re-use, which brings a number of tangible benefits. Among such benefits, John Holt et al. distinguish the shortened development time, since by working to a set of pre- defined Viewpoints, the structure and the content of each View Fig. 7. Service-Based and Flow-Based Interface Definition View (taken from [4]) has already been decided, hence reducing the amount of time required to generate the individual Views [4]. In addition, the The fourth Interface Behavior Viewpoint identifies the improved consistency of the Model is emphasized because typical scenarios showing how Interfaces are used [4]. An when working in accordance with the Pattern Viewpoints (and example of the Interface Behavior View is shown in Figure 8. Ontology), the consistency between the resultant Pattern View is guaranteed [4]. If systems modelers are educated and trained in the use of Patterns, they can apply this knowledge in a variety of applications, thus shortening the learning curve [4]. John Holt et al. [4] also mentioned the benefit of increased efficiency through the use of the MBSE modeling tool for the implementation of Patterns, as the Viewpoints that describe the Pattern may be implemented in a modeling tool through the use of profiles. When discussing the realization of the MBSE Patterns, John Holt et at. [4] stated that three aspects need to be considered in order to realize MBSE Patterns effectively and efficiently: People, Process, and Tools. For example, the MBSE Patterns can be used as part of the Competency assessment Process or to shorten the learning curve associated with MBSE [4]. The MBSE Frameworks may be constructed by re-using and tailoring the established Patterns, and if each Pattern has its associated Viewpoints defined, then the definition of the Framework becomes so much quicker and easier as the structure and contents of each View will already be defined [4]. Good MBSE modeling tools may be tailored to support a defined MBSE approach by defining the profiles, and thus the use of profiles allows the tool to be tailored to implement a specific approach to MBSE [4]. VII. CONCLUSIONS Fig. 8. Interface Behavior View (taken and modified from [4]) The review of the existing methodology for the definition The fifth Interface Protocol Definition Viewpoint defines and description of the MBSE Pattern based on the book by any protocols to which an interface or port must conform [4]. John Holt et al. [4] showed that: The Interface Protocol Definition View is represented by the SysML State Machine Diagram. 1. A consistent MBSE Pattern can be defined with the help of the Ontology and the Framework, using Viewpoints and When using the “Interface Definition Pattern”, at least one Views as their realization. Interface Context View and one Interface Definition View are needed to specify Interfaces, their associated Ports, and the 2. In order to define the Pattern in a completed way, the key connections between them [4]. In practice, however, multiple questions about the context, purpose, definition, relationships, Interface Identification Views, Interface Context Views, and 57 and rules of the Pattern should be answered in the form of REFERENCES SysML diagrams. [1] Incose, INCOSE Systems Engineering Handbook, WILEY 2015. 3. The structural and behavioral aspects of the Patterns are [2] Gamma, E., Helm, R., Johnson, R., Vlissides, J., “Design Patterns.” Addison-Wesley Publishing Company, 1996. presented in five Viewpoints, which serve as a basis for the creation of Views. [3] Peterson, T., Schindel, W. D., Hamilton, B. A., “Model-based system patterns for automated ground vehicle platforms,” INCOSE international 4. The use of Patterns not only helps to shorten system symposium, vol. 25, pp. 388–403, 2015. development time, but also improves the consistency of the [4] Holt, J., Perry, S., Brownsword, M., “Foundations of model-based model, shortens the learning curve, and increases the efficiency systems engineering: From patterns to models, Institution of Engineering and Technology.” Iet Professional Applications of Computing, 2016. of MBSE modeling tools. [5] Simpson J., J., Simpson M., “Foundational Systems Engineering (SE) 5. The MBSE methodology should be used together with Patterns for a SE Pattern Language,” INCOSE International Symposium, vol. 16, pp. 1675-1687, 2006. the MBSE Patterns that increases the effectiveness and efficiency of modeling. [6] Paredis, C. J. J., Bishop, C., Bodner, D., “Introduction to Information Visualization (InfoVis) techniques for Model-Based Systems Engineering,” Conference on Systems Engineering Research, vol. 16, pp. 49-58, 2013. 58