To coordinate the operation of network devices from different manufacturers, ensuring the interaction of networks that use a different signal propagation medium, a reference model for the interaction of open systems (OSI) has been created. reference model built on a hierarchical basis. Each layer provides a service to a higher layer and uses the services of a lower layer.
Data processing starts from the application layer. After that, the data passes through all layers of the reference model, and through the physical layer is sent to the communication channel. At the reception is reverse processing data.
The OSI reference model introduces two concepts: protocol And interface.
A protocol is a set of rules on the basis of which the layers of various open systems interact.
An interface is a set of means and methods of interaction between elements of an open system.
The protocol defines the rules for the interaction of modules of the same level in different nodes, and the interface determines the rules for the interaction of modules of neighboring levels in the same node.
There are seven layers of the OSI reference model in total. It is worth noting that real stacks use fewer levels. For example, the popular TCP/IP uses only four layers. Why is that? We'll explain a little later. Now let's look at each of the seven levels separately.
Layers of the OSI model:
- physical level. Defines the type of data transmission medium, physical and electrical characteristics interfaces, signal type. This layer deals with bits of information. Examples of physical layer protocols: Ethernet, ISDN, Wi-Fi.
- channel level. Responsible for access to the transmission medium, error correction, reliable data transmission. At the reception The data received from the physical layer is packed into frames, after which their integrity is checked. If there are no errors, then the data is transferred to the network layer. If there are errors, the frame is discarded and a retransmission request is generated. The link layer is divided into two sublayers: MAC (Media Access Control) and LLC (Local Link Control). The MAC regulates access to the shared physical medium. LLC provides network layer service. Switches work at the link layer. Protocol examples: Ethernet, PPP.
- network layer. Its main tasks are routing - determining the optimal path for data transmission, logical addressing of nodes. In addition, network troubleshooting tasks (ICMP protocol) can be assigned to this level. The network layer deals with packets. Protocol examples: IP, ICMP, IGMP, BGP, OSPF).
- transport layer. Designed to deliver data without errors, loss and duplication in the order in which they were transmitted. Performs end-to-end control of data transfer from the sender to the recipient. Protocol examples: TCP, UDP.
- session level. Manages the creation/maintenance/termination of a communication session. Protocol examples: L2TP, RTCP.
- Executive level. Performs data transformation into the desired form, encryption/encoding, compression.
- Application level. Carries out the interaction between the user and the network. Interacts with client-side applications. Protocol examples: HTTP, FTP, Telnet, SSH, SNMP.
After getting acquainted with the reference model, we will consider the TCP / IP protocol stack.
The TCP/IP model defines four layers. As you can see from the figure above, one TCP / IP layer can correspond to several layers of the OSI model.
Layers of the TCP/IP model:
- Network interface layer. Corresponds to the two lower layers of the OSI model: link and physical. Based on this, it is clear that this level determines the characteristics of the transmission medium (twisted pair, optical fiber, radio air), the type of signal, the encoding method, access to the transmission medium, error correction, physical addressing (MAC addresses). In the TCP / IP model, the Ethrnet protocol and its derivatives (Fast Ethernet, Gigabit Ethernet) operate at this level.
- Interworking layer. Corresponds to the network layer of the OSI model. Takes over all its functions: routing, logical addressing (IP addresses). On given level the IP protocol is working.
- transport layer. Corresponds to the transport layer of the OSI model. Responsible for delivering packets from source to destination. At this level, two protocols are involved: TCP and UDP. TCP is more reliable than UDP by making pre-connection requests for retransmission when errors occur. However, at the same time, TCP is slower than UDP.
- Application level. Its main task is to interact with applications and processes on hosts. Protocol examples: HTTP, FTP, POP3, SNMP, NTP, DNS, DHCP.
Encapsulation is a method of packing a data packet, in which the service headers of the packet, independent of each other, are abstracted from the headers of lower levels by including them in higher levels.
Let's look at a specific example. Suppose we want to get from the computer to the site. To do this, our computer must prepare an http request to receive the resources of the web server on which the page of the site we need is stored. At the application layer, an HTTP header is added to the data (Data) of the browser. Further, at the transport level, a TCP header is added to our packet, containing the port numbers of the sender and recipient (port 80 for HTTP). At the network level, an IP header is formed containing the IP addresses of the sender and recipient. Immediately before transmission, an Ethernet header is added at the data link layer, which contains the physical (MAC addresses) of the sender and recipient. After all these procedures, the packet in the form of bits of information is transmitted over the network. On admission, the process is reversed. The web server at each level will check the corresponding header. If the check is successful, then the header is discarded and the packet goes to the upper level. Otherwise, the entire packet is dropped.
Support the project
Friends, the Netcloud website is developing every day thanks to your support. We plan to launch new sections of articles, as well as some useful services.
You have the opportunity to support the project and contribute any amount you see fit.
A model with an ideal point involves comparing a specific product or other object with some standard as a difference. In accordance with the model, each feature is normalized as a distance from the ideal or reference value of the feature. To apply the model, first of all, an idea is formed of an ideal product from the point of view of consumers - an "ideal" point X0 is introduced.
The model characterizes the degree of closeness of a particular product to the "ideal" one in accordance with the dependence
Where TO i – weight coefficients; X 0i – ideal point coordinates. Exponent T is chosen by the researcher and usually takes values at level 1 or 2. The summation is carried out over P product properties. Low values are best W, for if the ideal point is the best, then it is obvious that a minimum distance from it is desirable.
The choice of the ideal point is rather complicated and ambiguous. The reader should pay attention to the following possible approaches to choosing an ideal point.
- 1. The best scores in terms of severity: "all fives". If we consider such a consumer attribute as the convenience of controlling complex equipment, such as a car or a music center, then the coordinates of the ideal point will correspond to the border of the selected scale. However, the corresponding hypothetical "best in all respects" product will be far from reality, since there is not always a product that is the best in all respects. In particular, it is difficult to combine the properties of a limousine and an SUV in one car. If best product still exists, its price will be excessively high.
- 2. Application of the parameters of the real most competitive or "best on the market" product according to the principle: "my dream girl" or "real man". The peculiarity of this approach is that deviations from the ideal point in any direction, even in the direction of formal improvement, are considered undesirable.
- 3. Applying such objective properties when there is an optimal level of the property. In this case, the ideal levels will not necessarily be either the highest or the lowest. In such a situation, the use of a model with an ideal exact one is most justified. Examples of parameters with the optimum: TV screen size for a car or kitchen, TV picture brightness. good example The presence of an optimal level is the illumination of the room, when "too bright" and "too dark" are equally undesirable. A remark should be made about the need to specify the purpose of the product. So, if you do not indicate that the TV is intended for the kitchen, then you may want to consider the largest TV on sale as ideal.
- 4. Best properties for a given price. The following approach is proposed. In order not to put "all fives", which in principle is not required, and it is unrealistic for the price, you must have regression model the dependence of price on property levels, which corresponds to parametric pricing. Then the expert can choose a set of properties at each price level available to him. And this is real, because the approach "mobile should not cost more than ten thousand" is used by many.
Obviously, to apply the model with an ideal point, the dimensions of all coordinates must match in order to be able to sum the corresponding quantities in the formula. One way out of the problem is to use dimensionless scoring. Another way, which is discussed below, is normalization, when the actual levels are divided into reference or normative, which can also be the coordinates of an ideal point.
Model with normalized levels of factors
The use of models with relative factors makes it possible to combine factors with different dimensions in one model. The corresponding model looks like this:
(16.2)
All designations correspond to those introduced in formula (16.1); Zi are parametric indices.
The model is widely used in the calculation of product quality indices and, especially, in assessing competitiveness. When calculating quality indices X i0 - normative, specified by the standards and technical conditions, the levels of manifestation of the properties of the goods. As a rule, the model (16.2) is applied while simultaneously considering the objective (production and operational) properties of the product, such as speed, power, dimensions, reliability, etc., although it is possible to consider objective properties as well.
When assessing competitiveness X i0 – parameters of the product being compared, which may be the product of the strongest competitor. In the literature on competitive analysis, there are various names for the indicator - consolidated parametric index of consumer properties, group indicator of competitiveness.
The reference model architecture artificially includes two dimensions:
process measurement, which characterizes the results of the process, which are significant measurable goals of the process;
process capability measurement, which characterizes a set of process attributes that are applicable to any process and are measurable characteristics that are necessary to control the process and improve its ability to perform.
The reference model groups processes, when measuring a process, into three life cycle process groups that contain five process categories according to the type of activity to which it addresses.
Initial life cycle processes consist of categories of processes supplier - customer and engineering.
Process category supplier - customer consists of processes that are directly affected by the customer, the development of support and the transition of the software to the customer, and provide for the correct functioning and use of the software product and / or services.
Engineering process category consists of the processes that directly define, implement, or support the software product, its relation to the system, and its consumer (customer) documentation.
Supporting life cycle processes consist of support process categories.
Organizational life cycle processes consist of categories of management and organization processes.
Control process category consists of processes that contain general methods that can be used by anyone who manages any type of project or process within the software life cycle.
Organization process category consists of the processes that set the organization's business goals and develop (develop) the process, product, and active resources that, when used by projects in the organization, will help the organization achieve its business goals.
Process Categories and Processes provide a grouping of activity types. Each process in the reference model is described in terms of a goal statement. These claims include the unique functional goals of the process that are validated in a specific environment. The goal statement includes additional material that defines the outcomes of successful implementation of the process. Meeting the purpose of a process represents the first step in building process capability.
The reference model does not specify how, or in what order, the elements of the process goal statements are to be achieved. The process objectives will be achieved in the organization through various lower level activities, tasks and practices performed to produce a work product. These tasks, activities, and practices performed, as well as the characteristics of the work products produced, are indicators that demonstrate whether the goal of a particular process has been achieved.
Process capability development is characterized in terms of process attributes grouped into capability levels. Process attributes are attributes of a process that can be assessed on an achievement scale, providing a measure of the capability of a process. Attributes apply to all processes. Each process attribute describes an aspect of the overall ability to manage and improve the effectiveness of the process in achieving its goals and contributing to the business goals of the organization.
A feature level is characterized by a set of attributes that work together. Each level provides a major extension of the ability to execute a process. Levels constitute a rational way of development through the improvement of the possibility of any process.
There are six capability levels in the reference model.
Level 0: Unfinished. General failure to achieve the goal of the process. There are not easily identified work products or process outputs.
Level 1: Executable. The goal of the process, in general, is achieved. Achievement cannot be strictly planned and tracked. The organization's personnel are aware that the process must be performed and there is general agreement that the process is performed as required and when required. There are certain work products of the process, and they testify in favor of achieving the goal.
Level 2: Managed. The process produces work products according to certain procedures, is planned and monitored. Work products meet specific standards and requirements. The main difference from Executable level in that the execution of the process now produces work products that fully meet the quality requirements within a certain period of time and an allocated resource.
Level 3: Installed. The process is executed and controlled using a defined process based on good software engineering principles. Individual process implementations use documenting processes, approved, customized versions of the standard, in achieving specific process outcomes. The resources needed to establish a process definition are also in place. The main difference from managed level that the process Set level uses a specific process that is able to achieve its outputs.
Level 4: Predictable. A certain process, in practice, is consistently performed within certain limits and achieves certain goals. Detailed process steps are collected and analyzed. This leads to a quantitative understanding of process capability and an improved ability to predict performance. The execution of the process is objectively controlled. The quality of work products is quantitatively known. The main difference from Set level in that a certain process is now executed sequentially within certain limits in order to achieve its certain outputs.
Level 5: Optimizing. Process execution is optimized to meet current and future business needs. The process achieves repeatability when certain business goals are achieved. Quantified process performance and performance targets for performance are established based on the organization's business objectives. A continuous process monitoring these goals allows for quantitative feedback and improvement is achieved by reviewing the results. The main difference from predictable level in that defined and standard processes are now dynamically changing and adapting to effectively achieve current (actual) and future business goals.
Naturally, the reference model cannot be used as a basis for making reliable and consistent process capability assessments, as the level of detail is not sufficient. The process goal and capability attribute descriptions in the reference model need to be supported by a comprehensive set of process performance and capability metrics. In this way, a consistent process capability rating will be possible.
Process measurement
This subsection provides a classification of the processes adopted by organizations involved in the development, operation, acquisition, delivery and maintenance of software. The classification recognizes five categories of processes that contain all processes. The categories and their processes are comparable to those defined in draft ISO/IEC 12207, Information technology - Software process life cycle, discussed in Section 2.
As noted above, in the reference model, processes are grouped into three groups and five categories of processes:
initial life cycle processes include engineering process categories and supplier - customer;
supporting life cycle processes include support process categories;
organizational life cycle processes include the categories of process management and organization.
Individual processes are described in terms of six components.
Process ID. Identifies a category and a sequence number within that category. The numbering scheme differs between top-level processes and second-level processes. The identifier consists of two parts: a category abbreviation (for example, ENG for the engineering process category) and a number (for example, CUS. 1 indicates the Acquisition Process and CUS. 1.2 indicates the second level process, the Supplier Selection Process, which is a component process of the Acquisition Process ).
Process name. A descriptive phrase that highlights a fundamental property of a process (for example, Supplier Selection).
Process type. There are 3 types of top-level processes (basic, extended, new) and 2 second-level processes (component, extended) that are related to ISO/IEC 12207 processes as follows. The new processes are in addition to those defined in ISO/IEC 12207. processes are identical in purpose to ISO/IEC 12207 processes. Extended processes are augmented on an existing ISO/IEC 12207 process. Component processes group one or large quantity ISO/IEC 12207 actions from the same process. Extended component processes group one or more ISO/IEC 12207 activities from the same process and include additional material.
Purpose of the process. Material that specifies the purpose of the process, setting the overall goals for the execution of the process at the top level. Optional additional material may be included to further define the goal statement.
Process results. List of process result descriptions.
Process notes. An optional list of informative notes about the process and its relationship to other processes.
For example, here are a few processes from each process category.
CUS.1 Acquisition Process
Basic process
Target Acquisition Process is to obtain a product and / or service that satisfies the need expressed by the customer (client). The process begins with the definition of the customer's need and desired results, with acceptance of the product and/or service required by the customer. As a result of the successful implementation of the process:
A contract will be developed that clearly expresses the expectations, duties and obligations of both the customer and the supplier;
A product and / or service will be produced that will satisfy the identified need of the customer;
The acquisition will be verified so that certain constraints such as cost, plan and quality are met.
CUS.1.1 Acquisition Preparation Process
Component Process CUS.1 - Acquisition Process
Target Acquisition Preparation Process is to establish the needs and objectives of the acquisition. As a result of the successful implementation of the process:
The need to acquire, develop, or expand a system, software product, or software development process will be identified;
System requirements will be formulated;
An acquisition strategy will be developed;
Acceptance criteria will be defined.
ENG.1 Development Process
Basic process
Target development process is to transform an agreed set of requirements into a functional software product or software system that meet the stated needs of the customer. As a result of the successful implementation of the process:
A software product or software system will be developed;
Intermediate work products will be developed, which shows that the final product is based on agreed requirements;
Consistency between software requirements and software designs will be established;
The test data will show that the final product meets the agreed requirements;
The final product will be installed in the target environment and accepted by the customers.
NOTE: Agreed requirements may be provided by an Acquisition Process (CUS. 1) or Requirements Establishment Process (CUS. 3) operation.
ENG.1.1 System Requirements Development and Analysis Process
Component Process ENG.1 - Development Process
The purpose of the System Requirements Design and Analysis Process is to establish the system requirements (functional and non-functional) and architecture, identifying which system requirements should be allocated to which elements of the system and in which version. As a result of the successful implementation of the process:
System requirements will be developed, which corresponds to the established needs of the customer;
A solution will be proposed identifying the main elements of the system;
The agreed requirements will be allocated to each of the main elements of the system;
A release strategy will be developed to prioritize implementation system requirements;
System requirements will be approved and modified as required;
The requirements, the proposed solution and their links will be communicated to all interested parties.
SUP.1 Documentation Process
Advanced Process
Target Document Development Process is to develop and maintain documents that record the information generated by a process or activity. As a result of the successful implementation of the process:
A strategy will be developed identifying the documents that will be produced during the life cycle of the software product;
The standards to be consulted for the development of documents will be defined;
All documents to be produced by the process or project will be identified;
All documents will be developed and published in accordance with certain standards;
All documents will be maintained in accordance with certain criteria.
NOTE - The process supports the execution of process attribute 2.2 in the examples where it is introduced.
MAN.1.1 Project Management Process
Component Process MAN.1 - Management Process
Target Project Management Process is to identify, establish, coordinate, and control the activities, tasks, and resources needed for a project to create a product and/or service to meet agreed requirements. As a result of the successful implementation of the process:
The scope of the project will be defined;
The feasibility of achieving project objectives with available resources and constraints will be assessed;
The tasks and resources required to complete the work will be measured and evaluated;
Interfaces between project elements and other projects and organizational units will be identified and tested;
Project implementation plans will be developed and implemented;
The progress of the project will be checked and reported;
Actions to correct deviations from the plan and prevent recurrence of problems identified in the project will be taken when the project objectives are not achieved.
NOTE This process supports the execution of process attribute 2.1 in the examples where it is introduced.
ORG.2 Improvement Process
Basic Process
The Improvement Process is a process for establishing, evaluating, measuring, managing and improving the software life cycle process. As a result of the successful implementation of this process:
A set of organizational process assets will be developed and made available;
The organization's process capability will be periodically assessed to determine the extent to which the implementation of the process is effective in achieving the organization's objectives;
Measuring Opportunity
The reference model capability dimension defines the measurement scale for evaluating the process capability of any process. The capability of a process is defined on a six-point ordinal scale that allows one to rate capability from the bottom of the scale, the unfinished level, to the top end of the scale, the optimizing level. The scale defines the improvement in the capability of an ongoing process from efficiency that is incapable of delivering specific results up to efficiency that is capable of meeting the business goal and supporting continuous process improvement. Therefore, the scale defines a clear path for improvement for each individual process.
Within the capability model, the capability measure is based on a set of nine process attributes (PAs) (see Table 4.1). Process attributes are used to determine whether a process has reached a given capability. Each attribute measures a specific aspect of process capability. The attributes are themselves measured on a percentage scale and therefore provide a more detailed understanding of the specific aspects of the process capability required to support process improvement and capability determination.
For example, let's take one of the attributes of the third level of capability.
AP 3.1 Attribute Definition and Process Transformation
To what extent a process is executed as a converted instance of a standard process definition. The standard process meets the defined business objectives of the organization. The transformation is performed to suit the specific purposes of the process instance. As a result of fully reaching this attribute:
Process documentation, together with appropriate guidance on customizing standard process documentation, will be determined that is capable of providing the normal process scope and functional and non-functional requirements for the work product;
The execution of the process will be carried out in accordance with the selected and/or adapted standard process documentation;
Historical process execution data will be collected, firstly, to establish and improve understanding of process behavior, secondly, to assess process execution resource needs;
Experiences from the use of process documentation will be used to improve the standard process.
Table 4.1.
|
Number |
Name |
|
Level 1 |
Running process |
|
AP 1.1 |
Process execution attribute |
|
Level 2 |
Managed Process |
|
AP 2.1 |
Execution control attribute |
|
AP 2.2 |
Work Product Management Attribute |
|
Level 3 |
Established process |
|
AP 3.1 |
Process definition and transformation attribute |
|
AP 3.2 |
Process resource attribute |
|
Level 4 |
predictable process |
|
AP 4.1 |
Process dimension attribute |
|
AP 4.2 |
Process control attribute |
|
Level 5 |
Optimizing Process |
|
AP 5.1 |
Process change (verification) attribute |
|
AP 5.2 |
Improvement Opportunity Attribute |
A process attribute represents a measurable characteristic of any process, as defined above.
N Not reached:
0% - 15% - There is little or no confirmation of achievement of a particular attribute.
P Partially reached:
16% - 50% - there is evidence of a reliable systematic method to achieve a certain attribute. Some aspects of achievement can be unpredictable.
L Largely achieved:
51% - 85% - there is evidence of a reliable systematic method to a significant achievement of a certain attribute. Process execution may vary in some areas.
F Fully reached:
86% - 100% - there is confirmation of a complete and systematic method to the complete achievement of a certain attribute. No significant deficiencies exist within a particular part of the organization.
Each process attribute assessed in any part of the organization, including the highest capability level defined in the scope of assessment, must be consistent with a rating using the attribute scale defined above. The set of attribute ratings for a process forms a profile for that process. The evaluation output includes a set of profiles for all evaluated processes.
The identifier used must provide objective evidence of use in order to determine the rating to be retrieved. Ratings may be presented in any format, such as matrices or as part of a database, provided that the presentation allows the identification of individual ratings according to this reference scheme.
The capability level achieved by a process shall be derived from the attribute rating for that process, according to the process capability level model defined in Table 4.2. The purpose of this requirement is to ensure that values are consistent when a process capability level is referenced for a process.
The tables below provide summary lists of the processes that are included in the reference model (table 4.3) and the correspondence between the processes of the reference model and the processes defined in draft ISO/IEC 12207 (table 4.4).
Table 4.2
|
Scale |
Process attributes |
Grade |
|
Level 1 |
Process execution |
Mainly or completely |
|
Level 2 |
Process execution Execution control Work Product Management |
Fully Mainly or completely Mainly or completely |
|
Level 3 |
Process execution Execution control Work Product Management Process resource |
Fully Fully Fully Mainly or completely Mainly or completely |
|
Level 4 |
Process execution Execution control Work Product Management Process definition and transformation Process resource Process measurement Process control |
Fully Fully Fully Fully Fully Mainly or completely Mainly or completely |
|
Level 5 |
Process execution Execution control Work Product Management Process definition and transformation Process resource Process measurement Process control Process change Possibility of further improvement |
Fully Fully Fully Fully Fully Fully Fully Mainly or completely Mainly or completely |
Table 4.3.
|
Process |
|||||
|
Number |
Name |
Number |
Name |
||
|
Acquisition (basic) |
|||||
|
Acquisition preparation (component) |
|||||
|
Vendor selection (component) |
|||||
|
Vendor Check (Component) |
|||||
|
Customer approval (component) |
|||||
|
Support (Basic) |
|||||
|
Requirements setting (new) |
|||||
|
Operation (advanced) |
|||||
|
Functional Usage (Advanced Component) |
|||||
|
User Support (Advanced Component) |
|||||
|
Development (basic) |
|||||
|
Analysis and development of system requirements (component) |
|||||
|
Software requirements analysis (component) |
|||||
|
Software development (component) |
|||||
|
Software design (component) |
|||||
|
Software integration (component) |
|||||
|
Software testing (component) |
|||||
|
System testing and integration (component) |
|||||
|
Operation of the system and software (basic) |
|||||
|
Supporting life cycle processes |
|||||
|
Documentation (advanced) |
|||||
|
Configuration management (basic) |
|||||
|
Quality assurance (basic) |
|||||
|
Verification (basic) |
|||||
|
Validation (Basic) |
|||||
|
Joint review (baseline) |
|||||
|
Check (basic) |
|||||
|
Problem solving (basic) |
|||||
|
Measurement (new) |
|||||
|
Reusable (new) |
|||||
|
Management (basic) |
|||||
|
Project management (component) |
|||||
|
Quality management (new) |
|||||
|
Risk management (new) |
|||||
|
Organizational alignment (new) |
|||||
|
Improvement process (basic) |
|||||
|
Create a process (component) |
|||||
|
Process evaluation (component) |
|||||
|
Process improvement (component) |
|||||
|
Human Resource Management (advanced) |
|||||
|
Infrastructure (basic) |
|||||
|
Table 4.4. |
||||||||||||||||||
|
Activities and processes 12207 |
Processes 15504 | |||||||||||||||||
|
Initial life cycle processes | ||||||||||||||||||
|
Acquisition process |
Acquisition process |
basic |
||||||||||||||||
|
Initialization |
Acquisition preparation process |
Component |
||||||||||||||||
|
Preparing a Bid-for-Proposal [-bid] |
Supplier selection process |
Component |
||||||||||||||||
|
Contract preparation and adjustment |
Supplier selection process |
Component |
||||||||||||||||
|
Vendor verification |
Vendor Verification Process |
component |
||||||||||||||||
|
Acceptance and completion |
Customer approval process |
component |
||||||||||||||||
|
Delivery process |
Delivery process |
basic |
||||||||||||||||
|
Initialization |
Delivery process |
basic |
||||||||||||||||
|
Preparing a response |
Delivery process |
basic |
||||||||||||||||
|
Contract |
Delivery process |
basic |
||||||||||||||||
|
Planning |
Delivery process |
basic |
||||||||||||||||
|
Execution and management |
Delivery process |
basic |
||||||||||||||||
|
Review and evaluation |
Delivery process |
basic |
||||||||||||||||
|
Delivery and completion |
Delivery process |
basic |
||||||||||||||||
|
Requirements setting process | ||||||||||||||||||
|
Development process |
Development process |
basic |
||||||||||||||||
|
Process Implementation |
Development process |
basic |
||||||||||||||||
|
Analysis of system requirements |
component |
|||||||||||||||||
|
System architecture development |
System requirements development and analysis process |
component |
||||||||||||||||
|
Analysis of software requirements |
Software requirements analysis process |
component |
||||||||||||||||
|
Software architecture development |
Software development process |
component |
||||||||||||||||
|
Working draft software |
Software development process |
component |
||||||||||||||||
|
Software coding and testing |
Software Design Process |
component |
||||||||||||||||
|
Software integration |
Software integration process |
component |
||||||||||||||||
|
Software qualification testing |
Software testing process |
component |
||||||||||||||||
|
System integration |
component |
|||||||||||||||||
|
System Qualification Testing |
System testing and integration process |
component |
||||||||||||||||
|
Software installation |
Delivery process |
basic |
||||||||||||||||
|
Software support |
Delivery process |
basic |
||||||||||||||||
|
Functioning process |
basic |
|||||||||||||||||
|
Process Implementation |
Functional use process |
extended component |
||||||||||||||||
|
Functional testing |
Functional use process |
extended component |
||||||||||||||||
|
System operation |
Functional use process |
extended component |
||||||||||||||||
|
User support |
User support process |
extended component |
||||||||||||||||
|
Operating process |
basic |
|||||||||||||||||
|
Process Implementation |
Software and system operation process |
basic |
||||||||||||||||
|
Analysis of problems and modifications |
Software and system operation process |
basic |
||||||||||||||||
|
Implementation of the modification |
Software and system operation process |
basic |
||||||||||||||||
|
Commissioning |
Software and system operation process |
basic |
||||||||||||||||
|
Migration |
Software and system operation process |
basic |
||||||||||||||||
|
Software recycling |
Software and system operation process |
basic |
||||||||||||||||
|
Supporting life cycle processes | ||||||||||||||||||
|
Documentation process |
Documentation process |
extended |
||||||||||||||||
|
Process Implementation |
Documentation process |
extended |
||||||||||||||||
|
Design and development |
Documentation process |
extended |
||||||||||||||||
|
Products |
Documentation process |
extended |
||||||||||||||||
|
Exploitation |
Documentation process |
extended |
||||||||||||||||
|
Configuration management process |
Basic |
|||||||||||||||||
|
Process Implementation |
Configuration management process |
basic |
||||||||||||||||
|
Configuration Identification |
Configuration management process |
basic |
||||||||||||||||
|
Configuration control |
Configuration management process |
basic |
||||||||||||||||
|
Accounting for configuration status |
Configuration management process |
basic |
||||||||||||||||
|
Configuration evaluation |
Configuration management process |
basic |
||||||||||||||||
|
Release and delivery management |
Configuration management process |
basic |
||||||||||||||||
|
Quality Assurance Process |
Quality Assurance Process |
basic |
||||||||||||||||
|
Process Implementation |
Quality Assurance Process |
basic |
||||||||||||||||
|
Product Warranty |
Quality Assurance Process |
basic |
||||||||||||||||
|
Process Guarantee |
Quality Assurance Process |
basic |
||||||||||||||||
|
Quality assurance systems |
Quality Assurance Process |
basic |
||||||||||||||||
|
Verification process |
Verification process |
basic |
||||||||||||||||
|
Process Implementation |
Verification process |
basic |
||||||||||||||||
|
Verification |
Verification process |
basic |
||||||||||||||||
|
Validation Process |
basic |
|||||||||||||||||
|
Process Implementation |
Validation Process |
basic |
||||||||||||||||
|
Validation |
Validation Process |
basic |
||||||||||||||||
|
Joint review process |
Joint review process |
basic |
||||||||||||||||
|
Process Implementation |
Joint review process |
basic |
||||||||||||||||
|
Project Management Reviews |
Joint review process |
basic |
||||||||||||||||
|
Technical reviews |
Joint review process |
basic |
||||||||||||||||
|
Verification process |
Verification process |
basic |
||||||||||||||||
|
Process Implementation |
Verification process |
basic |
||||||||||||||||
|
Verification process |
basic |
|||||||||||||||||
|
Problem Solving Process |
Problem Solving Process |
basic |
||||||||||||||||
|
Process Implementation |
Problem Solving Process |
basic |
||||||||||||||||
|
Problem solving |
Problem Solving Process |
basic |
||||||||||||||||
|
Measurement process | ||||||||||||||||||
|
Reuse process | ||||||||||||||||||
|
Organizational life cycle processes | ||||||||||||||||||
|
Management process |
Management process |
basic |
||||||||||||||||
|
Initialization and Scoping |
Project Management Process |
component |
||||||||||||||||
|
Planning |
Project Management Process |
component |
||||||||||||||||
|
Execution and control |
Project Management Process |
component |
||||||||||||||||
|
Review and evaluation |
Project Management Process |
component |
||||||||||||||||
|
closure |
Project Management Process |
component |
||||||||||||||||
|
Quality Management Process | ||||||||||||||||||
|
Risk management process | ||||||||||||||||||
|
Organizational alignment process | ||||||||||||||||||
|
Infrastructure Process |
Infrastructure Process |
basic |
||||||||||||||||
|
Process Implementation |
Infrastructure Process |
basic |
||||||||||||||||
|
Creation of infrastructure |
Infrastructure Process |
basic |
||||||||||||||||
|
Infrastructure operation |
Infrastructure Process |
basic |
||||||||||||||||
|
Improvement process |
Improvement process |
basic |
||||||||||||||||
|
Create a process |
Process creation process |
component |
||||||||||||||||
|
Process evaluation |
Process evaluation process |
component |
||||||||||||||||
|
Process improvement |
Improvement process |
component |
||||||||||||||||
|
Process preparation |
extended |
|||||||||||||||||
|
Process Implementation |
Human resource management process |
extended |
||||||||||||||||
|
Substantial development preparation |
Human resource management process |
extended |
||||||||||||||||
|
Preparing the implementation of the plan |
Human resource management process |
Model classification The problem of classifying models, like any fairly complex phenomena and processes, is complex and multifaceted. The objective reason for this is that the researcher is only interested in one property (or several properties) of the system (object, process, phenomenon), for which the model was created to display. Therefore, the classification can be based on many different classification features: description method, functional purpose, degree of detail, structural properties, scope, etc. Consider some of the most commonly used classes (types) of models (Table 1.4.1). Table 1.4.1
material(physical, real) models - models built by means of the material world to reflect its objects, processes. Ideal(imaginary) models - models built by means of thinking on the basis of our consciousness. Informational(abstract, theoretical) models - models built on one of the languages (sign systems) for encoding information. material models are real, material constructions that serve to replace the original in a certain respect. The main requirement for the construction of this class of models is the requirement of similarity (similarity, analogy) between the model and the original. There are several types of similarity - geometric, physical, analogy, etc. geometric similarity is the main requirement for the construction of geometric models, which are an object that is geometrically similar to its prototype and serves for demonstration purposes. Two geometric figures are similar if the ratio of all corresponding lengths and angles is the same. If the similarity coefficient is known - the scale, then by simply multiplying the dimensions of one figure by the scale value, the dimensions of the other figure are determined. In the general case, such a model demonstrates the principle of operation, the mutual arrangement of parts, the process of assembly and disassembly, the layout of the object and is intended to study properties that are invariant (independent) of the absolute values of the linear dimensions of the object. Examples of geometric models are: car models, mannequins, sculptures, prostheses, globes, etc. They depict the prototype not in all the variety of its properties, not in any qualitative boundaries, but within purely spatial ones. Here there is a similarity (similarity) not in general between things, but between special types of things - bodies. This is the limitation of this class of models. Note that a direct similarity is realized here. physical likeness refers to the model and the original of the same physical nature and reflects their similarity in the similarity of the ratios of the physical variables of the same name at the corresponding spatio-temporal points. Two phenomena are physically similar if, according to the given characteristics of one, it is possible to obtain the characteristics of the other by simple recalculation, which is similar to the transition from one system of units of measurement to another. Geometric similarity is a special case of physical similarity. With physical similarity, the model and the original may be in more complex geometric relationships than linear proportionality, since physical properties the original is not proportional to its geometric dimensions. Here it is important that the space of physical variables of the model be similar to the space of physical variables of the original. In this case, the physical model in relation to the original is an analogy of the type of isomorphism (one-to-one correspondence). Central problem is the problem of correctly recalculating the results of a model experiment to the results of testing the original in real conditions. The similarity is based on the observance of certain physical criteria. Ideal(imaginary) models are ideal constructions in our minds in the form of images or ideas about certain physical phenomena, processes, objects, systems (geometric point, infinity, etc.). abstract(theoretical, informational) models - models representing modeling objects in a figurative or symbolic form. Some hypothesis 1 about the properties of matter, assumptions about the behavior of a complex system under conditions of uncertainty, or a new theory about the structure of complex systems can serve as examples of abstract models. On abstract models and on speculative analogy (similarity) between the model M and original S an abstract (theoretical) modeling is being built. A striking representative of abstract and iconic modeling is a mathematical model. Mathematical model– this is a set of mathematical formulas, equations, relationships, describing the properties of the modeling object that are of interest to the researcher. Appropriate models can be used to study each aspect of modeling (type, structure, behavior) or their combination: appearance models, structure models, behavior patterns. Appearance model most often comes down to enumeration of the external features of the modeling object and is intended for identification (recognition) of the object. Structure model is a list of the constituent elements of the modeling object indicating the relationships between these elements and is intended for visual display, studying properties, identifying significant relationships, and studying the stability of the modeling object. Behavior Model is a description of changes in the appearance and structure of the modeling object over time and as a result of interaction with other objects. The purpose of behavior models is to predict the future states of the modeling object, manage objects, establish links with other objects external to the modeling object. Objectively, the levels of our ideas, the levels of our knowledge about various phenomena, processes, and systems are different. This is reflected in the ways in which the phenomena under consideration are presented. TO informal Models include displays (images) obtained using various forms of thinking: emotions, intuition, imaginative thinking, subconsciousness, heuristics as a set of logical techniques and rules for finding truth. In non-formalized modeling, the model is not formulated, but instead some fuzzy mental reflection (image) of reality is used, which serves as the basis for making a decision. An example of indefinite (intuitive) ideas about an object is a fuzzy description of a situation based on experience and intuition. TO formalized figurative models can be attributed to models, when models are built from any visual elements (elastic balls, fluid flows, trajectories of bodies, etc.). Formalizable abstract models include sign models, including mathematical constructions, programming languages, natural languages, along with the rules for their transformation and interpretation. According to their purpose, the models are designed to solve many problems: research(descriptor, cognitive, conceptual, formal) models are designed to generate knowledge by studying the properties of an object; educational models are designed to transfer knowledge about the object under study; workers(optimization, management) models are designed to generate the right actions in the process of achieving the goal. TO research models include semi-natural stands, physical models, mathematical models. Note that research models can act as training models if they are intended to transfer knowledge about the properties of an object. Examples of working models are: robot; autopilot; mathematical model of the object, built into the control or monitoring system; artificial heart, etc. At the same time, research and educational models should approach reality, and working models should reflect this reality. There is no clear boundary between these models. So, for example, a research model that adequately reflects the properties of an object can be used as a working one. Research models are carriers of new knowledge, training models combine old knowledge with new ones. Working models idealize the accumulated knowledge in the form of ideal actions to perform certain functions that it would be desirable to implement. Descriptor Models- descriptive models, designed to establish the laws of change in the parameters of these processes and are implementations of descriptive and explanatory meaningful models at the formal level of modeling. An example of such a model is a model of the motion of a material point under the action of applied forces, using Newton's second law. By setting the position and speed of the point at the initial moment of time (input values), the mass of the point (model parameter) and the law of change of applied forces (external influences), it is possible to determine the speed and coordinates of the point at any subsequent time moment (output values). cognitive(mental, cognitive) models - models representing a certain mental image of the object, its ideal model in the head of the researcher, obtained as a result of observing the original object. Forming such a model, the researcher, as a rule, seeks to answer specific questions, therefore, everything unnecessary is cut off from the infinitely complex structure of the object in order to obtain a more compact and concise description of it. Cognitive models are subjective, as they are formed speculatively on the basis of all previous knowledge and experience of the researcher. One can get an idea of a cognitive model only by describing it in a symbolic form. The representation of a cognitive model in natural language is called content model . Cognitive and content models are not equivalent, because the former may contain elements that the researcher cannot or does not want to formulate. conceptual model It is customary to call a meaningful model, the formulation of which uses the concepts and representations of subject areas of knowledge involved in the study of the object of modeling. In a broader sense, a conceptual model is understood as a meaningful model based on a particular concept or point of view. formal model is a representation of a conceptual model using one or more formal languages (for example, mathematical theory languages, universal modeling language, or algorithmic languages). In the humanities, the modeling process in many cases ends with the creation of a conceptual model of an object. In the natural sciences and technical disciplines, as a rule, it is possible to construct a formal model. Thus, cognitive, content and formal models constitute three interrelated levels of modeling. Optimization Models- models designed to determine the optimal (best) parameters of the modeled object from the point of view of some criterion or to search for the optimal (best) control mode for some process. As a rule, such models are built using one or more descriptive models and include some criterion that allows you to compare different options for sets of output values with each other in order to choose the best one. Restrictions in the form of equalities and inequalities associated with the features of the object or process under consideration can be imposed on the range of input parameters. An example of an optimization model is the simulation of the process of launching a rocket from the Earth's surface in order to lift it to a given height in minimum time under restrictions on the magnitude of the engine impulse, the time of its operation, the initial and final mass of the rocket. Mathematical relations of the descriptive model of the rocket motion act in this case as constraints of the equality type. Note that for most real processes, structures, it is required to determine the optimal parameters according to several criteria at once, i.e. we are dealing with so-called multiobjective optimization problems. Management Models– models used to make effective management decisions in various fields purposeful human activity. In general, decision-making is a process comparable in complexity to the process of thinking in general. However, in practice, decision-making is usually understood as the choice of some alternatives from a given set of them, and the overall decision-making process is represented as a sequence of such choices of alternatives. Unlike optimization models, where the selection criterion is considered to be certain and the desired solution is established from the conditions of its extremality, management models require the introduction of specific optimality criteria that allow one to compare alternatives under various uncertainties of the problem. The type of optimality criterion in managerial models is not fixed in advance. This is the main feature of these models. Recording Models are models designed to register properties and qualities of interest to the researcher that are not available for direct registration on the modeling object. When solving control problems for complex dynamic objects, reference and predictive models are used, which are a formalized display of the desired characteristics of the control object for the purposes of current or future control of the object. reference model is a model that describes in one form or another the desired (idealized) properties of the modeling (control) object. Predictive Models– models designed to determine future states ( future behavior) of the simulation object. simulation models- this is a set of descriptions of the elements of the system, the interconnections of elements with each other, external influences, algorithms for the functioning of the system (or rules for changing states) under the influence of external and internal disturbances. Simulation models are created and used when the creation of a single model of a complex system is impossible or very difficult, the available mathematical methods do not allow obtaining satisfactory analytical or numerical solutions of the problems under consideration. But the presence of descriptions of elements and algorithms of functioning allows you to simulate the process of functioning of the system and produce measurements characteristics of interest. It can also be noted that simulation models can be created for a much wider class of objects and processes than analytical and numerical models. In addition, since, as a rule, computing means (computers and other means) are used for implementation, universal or special algorithmic languages serve as means of a formalized description of simulation models. Simulation modeling in the study of large (complex) systems remains practically the only available method for obtaining information about the behavior of the system under conditions of uncertainty, which is especially important at the stage of its design. Using this method, you can choose the structure, parameters and control algorithms of the synthesized system, evaluate their effectiveness, and also simulate the behavior of the system under conditions that cannot be reproduced on a real prototype (for example, accidents, failures, emergencies, etc.). When, in simulation modeling, the behavior of a system is studied under the action of random factors, followed by statistical processing of information, it is advisable to use the static modeling method as a method of machine implementation of the simulation model. In this case, the method of statistical tests (Monte Carlo method) is considered as a numerical method for solving analytical problems. A special class of models are cybernetic models that reflect the management aspects of the behavior of complex systems based on information exchange between its elements. The very physical nature of cybernetic models differs from the physical nature of the prototype and its elements. A feature of cybernetic models is the possible presence in them, in addition to the control mechanism, of mechanisms of self-organization, learning, adaptation, etc., and in more complex systems, artificial intelligence. Taking into account the time factor in modeling leads to the use of static and dynamic models. Static Models reflect the steady (equilibrium) modes of operation of the system; Static modes of operation of elements, objects, systems are reflected in their static characteristics (linear, non-linear) and are described by the corresponding algebraic functional dependencies. Dynamic Models reflect unsteady (non-equilibrium, transient) modes of operation of the system. To describe non-equilibrium (transient) modes of operation of the system, differential equations or systems of differential equations are most often used. Let us consider some properties of models that allow, to one degree or another, either to distinguish or identify the model with the original (object, process). It is customary to single out the following properties of models: adequacy, complexity, finiteness, truth, proximity. Adequacy. Under adequacy Models are usually understood as the correct qualitative and quantitative description of an object (process) according to a selected set of characteristics with a certain reasonable degree of accuracy. Adequacy is the most important requirement for a model; it requires the model to correspond to its real object (process, system, etc.) with respect to the selected set of its properties and characteristics. This means not adequacy in general, but adequacy in terms of those properties of the model that are essential for the researcher. Full adequacy means the identity between the model and the prototype. A mathematical model can be adequate with respect to one class of situations (the state of the system + the state of the environment) and not adequate with respect to another. The use of an inadequate model can lead either to a significant distortion of the real process or properties (characteristics) of the object under study, or to the study of non-existent phenomena, properties and characteristics. You can introduce the concept of the degree of adequacy, which will vary from 0 (lack of adequacy) to 1 (full adequacy). The degree of adequacy characterizes the proportion of the truth of the model with respect to the selected characteristic (property) of the object under study. We note that in some simple situations numerical assessment of the degree of adequacy is not particularly difficult. The difficulty in assessing the degree of adequacy in the general case arises from the ambiguity and fuzziness of the adequacy criteria themselves, as well as from the difficulty of choosing those features, properties and characteristics by which adequacy is assessed. The concept of adequacy is a rational concept, therefore, increasing its degree should also be carried out at a rational level. The adequacy of the model must be checked, controlled, refined constantly in the process of research on particular examples, analogies, experiments, etc. As a result of the adequacy check, it is found out what the assumptions made lead to: either to an acceptable loss of accuracy, or to a loss of quality. When checking the adequacy, it is also possible to justify the validity of the application of the accepted working hypotheses in solving the problem or problem under consideration. Simplicity and complexity. Simultaneous requirement of simplicity and adequacy of the model is contradictory. From the point of view of adequacy, complex models are preferable to simple ones. In complex models, it is possible to take into account a larger number of factors that affect the studied characteristics of objects. Although complex models more accurately reflect the simulated properties of the original, they are more cumbersome, hard to see and inconvenient to use. Therefore, the researcher seeks to simplify the model, since it is easier to operate with simple models. When striving to build a simple model, the basic model simplification principle: the model can be simplified as long as the basic properties, characteristics and patterns inherent in the original are preserved. This principle points to the limit of simplification. At the same time, the concept of simplicity (or complexity) of a model is a relative concept. The model is considered quite simple if modern research tools (mathematical, informational, physical) make it possible to conduct a qualitative and quantitative analysis with the required accuracy. And since the possibilities of research tools are constantly growing, those tasks that were previously considered difficult can now be classified as simple. A more difficult task is to ensure the simplicity / complexity of the model of a complex system consisting of separate subsystems connected to each other in a certain hierarchical and multiply connected structure. At the same time, each subsystem and each level has its own local criteria of complexity and adequacy, which are different from the global criteria of the system. In order to reduce the loss of adequacy, it is more expedient to simplify the models: 1) at the physical level while maintaining the basic physical relationships, 2) at the structural level with the preservation of the main system properties. Simplification of models at the mathematical level can lead to a significant loss of the degree of adequacy. For example, truncation of the high-order characteristic equation to the 2nd - 3rd order can lead to completely wrong conclusions about the dynamic properties of the system. Note that more simple models are used in solving the synthesis problem, and more complex exact models are used in solving the analysis problem. Finiteness of models. It is known that the world is infinite, like any object, not only in space and time, but also in its structure (structure), properties, relations with other objects. Infinity is manifested in the hierarchical structure of systems of different physical nature. However, when studying an object, the researcher is limited by the finite number of its properties, connections, resources used, etc. It is as if it “cuts out” some finite fragment from the infinite world in the form of a specific object, system, process, etc. and tries to cognize the infinite world through the final model of this fragment. The finiteness of system models lies, firstly, in the fact that they reflect the original in a finite number of relations, i.e. with a finite number of connections with other objects, with a finite structure and a finite number of properties at a given level of study, research, description, available resources. Secondly, that the resources (information, financial, energy, time, technical, etc.) of modeling and our knowledge as intellectual resources are finite, and therefore objectively limit the possibilities of modeling and the very process of knowing the world through models. Therefore, the researcher (with rare exceptions) deals with finite-dimensional models. The choice of model dimension (its degree of freedom, state variables) is closely related to the class of problems to be solved. An increase in the dimension of the model is associated with problems of complexity and adequacy. In this case, it is necessary to know what is the functional relationship between the degree of complexity and the dimension of the model. If this dependence is a power law, then the problem can be solved by applying computing systems. If this dependence is exponential, then the “curse of dimensionality” (R. Kalman 1) is inevitable and it is almost impossible to get rid of it. As noted above, an increase in the dimension of the model leads to an increase in the degree of adequacy and, at the same time, to the complication of the model. At the same time, the degree of complexity is limited by the possibility of operating with the model, i.e. the modeling tools available to the researcher. The need to move from a rough simple model to a more accurate one is realized by increasing the dimension of the model by involving new variables that are qualitatively different from the main ones and which were neglected when constructing a rough model. These variables can be assigned to one of the following three classes: 1) fast-flowing variables whose extent in time or space is so small that in a rough examination they were taken into account by their integral or averaged characteristics; 2) slow flowing variables whose extent of change is so great that in rough models they were considered constant; 3) small variables(small parameters), the values and influences of which on the main characteristics of the system are so small that they were ignored in rough models. Note that the division of the complex motion of the system in terms of velocity into fast and slow motions makes it possible to study them in a rough approximation independently of each other, which simplifies the solution of the original problem. As for small variables, they are usually neglected when solving the synthesis problem, but they try to take into account their influence on the properties of the system when solving the analysis problem. When modeling, they try to identify, if possible, a small number of main factors, the influence of which is of the same order and is not too difficult to describe mathematically, and the influence of other factors can be taken into account using averaged, integral, or "frozen" characteristics. Approximation of models. It follows from the above that the finiteness and simplicity (simplification) of the model characterize quality difference (at a structural level) between the original and the model. Then the approximation of the model will characterize quantitative side of this difference. It is possible to introduce a quantitative measure of approximation by comparing, for example, a rough model with a more accurate reference (complete, ideal) model or with a real model. Approximation of the model to the original inevitable, exists objectively, since the model as another object reflects only individual properties of the original. Therefore, the degree of approximation (proximity, accuracy) of the model to the original is determined by the formulation of the problem, the purpose of modeling. An excessive desire for increased accuracy of the model leads to its significant complication, and, consequently, to a decrease in its practical value. Therefore, apparently, the principle of L. Zadeh 1 is true that when modeling complex (man-machine, organizational) systems, accuracy and practical meaning are incompatible and exclude each other. The reason for the inconsistency and incompatibility of the requirements for accuracy and practicality of the model lies in the uncertainty and fuzziness of knowledge about the original itself - its behavior, its properties and characteristics, about the behavior of the environment, about the mechanisms for forming the goal, ways and means to achieve it, etc. The truth of the models. Each model has a grain of truth, i.e. any model in some way correctly reflects the original. The degree of truth of the model is revealed only by its practical comparison with the original, because only practice is the criterion of truth. On the one hand, any model contains unconditionally true, i.e. definitely known and correct. On the other hand, the model also contains conditionally true, i.e. true only under certain conditions. A typical modeling error is that researchers use certain models without checking their truth conditions, the limits of their applicability. This approach obviously leads to incorrect results. Note that any model also contains the supposedly true (plausible), i.e. something that can be either true or false under conditions of uncertainty. Only in practice is the actual relationship between true and false in specific conditions established. Thus, when analyzing the truth level of the model, it is necessary to find out: 1) accurate, reliable knowledge; 2) knowledge that is reliable under certain conditions; 3) knowledge estimated with some degree of uncertainty; 4) knowledge that cannot be assessed even with some degree of uncertainty; 5) ignorance, i.e. what is unknown. Thus, assessing the truth of a model as a form of knowledge comes down to identifying the content in it of both objective, reliable knowledge that correctly reflects the original, and knowledge that approximately evaluates the original, as well as what constitutes ignorance. The theory of adaptive systems arose in connection with the need to solve a wide class of applied problems for which traditional methods are unacceptable, requiring knowledge of an adequate mathematical model object. The quality of traditional (non-adaptive) management methods is the higher, the more a priori information about the object itself and the conditions of its operation. In practice, it is quite difficult to provide an accurate mathematical description of the control object. For example, the dynamic characteristics of aircraft are highly dependent on the flight mode, technological variations, and the state of the atmosphere. Under these conditions, traditional methods often turn out to be inapplicable or do not provide the required quality of the system. automatic control. In this regard, already at the initial stage of development of the theory of automatic control, it seemed to be a very effective way to build control systems that do not require complete a priori information about the object and the conditions for its operation. The effect of adaptation to the operating conditions in adaptive systems is ensured by accumulating and processing information about the behavior of an object during its operation, which can significantly reduce the impact of uncertainty on the quality of control, compensating for the lack of a priori information at the system design stage. A control system that automatically determines the required control law by analyzing the behavior of an object under current control is called adaptive . Adaptive systems can be divided into two large classes: self-organizing and self-tuning. In with self-organizing systems in the process of functioning, a control algorithm (its structure and parameters) is formed, which allows optimizing the system in terms of the set control goal (CC). This kind of problem arises, for example, under conditions of changing the structure and parameters of the control object depending on the operating mode, when a priori information is not enough to determine the current mode. With a wide class of possible object structures, it is difficult to hope for the choice of a single structure of the control algorithm capable of ensuring the achievement of the control goal in a closed system in all modes of operation. Thus, we are talking about synthesis with a free controller structure. The obvious complexity of the problem statement does not allow us to hope for simple algorithms for solving it, and, consequently, for the widespread introduction of systems into practice at present. The task is greatly simplified if the structure of the control object is known and unchanged, and the behavior depends on a number of unchanged parameters. The problem is solved in the class of self-adjusting systems (SNS), in which the structure of the controller is given (selected in advance) and it is only required to determine the algorithm for tuning its coefficients (adaptation algorithm). self-adjusting system automatic control is a system that independently changes its dynamic characteristics in accordance with changes in external conditions in order to achieve the optimal output of the system. In the case of self-adjusting flight control systems, this optimal system output will be the optimal response to external disturbances. SNAs are divided into two subclasses: search and non-search. In the search SNA, the minimum (or maximum) of the quality measure (installation performance, fuel consumption, etc.) is searched for using specially organized search signals. Protozoa search engines are the majority of extremal systems in which the lack of a priori information is made up for by current information obtained in the form of an object's reaction to artificially introduced search (trial, test) influences. In searchless CNNs, there is a model with the desired dynamic characteristics in an explicit or implicit form. The task of the adaptation algorithm is to adjust the coefficients of the controller in such a way as to reduce the mismatch between the control object and the model to zero. Such control is called direct adaptive control, and systems - adaptive systems with reference model . In the case of indirect adaptive control, the object is first identified, and then the corresponding controller coefficients are determined. Such regulators are called self-tuning. With direct adaptive control, the adaptation loops operate in a closed loop, which makes it possible to fend off changes in the parameters of the object and the controller during operation. However, each self-tuning circuit increases the order of the system by at least one, and at the same time significantly affects the overall dynamics of the closed system. In the case of indirect adaptive control, self-tuning loops operate in an open loop and therefore do not affect the system dynamics. However, all identification errors, deviations of object and controller parameters significantly affect the control accuracy. In non-search self-adjusting systems, the reference model can be implemented as a real dynamic link (explicit model) or present as some reference equation relating the controlled variables and their derivatives (implicit model). In the implicit model, the coefficients of the reference equation are the parameters of the adaptation algorithm. Figure 1 shows one of the adaptive control options often used in actuators, where the controller parameters are adjusted by the control computer according to the reference model. reference model shows the ideal desired response of the system to the driving signal g(t). As a reference model, typical links of automatic control systems are used (for example, an aperiodic link). The parameters of the PID controller (proportional-integral-derivative controller) are tuned to minimize the mismatch between the output of the model and the real system. The task of the tuning loop is to reduce this mismatch to zero in certain time with a guarantee of the stability of the transition process. This problem is far from trivial - it can be shown that it cannot be solved with linear relations "error - controller coefficients". For example, the following algorithm for setting parameters is proposed in the literature: where k are adjustable coefficients of the PID controller; A is a constant coefficient that specifies the rate of adaptation.
Rice. 1. Block diagram of an adaptive system with a reference model The gradient function determines the sensitivity of the error c(t) to the variation of the controller coefficients. The absolute stability of a closed system, which is essentially non-linear, is ensured by selecting the parameter A in the setup program. Thus, in order to implement adaptive control according to this scheme, the control computer must solve the following tasks in real time:
In addition to the considered block diagram with the reference model, other methods are known. auto tuning parameters and structure of regulators. | ||||||||||||||||
