Insights into the invenio Systems Engineering Framework (iSEF)
Part 2 -?Recursive System Design Modeling
Abstract
In the previous article (Part 1), the author presented the 3 dimensions of a systems architecture. In this article, the focus moves forward to illustrate the placement of architectural elements within these dimensions to construct a comprehensive yet comprehensible system model. The article will again leverage the invenio Systems Engineering Framework (#iSEF) introduced in Part 1, utilizing its Viewpoints, System Abstraction Levels, and Hierarchy Depths to explain a full architecture step.
This article will provide an overview of the system architecture standards and important modeling principles of the iSEF. The objective is to establish for the reader a good understanding and a foundation for subsequent modeling activities across various viewpoints and System Abstraction Levels, which will be covered in upcoming articles. The main focus of this article is to elucidate the following principles:
Following the overview, each subsequent article will focus later on specific steps, using the fictional product "Vehicle Crash Recorder" as an illustrative example for design and implementation.
To facilitate understanding of the terminology used throughout this series of articles, a summary of key terms will be provided at the end of each article.
Remark: In this article, several terms are used. such terms written in italic letters can be seen at the end of the article.
For curious readers, the upcoming article series will cover the following steps:
Step 1: Definition of Features using the Variability Viewpoint to define Functional and Technical Features and their relationship regarding variability governed by variation points.
Step 2: System Context and SoI Definition using the Operational Viewpoint to define the System Context, System of Interest, and its interaction with external elements.
Step 3: Requirements Derivation using the Requirements Viewpoint to derive requirements and establish traceability between system elements, design constraints, interfaces, and other design aspects.
Step 4: Operational Analysis using the Operational Viewpoint, conduct an analysis of the intended SoI from a system behavior perspective, including use case analysis and recursive system activity refinement.
Step 5: Functional Design Development: The Functional design is developed using the functional viewpoint, involving state machine definitions and activity refinements and completing the architecture by a functional composition.
Step 6: Logical Component Design Applying the Logical Viewpoint to design the logical components, including structural system composition, interface definition, and port linking for the target system.
Step 7: Technical System Development leveraging the Technical Viewpoint to develop the technical system dependent on needed technologies and decisions on how to build a system, combining all logical elements to build the complete technical system.
Step 8: Physical Implementation using the Physical Viewpoint to realize the physical architecture of the end-user system, using methods such as composing and interlinking the appropriate physical elements and linking the still abstracted technical element to the chosen physical realizing components.
But first, it is important to return and introduce some significant architecture and modeling principles while the above steps are explained in the following articles.
Remark: Before delving into the articles, we recommend familiarizing yourself with the glossary to better understand the terminology used throughout this series. Happy reading!
The Domain-Specific System Abstraction Levels
The central premise of abstraction levels is that all systems, without exception, can be classified into 5 distinct System Abstraction Levels when they undergo an analysis and decomposition. When delving further into the discipline-specific architecture then, a sixth level, namely the Component Element Abstraction Level, becomes relevant. But for now, let's keep the 5 System Abstraction Levels when creating a systems architecture. This categorization applies universally, encompassing even complex systems such as airplanes, mobile services, and, interestingly, also the human body. As discussed in Part 1, the generalized representation of these 5 system abstraction levels is depicted in the figure below with some examples.
When, for example, considering the "vehicle domain", the System Abstraction Levels primarily encompass the scope of this specific domain. As a result, the 2nd and 3rd System Abstraction Levels are classified as the <Vehicle> Abstraction Level and <Vehicle> System Abstraction Level, respectively. This principle applies similarly to other domains, such as "Mobile Services" or "Backend Services". It is important that the categorization of the 2nd and 3rd levels are domain-specific, while the remaining levels are generic and cross-domain applicable, as the elements of a System Product Abstraction Level and its components can be used within more than one domain which makes this approach very efficient and flexible.
Another important criterion is that only elements defined within the same System Abstraction Level are permitted to communicate with each other. Direct communication between elements at the vehicle level and an element at the system product level, for instance, is strictly prohibited as it would violate the principles of abstraction levels. Instead, using System Abstraction Levels allows the establishment of decomposition models and enables consistent reuse. It is obviously not meaningful for systems at different abstraction levels to directly interact with system elements from other levels, which can be referred to as "level hopping."
Furthermore, it is important to note that any system that can be directly operated or accessed by an end-user is placed at the User Domain Abstraction Level. This applies to various examples such as smartphones, bicycles, and vehicles, as well as airplanes and navigation or satellite systems. Complex systems may have an additional hierarchical structure within the System Abstraction Levels to facilitate their clustering. To remind the Reader, the System Abstraction Level is not the hierarchy of a system decomposition! It is a supporting classification to manage a Full Architecture Step within the abstraction a system should be considered.
A key aspect of employing the System Abstraction Levels methodology is ensuring that all system operators, regardless of their location (e.g., inside or outside the vehicle), are described in their interaction on the Environment Abstraction level. This allows for communication between elements (systems) at the same abstraction level, adhering to the principles and rules established by the framework.
So far, domains with their exemplarily given prefixes within the engineering framework, among others, are:
Every system can be categorized into one of the five System Abstraction Levels. During the decomposition process, a subsystem resulting from a decomposition step may be already and also typically classified at a lower System Abstraction Level compared to its parent system (refer here also the next section). In order to perform a transition from one System Abstraction Level to the next lower level, at least one Full Architecture Step is generally required if no further tailor mechanisms are applied. A Full Architecture Step encompasses herewith, from the analysis to the physical architecture, all necessary steps over the five architectural views, as elaborated in the upcoming section.
It is important to note that the development process should always start at a System Abstraction Level where the System of Interest (SoI) is positioned. The starting System Abstraction Level for the system context is then one System Abstraction Level above the SoI. It is important to understand that the Environment Abstraction Level does not necessarily need to be the starting point. In business domains like automotive, where Electronic Control Units (ECUs) are typically developed, the initial System Abstraction Level for the context will often be either the "Vehicle System Level" while the SoI is placed at the "System Product Level".
In ACMBSE (Architecture-Centric Model-Based Systems Engineering), as seen already in Part 1, among other system engineering approaches, the Hierarchy Depth and the System Abstraction Levels are orthogonal. At each System Abstraction Level, the Hierarchy Depths reset to one. This brings several advantages:
Duality of Element Definition and Element Usage
The following definition, which is a key principle within the ACMBSE method, is crucial for accurately placing system elements within the 3-dimensional space over abstraction levels.
The ISEF modeling language iSefML, based on SysML, employs an object-oriented modeling approach that adheres to principles of inheritance, composition, and aggregation. However, before a system element can interact with other elements, it must undergo the process of a definition. This involves specifying all the characteristics of the element, including behavior and interfaces. When an element is then composed within another element, such as the system of interest (SoI), placed into a system context or a higher-level system element, then this Block element will be instantiated and becomes a Part, which is referred to as an "Element Usage." while the Block element is referred to an "Element Definition". The diagram below illustrates this concept.
A defined element can be instantiated or composed as a Part multiple times, depending on how it needs to be used in various roles and contexts. It's important to note that the element's defined interfaces remain unchanged, as they are defined at the block element and used only at the instantiated parts or objects.
The important principle is now: If an element is instantiated or composed into a context, which can also include Actors and not just block elements, the System Context is defined at the next higher System Abstraction Level (as shown in the example figure). All instances achieve the same abstraction level as the System Context. In cases where a hierarchy is applied, the composing element may be at the same System Abstraction Level. Additionally, when Actors are used, the higher composing element must be a System Context. In iSefML, all Block elements are predefined at a specific System Abstraction Level. The abstraction level is generally fixed and predefined and allows the application of predefined decomposition models.
Designing Model using a Full Architecture Step
The Viewpoint descriptions provided in Part 1 are applicable to all 5 System Abstraction Levels. If there are variations in using or omitting a Viewpoint across different System Abstraction Levels, then a tailored concept must apply. It is possible to tailor an individual view entirely or partially, which will be discussed in one of the upcoming articles. Nevertheless, the order of Viewpoints, as mentioned in the Figure below, must not be changed in order from Viewpoint 1..5. The Requirements Viewpoint and Variability Viewpoint are additionally used to trace requirements respectively derive requirements from Technical- and Functional Features and are extending the full architecture step.
In the case of platform projects that do not involve the development of a technical and/or physical platform solution, it may not be feasible to create a technical and/or physical view, and therefore, such Viewpoints may be omitted. But this principle is then as well considered as a tailored concept.
The figure above illustrates the relationship between Concerns, Viewpoints, and Views. The Concerns of specific stakeholders are addressed by an Architecture View, which is governed by an Architecture Viewpoint for the System of Interest (SoI). The Architecture Viewpoints also define conventions for up to 8 Model Kinds, such as Feature Model, Communication Model, and Integration Model, as shown in the image below in this article. These Model Kinds need to be applied in the Architecture Model.
The Architecture Description is expressed through Architecture Views, which are collections of 1 to 5 System Abstraction Levels. The Development Scope determines the required System Abstraction Levels based on the relevant Concerns, guided by the Abstraction Level Definitions.
The figure above is based on the ISO42010 standard and has been extended to include the Development Scope, Abstraction Level Definition, and System Abstraction Levels for the iSEF. This extension allows for the development of complex systems both within and outside specific domains, such as the vehicle domain, yet focuses on specific architecture topics expressed in the Views.
领英推荐
Workflow for a Full Architecture Step
When working with the Viewpoints across the System Abstraction Levels, it is important to follow certain rules for modeling within the five architecture-relevant viewpoints.
Rule 1: A Full Architecture Step always begins with the Operational Viewpoint, as it serves as the initial step for system analysis and sets the context for the subsequent operational analysis.
Rule 2: A Full Architecture Step is performed recursively at each System Abstraction Level, adhering to the same modeling principles specified in the method descriptions for each individual Viewpoint.
Rule 3: A Full Architecture Step can be terminated and transitioned to the next System Abstraction Level if no further architecture step is required for the remaining viewpoints. Any applied tailor concepts should be documented.
Rule 4: Within a Full Architecture Step, viewpoints cannot be omitted except for possibly developing the technical/physical solution directly from the Operational Viewpoint. In such cases, the Technical Viewpoint follows as long as functional and logical architecture modeling is not necessary.
Rule 5: The architecture-relevant viewpoint activities must be processed in the following order: Operational Viewpoint, Functional Viewpoint, Logical Viewpoint, Technical Viewpoint, and Physical Viewpoint.
Rule 6: The Requirement Viewpoint and the Variability Viewpoint are auxiliary viewpoints that can be recursively used within each of the five viewpoints specified in Rule 5. If just textual requirements engineering applies and only structures are modeled, then the requirements viewpoint becomes mandatory.
Rule 7: Each performed architecture step within a viewpoint results in a system architecture specific to that Viewpoint, including rationales (design decisions) and System Design Requests in the form of requirements for the next system abstraction level.
Rule 8: Artifacts can only be linked and handed over from one Viewpoint to the next in the specified order (Viewpoint-linking). Reversing the order of element usage would violate the methodological principles of the architecture steps sequence.
Rule 9: Communication between elements is allowed only over viewpoints horizontally within the same System Abstraction Level. When dealing with elements from different viewpoints, viewpoint linking shall be utilized, and the elements need to be embedded in viewpoint order.
Rule 10: Only elements specifically designated for the particular Viewpoint are allowed for modeling within that Viewpoint. SysML elements that are not intended for use in the iSEF-specific viewpoint should not be utilized. A more detailed metamodel for each System Abstraction Level may be presented in upcoming articles within this series.
Emerging Collaboration Systems
When a system block is decomposed into two separate blocks, a new interaction may arise between them, necessitating collaboration between the decomposed blocks over specific communication interfaces. What does this mean? If a block element is divided into two elements, then it may be necessary to extend the model by an additional collaboration system between those two elements to enable specific communication using a hardware interface or communication protocol. This is called an Emerging Collaboration System.
This collaboration is divided into parts that form new functionalities for information exchange between those blocks represented as parts of a Communication Model, while the original functional content will be part of the Feature Model. This approach allows for the preservation of consistent outer interfaces for System Block A and System Block B, while the collaboration parts can be separated into a Communication Model, separated from the user-perceivable content of the Feature Model. This principle later allows a very efficient way to develop reusable systems following the OSI and OSC Reference Models (Decomposition Models), which is shown in some later articles.
Introduction to Model Kinds and their Usage
As discussed in the previous section, it is recommended to maintain a separation between the feature-specific system model and the communication-specific system model. To achieve this separation, it is advisable to place these models in different modeling structures (packages), referred to as Model Kinds. This approach allows the separation of concerns between the feature-specific aspects and the communication-specific aspects, facilitating an effective and flexible integration of these independent architectures into a dedicated integration-specific system model.
The iSEF defines eight distinct modeling packages or Model Kinds, as depicted in the diagram below. These Model Kinds have specific dependencies and an integration order that ensures the separation of different models and keeps maximum independence. Leveraging these Model Kinds assists the architect in organizing the models into packages and modeling units, facilitating better reusability of deployed system models. The following Model Kinds are defined currently within iSEF:
Remark: It is important to strictly adhere to the integration order to avoid circular references and maintain the integrity of the models.
Linking Elements between Architecture Viewpoints (Matryoshka Principle)
The "Matryoshka Principle" is a fundamental characteristic and modeling principle of the invenio Systems Engineering Framework when it comes to the task of systematically linking the elements and aspects of the Viewpoints. It enables a strong and type-safe interface-supported binding between architecture views and their elements compared to a simple Allocation in SysML. This principle enhances significantly design strength and supports automated checking mechanisms for better compatibility of elements across viewpoints. This principle enables further building executable model structures from the Functional Viewpoint down to the Physical Viewpoint. In a future article within this series, we will delve into more details about the Matryoshka Principle and its important and powerful viewpoint-linking.
The "Matryoshka Principle" ensures that functional, logical, technical, and physical elements are well-fitted together, especially for safety designs until ASIL D, allowing the creation of formal information flows, operations, and events between different views. This principle facilitates communication between Function Blocks and Logical Nodes, connecting Functional Values and Logical Signals through ports. Further, it facilitates the transport of logical signals over the technical and physical infrastructure as defined in the Technical- and Physical Viewpoint. Interface Behavior Blocks, as seen in the figure below, contain the necessary logic to link these elements, making the information visible and facilitating its transport. In upcoming articles in this series where we will provide more about the "Matryoshka Principle" and its practical implementation.
The composition of elements across the viewpoints, as illustrated in the above figure, offers the following possibilities:
These composition capabilities provide an unparalleled level of flexibility in system design, facilitating high reusability, detailed model execution, versatile deployment, and stringent visualization of the architecture. The iSEF profile, integrated into the IBM tool Rhapsody, contains already pre-defined templates for interfaces across all viewpoints that assist in defining the required specific interfaces of a system easily. The framework also offers a wide range of standardized Functional Values, Logical Signals, Service Definitions, Technical Lines, and Physical Leads that seamlessly fit and operate together. Additional helper functions automate the creation of item flows between these ports, streamlining the modeling process.
Constraints for a Reusable System Design - Decomposition Models
Depending on the System Abstraction Levels, the decomposition of a system leads to varying distributions of functionality among its subsystems. However, the overall black-box functionality of the system remains unchanged. Only the black-box functionality of the subsystem varies depending on the chosen decomposition scheme.
It is now important to understand when the target is to develop an architecture with highly reusable system elements developed by different teams, then it is essential that all engineers develop such system elements following the same decomposition scheme. The best example is hereby the OSI Layer reference model, enabling standardized interface definitions between the 7 OSI Layers. In Analogy the decomposition schemes apply to the ACMBSE method of developing a coherent system architecture.
Decomposition Meta Models in the iSEF provide a solution to this situation by defining a set of system block elements with specific purposes, incorporating well-established design principles. Exemplarily for the Operational Viewpoint is given a decomposition scheme dependent on the System Abstraction Level for operational block elements such as "Sensing System", "Control System", and "Actuation System" among many others. The figure below illustrates this.
The iSEF profile provides a set of standardized decomposition models for each Viewpoint across all System Abstraction Levels following the ACMBSE method, enabling the construction of a flexible and highly reusable set of systems and subsystems that can be composed into various target systems enabling as well standardized interfaces. Each category of a system has a clear task, such as performing a system analysis, conducting a functional analysis and design, allocating functions to logical resulting to implement nodes nodes technical and physical system elements at each System Abstraction Level.
For the identification and handover of system parts to the next architect, it is necessary to decompose the system of interest into smaller parts. The above-shown SCA pattern is commonly used as the design base for all other decomposition models. In the Operational View, as introduced in the figure above, demonstrates an applied SCA pattern where the sensing and actuation parts are separated from a hardware-independent control part. The interaction part acts as a direct user interface and abstracts it. Sensing Systems handle technical sensors, while Actuation Systems control technical actuators. Control Systems can further directly send functional abstracted control requests to an external Actuator System rather driving a technical device.
Two important facts should be noted when performing a system design:
With these two facts in mind, associations can be established using a communication system between the Sensing/Interaction Systems and the Control System and between the Control System and the Actuator Systems. This allows us to define how to create a cluster of repeatedly usable elements, systems, and functions.
The iSEF decomposition model includes real-time model checking to ensure that this pattern is not violated during the composition of elements into others. It effectively detects any violations or incorrect interface connections, enabling the identification of potential issues in the architecture.
Summary
The invenio Systems Engineering Framework (iSEF) offers a comprehensive and structured approach to system design and modeling, allowing for the effective development of complex systems across different domains. This framework is based on the concept of System Abstraction Levels, which categorizes systems into five distinct levels. This categorization applies universally and provides a clear abstraction for system analysis and decomposition.
One of the key principles within the iSEF is the "Matryoshka Principle," which emphasizes the strong linkage and composition of architectural views across different Viewpoints. This method ensures that the interfaces and interactions between system elements are well-defined and consistent, enabling better design principles, reusability, and automated model checking. The provided decomposition schemes allow for the separation of feature-specific and communication-specific system models, facilitating a more effective integration of architectures into an integration-specific system model.
The iSEF and its applied ACMBSE principles are particularly valuable for platform projects and systems with multiple stakeholders. It allows for the decomposition and modeling of platform systems in a way that accommodates different decompositions chosen by customers, minimizing the effort required for changes and adaptations. By following the ACMBSE approach, systems engineers can achieve a consistent and transparent architecture description, ensuring the effective communication and integration of very complex systems.
In the upcoming articles, we will explore the content discussed above, providing further details on the key aspects of the ACMBSE principles and how the iSEF applies them. Specifically, we will focus on the 8 steps to build an architecture, as mentioned earlier. Furthermore, some future articles will explore the various decomposition schemes of the framework much more deeply.
If you found this article again insightful and engaging, we would greatly appreciate your support by leaving a comment or giving it a thumbs-up. Your feedback and interaction are invaluable to me and serve as inspiration to continue sharing valuable content. We also invite you to stay tuned for our upcoming articles in this series, where we will continue to expand your knowledge and keep you informed. Thank you for your time and support!
Stay Linked - Stay Curious!
Enrico Seidel