2. Results and discussion. The rapid growth in the complexity and size of modern software
systems, while simultaneously increasing the responsibility of the TSRT functions performed, has
sharply increased the requirements from customers and users for their quality, operational
Namangan Institute of Engineering and Technology
nammti.uz
10.25.2023
Pg.278
reliability and safety of use. The characteristics of the main projects have fundamentally changed -
developments have moved from programming “in the small” to programming “in the large” [2].
As the use and complexity of TSRT have increased, areas have emerged (primarily those
associated with UAV applications) where errors or poor software quality can cause harm far
outweighing the benefits of their use. In these critical cases, anomalies and defects in the
functioning of the TSRT software are unacceptable in the event of any distortion of the source data,
failures, partial hardware failures and other abnormal situations. However, sometimes excessively
high requirements for the quality of software for such systems cannot be met in principle due to
real limitations of all types of resources: budget, development time, characteristics of computing
systems and qualifications of specialists. This led to the emergence, development and application
of methods, standards and automation tools for industrial software engineering, ensuring the
creation of complex TSRT software architectures with specified high-quality indicators under real
restrictions on the use of development resources.
Since the cost of failure of TSRT software, especially critical ones, is usually very high, it is
necessary to ensure that the architectural specification of critical systems is of high quality and
accurately reflects the real needs of the system users.
TSRT software architecture reliability is a complex concept that must be considered at the
system-wide level, rather than at the level of individual architectural components. Because system
components are interconnected, a failure in one component can propagate through the system to
other components. In complex software systems, when determining failure-free operation, a set of
components is taken into account, among which one of the important places is occupied by software
reliability, which is defined as the probability of software failures.
Currently, software engineering is an independent discipline that deals with the problems of
creating reliable and trouble-free software systems. This discipline calculates the probabilities of
failure of various system components and determines how their combinations affect the overall
reliability of the system.
As the number of dependent components increases, the likelihood of system failure also
increases. If there are many critical components in a system, then each individual component must
be very reliable so that the probability of system failure is low. To increase reliability, components
can be duplicated (N-variant and multi-version software design [3]). Then a group of identical
components that duplicate each other will work correctly as long as at least one component works
correctly.
System reliability can be defined as a non-functional requirement, which is expressed
numerically through the indicators proposed and discussed in [4]. To fulfill non-functional
requirements for failure-free operation, it is necessary to additionally set functional requirements
for the system that determine ways to eliminate system failures. Examples of such requirements
are as follows.
1. Establishing a specific range for all values entered by the operator, and systematically
monitoring all entered values to check whether they fall within this range.
2. During the initialization process, the system must check all disks for bad blocks.
3. To implement the system shutdown control subsystem, N-variant programming should be
used (a special method for ensuring software fault tolerance).
4. The system must be implemented in a secure subset of a high-level programming language
and verified using static analysis.
There are no simple rules that can be used to derive the functional requirements for fault-free
software architecture. Organizations developing special systems usually have some knowledge of
possible non-failure requirements and how these requirements affect the actual reliability of the
software.
|
