Get best of the week

Design at the system level. Part 3: Linking System Composer and the MathWorks Toolchain

In the first twoparts of the tutorial we looked at building system architecture and designing at the system level and at the same time looking at System Composer. The architecture of the system itself is excellent, but you need to make sure that it is connected with the developed system. The lack of such a connection in traditional tools using SysML or UML, by the way, was the reason for the creation of System Composer. The fact is that many companies already use the Model-Oriented Design (MOS) paradigm for development, and they had to use third-party tools for systems engineering, which was inconvenient. System Composer was created to bridge this gap. In this final part of the tutorial, I will show how to use System Composer together with the MathWorks toolchain for Model-oriented design.

Binding Architecture to Requirements


First, let's define what are the requirements. Requirements are what the system should do. Their differences from the technical specifications are that the requirements are a description of the functioning of the system. MATLAB / Simulink has a Simulink Requirements requirements management tool. It allows you to both import requirements from external systems, such as IBM DOORS, and write them in the native Requirements Editor. The requirements themselves are stored in special files with the extension * .slreqx. Create the requirements and save them in the file AccessControl.slreqx. We formulate the requirements themselves from the reasoning in the first part:

  • RFID tag reading must be provided.
  • Data retrieved from the RFID tag must be transferred to an external database
  • Based on the database response, a ban or permission is generated
  • User must be notified of access status
  • The lock is unlocked based on access status

These requirements were created in the Requirements Editor, a requirements creation tool included with Simulink Requirements and saved to a file. If you open this file in the model itself using Requirements Perspective, then we will see the following:



In order to attach a requirement to an architecture element, simply transfer the requirement to the desired architecture element with the mouse.

And what if the requirements have changed, as is often the case in the early stages of design? How to analyze their impact on our architecture? Fortunately, Simulink Requirements allows you to track changes in requirements and marks those architectural elements that were affected by these changes:



To analyze the coverage of an architecture with requirements, on the Requirements tab, select Share and then Generate Traceability Matrix. A traceability matrix will be created that graphically displays the relationships of requirements and elements. This matrix is ​​a table, the columns of which are the elements of architecture or model, the rows are the requirements themselves, and the cells contain graphic notes about the relationship between the requirements and the elements.

And if you click on the Highlight Missing Links button, then uncovered elements in the matrix will be highlighted in yellow:



Analysis of the completeness of coverage of requirements and their traceability is a very important process if you create a system that is critical to safety, it does not matter for an airplane, car or a nuclear reactor. For such systems there should be no elements uncovered by the requirements! If you are interested in how these systems are developed and how they are developed in the MOS paradigm, write in the comments, as the topic is very extensive and long and goes beyond the scope of the tutorial.

Architecture Analytics at MATLAB


Since System Composer is part of the MathWorks toolchain, we can analyze the properties of the architecture, make reports, and more. The analysis of the architecture allows you to calculate the number of working hours required to implement the system, the minimum weight and dimensions, TDP and so on. And if we conduct an analysis systematically, and not one-time, then we can see the dynamics of the development of our system, as well as find problem areas.

Let's say for our ACS we want to calculate the number of working hours. All components have a common Workload property, and obviously we need to add up the values ​​of these properties. To do this, let's create an architecture instance for analysis by clicking on the Analysis Model, and then select the GenericComponent for analysis:



Then click the Instantiate button and get the following result:



Here we can assign the values ​​of the Workload property to each element and click the Update button to update these values ​​in the architecture itself. And we don’t have to click, because the instance exists separately from the architecture, and we can play around with property values ​​to find project compromises or find optimal property values. The analysis itself is performed by a separate function created in MATLAB. Here, for example, is the code for our “analytic” function:

function AccessControl_simple_analytics(instance,varargin)
if instance.isComponent()
workload = 0;    
    for child=instance.Components
        child_workload = child.getValue("GenericComponent.Workload");
        workload = workload + child_workload;
    end
instance.setValue("GenericComponent.Workload",workload);
end
end

After the function has been created, click on Analyze and select it in the Select Function menu. Now, when the Analyze button is clicked, the value of the Workload property will be summed:



This was an extremely simple example of architecture analysis and in real, combat, analysis tasks, the whole spectrum of MATLAB analytical capabilities is used, such as curve fitting, regression analysis, etc.

The main thing here is that we can and should conduct a systematic analysis of our architecture in order to develop the project.

The relationship of components and their implementation


And finally, System Composer is not a separate tool that exists separately from Simulink. After defining the architecture, each of its components can be tied to a Simulink model, while you can select an existing model or create a model automatically! This allows you to run simulations and explore the behavioral characteristics of the system directly in System Composer.



Most importantly, if a model is created from a component, the input and output ports with the necessary interfaces are automatically generated in the model. This is a very important trifle, since component integration usually slows down due to inconsistent component interfaces, and pre-built interfaces solve this problem. Each generated model can be given to a specific artist and be calm that it will later be integrated into the architecture

findings


Over the course of three articles, I showed the basic design techniques at the system level. It's time to take stock.

Designing at the system level requires a fairly detailed analysis of the task and requires intuitive tools. System Composer is an easy-to-learn tool and takes full advantage of the model-oriented design methodology for creating and analyzing system architectures, as well as the analytical capabilities of MATLAB.

The use of System Composer for a thorough analysis of design decisions allows us to gain an understanding of the nature of the components and to identify potential bottlenecks in the system that would otherwise be found in the late stages of development. Various methods can be used for analysis - from data flow analysis to numerical analytics.

And, as you can see, designing at the system level is not at all scary, and tools that support system design help you with this.

Want to know more? We conducted an introductory webinar on systems engineering, and as part of this webinar, I just showed this tutorial. And my colleague Mikhail Peselnik told why system engineering is needed at all. The webinar itself is here .

More articles:


All Articles