Best Practices für Simulink: Modellmetriken analysieren & Refactoring

As shown here, the example subsystem consists of several input and output ports, along with two additional subsystems. At the current structural level, the focus is solely on these two subsystem blocks, without delving into the internal contents of each. In other words, the current subsystem includes input ports, output ports, and two internal blocks. It is essential to understand the concept of structural hierarchy at this point. At the structural level, the goal is to gain clarity on the origin and destination of signals, the direction of signal flow, and the way in which they are interconnected. This refers to the structural layout of the current modeling level. To assess local complexity from a structural perspective, it is not necessary to understand the internal computations or logic performed within the blocks. Instead, the focus is placed on the visible, representative structural components. At the current model level, the local complexity of this subsystem can be quantitatively evaluated by considering all visible elements. For example, a calculated value—such as 33 in this case—can be used to characterize the local complexity of the subsystem.

Why calculate local complexity? In fact, the goal is to focus on key features at a specific model level. By applying an appropriate hierarchical structure, the content represented by the model becomes easier to read and understand—thereby enhancing model readability. All other information related to the model's internal logic or details is intentionally omitted at the current level and deferred to other layers of the model’s structure. A well-balanced subsystem layout with reasonable complexity improves structural quality, enhances simplicity and readability, and reduces the effort required for review and maintenance. If this number alone does not yet convey more useful insights into the complexity, there is no need to worry. The following example in Figure 3 will help clarify this further.

As shown on the left side of Figure 3, the subsystem is relatively small in scale and consists primarily of a few simple computational steps. When evaluated using the same local complexity calculation method, its complexity value is determined to be 60. In contrast, the subsystem on the right side of Figure 3 is significantly larger in scale and evidently involves more computational logic. Intuitively, one would consider the right-hand subsystem to be more complex. The question is: how much more complex is it? Can a numerical value be used to quantify the difference in complexity compared to the smaller subsystem? By applying the same local complexity calculation, the complexity value of the right-hand subsystem is determined to be 600. This indicates that the larger subsystem is approximately ten times more complex than the smaller one.

Next, the analysis focuses on this large subsystem with relatively high complexity (refer to the right side of Figure 3 and Figure 4). A complexity value of 600 is not considered extremely high, but it falls within the medium-high range. For such subsystems, the question is how to improve readability. From a holistic perspective, the subsystem involves some parallel computation, and certain signal flows are not clearly defined. To improve readability, an attempt can be made to limit the local complexity to a certain threshold, as a complexity value of 600 is already somewhat large. Therefore, the subsystem will be restructured to address these issues.

The model is essentially divided into two parts: the upper and lower sections. In the current structural layer, subsystems are created for each, with calculations placed in the lower model layer. After restructuring, the local complexity (see Figure 5) is significantly reduced to 40. More importantly, the redesigned subsystems provide a clearer and simpler layout, making the understanding of signal flow, data flow, and computations more straightforward. This improves both comprehensibility and maintainability.

Local complexity helps assess the size of model components or the complexity of subsystems. Building upon the earlier analysis at the subsystem level, the scope is now extended to examine the global complexity of the model system or its subsystems, to better understand the overall implementation scale. For the same model system or subsystem (as shown in Figure 6), the subsystem consists of input ports, output ports, and two subsystem blocks. All internal implementations—such as specific computations and components within deeper-level subsystems—are considered, as displayed in the model browser in Figure 6. The complexity of all elements within the model subsystem is calculated, and the complexities of each contained subsystem are summed. This results in a global complexity value of 352 for the system. Thus, the global complexity at this structural level includes not only the local complexity of 33, but also the local complexities contributed by all subsystems.

Global complexity metrics help ensure that a unit or component does not become excessively complex, thus maintaining its readability. Additionally, it is important that such units and components remain measurable, particularly for the purposes of review and testing. In this context, the complexity metric can be directly associated with the required effort—higher complexity indicates greater workload for both review and testing.

Therefore, the magnitude of global complexity directly corresponds to the amount of workload, highlighting its impact on structural quality. Keeping units small improves readability, modularity and testability, thereby enhancing the implementation efficiency. If a given functional requirement can be implemented in two different ways, both of which are functionally correct, a significant difference in their global complexity values indicates that the approach with lower complexity is the more efficient implementation. Thus, while global complexity may not affect functional quality, it may have an impact on structural quality, serving as a reflection of the effectiveness of the design and modeling process.

How does global complexity contribute to improving modeling efficiency in practice? This can be illustrated using a typical example model in MATLAB/Simulink. Firstly, global complexity metrics can be used to assess and constrain the overall size of model components, thereby reducing the structural complexity of the model. Secondly, they provide indicators of testability. For instance, by using libraries or model references (as shown in Figure 7), files can be partitioned into separate model components, enhancing both modularity and testability. Finally, global complexity serves as an indicator of modularity. Proper block partitioning enables block reuse and independent testing. A modular design aligns with the overall software architecture, linking directly to key requirements and test strategies. Modularization also enables flexible loading and compilation of components, allowing them to be reused across different projects without the need for repeated global-level review and testing of the same structural component types.

Previously, the concept of complexity was discussed, along with how to evaluate the size and complexity of a component. The focus now shifts to understanding how well the internal parts of a component work together—that is, whether different computations or operations within the component are interrelated. To accomplish this, the degree of interaction among elements within a component is analyzed. In MATLAB/Simulink/Stateflow, this is represented using the concepts of cohesion and incoherence [1]. The core idea is that every block within a subsystem should directly or indirectly influence, and be influenced by, other blocks within the same subsystem. For each block b, the number of blocks that are affected by or affect b—including b itself—is calculated. This total, referred to as the number of blocks on paths through b, is abbreviated as bop. In a highly cohesive subsystem, the bop of each block tends to approach the total number of blocks in the subsystem. In contrast, a subsystem with low cohesion will have blocks whose bop values are significantly lower compared to the total block count.

When designing the structure or performing modular computations within a subsystem, the goal is to group related functionalities together within the same subsystem. Conversely, functionalities that are unrelated should be separated to enhance comprehensibility. If all blocks are focused on a single function or computation, the subsystem becomes significantly easier to comprehend. Therefore, it is important to identify parallel or independent components within the model to support model refactoring. This facilitates modularization and encapsulation, ultimately improving key quality properties such as testability and maintainability.

How does incoherence assist in refactoring operations? Incoherence can be interpreted as a rough estimate of the number of disconnected or parallel components within a subsystem. For example, in Figure 9, all blocks involved in the computation lie on a single path—this represents the simplest case, with a calculated incoherence value of 1. In Figure 10, like the earlier example, the subsystem includes a partial split in the computational path, resulting in an incoherence value of 1.3. Now, consider what happens in Figure 11, where parallel computation is introduced. An additional set of independent, parallel components increases the number of disconnected elements in the subsystem, leading to an incoherence value of 2. From this, the integer part of the incoherence value provides an approximate indication of how many parallel or separated component groups exist within the subsystem.

A more complex example can further illustrate this concept. Incoherence can be utilized to identify subsystems that exhibit both high complexity and a high degree of disconnection. As shown in Figure 12, the local complexity of the subsystem reaches 1104, which introduces significant difficulties in terms of readability and testability. The corresponding incoherence value is approximately 5, suggesting that the subsystem can be divided into four to five independent components. Based on this analysis, the model may be refactored into four larger, separate components. Alternatively, a partition into five components is also viable, depending on specific structural or functional requirements.

After refactoring, a new structure like that shown in Figure 13 is obtained, forming a new structural layer that makes the overall model easier to understand. Firstly, it clearly shows which input signals correspond to specific functionalities or computations within the subsystem unit, which is crucial for the evaluation of functional signals. Secondly, it can be observed that while the incoherence value remains approximately the same, the local complexity value is significantly reduced, thereby improving the comprehensibility of this model layer. At this stage, the model introduces a structural layer, rather than a mixture of functional and structural layers.

In addition to providing a rough estimate of separated components, the model metric of incoherence also helps prevent designs with implicit data flows, as illustrated in the example shown in Figure 14. The subsystem consists of many individual charts, where major signal data flows are hidden using Goto/From blocks, making it difficult to understand the properties and directions of the signals. Statistical analysis indicates that the subsystem exhibits extremely high local complexity and poor readability. However, the incoherence value is only 3, suggesting that although the use of Goto/From blocks visually separates functional components, the subsystem can be simplified into three main functional groups.

The refactored model shown in Figure 15 demonstrates clearer subsystem structures and data signal flows, while also significantly reducing the local complexity.

Structural and Functional Layers

How can the separation of structure and functionality be interpreted? Taking the Simulink subsystem shown in Figure 16 as an example, the input and output ports are referred to as neutral blocks, as they are typically necessary in most cases. Within the subsystem, no actual computation takes place; instead, it contains only two internal subsystems. A subsystem that consists solely of such structural blocks is referred to as a structural subsystem.

Similarly, in the subsystem shown in Figure 17, besides the input and output ports, all other blocks perform functional operations such as mathematical calculations, logic operations, bitwise operations, or function calls. A subsystem that contains only functional operation blocks is referred to as a functional subsystem.

In accordance with the architectural design principles recommended by ISO 26262, it is advisable to establish an appropriate hierarchical structure for subsystems. But what constitutes an "appropriate" hierarchy? In this context, appropriateness can be defined as a dedicated differentiation between structural and functional layers. By separating structural and functional elements, a consistent hierarchy for signal processing, structural organization, and functional implementation can be achieved, thereby improving structural quality in terms of readability, modularity, testability, and adaptability to modifications.

A set of recommended best practices for model architecture design is presented here. In the software development process, the software architecture is typically outlined at a high level during the architectural design phase. Based on this initial structure, the model system should be designed and refactored using the previously discussed model metrics to ensure that the system or its subsystems align with industry’s best practices and the intended software architecture. During the detailed design phase, care must still be taken to avoid mixing structural and functional block elements within the same subsystem. The goal is to achieve a well-organized, visually clean, and logically layered model structure, such as the appropriately layered architecture shown in Figure 18. In this example, the top-level Simulink root layer represents the overall system structure. Beneath it, Model Layer 1 includes subsystems responsible for signal distribution and software architecture layers. Further below, Model Layer K consists of subsystems that implement structural aspects of software architecture. From a certain level—such as Model Layer m—onward, the subsystems transition into either structural layers of the architecture or the actual implementation of functional computations, extending down to the lowest layer of functional logic. In this layered design, structural subsystems are maintained until the final computation layer. Throughout the modeling process, proper use of library links and model references helps reduce system complexity and contributes to a final architecture that is simple, readable, testable, and maintainable.

Invalid Interfaces and Interface Size

When discussing subsystem layers, structural organization, and hierarchical model architecture, it is essential to consider the signal flow between subsystems and the interfaces entering each subsystem.

According to the software design principles recommended in ISO 26262, interface sizes should be kept within a reasonable range to prevent oversized interfaces that can impair system comprehensibility. In limiting interface size, two aspects must be considered: the total number of subsystem interfaces and the consolidation of signals through bus structures. More importantly, emphasis should be placed on the effectiveness of the interface signals themselves. This means that all input signals to a subsystem must be functionally relevant—specifically tied to the functional requirements implemented within the subsystem. Ineffective or unused signals should be avoided, as they add unnecessary complexity and reduce model clarity. To better illustrate this, consider the example shown in Figure 19. Five basic input signals are passed into a subsystem that contains multiple hierarchical levels and a model reference. Notably, only two of the five input signals—signal a and signal b—are used in dot product computation. The remaining signal c, signal d, and signal 1—are ineffective inputs, as they are not used in any downstream functionality or computation.

However, in certain cases, it may be unclear whether signals are truly used—especially when the internal structure of a subsystem or the details of referenced models are not fully visible or understood. A typical use case is illustrated in Figure 20, where an entire signal bus is fed into a subsystem. However, only a subset of the signals is actually required for the functional implementation within the subsystem, while the remaining signals are effectively bypassed and unused. To address this, it is recommended to limit interface size to ensure that units and components remain reusable, while avoiding the introduction of virtual coupling. To achieve this, the use of explicit signal flow is often enforced, which improves the model’s readability, modularity, testability, maintainability, and adaptability to changes.

What are the best practices for managing interface size and signal handling? First, it is important to note that simply imposing a fixed numerical limit on the number of input and output ports is not a practical approach. Instead, as illustrated in Figure 21, a recommended best practice is to group required signals based on functional needs into buses. Ideally, these buses should consist only of valid and necessary signals for the subsystem, with signal flows made explicit, as demonstrated in the signal grouping and extraction process shown in Figure 18. Therefore, required bus signals should be extracted or modified outside the subsystem, using signal selectors to explicitly choose only the signals that are actually needed. This approach ensures that the essential signal flow is clearly represented at the structural level, enhancing the subsystem’s clarity, modularity, and maintainability.

Clone Components

Now suppose a well-designed model is already in place, with all structural quality metrics fully optimized. When there's a need to reuse a specific function or algorithm in other parts of the model, a common operation is to manually duplicate a block, component, or subsystem. When similar structures—such as subsystems with identical or highly similar properties—appear in multiple locations, they are referred to as a clone group. Regarding subsystem cloning and clone group operations, consider a scenario where a small subsystem contains a set of computational blocks and constants arranged in a specific layout. As a reusable component, it is copied and pasted elsewhere in the model, followed by some layout and parameter adjustments (as shown in Figure 22). Predictably, repeating such operations across the model leads to a rapid increase in system complexity, along with a corresponding rise in review and testing workload. To simplify the design and reduce overall system complexity, models containing clone groups can be restructured as separate reference models. If certain subsystems need to be reused often, they should be converted into library components. By converting subsystems into model references or Simulink libraries, you can significantly reduce model complexity, lower testing and maintenance effort, and ultimately decrease code size.

Therefore, identifying many clones and clone groups and replacing them with library references is considered the best practice for handling cloned components. This approach can significantly reduce global complexity, which directly correlates with model size and development effort. In complex model-based systems composed of a wide variety of block types, individual model components are often developed in parallel and in distributed groups. As a result, copy-paste patterns and clone groups frequently emerge, contributing to relatively high global complexity. For example, based on clone group and complexity analysis conducted in a specific project [2] (see Figure 23), the system had a substantial number of cloned components and repetitive subsystems. By improving these clone groups and duplicated subsystems, a complexity reduction of approximately 10% was achieved. In general, for large-scale engineering projects, a 10% reduction in complexity translates into a similar reduction in review and testing effort, leading to significant savings in labor and costs.