Continuing the theme , let's look at the problem of mathematical modeling from the other side. After we have made sure that the model corresponds to the homespun truth of life, we can answer the main question: βwhat, in fact, do we have here?β. When creating a model of a technical object, we usually want to make sure that this object will meet our expectations. For this, dynamic calculations of processes are carried out and the result is compared with the requirements. This is a digital twin, a virtual prototype, and so on. fashionable shnyags who at the design stage solve the problem of how to make sure that we get what we planned.
How can we quickly make sure that our system is exactly what we are designing, will our design fly or float? And if it flies, how high? And if it swims, how deep?
This article discusses the automation of checking the fulfillment of the requirements of a technical building when creating dynamic models of technical systems. As an example, let's look at the element of the technical task for the air-cooling system of an aircraft.
We consider those requirements that can be expressed numerically and verified mathematically on the basis of a specific calculation model. It is clear that this is only a part of the general requirements for any technical system, but it is precisely for their verification that we spend time, nerves and money to create dynamic models of an object.
When describing technical requirements in the form of a document, several types of different requirements can be distinguished, each of which requires different approaches for the formation of automatic verification of compliance with the requirements.
For example, consider this small but realistic set of requirements:
- Atmospheric air temperature at the entrance to the SVO:
in the parking lot - from minus 35 to 35 ΒΊΠ‘,
in flight - from minus 35 to 39 ΒΊΠ‘. - The static pressure of atmospheric air in flight is from 700 to 1013 GPa (from 526 to 760 mm Hg).
- The total air pressure at the inlet to the SVO air intake in flight is from 754 to 1200 GPa (from 566 to 1050 mm Hg).
- Cooling air temperature:
in the parking lot - no more than 27 ΒΊΠ‘, for technical units - no more than 29 ΒΊΠ‘,
in flight - no more than 25 ΒΊΠ‘, for technical units - no more than 27 ΒΊΠ‘. - Cooling air consumption:
in the parking lot - not less than 708 kg / h,
in flight - not less than 660 kg / h. - The air temperature in the instrument compartments is not more than 60 ΒΊΠ‘.
- The amount of finely dispersed free moisture in the cooling air is not more than 2 g/kg of dry air.
Even in such a limited set of requirements, there are at least two categories that need to be handled differently in the system:
- requirements for operating conditions of the system (clauses 1-3);
- parametric requirements for the system (clauses 3-7).
Requirements of the operating conditions of the system
External conditions for the developed system during modeling can be set as boundary conditions, or as a result of the operation of the overall system.
In dynamic simulation, you need to make sure that the specified modes of operation are covered by the simulation process.
Parametric system requirements
These requirements are parameters provided by the system itself. During the simulation process, we can get these parameters as the results of the calculation and make sure that the requirements are met in each specific calculation.
Identification and coding of requirements
For the convenience of working with requirements, existing standards recommend assigning an identifier to each requirement. When assigning identifiers, it is highly desirable to use a single coding system.
A requirement code can be just a number representing the requirement ordinal, or it can contain the type of requirement code, the code of the system or machine to which it applies, the parameter code, the location code, and much more that the engineer can imagine. (See the article for an option to use encoding)
Table 1 provides a simple example of requirements coding.
- source code of requirements R - requirements of TK;
- code type requirements E - requirements - parameters of the external environment, or operating conditions
S - requirements provided by the system; - aircraft status code 0 - any, G - in the parking lot, F - in flight;
- physical parameter type code T β temperature, P β pressure, G β flow rate, humidity H;
- order number of the requirement.
| ID Requirements |
Description | Parameter |
| REGT01 | Atmospheric air temperature at the entrance to the SVO: at the parking lot - from minus 35ΒΊΠ‘. up to 35 ΒΊΠ‘. | |
| REFT01 | Atmospheric air temperature at the entrance to the SVO: in flight - from minus 35 ΒΊΠ‘ to 39 ΒΊΠ‘. | |
| REFP01 | Static pressure of atmospheric air in flight from 700 to 1013 hPa (from 526 to 760 mm Hg). | |
| REFP02 | The total air pressure at the inlet to the SVO air intake in flight is from 754 to 1200 hPa (from 566 to 1050 mm Hg). | |
| RSGT01 | Cooling air temperature: in the parking lot no more than 27 ΒΊΠ‘ | |
| RSGT02 | Cooling air temperature: in the parking lot, for technical units no more than 29 ΒΊΠ‘ | |
| RSFT01 | The temperature of the cooling air in flight is not more than 25 ΒΊΠ‘ | |
| RSFT02 | Cooling air temperature: in flight, for technical units no more than 27 ΒΊΠ‘ | |
| RSGG01 | Cooling air consumption: at a stop not less than 708 kg/h | |
| RSFG01 | Cooling air consumption: in flight not less than 660 kg/h | |
| RS0T01 | The air temperature in the instrument compartments is not more than 60 ΒΊΠ‘ | |
| RSH01 | The amount of fine free moisture in the cooling air is not more than 2 g/kg of dry air |
Requirements check system design.
For each calculation requirement, there is an algorithm for assessing the correspondence between the calculation parameters and the parameters specified in the requirement. By and large, any control system always contains algorithms for checking requirements simply by default. And even any regulator contains them. If the temperature is out of range, the air conditioner turns on. Thus, the first stage of any regulation is to check the compliance of the parameters with the requirement.
And since verification is an algorithm, then we can use the same tools and tools that we use to create control programs. For example, the SimInTech environment allows you to create project packages containing various parts of the model, made in the form of separate projects (object model, control system model, environment model, etc.).
The requirements check project in this case becomes the same algorithm project and is connected to the model package. And in the dynamic simulation mode, it performs an analysis for compliance with the requirements of the TOR.
A possible example of designing a system project is shown in Figure 1.
Figure 1. An example of designing a verification project.
As well as for control algorithms, requirements can be formatted as a set of sheets. For the convenience of working with algorithms in structural modeling environments such as SimInTech, Simulink, AmeSim, the possibilities of creating multilevel structures in the form of submodels are used. This organization allows you to group various requirements into sets to simplify the work with an array of requirements, as is done for control algorithms (see Fig. 2).
Figure 2. Hierarchical structure of the requirements verification model.
For example, in the case under consideration, two groups are distinguished: requirements for the environment and requirements directly to the system. Therefore, a two-level data structure is used: two groups, each of which is a leaf of the algorithm.
To connect data to the model, a standard scheme for generating a signal database is used, which stores data for exchange between parts of the project.
When creating and testing software, the readings of sensors (analogues of real sensors of the system) that are used by the control system are placed in this database.
For a test project, any parameters calculated in the dynamic model can be stored in the same database and thus used to verify that the requirements are met.
The dynamic model itself in this case can be implemented in any mathematical modeling system or even as an executable program. The only requirement is the availability of software interfaces for issuing simulation data to the external environment.
Figure 3. Connecting the test project to the complex model.
An example of a basic requirements check sheet is shown in Figure 4. From the developer's point of view, it is a common calculation scheme that graphically presents the requirements check algorithm.
Figure 4. Requirements check sheet.
The main parts of the check sheet are described in Figure 5. The check algorithm is formed similarly to the design schemes of control algorithms. On the right side there is a block for reading signals from the database. In this block, the signal database is accessed during the simulation.
The received signals are analyzed to calculate the requirements verification conditions. In this case, an altitude analysis is performed to determine the position of the aircraft (whether it is parked or in flight). For this purpose, other signals and calculated parameters of the model can also be used.
The test conditions and the parameters to be checked are passed to the typical test blocks, in which the parameter data is analyzed for compliance with the specified requirements. The results are recorded in the signal database in such a way that they can be used to automatically generate a checklist.
Figure 5. The structure of the payroll check requirements.
It is not necessary to use the signals contained in the database as the parameters to be checked, which are controlled by the parameters calculated during the simulation. Nothing prevents us from carrying out additional calculations within the framework of the draft requirements, just as we calculate the verification conditions.
For example, this requirement:
The number of inclusions of the corrective system during the flight to the target should not exceed the number 5, and the total time of the corrective system should not exceed 30 seconds.
In this case, the algorithm of the counter of the number of inclusions and the total operating time is added to the calculation scheme of the requirements project.
Typical requirements check block.
Each generic requirement check box is designed to calculate the fulfillment of a particular type of requirement. For example, in the environmental requirements, there is a range of operating ambient temperatures in the parking lot and in flight. This block should receive the air temperature in the model as a parameter and determine whether this parameter covers the specified temperature range./p>
The block contains two input ports, param and condition.
The parameter to be checked is applied to the first one. In this case, "Ambient temperature".
A Boolean variable is supplied to the second port - the condition for performing the check.
If the second input is TRUE (1), then the block performs the requirement check calculation.
If FALSE (0) comes to the second input, then the verification conditions are not met. This is necessary in order to be able to take into account the calculation conditions. In our case, this input is used to enable or disable validation depending on the state of the model. If the aircraft is on the ground during the simulation, then flight-related requirements are not checked, and vice versa, if the aircraft is in flight, then parking requirements are not checked.
This input can also be used when setting up the model, for example, at the initial stage of the calculation. When the model is brought to the required state, the check blocks are disabled, but as soon as the system enters the required mode of operation, the check blocks are turned on.
The parameters of this block are:
- boundary conditions: upper (UpLimit) and lower (DownLimit) limits of the ranges to be checked;
- required system exposure time at the boundary ranges (TimeInterval) in seconds;
- ReqName request identifier;
- out of range tolerance Out_range is a Boolean variable that determines whether it is a violation of the requirement for a value to be out of the checked range.
In some cases, the output of the tested value means that the system has a headroom and may be operating outside the operating range. In other cases, exit means that the system is unable to keep the specified parameters within the range.
Figure 6. A typical block for checking a property on a diagram and its parameters.
As a result of the calculation of this block, the Result variable is formed at the output, which takes the following values:
- 0 - rNone, value is not defined;
- 1 - rDone, the requirement is fulfilled;
- 2 - rFault, the requirement is not met.
The block image contains:
- identifier text;
- digital displays of measurement limits parameters;
- color identifier of the parameter state.
Inside the block, there can be a rather complex logic inference circuit.
For example, to check the operating temperature range of the block shown in Figure 6, the internal circuit is shown in Figure 7.
Figure 7. Internal diagram of the block for determining the temperature range.
Inside the schematic block, the properties specified in the block parameters are used.
In addition to requirements compliance analysis, the internal block diagram contains a graph necessary to display simulation results. This graph can be used both for viewing during the calculation and for analyzing the results after the calculation.
The results of the calculation are transmitted to the output of the block and are simultaneously written to a common report file, which is created based on the results for the entire project. (see fig. 8)
An example of a report created based on the simulation results is an html file created according to a given format. The format can be arbitrarily configured to the format adopted in a particular organization.
Inside the schematic block, the properties specified in the block parameters are used.
In addition to requirements compliance analysis, the internal block diagram contains a graph necessary to display simulation results. This graph can be used both for viewing during the calculation and for analyzing the results after the calculation.
The results of the calculation are transmitted to the output of the block and are simultaneously written to a common report file, which is created based on the results for the entire project. (see fig. 8)
An example of a report created based on the simulation results is an html file created according to a given format. The format can be arbitrarily configured to the format adopted in a particular organization.
Figure 8. An example of a report file on the results of the simulation.
In this example, the report form is configured directly in the project properties, and the format in the table is set as global project signals. In this case, SimInTech solves the task of setting up the report itself, and the block for writing results to a file uses these lines to write to the report file.
Figure 9. Setting the report format in the project's global signals
Using the signals database for requirements.
To automate work with property settings, a typical structure is created in the signal database for each type block. (see fig. 10)
Figure 10. An example of the structure of the requirement check block in the signal database.
Signal database, provides:
- Storage of all necessary system requirements parameters.
- Easily view the requirements existing in the project from the given parameters and the current simulation results.
- Setting up one block, a group of blocks using a scripting programming language. Changes in the signal database lead to changes in block property values ββin the diagram.
- Storage of text descriptions, links to TOR items or identifiers in the requirements management system.
Signal database structures for requirements can be easily configured to work with a third-party requirements management system. The general scheme of interaction with requirements management systems is shown in Figure 11.
Figure 11. Scheme of interaction with the requirements management system.
The sequence of interaction between the SimInTech test project and the requirement management system is as follows:
- The technical task is divided into requirements.
- Such requirements of the technical task are singled out, which can be verified by mathematical modeling of technical processes.
- The attributes of the selected requirements are transferred to the SimInTech signal database in the structures of typical blocks (for example, maximum and minimum temperatures).
- During the calculation, the data of the structures are transferred to the calculation schemes of the blocks, the analysis is performed and the results are stored in the signal database.
- Upon completion of the calculation, the results of the analysis are transferred to the requirements management system.
Requirements steps 3 to 5 may be repeated during the design process when there are changes to the design and/or requirements and, accordingly, the impact of the changes needs to be rechecked.
Conclusions.
- The created prototype of the system provides a significant reduction in the time of analysis of existing models for compliance with the requirements of the TOR.
- The proposed testing technology uses already existing dynamic models and can be used even for any dynamic models, including those made not in the SimInTech environment.
- The use of batch data organization allows you to create requirements testing packages in parallel with the development of models, or even use these packages as a specification for the development of models.
- The technology can be integrated with existing requirements management systems at no significant cost.
For those who have read to the end,
Source: habr.com