Automated systems terms and definitions. Requirements for organizational support of automated control systems

GOST 24.104-85 Automated control systems. General requirements (Section 3 replaced by GOST 34.603-92) Section 3 replaced by GOST 34.603-92 By Decree of the USSR State Committee on Standards dated December 20, 1985 No. 4632, the introduction date was established

from 01/01/1987

This standard applies to automated control systems (ACS) of all types (except for national ones) and establishes general requirements for the ACS as a whole, the functions of the ACS, personnel training and types of ACS support, safety and ergonomics, types and procedures for testing when putting the ACS into operation, completeness of the automated control system, guarantees.

The standard does not establish requirements for automated control systems determined by the specifics of control objects. These requirements are formulated in the technical specifications for the creation or development of each automated control system or in other regulatory and technical documents of the customer department of the automated control system.

Additional requirements for automated control systems for technological processes, automated control systems for enterprises, industrial and scientific-production associations, and industry-specific automated control systems are established in mandatory appendices 1-3, respectively.

Reference Appendix 4 provides explanations of some of the terms used in the standard.

1. REQUIREMENTS FOR ACS

1.1. Requirements for the automated control system in general

1.1.1. An automated control system of any type must comply with the requirements of this standard, the requirements of the technical specifications for its creation or development (hereinafter referred to as the technical specifications for the automated control system), as well as the requirements of regulatory and technical documents in force in the department of the customer of the automated control system.

1.1.2. The commissioning of automated control systems should lead to useful technical, economic, social or other results, for example:

reducing the number of management personnel;
improving the quality of functioning of the control object;
improving the quality of management, etc.

1.1.3. The specific content of the requirements under paragraphs. 1.1.2, 1.1.5-1.1.11, 1.2, 1.3, 1.4.2, 1.4.3, 1.4.6, 1.4.9, 1.5.2, 1.5.4, 1.5.6, 1.5.7, 1.6. 2, 1.6.6, 1.6.12, 1.7.2, 1.7.3 are installed in the technical specifications for the automated control system.

1.1.4. The automated control system must ensure the achievement of the goals of its creation (development) established in the terms of reference for the automated control system.

1.1.5. The automated control system must ensure compatibility between its parts, as well as with automated systems (AS) interconnected with this automated control system.

In cases where an automated control system or a set of automated control systems (AS) is created on the basis of a computer network, multi-level interaction protocol systems must be used to ensure compatibility between elements of such a network.

1.1.6. The automated control system as a whole and all types of its support must be adapted to modernization, development and expansion within the limits of the requirements specified in the terms of reference for the automated control system.

1.1.7. The reliability of the automated control system as a whole and each of its automated functions must be sufficient to achieve the established goals of system operation under given application conditions.

1.1.8. The adaptability of the automated control system must be sufficient to achieve the established goals of its operation in a given range of changes in application conditions.

1.1.9. The ACS must provide for monitoring the correct performance of automated functions and diagnostics, indicating the location, type and cause of violations of the correct functioning of the ACS.

1.1.10. ACSs that have measuring channels must have the ability to control the metrological characteristics of the measuring channels.

1.1.11. The automated control system must provide protection measures against incorrect actions of personnel leading to an emergency condition of an object or control system, against accidental changes and destruction of information and programs, as well as against unauthorized intervention.

1.1.12. Any information entering the ACS is entered into the system once using one input channel, unless this leads to failure to comply with the requirements established in the technical specifications for the ACS (for reliability, reliability, etc.).

1.1.13. Output information of the same semantic content must be generated in the automated control system once, regardless of the number of recipients.

1.1.14. The information contained in the ACS databases must be updated in accordance with the frequency of its use when performing system functions.

1.1.15. The automated control system must be protected from information leakage, if this is stipulated in the technical specifications for the automated control system.

1.1.16. The name of the ACS must include the name of the type of ACS and the control object.

For example:

Process control system for heating metal in a methodical furnace;
organizational and technological automated control system in workshop No. 5;
Automatic control system of the Hammer and Sickle plant

1.2. Requirements for ACS functions

1.2.1. The automated control system, to the required extent, must automatically perform:

collection, processing and analysis of information (signals, messages, documents, etc.) about the state of the control object;
development of control actions (programs, plans, etc.);
transmission of control actions (signals, instructions, documents) on execution and its control;
implementation and control of control actions;
exchange of information (documents, messages, etc.) with interconnected automated systems.

1.2.2. The composition of automated functions (tasks, sets of tasks - hereinafter referred to as functions) of the automated control system must ensure the ability to control the corresponding object in accordance with any of the goals established in the technical specifications for the automated control system.

1.2.3. The composition of the automated functions of the automated control system and the degree of their automation must be technically, economically and (or) socially justified, taking into account the need to free personnel from performing repetitive actions and create conditions for the use of their creative abilities in the work process.

1.3. Requirements for the preparedness of automated control system personnel

1.3.1. The qualifications of the ACS personnel must ensure the effective functioning of the system in all specified modes.

1.3.2. ACS personnel must be prepared to perform their duties in accordance with organizational support instructions.

1.3.3. Each person who is part of the automated control system personnel must apply appropriate information models and work with the technical means and documentation used by him that determine the procedure for his activities.

1.4. Requirements for technical support of automated control systems

1.4.1. The complex of technical means of the automated control system must be sufficient to perform all automated functions of the automated control system.

1.4.2. The complex of technical means of automated control systems should mainly use technical means of mass production. If necessary, the use of technical means of single production is allowed.

1.4.3. Replicated automated control systems and their parts must be built on the basis of unified technical means.

1.4.4. ACS technical means must be placed in compliance with the requirements contained in the technical, including operational, documentation for them, and in such a way that it is convenient to use them during the operation of the ACS and perform maintenance.

1.4.5. The placement of technical means used by automated control system personnel when performing automated functions must meet ergonomic requirements: for production equipment in accordance with GOST 12.049-80, for means of presenting visual information in accordance with GOST 21829-76, including for collective use boards made of digital sign-synthesizing electroluminescent indicators according to GOST 21837-76.

1.4.6. The technical means of the automated control system used in the interaction of the automated control system with other systems must be compatible in interfaces with the corresponding technical means of these systems and the communication systems used.

1.4.7. The automated control system must use technical means with a service life of at least ten years. The use of technical means with a shorter service life is allowed only in justified cases and in agreement with the customer of the automated control system.

1.4.8. Any of the technical means of the automated control system must allow its replacement by a means of a similar functional purpose without any design changes or adjustments in the remaining technical means of the automatic control system (except for cases specifically specified in the technical documentation for the automatic control system).

1.4.9. ACS technical means may be used only under the conditions specified in the operational documentation for them. In cases where it is necessary to use them in an environment whose parameters exceed the permissible values established for these technical means, measures must be provided to protect individual technical means of the automated control system from the influence of external influencing factors.

1.4.10. The automated control system must use computer technology that meets the general technical requirements in accordance with GOST 22552-84.

1.4.11. The automated control system must use technical means corresponding to:

for resistance to external influencing factors - GOST 12997-76 for industrial devices and automation equipment GSP, GOST 14254-80 for shells of electrical engineering products, GOST 17516-72 for electrical engineering products regarding the impact of mechanical environmental factors, GOST 21552-84 for computing equipment technology;
for power parameters - GOST 12997-76 for industrial devices and automation equipment GSP, GOST 21552-84 for computer equipment;
by performance category - GOST 12997-76 for industrial devices and automation equipment GSP, GOST 21552-84 for computer equipment.

1.4.12. Protection of technical means of the automated control system from the influence of external electric and magnetic fields, as well as interference in power supply circuits, must be sufficient for the technical means to effectively fulfill their purpose during the operation of the automatic control system.

1.4.13. In the ACS, in accordance with the requirements stipulated by the “All-Union Standards of Permissible Industrial Interference” 1-72 - 9-72 and GOST 23450-79, measures must be provided to protect the external environment from industrial radio interference emitted by the technical means of the ACS during operation, as well as in moment of switching on and off.

1.4.14. General ergonomic requirements for mnemonic diagrams - according to GOST 21480-76, for counting devices for visual indicators - according to GOST 22902-78, for collective use boards on digital character-synthesizing electroluminescent indicators - according to GOST 21837-76, for cathode ray tubes for displaying visual information - according to GOST 23144-78.

1.4.15. General ergonomic requirements for switches on control panels: rotary switches - in accordance with GOST 22613-77, keyboard and push-button switches - in accordance with GOST 22614-77, "Toggle switch" type - in accordance with GOST 22615-77.

1.4.16. General ergonomic requirements for audible primary message alarms are in accordance with GOST 21786-76.

1.4.17. General ergonomic requirements regulating the organization of the workplace, the relative arrangement of information display devices, controls and communications within the workplace - in accordance with GOST 22269-76, including remote controls - in accordance with GOST 23000-76.

1.4.18. General ergonomic requirements for operator chairs in accordance with GOST 21889-76.

1.4.19. General ergonomic requirements for the hall, operator cabins and the relative arrangement of seats are in accordance with GOST 21958-76.

1.5. ACS software requirements

1.5.1. The ACS software must be sufficient to perform all the functions of the ACS, implemented using computer technology, and also have the means to organize all the required data processing processes, allowing timely execution of all automated functions in all regulated operating modes of the ACS.

1.5.2. ACS software must have the following properties:

functional sufficiency (completeness);
reliability (including restoreability, availability of error detection tools);
adaptability;
modifiability;
modularity of construction and
ease of use.

1.5.3. ACS software should be primarily built on the basis of existing application packages and other programs borrowed from government, industry and other funds of algorithms and programs, allow loading and checking in parts and allow the replacement of some programs without correction of others.

1.5.4. The automated control system should primarily use database management systems (DBMS), registered in the prescribed manner.

1.5.5. ACS software must be built in such a way that the absence of individual data does not affect the performance of ACS functions in the implementation of which this data is not used.

1.5.6. ACS software must have tools for diagnosing ACS hardware and monitoring the reliability of input information.

1.5.7. The ACS software must implement measures to protect against errors when entering and processing information, ensuring the specified quality of performance of the ACS functions.

1.5.8. The general software of the automated control system should allow the configuration of special software components and the further development of the automated control system software without interrupting the process of its functioning. The already generated and loaded part of the software must be protected from accidental changes.

1.5.9. All special software programs for a specific automated control system must be compatible both with each other and with its general software.

1.5.10. Operational software documentation for the automated control system must comply with ESPD standards and contain all the information necessary for automated control system personnel to use the software, for its initial loading and (or) generation, loading information from the internal machine information base, launching automated control systems programs, and checking their functioning using appropriate tests.

1.5.11. Newly developed during the creation of a specific automated control system, software products included in its software must be registered in the state, industry or other funds of algorithms and programs (as appropriate).

1.6. Requirements for information support of automated control systems

1.6.1. The information support of the automated control system must be sufficient to perform all automated functions of the automated control system.

1.6.2. To encode information used only in a given automated control system, classifiers accepted by the customer of the automated control system must be used.

1.6.3. To encode output information used at a higher level into the ACS, classifiers of higher-level control systems must be used, except in specially specified cases.

1.6.4. General ergonomic requirements for information coding are in accordance with GOST 21829-76.

1.6.5. The following must be used in the automated control system for communication between devices of a complex of technical means:

input and output signals:
- electrical - current and voltage according to GOST 26.011-80, with discrete changes in parameters according to GOST 26.013-81, coded according to GOST 26.014-81,
- hydraulic according to GOST 26.012-80,
- pneumatic according to GOST 26.015-81;
alphanumeric character sets according to GOST 19767-74;
8-bit codes according to GOST 19768-74.

1.6.6. The information support of the automated control system must be compatible with the information support of systems interacting with it, in terms of content, coding system, addressing methods, data formats and the form of presentation of information received and issued by the automated control system.

1.6.7. The forms of documents created by the automated control system must comply with the requirements of the USD standards or regulatory and technical documents of the department of the customer of the automated control system.

1.6.8. The forms of documents and video frames entered, output or adjusted through ACS terminals must be consistent with the relevant technical characteristics of the terminals.

1.6.9. The totality of information arrays of automated control systems must be organized in the form of databases on computer media.

1.6.10. The form of presentation of the output information of the automated control system must be agreed upon with the customer (user) of the system.

1.6.11. The terms and abbreviations used in the output documents of the automated control system must be generally accepted in the given subject area and agreed with the customer of the system.

1.6.12. The automated control system must provide the necessary measures to control and update data in the information arrays of the automated control system, restore the arrays after the failure of any technical means of the automated control system, as well as control the identity of the information of the same name in the databases.

1.7. Requirements for organizational support of automated control systems

1.7.1. The organizational support of the automated control system must be sufficient for the effective performance by the automated control system personnel of the duties assigned to them in the implementation of automated responsibilities in the implementation of automated and related non-automated functions of the system.

1.7.2. The organizational structure of the automated control system must allow the performance of all functions of the automated control system, taking into account their distribution among management levels.

1.7.3. Requirements for the distribution of responsibilities among personnel involved in the operation of the automated control system in real time are determined taking into account the requirements of clause 11 of mandatory Appendix 1.

1.7.4. Instructions for the organizational support of the automated control system must determine the actions of the automated control system personnel necessary to perform each automated function in all modes of operation of the automated control system, taking into account the specified requirements for the accuracy and speed of implementation by the automated control system personnel of their functional duties, and also contain specific instructions on actions in the event of emergency situations or violation of the normal operating conditions of the automated control system. Requirements for the content of instructions are in accordance with GOST 24.209-80.

1.7.5. For each automated function that is performed in interaction of this ACS with other systems, instructions to the personnel of the ACS and these systems must be interconnected for all modes of performing this function and contain instructions on the actions of personnel in the event of failures of technical means of the ACS.

1.8. Requirements for linguistic support of automated control systems

1.8.1. The linguistic support of the automated control system must be sufficient for communication between various categories of users in a form convenient for them with the automated control system automation tools and for carrying out procedures for converting and machine representation of information processed in the automated control system.

1.8.2. The linguistic support of the automated control system should include:

language tools are provided to describe any information used in the automated control system;
the language means used are unified;
descriptions of similar elements of information and recording of syntactic structures have been standardized;
Convenience, unambiguity and stability of communication between users and automated control systems are ensured;
means are provided for correcting errors that arise when users communicate with the technical means of the automated control system.

1.8.3. The linguistic support of the automated control system must be reflected in the documentation (instructions, descriptions) of the organizational support of the automated control system in the form of rules for communication between users and technical means of the automated control system in all modes of system operation.

1.9. Requirements for legal support of automated control systems

Legal support for automated control systems should include a set of legal norms:

determining the legal validity of information on data carriers and documents used in the operation of the automated control system and created by the system;
regulating legal relations between people who are part of the ACS personnel (rights, duties and responsibilities), as well as between the ACS personnel and the personnel of systems interacting with the ACS.

Note. Rules and regulations arising from the legal validity of information on data carriers and legal norms must be included in the organizational support instructions and regulations for the relevant ICS services.

1.10. Requirements for operational documentation for automated control systems

1.10.1. The operational documentation for the ACS must be sufficient for putting the ACS into operation and for its effective functioning.

1.10.2. The operational documentation for the automated control system must:

contain information necessary for quick and high-quality development and proper operation of automated control systems;
contain instructions on the activities of ACS personnel in emergency situations or in case of violation of the normal operating conditions of the ACS;
not contain provisions that are subject to ambiguous interpretation.

2. SAFETY REQUIREMENTS

2.1. Incorrect actions of ACS personnel should not lead to an emergency.

2.2. Safety requirements for electrical products used in automated control systems are in accordance with GOST 12.2.007.0-75.

2.3. Security requirements for computer equipment used in automated control systems are in accordance with GOST 25861-83.

2.4. All external elements of the technical means of the automatic control system that are energized must be protected from accidental contact, and the technical means themselves must be grounded or protectively grounded in accordance with GOST 12.1.030-81 and “Rules for power supply devices”.

2.5. ACS technical equipment located in explosion- and fire-hazardous installations must meet the requirements of the “Power Supply Rules”.

2.6. ACS technical means must be installed in such a way as to ensure their safe operation and maintenance.

2.7. Safety requirements must be established in a special section of job descriptions and (or) operating instructions for automated control systems and have links to operating instructions for technical equipment.

2.8. General ergonomic requirements for workplaces of automated control system personnel are in accordance with GOST 22269-76.

2.9. Comfortable living conditions for automated control system personnel must comply with current sanitary standards, maximum permissible living conditions - in accordance with GOST 12.1.005-76, permissible levels of influence of dangerous and harmful production factors - in accordance with GOST 12.0.003-74.

2.10. General ergonomic requirements for the microclimate of the working premises of automated control system personnel are in accordance with GOST 12.1.005-76.

2.11. Noise and sound power levels at the locations of automated control system personnel should not exceed the values established by GOST 12.1.003-83 and sanitary standards, while the noise and sound power levels created by all sources, including acoustic means of data transmission, must be taken into account.

2.12. The illumination levels of workplaces of automated control system personnel must correspond to the nature and working conditions. Protection against glare and glare reduction must be provided.

2.13. General ergonomic requirements for vibration of equipment at the workplaces of automated control system personnel are in accordance with GOST 12.1.012-78.

2.14. Signal colors and safety signs according to GOST 12.4.026-76.

3. TYPES AND PROCEDURE OF TESTS WHEN PUTTING ACS INTO OPERATION

This section applies to all automated control systems, except those created by order of the Ministry of Defense.

3.1. An automated control system or a separately delivered function of an automated control system (hereinafter referred to as the automated control system), when putting it into operation, must undergo preliminary and acceptance tests, as well as tests provided for by the regulatory and technical documents in force in the department of the customer of the automated control system.

3.2. Acceptance testing of the automated control system must be preceded by its trial operation at the control facility.

3.3. ACS tests are carried out in accordance with the document “Test Program”, which is prepared by the ACS developer. Requirements for the content of the test program are in accordance with GOST 24.208-80.

3.4. ACS tests may be carried out in one or several stages.

Based on the test results, the ACS draws up a “Test Report”. Requirements for the content of the test report are in accordance with GOST 24.208-80.

When testing an ACS step by step, the “Test Report” based on the results of the previous stage should contain a conclusion about the possibility of submitting the ACS to the next stage of testing.

3.5. Preliminary tests of the automated control system

3.5.1. Preliminary tests of the automated control system are carried out to determine its performance and resolve the issue of the possibility of accepting the automatic control system for trial operation.

3.5.2. The “test program” for preliminary testing of the ACS is approved by the customer of the ACS.

3.5.3. Preliminary tests of the ACS are organized by the customer and carried out jointly by the ACS developer and the customer.

3.5.4. The commission for conducting preliminary tests of the automated control system is formed by order of the customer. A representative of the customer of the automated control system is appointed as the chairman of the commission.

3.5.6. The “Test Report”, drawn up based on the results of preliminary tests of the ACS, provides a conclusion on the possibility of accepting the ACS for trial operation, as well as a list of necessary modifications and recommended deadlines for their implementation.

3.6. Trial operation of automated control systems

3.6.1. The results of acceptance of the ACS for trial operation are documented in the “Acceptance Certificate for Trial Operation”, drawn up on the basis of the “Test Report” by the commission that conducted preliminary tests of the ACS. Requirements for the content of the act are in accordance with GOST 24.208-80.

3.6.2. The duration of trial operation of the automated control system is determined by the time required to verify the correct functioning of the automated control system when performing each automated function and the readiness of the automated control system personnel to participate in the performance of all automated functions of the automated control system.

3.6.3. The minimum duration of trial operation of the automated control system (except for the automatic control system) before acceptance testing is determined for each automated function of the automated control system that is submitted; it must correspond to the values indicated in the table. If the total duration of interruptions to the continuity of an automated function exceeds the value specified in the table, trial operation must be continued until results consistent with the table are obtained or until a decision is made to terminate it.

It is allowed, by agreement with the customer, to submit the ACS for acceptance testing without trial operation of those automated functions whose solution frequency is less than once a month, provided that not only such functions are automated in the ACS.

Frequency of automated function execution	Minimum duration of trial operation of the automated control system before acceptance testing	Allowable total duration of disruptions to the continuity of execution of an automated automated control system function
Continuously	1 month	No more than 3 days
Once a day or more often	Same	No more than 10% of the planned number of solutions
Less than once a day to once a month	3 months	Same
Less than once a month to once every six months	Period between two consecutive decisions	Disruptions to the continuity of function performance are not allowed
Once a year or less	The period of time required to test the adopted technology for collecting and processing information during a one-time execution of the ACS function	Same

Notes:

1. A violation of the continuity of execution of an automated function of an automated control system is considered to be its failure to perform it at the time specified in the technical documentation for the automated control system, unless this is caused by a violation of the operating conditions of the automated control system or the control object.

2. If the actual duration of trial operation of the automated control system was longer than the time indicated in the second column of the table, then the total duration of the disruption of continuity of execution for each automated function is determined for the period of time indicated in the table and immediately preceding the acceptance tests.

3.6.4. During the trial operation of the ACS, a work log is kept in which information is recorded: on the duration of operation of the ACS, on the results of monitoring the correct functioning of the ACS, on failures, malfunctions, emergency situations, on changes in the parameters of the control object and ongoing adjustments to technical documentation.

3.6.5. Based on the results of trial operation, a certificate of completion of work on checking the automated control system in trial operation mode is drawn up. Requirements for the content of the act are in accordance with GOST 24.208-80.

3.7. ACS acceptance tests

3.7.1. Acceptance tests of the ACS are carried out to determine its compliance with the technical specifications for the ACS, the requirements of this standard and to determine the possibility of putting the ACS into operation.

3.7.2. Depending on the importance of the control object and the automated control system, acceptance tests can be:

government;
interdepartmental;
departmental

and must be carried out by the relevant acceptance committees. The acceptance committee is formed by order of the ministry (department) of the customer of the automated control system. The level of the acceptance committee must be established in the technical specifications for the automated control system.

3.7.3. A representative of the customer of the automated control system is appointed as the chairman of the acceptance committee. The acceptance committee must include representatives of the ACS developer.

3.7.4. The work of the acceptance committee does not include the acceptance of buildings, structures and auxiliary equipment, the creation of which was carried out in connection with the creation of an automated control system. The commission checks only the availability of certificates of acceptance for operation and the fulfillment of the requirements contained in the design assignments in adjacent parts of the facility project, issued during the design of the automated control system.

3.7.5. The customer and developer present the following documentation to the acceptance committee:

terms of reference for the creation of an automated control system;
draft acceptance testing program;
ACS preliminary test report;
certificate of acceptance of the automated control system for trial operation;
act(s) on completion of work on checking the automated control system in trial operation mode;
technical documentation for the automated control system (by decision of the acceptance committee).

3.7.6. Before submitting for acceptance testing, automated control systems with measuring channels are subject to metrological certification in accordance with current standards.

3.7.7. Before presenting the ACS for acceptance testing, the system and its technical documentation must be finalized based on the comments of the preliminary test protocol and the certificate of completion of work on checking the ACS in trial operation mode.

It is allowed, by decision of the acceptance committee, to finalize the technical documentation of the automated control system after it has been put into operation. The deadlines for finalizing the technical documentation of the automated control system are indicated in the system acceptance test report.

3.7.8. Acceptance tests of the automated control system must be carried out at a functioning control facility.

3.7.9. The “test program” for acceptance testing of the automated control system must be approved by the decisions of the acceptance committee. Coordination of the acceptance testing program with the customer of the automated control system is mandatory.

3.7.10. Based on the results of acceptance tests, the commission draws up a test report and an act on putting the ACS into operation (or a conclusion on non-acceptance of the ACS with a list of necessary modifications and recommended deadlines for their implementation). Requirements for the content of the protocol and act in accordance with GOST 24.208-80. The requirements for the content of the conclusion on non-acceptance of the automated control system are similar to the requirements for the content of the act on putting the automated control system into effect.

3.7.11. In the case of stage-by-stage acceptance tests, the act of putting the automated control system into operation is drawn up on the basis of the acts of putting into operation individual parts of the system and (or) “Test Reports” of all stages of the acceptance testing of the automated control system.

3.7.12. The date of commissioning of the automated control system is considered to be the date of signing the act of commissioning by the acceptance committee.

3.7.13. The act on putting the automated control system into effect is approved by the ministry (department) of the customer.

4. COMPLETENESS OF THE ACS PUT INTO OPERATION

4.1. The ACS should include:

ACS technical means in the form of a complex of ACS technical means prepared for operation;
spare parts and devices (SPTA), instruments and devices for testing operability, setting up technical equipment and monitoring the metrological characteristics of the measuring channels of the automated control system to the extent provided for by the custom design documentation agreed with the customer of the automatic control system and the user's metrology service in terms of testing equipment;
operational documentation in accordance with GOST 2.601-68 for each of the products included in the CTS ACS;
at least two copies of programs on data carriers and operational documentation on them in accordance with GOST 19.101-77, taking into account the restrictions and additions in accordance with GOST 24.101-80 and GOST 24.207-80;
a form for the ACS software as a whole or for the software of an ACS function put into operation separately and forms for software products (according to GOST 19.004-80), each in one copy. Requirements for the form - according to GOST 19.501-78;
two copies of operational documentation for the automated control system in accordance with GOST 24.101-80, including the necessary documentation for the information support of the automated control system (the automated control system form in one copy).

By agreement between the ACS developer and the ACS customer, the completeness of the ACS can be expanded.

4.2. ACS staff must be staffed with personnel meeting the requirements of clause 1.3.

4.3. To complete the created automated control system, the following can be used, supplied as production and technical products:

complex (complexes) of hardware and software with operational documentation for them in accordance with GOST 2.601-68;
software products with operational documentation for them in accordance with GOST 19.101-77;
technical equipment with operational documentation for them in accordance with GOST 2.601-68.

4.4. The procedure for development, launching into production and testing of supplied components used in the automated control system must comply with State standards for the system of development and launching of products into production.

Before being put into production, prototypes of components are subjected to acceptance (state, interdepartmental, departmental) tests.

5. WARRANTY

5.1. The developer of the automated control system guarantees compliance of the automated control system with the requirements of this standard and the technical specifications for the automatic control system, subject to the user's compliance with the operating conditions and rules.

5.2. The compliance of hardware, software and automation equipment systems used in automated control systems and supplied as production and technical products with the requirements of standards and specifications for them is guaranteed by the manufacturers of these types of products, subject to the user's compliance with the operating conditions and rules.

5.3. The warranty period for the ACS is calculated from the date the ACS is put into operation.

5.4. The warranty period for the ACS must be established in the technical specifications for the ACS and cannot be less than 18 months.

ANNEX 1
Mandatory

ADDITIONAL REQUIREMENTS FOR AUTOMATED PROCESS CONTROL SYSTEMS (APCS)

1. Process control systems in industry and in the non-industrial sphere must manage the technological object as a whole and supply interconnected systems with reliable technological and technical and economic information about the operation of the technological control object (TOU).

2. The automated process control system must develop and implement control actions on the control system that are rational in terms of goals and control criteria in real time of the technological process in the control object.

3. The automated process control system must perform control, information and auxiliary functions.

4. The process control system must be compatible with all automated systems (AS) interconnected with it, specified in the terms of reference for the process control system, including systems included with this process control system as part of flexible automated production, for example, CAD technologies, automated warehouse and transport systems, AS for technological preparation of production.

5. Control actions in the automated process control system must be generated automatically or generated by its operational personnel using a set of automation tools included in the system.

6. The automated process control system must ensure control of the facility under normal, transient and pre-emergency conditions of its operation, as well as protection or shutdown of the facility in the event of a threat of an accident.

7. The automated process control system must carry out the function of monitoring the execution of control actions on the technical equipment and signal when the executive bodies reach their maximum permissible positions.

8. When implementing the function of emergency automatic deflection of equipment in the process control system, an alarm about this must be provided to the operating personnel using light and, if necessary, sound signals with automatic registration of the shutdown time.

9. As the main technical means of automated process control systems, products of the State System of Industrial Instruments and Automation Equipment (GSP), other products that meet the requirements of ESSP standards, and computer equipment that comply with GOST 21552-84 should be used.

10. Technical means of automated process control systems located on process equipment must meet the requirements for their operating conditions.

11. Responsibilities between operators should be distributed taking into account:

participation of personnel in performing manual functions of the system and its interaction with other systems;
the permissible level of psychophysiological and emotional load of operators established by industry normative and technical documents associated with the performance of the duties assigned to each of them and his responsibility for the final and intermediate results of work, as well as the required level of his activity in the process of work.

12. Each person included in the staff must have:

knowledge, the volume and depth of which allows him to perform actions (interactions) included in the corresponding automated and interconnected non-automated functions of the automated process control system, as well as make the right decisions in emergency situations or other violations of normal operation;
developed skills that allow performing all actions and interactions with specified accuracy and speed.

13. The automated process control system software must provide, and the organizational support must reflect, language tools for communication between operational personnel and the automated process control system, convenient and accessible to persons who do not have programmer qualifications.

14. Codes and symbols used in the process control system should be close to the terms and concepts used by the technological personnel of the control object, and should not cause difficulties in their perception.

15. The measuring channels of the automated process control system must have metrological characteristics that ensure the performance of its information functions with the indicators specified in the technical specifications for the automated process control system.

16. Requirements for testing automated process control systems

16.1. Preliminary tests of the automated process control system are carried out on an existing technical equipment.

16.2. Preliminary tests of the functions of the automated process control system necessary for the start-up and running-in of process equipment can be carried out on site using simulators.

16.3. Determination of the actual values of indicators of technical and economic efficiency and reliability of the automated process control system is carried out after its commissioning. The operating time of the automated process control system, necessary to determine the actual values of its indicators, is calculated according to the appropriate methods approved in the prescribed manner.

APPENDIX 2
Mandatory

ADDITIONAL REQUIREMENTS FOR ACS BY ENTERPRISES, PRODUCTION AND RESEARCH AND PRODUCTION ASSOCIATIONS

1. The automated control system must increase the efficiency of production and economic activities of enterprises, production or scientific and production associations (hereinafter referred to as enterprises).

2. The enterprise automated control system (ACS) must provide automated collection and processing of information with the widespread use of optimization methods for the main tasks and control subsystems of the general plant and workshop level, including, if necessary, in real time in teleprocessing and dialogue mode.

3. The automated control system must be implemented as a set of jointly functioning subsystems, the interaction between which must occur through a common (single or distributed) database.

4. Organizational support for automated control systems should provide for the improvement of management methods and the structure of the enterprise management system during the creation and development of automated control systems.

APPENDIX 3
Mandatory

ADDITIONAL REQUIREMENTS FOR INDUSTRY AUTOMATED CONTROL SYSTEMS (OACS)

1. OASU must ensure:

improving the characteristics of the control object (increasing labor productivity in the industry, improving product quality, timely delivery of products, reducing the cost of manufactured products);
improvement of information processing processes (reducing the cost of information processing, increasing the reliability of the initial ones, increasing the accuracy and efficiency of calculations);
improving the organization of management functions (in particular, rational distribution of work between departments of the management apparatus, computer centers and research organizations and enterprises).

2. The OASU must automate industry management functions, for example:

forecasting and planning of industry production and resources;
management of scientific and technical development of the industry and technical preparation of industry production;
industry workforce management;
management of industry material resources;
management of capital construction in the industry;
management of industry financial resources;
management, including operational management, of main production at the industry level, etc.

3. OACS should be implemented as a set of jointly functioning subsystems, interaction between which should occur through common databases.

4. OASU must include a data collection system based on the computer centers of OASU, organizations and enterprises in the industry, ensuring rational distribution of information in databases for solving interacting problems and transfer of information between systems via communication channels and on computer media.

5. OACS must provide an interactive mode of working with system databases.

6. The creation of the OASU should lead to the improvement of methods and structure of industry management.

7. The duration of trial operation of parts of the OACS must ensure a one-time performance of all calculations necessary to perform the automated functions of the introduced part of the OACS, and should not exceed 3 months.

The specific duration of trial operation of the OASU is established by agreement between the developer and the customer.

APPENDIX 4
Information

EXPLANATION OF SOME TERMS USED IN THIS STANDARD

Complex of automation equipment (CAS)- a supplied set of mutually agreed upon sets of hardware and software (products), developed and manufactured as products for industrial and technical purposes. The KSA may also include other products and (or) documents included in the information, organizational or other types of support for automated systems.

Expansion of automated control systems- a set of measures taken in the automated control system when expanding its control object without changing the composition of the automated control system functions.

Video frame (in ACS)- image on the screen of a cathode ray tube document of a drawing or message text used in the automated control system.

ACS measuring channel- a functionally integrated set of technical and (if necessary) software tools designed to implement one simple measuring function of the automated control system.

Preliminary tests of the automated control system- control tests carried out to determine the possibility of accepting the automated control system for trial operation.

ACS acceptance tests- control tests of the automated control system, carried out to determine its compliance with the technical specifications for the creation of the automated control system, the requirements of the standards and to determine the possibility of putting the automated control system into operation.

State tests- acceptance tests of automated control systems conducted by the state commission.

Interdepartmental testing- acceptance tests of automated control systems conducted by a commission of representatives of several interested ministries and (or) departments.

Departmental tests- acceptance tests of automated control systems conducted by a commission of representatives of the interested ministry or department.

Editor A.I. Lomina
Technical editor N.P. Zamolodchikova
Proofreader E.I. Evteeva
Delivered to set 01/16/86. Signed for publication on 04/08/86. Conditional oven l. 1.5. Conditional cr.-ott. 1.5 Academic ed. l. 1.5.
Circulation 40,000 Price 10 kopecks.
Order "Badge of Honor" Publishing house of standards, 123810, Moscow, GSP, Novopresnensky lane, 3
Type. "Moscow Printer", Moscow, Lyalin lane, 6. Order 1772

Today we will talk about domestic standards for design documentation. How these standards work in practice, why they are bad and why they are good. When developing documentation for government and serious private customers, we usually have no choice - compliance with standards is included in the requirements for documenting technical specifications. In practice, I have encountered various examples of misunderstanding of the structure of standards, what should be in the documents and why these documents are needed. As a result, the pens of technical writers, analysts and specialists sometimes produce such gems that it is unclear in what state of consciousness they were written. But in fact, everything is quite simple. A search on Habr did not return any links to more or less complete material on this topic, so I propose to fill in this annoying gap.

What are documentation standards?

In the 34 series in question, there are only 3 main documentation standards:

The most beloved and popular standard for the development of technical specifications. The only thing you should not forget is that it is tightly connected with other standards of the series, and if you have received technical specifications made according to this standard, it is highly advisable to adhere to other standards, even if there are no direct requirements for this. At least in terms of general ideology (about which below)

This is a basic document that provides a complete list of GOST 34 documentation, recommendations for coding documents, which stages of the project the documents belong to (the stages are described in GOST 34.601-90), as well as how they can be combined with each other.

In fact, this standard is a large table with comments. It can be put into Excel for ease of use.

A voluminous standard that describes the content of project documents with varying degrees of detail. The above-mentioned GOST 34.201-89 is used as an index.

There are many questions and interpretations of its provisions regarding the RD 50-34.698-90 standard, which, due to their vagueness, are often understood differently by the customer and the contractor, or even members of the project team. But, unfortunately, we don’t have anything more concrete.

Let us now consider the pros and cons of the standards, traditionally starting with the cons.

Disadvantages of standards

The main disadvantage is obvious to everyone - the standards are old. They contain an outdated idea of the architecture of an automated system. For example:

two-tier applications, consisting of a client program and a DBMS server (no three or more “tier” applications, no Weblogic or JBoss)
the structure of the database tables, being described, will give an idea of the logical data model (the fact that there could be some kind of Hibernate between the application and the database seemed like a bad excess then)
the user interface is single-window (is there anything else? What is a “browser”?)
There are few reports in the system; they are all paper and printed on a dot-matrix printer.
The program being developed is focused on solving the “information processing problem,” which has a clear input and output and is highly specialized. Information processing is based on an “algorithm”. Sometimes there are several “algorithms”. (Object-oriented programming was then just taking its first steps and was not seriously considered).
the database administrator understands what information is in the tables and actively participates in editing system directories (is there really one DBMS server for 50 different applications?)

Accordingly, the standard has artifacts like the following:

5.8. Drawing of the document form (video frame)
The document must contain an image of the form of the document or video frame in accordance with the requirements of state standards of the unified documentation system R 50-77 and the necessary explanations.

The point of the document is that Soviet enterprises used so-called “Printing Areas”, where there were high-speed matrix printers, the drivers for which were often written by the engineers themselves. Therefore, they had to maintain a register of all the documents that needed to be printed to ensure that the documents looked as they should when printed.

“Video frame” is also a document that was displayed on a text display. The displays did not always support the required characters and the required number of horizontal characters and vertical lines (and did not support graphics at all). Therefore, here, too, it was necessary to additionally coordinate the forms of all screen documents.

Now the words “machineogram”, “video frame”, “ADC” no longer tell us anything. I also didn’t find them in use, although I graduated from a specialized institute in the 90s. This was the time of the appearance of Windows 3.1, VGA displays, three-inch floppy disks and the first domestic Internet sites. But these words are in the standard, and the customer sometimes capriciously demands that we provide him with a complete set of documentation in accordance with GOST 34.201-89. Moreover, such formulations in the ToR migrate from one ministry to another and have already become a kind of unspoken template into which the content is hammered in.

So the document with the stupid name “Drawing of the document form (video frame)” in the project should and should not be empty.

What's good in the standard

Any standard is good in that it allows the customer and the contractor to speak the same language and provides a guarantee that, at least, the customer will not have any complaints “in form” to the transmitted results.

And the GOST 34 standards are also good because they were compiled by smart people, tested over the years, and they have a clear goal - to describe on paper as fully as possible the complex abstract essence that any automated control system represents.

When you need to competently set a task for Western contractors who have never heard of our GOST standards, you can also rely on these standards, or rather on their content and semantic component. Because, I repeat, the guarantee of completeness of information is worth a lot. No matter how much we flatter ourselves with the high level of our professionalism, we may forget to include elementary things in our requirements, while the same GOST 34.602-89 “remembers” everything. If it is not clear to you what the result of the work of Western contractors should look like, look at the documentation requirements and recommended sections. I assure you, it’s better not to think of it! Most likely, there are Western analogues of our standards, in which everything can be more complete, more modern and better. Unfortunately, I am not familiar with them, since there has not yet been a single case where our GOST standards were not enough.

You can laugh at the fact that the standards creators knew nothing about java or .NET, about HD monitors and the Internet, but I would not advise underestimating the scale of the work they did and its value to our professional community.

How to read and understand documentation standards according to GOST series 34

The standard divides all documents along two axes - time and subject area. If you look at Table 2 in GOST 34.201-89, you can clearly see this division (columns “Creation stage” and “Part of the project”

Stages of creating an automated control system

The stages of creation are defined in GOST 34.601-90. Three of them are relevant to documentation:

Draft design (ED)
Technical design (TP)
Development of working documentation (DD)

Preliminary design follows after the Technical Specifications stage and serves to develop preliminary design solutions.

Technical project describes the future system from all angles. Documents at the TP stage should, after reading, leave behind complete clarity in the proposed approaches, methods, architectural and technical solutions. At the next phase, it will be too late to describe approaches and justify technical solutions, so phase P is the key to successful completion of the work, since all the variety of requirements of the technical specifications must be reflected in the documents of phase P. At phase P, the system may not exist at all.

Working documentation designed for the successful deployment, commissioning and further operation of the new system. These are documents containing very specific information that describe physically existing entities, in contrast to the P phase, which describes future splendor.

Parts (sections) of project documentation for the creation of an automated control system

The subject area is divided into “Provisions”. At first it seems that such a division is redundant and unnecessary. But when you start working with this toolkit in practice, the ideology embedded in it gradually becomes clear.

An automated system, as defined by the compilers of GOST, is a combination of hardware, software and communication channels that processes information coming from different sources in accordance with certain algorithms and produces processing results in the form of documents, data structures or control actions. A primitive model of the simplest machine gun.

In order to fully describe this “machine”, the following sections are made (as in drawing):

Software (MS), answering the questions: what logic is hardwired inside the “black box”? Why were these particular algorithms, these particular formulas and these particular coefficients chosen?

Mathematical software knows nothing about processors or databases. This is a separate abstract area, the abode of “spherical horses in a vacuum.” But mathematical software can be very closely related to the subject area, aka Real Life. For example, control algorithms for traffic control systems must be approved by the State Traffic Safety Inspectorate before they are approved by the customer. And then you understand why they are included in a separate book. Because no one in the traffic police is interested in what OS the application server will run on, but what sign and speed limit will pop up on the board in the rain or snow is very interesting. They are responsible for their part and are not going to sign anything else. On the other hand, when they signed, there will be no questions about the technical side of the issue - why they chose those boards or traffic lights and not others. The wisdom of the “ancestors” is precisely manifested in such practical cases.

Information support (IS). Another slice of the system. This time the black box of our system is made transparent and we look at the information circulating in it. Imagine a model of the human circulatory system when all other organs are invisible. Something like this is Information Support. It describes the composition and routes of information flow inside and outside, the logical organization of information in the system, a description of reference books and coding systems (those who made programs for production know how important they are). The main descriptive part falls on the TP stage, but some “rudiments” flow into the RD stage, like the “Database Catalog” document. It is clear that previously it contained exactly what is written in the title. But today, try to create such a document for a complex complex system, when very often the system uses purchased subsystems with their own mysterious information storages. I'm not even saying that this document is not particularly needed now.

Or here is the “Statement of computer storage media”. It is clear that previously it contained numbers of magnetic drums or reels of film. Now what should I put in there?

In short, at the RD phase, Information Support documents represent a rather harmful rudiment, since formally they should exist, but there is nothing special to fill them with.

Software. Everyone's favorite part of project documentation. Yes, if only because it is just one document! And then, everyone understands what needs to be written down there. But I’ll repeat it anyway.

In this document, we must tell you with the help of which software the algorithms described in the ML are executed, processing the information described in the IR. That is, there is no need to duplicate information from other sections here. Here the architecture of the system is given, the rationale for the selected software technologies, their description (all sorts of system things: programming languages, frameworks, operating systems, etc.). Also in this document we describe how information processing tools are organized (message queues, storage, backup tools, availability solutions, all kinds of application pools, etc.). The standard contains a detailed description of the contents of this document, which any specialist will understand.

Technical support (TO). No less beloved part of the project documentation. The rosy picture is only clouded by the abundance of documents that need to be developed. In total, the standard requires the development of 22 documents, of which 9 are at the TC stage.

The fact is that the standard provides a description of all technical support, including computer hardware and networks, engineering systems and even the construction part (if required). And this economy is regulated by a huge number of standards and regulations, coordinated in different organizations, and therefore it is more convenient to split everything into parts and coordinate (edit) in parts. At the same time, the standard allows you to combine some documents with each other, which makes sense if the whole bunch is approved by one person.

Do not forget also that a set of quality standards implies recording and storage of technical documents, and our “books” from the customer may be distributed among different archives, depending on the subject of the description. This is another argument in favor of fragmenting documentation.

Organizational support (OO). Having suppressed the desire, normal for a techie, to skip through this section as quickly as possible, on the contrary, I will consider it in more detail. Since, colleagues, recently there have been some bad trends in projects that require clarification in this section.

At the TP stage, the section contains only one document “ Description of the organizational structure", in which we must tell the customer what he should prepare for in terms of changing the organizational structure. Suddenly you need to organize a new department to operate your system, introduce new positions, etc.

At the RD stage, other, more interesting documents appear, which I would like to consider separately.

User guide. Comments are unnecessary, I think.

Methodology (technology) of computer-aided design. If necessary, you can include a description of the process of software building, version control, testing, etc. in this document. But this is if the customer in the technical specification wishes to personally assemble the software. If he doesn’t require this (and doesn’t pay for it), then your entire internal kitchen is none of his business, and this document does not need to be done.

Technological instructions. Due to the fashion for formalizing business processes, a cunning customer sometimes tries to stuff operating regulations into this document. So, under no circumstances should you do this.

Description of business processes, role and job descriptions, work regulations - all this is ORD, that is, organizational and administrative documentation. Which is the product of a consulting project, which, as far as I understand, was not purchased from you. And they bought a technical project from you and also technical documentation for it.

The technological instruction is a layer between the operating instructions and the user manual. The RP describes in detail How you need to do certain actions in the system. The technological instruction says that which actions must be performed in certain cases related to the operation of the system. Roughly speaking, a technological instruction is a short digest of RP for a specific position or role. If the customer does not have roles formed or he wants you to create roles and job requirements yourself, include the most basic roles in the document, for example: operator, senior operator, administrator. The customer’s comments on the topic “but it’s not like that with us” or “we don’t like it” should be accompanied by a list of roles and a description of job responsibilities. Because business processes we we don't put it. We are these business processes automate.

I will write about the described rakes separately, with colorful examples, since this is not the first time that this has been repeated in different sectors of the “national economy.”

Description of the technological process of data processing (including teleprocessing). A pathetic relic of the cave age, when there were specially designated “Computer Operators” who fed punched cards to the machine and packaged a printout of the result in an envelope. This instruction is for them. I can’t tell you exactly what to write in it in the 21st century. Get out yourself. The best thing is to just forget about this document.

System-wide solutions (WSO). The standard provides for 17 documents in the OP section. Firstly, these are almost all documents of the preliminary phase of Schematic Design. Secondly, these are all kinds of estimates, calculations and brief descriptions of automated functions. That is, information for people not from the main IT production, but for support staff - managers, estimators, purchasing specialists, economists, etc.

And thirdly, the OP includes a mega-document called “Explanatory Note for the Technical Project”, which is intended to be a kind of Executive Summary, but in fact, many designers shove all the useful content of the TP stage into it. Such a radical approach can be justified and even mutually beneficial for both the customer and the contractor, but in certain cases.

Options for using GOST 34

Full and exact adherence to the standard. Naturally, no one will write such a cloud of documents voluntarily. Therefore, a complete set of documents is prepared only at the urgent request of the customer, which he secured in the technical specifications and also pinned down with an agreement on top. In this case, you need to take everything literally and give the customer physical “books”, on which will be the names of the documents from Table 2 of GOST 34.201-89, with the exception of completely unnecessary ones, the list of which you must discuss and secure in writing. The content of the documents must also, without any imagination, comply with RD 50-34.698-90, right down to the names of the sections. In order to make the customer's brain explode, sometimes a large system is divided into subsystems, and separate design documentation is issued for each subsystem. It looks terrifying and is not subject to normal control with the help of the earthly mind. Especially regarding the integration of subsystems. Which greatly simplifies acceptance. The main thing is that you yourself do not get confused and that your system still works as it should.
We just love GOST standards. Serious big companies love standards. Because they help people understand each other better. If your customer is noted for his love of order and standardization, try to adhere to the standard GOST ideology when developing documents, even if this is not required by the technical specifications. You will be better understood and approved by the approving specialists, and you yourself will not forget to include important information in the documentation, you will better see the target structure of the documents, plan the work of writing them more accurately, and save yourself and your colleagues a lot of nerves and money.
We don't care about documentation, as long as everything works. The vanishing appearance of the irresponsible customer. A similar view of documentation can still be found among small and poor customers, as well as in authoritarian “idiotocracies” left over from the time of perestroika, where the boss is surrounded by loyal friends - directors, and all issues are resolved in personal conversations. In such conditions, you are free to neglect documentation altogether, but it is better, after all, not to knock down the sight and at least schematically fill in the documentation with content. If not to this customer, then pass it on (sell it) to the next one.

Conclusion

This article was about our GOST standards for documenting automated control systems. GOSTs are old, but, as it turns out, they are still very useful in the household. Apart from some obvious rudiments, the structure of the documentation has the properties of completeness and consistency, and adherence to the standard eliminates many project risks, the existence of which we may not be aware of at first.

I hope the material presented was useful to you, or at least interesting. Despite the apparent tedium, documentation is an important and responsible job, in which accuracy is as important as writing good code. Write good documents, colleagues! And next week I’m going on two business trips in a row, so I can’t guarantee the publication of new materials (I don’t have a cache, I’m writing from my head).

Introduction

In the modern world, dozens and hundreds of different programs, applications, and information systems appear every day. They can be developed for the government or commercial sector, as well as for ordinary users. 90% of all users do not read documentation, consider it boring, tedious and uninteresting, and open the user manual only when something does not work out or it is completely impossible to figure it out without instructions. It is now common practice to design the user interface in such a way that it is intuitive, and the user can understand the system without having to read long manuals. However, when working with large customers, it is almost always necessary to submit a certain package of documents - manuals, instructions, design solutions, drawn up in accordance with GOST.
When you first encounter writing documentation in accordance with GOST, you are stupefied and completely shocked, since there are “sea” of these GOSTs and how and what to write according to them becomes unclear.
This article discusses GOST standards for writing documentation and their main points.

What are the GOST standards?

First, you need to understand what GOST standards are. Everyone just knows that GOST is something that was developed under the Union and there are simply an endless number of them. I hasten to reassure you that there are not many GOSTs for the IT sector, and all of them, despite their creation time, have not lost their relevance.
First of all, standards for writing documentation are divided into two types:

International standards (ISO, IEEE Std);
Russian or Soviet GOSTs.

International Standards
International standards are used to develop international level documentation. As a rule, they are not free, since they are not developed by government organizations, but, unlike ours, they were developed quite recently. The topic of international standards is very broad, so it will be discussed in another article. Several standards that are closely related to writing documentation are also touched upon.
List of main international standards for writing documentation:

IEEE Std 1063-2001 “IEEE Standard for Software User Documentation” - standard for writing user manuals;
IEEE Std 1016-1998 “IEEE Recommended Practice for Software Design Descriptions” - a standard for writing a technical description of a program;
ISO/IEC FDIS 18019:2004 “Guidelines for the design and preparation of user documentation for application software” is another standard for writing user manuals. There are a large number of examples in this document. So to speak, this is more like a guide to writing a user manual. It will be especially useful for novice specialists;
ISO/IEC 26514:2008 “Requirements for designers and developers of user documentation” is another standard for designers and developers of user documentation.

There are actually a lot of international standards and each country has its own, since the same standard may not always suit both European and Asian companies.

Russian standards
Russian standards are developed at the state level. They are all absolutely free and each of them is easy to find on the Internet. To write documentation for the program, two series of GOSTs 19 and 34 are used. It is these that will be discussed further.

What is the difference between GOST series 19 and 34?

The first question that arises is how, in general, these GOSTs 19 and 34 differ from each other.
In GOST 19.781-90 “Unified system of program documentation. Software for information processing systems. Terms and definitions" the definitions are indicated:

Program - data intended to control specific components of an information processing system in order to implement a specific algorithm.
Software is a set of information processing system programs and program documents necessary for the operation of these programs.

In GOST 34.003-90 “Information technology. Set of standards for automated systems. Automated systems. Terms and definitions" the definition is indicated:

Automated system (AS) - a system consisting of personnel and a set of automation tools for their activities, implementing information technology to perform established functions.
Depending on the type of activity, for example, the following types of AS are distinguished: automated control systems (ACS), computer-aided design systems (CAD), automated scientific research systems (ASRS) and others.

Depending on the type of controlled object (process), automated control systems are divided, for example, into: automated control systems for technological processes (ACS), automated control systems for enterprises (ACS), etc.
GOST 34 also makes a division into types of AS support:

Organizational;
Methodical;
Technical;
Mathematical;
Software;
Informational;
Linguistic;
Legal;
Ergonomic.

As a result, an Automated System is not a program, but a complex of types of software, including software. AS, as a rule, carries an organizational solution for a specific user and customer, and the Program can be created and replicated for a large number of users without being tied to any enterprise.
Therefore, if you are developing documentation for a program that you created for a specific enterprise, then your GOST is 34. If you are writing documents for a mass program, then your GOST is 19.

GOST 34

Series GOST 34 (GOST 34.xxx Information Technology Standards) consists of:

GOST 34.201-89 Types, completeness and designations of documents when creating automated systems - this standard establishes the types, name, completeness and numbers of documents. It is one of the main documents of the GOST 34 series. In fact, this is a basic document, so beginners need to familiarize themselves with it first.
GOST 34.320-96 Concepts and terminology for conceptual schemes and information bases - this standard establishes the basic concepts and terms of conceptual schemes and information bases, covering the development, description and application of conceptual schemes and information bases, information manipulation, as well as the description and implementation of the information process. The standard defines the role of the conceptual diagram. The provisions set out in it are advisory in nature and can be used to evaluate database management systems (DBMS). This document does not describe specific methods for using conceptual diagram support tools. The conceptual schema languages described in the standard should not be considered standard languages.
GOST 34.321-96 Information technologies. System of database standards. Governance Reference Model - This document establishes a data governance reference model.
The reference model defines common terminology and concepts related to information systems data. Such concepts are used to define the services provided by database management systems or data dictionary systems.
The reference model does not consider protocols for data management.
The scope of the reference model includes processes that deal with the management of persistent data and its interaction with processes other than the requirements of a specific information system, as well as general data management services for defining, storing, retrieving, updating, entering, copying, restoring and transmitting data.
GOST 34.601-90 Automated systems. Stages of creation - the standard establishes the stages and stages of creating an AS.
GOST 34.602-89 Technical specifications for the creation of an automated system (Instead of GOST 24.201-85) - establishes the composition, content, rules for drawing up the document “Terms of reference for the creation (development or modernization) of the system.”
This document is one of the frequently used documents in the GOST 34 series. When developing technical specifications for this GOST, you should remember about other standards, even if this document does not contain references to these standards.
GOST 34.603-92 Information technology. Types of tests of automated systems - the standard establishes types of tests of AS (autonomous, complex, acceptance tests and trial operation) and general requirements for their implementation.
RD 50-34.698-90 Automated systems. Requirements for the content of documents are one of the most important documents of GOST 34, since it describes the content of almost all documents, as well as a description of each paragraph of the document.
GOST R ISO/IEC 8824-3-2002 Information technology. Abstract Syntax Notation Version One - This standard is part of Abstract Syntax Notation Version 1 (ASN.1) and establishes a notation for the specification of user-defined constraints and table constraints.
GOST R ISO/IEC 10746-3-2001 Data management and open distributed processing.
In this standard:
- it is determined how open distributed processing (ODP) systems are specified using the concepts introduced in GOST R ISO/IEC 10746-2;
- The characteristics according to which systems belong to OPO systems have been identified.
The standard establishes a framework for coordinating the development of standards for ODP systems.
GOST R ISO/IEC 15271-02 Software life cycle processes - this GOST is needed more, in my opinion, for analysts when designing and modeling AS.
This document is useful, from my point of view, for purely educational purposes.
GOST R ISO/IEC 15910-2002 Process for creating user documentation for a software tool - defines the minimum required process for creating user documentation of all types for a software tool that has a user interface. These types include printed documentation (for example, user guides and quick reference cards), online documentation, help text, and online documentation systems.

So, based on everything written above, it is clear that the main documents in GOST 34 are 3: GOST 34.201-89, RD 50-34.698-90 and GOST 34.602-89.
When developing a documentation package, first, you need to open GOST 34.201-89 and select the stage of creation: Draft design, Technical design and Working documentation. Next, you should select documents for development that correspond to the stage of creation.

List of documents 34 GOST

Stage creation	Title of the document	Code	Part project	Prinad bed to project but-estimate Noah Doku cop tions	Prinad bed to exploitation tation noah up kumen tations	Additional instructions
EP	Sheet of preliminary design	EP*	OR	—	—	—
EP	Explanatory note To the preliminary design	P1	OR	—	—	—
EP, TP	Organizational chart	CO	OR	—	—	It is allowed to include P3 or PV in the document
	Structural diagram of the complex technical means	C1*	THAT	X	—
	Functional structure diagram	C2*	OR	—	—	When developing documents CO, C1, C2, C3 at the ES stage, it is allowed to include them in document P1
	specialized (new) technical means	AT 9	THAT	X	—	When developing at the technical stage allowed to include to document P2
	Automation scheme	C3*	THAT	X	—	—
	Technical specifications for development specialized (new) technical means	—	THAT	—	—	The project does not include
TP	Development tasks sanitary and other sections project related with the creation of the system	—	THAT	X	—	The project does not include
	Technical design sheet	TP*	OR	—	—	—
	List of purchased items	VP*	OR	—	—	—
	List of input signals and data	IN 1	AND ABOUT	—	—	—
	List of output signals (documents)	AT 2	AND ABOUT	—	—	—
	List of development tasks construction, electrical, sanitary and other sections project related with the creation of the system	AT 3	THAT	X	—	It is allowed to include P2 in the document
	Explanatory note to the technical project	P2	OR	—	—	Includes event plan on preparing an object for input systems into operation
	Description of automated functions	P3	OR	—	—	—
	Description of the task setting (set of tasks)	P4	OR	—	—	Allowed to include to documents P2 or P3
	Description of information ensuring the system	P5	AND ABOUT	—	—	—
	Description of the organization information base	P6	AND ABOUT	—	—	—
TP	Description of classification systems and coding	P7	AND ABOUT	—	—	—
	Array Description information	P8	AND ABOUT	—	—	—
	Description of the complex technical means	P9	THAT	—	—	For the task it is allowed to include in document 46 according to GOST 19.101
	Description of the software provision	PA	BY	—	—	—
	Description of the algorithm (project procedure)	PB	MO	—	—	It is allowed to include P2, P3 or P4 in documents
	Description of organizational structures	PV	OO	—	—	—
	Layout plan	C8	THAT	X	—	It is allowed to include P9 in the document
	Equipment list and materials	—	THAT	X	—	—
	Local estimate calculation	B2	OR	X	—	—
TP, RD	Project assessment system reliability	B1	OR	—	—	—
TP, RD	Document form drawing (video frame)	C9	AND ABOUT	—	X	At the TP stage it is allowed include in documents P4 or P5
RD	List of holders originals	DP*	OR	—	—	—
	Operating sheet documents	ED*	OR	—	X	—
	Hardware Specification	AT 4	THAT	X	—	—
	List of requirements in materials	AT 5	THAT	X	—	—
	Machine Media Inventory information	VM*	AND ABOUT	—	X	—
	Input array	AT 6	AND ABOUT	—	X	—
RD	Database directory	AT 7	AND ABOUT	—	X	—
	Composition of the output data (messages)	AT 8	AND ABOUT	—	X	—
	Local estimates	B3	OR	X	—	—
	Methodology (technology) automated design	I1	OO	—	X	—
	Technological instructions	AND 2	OO	—	X	—
	User guide	I3	OO	—	X	—
	Instructions for forming and database maintenance (data set)	I4	AND ABOUT	—	X	—
	KTS operating instructions	IE	THAT	—	X	—
	External wiring diagram	C4*	THAT	X	—	Allowed to be performed in in the form of tables
	Connection diagram external postings	C5*	THAT	X	—	Same
	Table of connections and connections	C6	THAT	X	—	—
	System division diagram (structural)	E1*	THAT	—	—	—
	General drawing	IN*	THAT	X	—	—
	Technical equipment installation drawing	SA	THAT	X	—	—
	Schematic diagram	SB	THAT	X	—	—
	Structural diagram of the complex technical means	C1*	THAT	X	—	—
	Equipment and wiring layout plan	C7	THAT	X	—	—
	Description of technological processing process data (including teleprocessing)	PG	OO	—	X	—
	General description of the system	PD	OR	—	X	—
	Test program and methodology (components, automation systems, subsystems, systems)	PM*	OR	—	—	—
	Form	FO*	OR	—	X	—
	Passport	PS*	OR	—	X	—
*Documents whose code is set in accordance with the requirements of ESKD standards

Note to the table:

The following notations are used in the table:
- EP - preliminary design;
- TP - technical design;
- RD - working documentation;
- OR - system-wide solutions;
- OO - decisions on organizational support;
- TO - solutions for technical support;
- IO - solutions for information support;
- Software - software solutions;
- MO - software solutions.
The X sign indicates that it belongs to the design estimates or operational documentation.
The nomenclature of documents of the same name is established depending on the design decisions made during the creation of the system.

When the list of documents has been determined, then in RD 50-34.698-90 you should find the selected documents and develop them strictly according to the specified points. All content points that are indicated must be in the document.
If the Technical Specifications are being developed, then you immediately need to open GOST 34.602-89 and develop the technical specifications strictly in accordance with the points.

GOST 19

Series of GOSTs 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) consists of:

1. GOST 19.001-77 General provisions - too general a document, it has no practical use. Therefore, you can skip it.
2. GOST 19781-90 Terms and definitions - a good list of definitions in the field of software for information processing systems. It contains nothing more than definitions.
3. GOST 19.101-77 Types of programs and program documents - one of the main documents of 19 GOST. This is where you should start working with GOST 19, since it contains a complete list and designations of GOST documents.

List of documents 19 GOST

Code	Document type	Development stages
		Sketchy project	Technical project	Working draft
		Sketchy project	Technical project	component	complex
—	Specification	—	—
05	List of original holders	—	—	—
12	Program text	—	—
13	Program description	—	—
20	List of operational documents	—	—
30	Form	—	—
31	Description of application	—	—
32	System Programmer's Guide	—	—
33	Programmer's Guide	—	—
34	Operator's manual	—	—
35	Language description	—	—
46	Technical Manual service	—	—
51	Test program and methodology	—	—
81	Explanatory note			—	—
90-99	Other documents

Legend:
— the document is mandatory;
— the document is mandatory for components that have independent use;
— the need to draw up a document is determined at the stage of development and approval of the technical specifications;
- - the document is not drawn up.

GOST 19.102-77 Stages of development - contains a description of the stages of development. Useful for educational purposes. In my opinion, it does not have much practical benefit.
GOST 19.103-77 Designations of programs and program documents - contains a description of assigning a number (code) to a document. Even after reading this GOST, a lot of questions remain about how to assign this same number to a document.
GOST 19.104-78 Main inscriptions - establishes the forms, sizes, location and procedure for filling out the main inscriptions of the approval sheet and title page in program documents provided for by ESPD standards, regardless of the methods of their implementation. Since documents 19 GOST are drawn up in frames, this document is very important.
GOST 19.105-78 General requirements for program documents - establishes general requirements for the preparation of program documents. The requirements are too general. As a rule, this GOST is almost not used to develop a document, since a special GOST for a document is enough, but for general knowledge it is still better to look into this GOST once.
GOST 19.106-78 Requirements for program documents executed in printed form - contains requirements for the execution of all documents 19 GOST.
GOST 19.201-78 Technical specifications, requirements for content and design - establishes the procedure for constructing and preparing technical specifications for the development of a program or software product.
The clauses of the technical specifications of 34 GOST and 19 GOST are different.
GOST 19.601-78 General rules for duplication, accounting and storage - general rules for duplication, circulation, accounting and storage of program documents. GOST describes in several points how to ensure that documents are not lost.
GOST 19.602-78 Rules for duplication, accounting and storage of program documents, printing executions. Method - addition to GOST 19.601-78.
GOST 19.603-78 General rules for making changes - establishes general rules for making changes to program documents. In essence, it describes a long bureaucratic algorithm for making changes to documents.
GOST 19.604-78 Rules for making changes to program documents made in print - describes the procedure for working and filling out the Change Registration Sheet.

A list of specialized GOSTs, that is, each of them describes the content and requirements for a specific document:

GOST 19.202-78 Specification. Requirements for content and design;
GOST 19.301-79 Test program and methodology. Requirements for content and design;
GOST 19.401-78 Program text. Requirements for content and design;
GOST 19.402-78 Description of the program;
GOST 19.403-79 List of original holders;
GOST 19.404-79 Explanatory note. Requirements for content and design;
GOST 19.501-78 Form. Requirements for content and design;
GOST 19.502-78 Description of application. Requirements for content and design;
GOST 19.503-79 System programmer's guide. Requirements for content and design;
GOST 19.504-79 Programmer's Guide. Requirements for content and design;
GOST 19.505-79 Operator's manual. Requirements for content and design;
GOST 19.506-79 Description of the language. Requirements for content and design;
GOST 19.507-79 Statement of operational documents;
GOST 19.508-79 Maintenance manual. Requirements for content and design.

Procedure for working with 19 GOST:

In GOST 19.101-77, select a document and its code according to the stage of development.
According to GOST 19.103-77, assign a number to the document.
Then, according to GOSTs 19.104-78 and 19.106-78, draw up a document.
From the specialized list of GOSTs, you should select the one that corresponds to the document being developed.

Conclusion

GOST is not scary and easy! The main thing is to understand what needs to be written and which GOST is used for this. Our main GOSTs 19 and 34 for writing documentation are very old, but still relevant to this day. Writing documentation according to the standard eliminates many issues between the contractor and the customer. Consequently, it saves time and money.

Date of introduction 01/01/92

This standard applies to automated systems (AS) used in various types of activities (research, design, management, etc.), including their combinations created in organizations, associations and enterprises (hereinafter referred to as organizations).

The standard establishes the stages and stages of creating an AS. Appendix 1 shows the content of work at each stage.

1. General Provisions

2. Stages and stages of creating an AS

Appendix 1 (for reference)

Appendix 2 (reference)

1. GENERAL PROVISIONS

1.1. is a set of works ordered in time, interconnected, combined into stages and phases, the implementation of which is necessary and sufficient to create an automated system that meets the specified requirements.

1.2. The stages and phases of creating an AS are distinguished as parts of the creation process for reasons of rational planning and organization of work ending with a given result.

1.3. Work on the development of the AS is carried out according to the stages and steps used to create the AS.

1.4. The composition and rules for performing work at the stages and stages established by this standard are determined in the relevant documentation of organizations involved in the creation of specific types of nuclear power plants.

The list of organizations involved in the creation of nuclear power plants is given in Appendix 2.

2. STAGES AND STAGES OF CREATION OF AS

2.1. The stages and stages of creating an AS are generally shown in the table.

stages	Stages of work
1. Formation of requirements for speakers	1.1. Inspection of the facility and justification for the need to create a nuclear power plant
	1.2. Formation of user requirements for speakers
	1.3. Preparation of a report on the work performed and an application for the development of an AS (tactical and technical specifications)
2. Development of the AC concept	2.1. Studying the object
	2.2. Carrying out the necessary research work
	2.3. Development of AC concept options and selection of an AC concept option that meets user requirements
	2.4. Drawing up a report on the work performed
3. Terms of reference	3.1. Development and approval of technical specifications for the creation of nuclear power plants
4. Draft design	4.1. Development of preliminary design solutions for the system and its parts
4. Draft design	4.2. Development of documentation for the speaker system and its parts
5. Technical design	5.1. Development of design solutions for the system and its parts
	5.2. Development of documentation for the speaker system and its parts
	5.3. Development and execution of documentation for the supply of products for completing the NPP and (or) technical requirements (technical specifications) for their development
	5.4. Development of design tasks in adjacent parts of the automation facility project
6. Working documentation	6.1. Development of working documentation for the system and its parts
6. Working documentation	6.2. Development or adaptation of programs
7. Input and action	7.1. Preparing the automation object for putting the NPP into operation
	7.2. Personnel training
	7.3. Complete set of speakers with supplied products (software and hardware, software and hardware systems, information products)
	7.4. Construction and installation works
	7.5. Commissioning works
	7.6. Carrying out preliminary tests
	7.7. Conducting trial operation
	7.8. Carrying out acceptance tests
8. AC support	8.1. Carrying out work in accordance with warranty obligations
8. AC support	8.2. Post-warranty service

2.2. The stages and milestones performed by organizations participating in the creation of nuclear power plants are established in contracts and technical specifications based on this standard.

It is possible to exclude the “Sketch Design” stage and individual stages of work at all stages, to combine the “Technical Design” and “Working Documentation” stages into one “Technical Detailed Design” stage. Depending on the specifics of the AS being created and the conditions for their creation, it is allowed to carry out individual stages of work before the completion of previous stages, parallel execution of work stages, or the inclusion of new stages of work.

APPENDIX 1.For reference

1. At stage 1.1 “Inspection of the facility and justification of the need to create an NPP”, in the general case, the following is carried out:

collection of data about the automation object and the types of activities carried out;
assessing the quality of functioning of the facility and the types of activities carried out, identifying problems that can be solved using automation tools;
assessment (technical, economic, social, etc.) of the feasibility of creating an NPP.

2. At stage 1.2 “formation of user requirements for speakers” the following is carried out:

preparation of initial data for the formation of requirements for the automated system (characteristics of the automation object, description of the requirements for the system, limitations on acceptable costs for development, commissioning and operation, the effect expected from the system, conditions for the creation and operation of the system);
formulation and execution of user requirements for speakers.

3. At stage 1.3 “Completing a report on the work performed and an application for the development of an AS (tactical and technical specifications)”, a report on the work performed at this stage and an application for the development of an AS (tactical and technical specifications) or another document replacing it are completed with similar content.

4. At stages 2.1 “Study of the object” and 2.2 “Carrying out the necessary research work,” the development organization conducts a detailed study of the automation object and the necessary research work (R&D) related to finding ways and assessing the possibility of implementing user requirements, draws up and approve research reports.

5. At stage 2.3 “Development of options for the AS concept and selection of an option for the AS concept that meets the user’s requirements”, in the general case, alternative options for the concept of the AS being created and plans for their implementation are developed; assessment of the necessary resources for their implementation and maintenance; assessing the advantages and disadvantages of each option; comparison of user requirements and characteristics of the proposed system and selection of the optimal option; determining the procedure for assessing the quality and conditions for accepting the system; assessment of the effects obtained from the system.

6. At stage 2.4 “Prepare a report on the work performed,” prepare and draw up a report containing a description of the work performed at the stage, a description and justification of the proposed version of the system concept.

7. At stage 3.1 “Development and approval of technical specifications for the creation of a nuclear power plant,” the development, execution, coordination and approval of technical specifications for the nuclear power plant and, if necessary, technical specifications for parts of the nuclear power plant are carried out.

8. At stage 4.1 “Development of preliminary design solutions for the system and its parts” determine: the functions of the AS; functions of subsystems, their goals and effects; composition of task complexes and individual tasks; concepts of the information base, its enlarged structure; database management system functions; composition of the computer system; functions and parameters of basic software.

9. At stage 5.1 “Development of design solutions for the system and its parts”, they ensure the development of general solutions for the system and its parts, the functional-algorithmic structure of the system, the functions of personnel and organizational structure, the structure of technical means, algorithms for solving problems and the languages used , on organizing and maintaining an information base, a system of classification and coding of information, on software.

10. At stages 4.2 and 5.2 “Development of documentation for the NPP and its parts”, the development, execution, coordination and approval of documentation is carried out to the extent necessary to describe the full set of design decisions taken and sufficient for the further implementation of work on the creation of the NPP. Types of documents - according to GOST 34.201.

11. At stage 5.3 “Development and execution of documentation for the supply of products for completing NPPs and (or) technical requirements (technical specifications) for their development”, preparation and execution of documentation for the supply of products for completing NPPs is carried out; determination of technical requirements and drawing up technical specifications for the development of products that are not mass-produced.

12. At stage 5.4 “Development of design tasks in adjacent parts of the automation project”, they develop, formalize, coordinate and approve design tasks in adjacent parts of the automation object project for carrying out construction, electrical, sanitary and other preparatory work related to the creation AC.

13. At stage 6.1 “Development of working documentation for the system and its parts”, working documentation is developed containing all the necessary and sufficient information to ensure the implementation of work on putting the NPP into operation and its operation, as well as to maintain the level of operational characteristics (quality) of the system in accordance with the adopted design decisions, its execution, coordination and approval. Types of documents - according to GOST 34.201.

14. At stage 6.2 “Development or adaptation of programs”, programs and system software are developed, selection, adaptation and (or) linking of purchased software, and development of program documentation in accordance with GOST 19.101.

15. At stage 7.1 “Preparation of the automation object for putting the plant into operation”, work is carried out on the organizational preparation of the automation object for putting the plant into operation, including: implementation of design solutions for the organizational structure of the plant; providing departments of the management facility with instructional and methodological materials; implementation of information classifiers.

16. At stage 7.2 “Personnel training”, personnel are trained and their ability to ensure the functioning of the plant is checked.

17. At the stage “Completing the speakers with supplied products”, they ensure the receipt of serial and individual production components, materials and installation products. Incoming quality control is carried out.

18. At stage 7.4 “Construction and installation work” the following is carried out: work on the construction of specialized buildings (premises) to accommodate technical equipment and NPP personnel; construction of cable channels; performing work on the installation of technical equipment and communication lines; testing of installed technical equipment; delivery of technical equipment for commissioning.

19. At stage 7.5 “Commissioning”, they carry out autonomous adjustment of hardware and software, loading information into the database and checking the system for maintaining it; comprehensive setup of all system tools.

20. At stage 7.6 “Conducting preliminary tests” the following is carried out:

testing the speakers for operability and compliance with technical specifications in accordance with the program and methodology of preliminary tests;
troubleshooting and making changes to the NPP documentation, including operational documentation in accordance with the test report;
execution of a certificate of acceptance of the NPP for trial operation.

21. At stage 7.7 “Conducting trial operation”, trial operation of the NPP is carried out; analysis of the results of trial operation of the NPP; modification (if necessary) of the AS software; additional adjustment (if necessary) of NPP technical equipment; execution of a certificate of completion of trial operation.

22. At stage 7.8 “Conducting acceptance tests” the following is carried out:

testing for compliance with technical specifications in accordance with the acceptance testing program and methodology;
analysis of AS test results and elimination of deficiencies identified during testing;
execution of an act of acceptance of the NPP for permanent operation.

23. At stage 8.1 “Performing work in accordance with warranty obligations”, work is carried out to eliminate deficiencies identified during the operation of the NPP during the established warranty periods, and to make the necessary changes to the documentation for the NPP.

24. At stage 8.2 “Post-warranty service” work is carried out on:

analysis of the functioning of the system;
identifying deviations of the actual operational characteristics of the NPP from the design values;
establishing the causes of these deviations;
eliminating identified deficiencies and ensuring stability of NPP operational characteristics;
making the necessary changes to the documentation for the speakers.

APPENDIX 2. Reference

LIST OF ORGANIZATIONS PARTICIPATING IN THE CREATION OF AU

1. The customer organization (user) for which the NPP will be created and which provides financing, acceptance of work and operation of the NPP, as well as the implementation of individual works on the creation of the NPP.

2. A development organization that carries out work on the creation of an AS, providing the customer with a set of scientific and technical services at various stages and stages of creation, as well as developing and supplying various software and hardware for the AS.

3. A supplier organization that manufactures and supplies software and hardware to the order of the developer or customer.

4. Organization-general designer of the automation facility.

5. Design organizations of various parts of the automation facility project for carrying out construction, electrical, sanitary and other preparatory work related to the creation of the nuclear power plant.

6. Construction, installation, commissioning and other organizations.

Notes:

1. Depending on the conditions for creating the NPP, various combinations of functions of the customer, developer, supplier and other organizations involved in the creation of the NPP are possible.

2. The stages and phases of the work they perform to create the AS are determined on the basis of this standard.

INFORMATION DATA

1. DEVELOPED AND INTRODUCED by the USSR State Committee for Product Quality Management and Standards

DEVELOPERS

Yu.H. Vermishev, Doctor of Engineering. sciences; Ya.G. Vilenchik; IN AND. Voropaev, Doctor of Engineering. sciences; L.M. Seidenberg, Ph.D. tech. sciences; Yu.B. Irz, Ph.D. tech. sciences; V.D. Kostyukov, Ph.D. tech. sciences; M.A. Labutin, cond. tech. sciences; N.P. Leskovskaya; I.S. Mityaev; V.F. Popov (topic leader); S.V. Garshina; A.I. Deafness; SOUTH. Zhukov, Ph.D. sciences; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, Ph.D. sciences; A.A. Klochkov; V.Yu. Korolev; IN AND. Makhnach, Ph.D. tech. sciences; S.B. Mikhalev, Doctor of Engineering. sciences; V.N. Petrikevich; V.A. Rakhmanov, Ph.D. econ. sciences; A.A. Ratkovich; R.S. Sedegov, Doctor of Economics. sciences; N.V. Stepanchikova; M.S. Surovets; A.V. Flegentov; L.O. Khvilevsky, Ph.D. tech. sciences; VC. Chistov, Ph.D. econ. Sciences

2. APPROVED AND ENTERED INTO EFFECT by Resolution of the USSR State Committee for Product Quality Management and Standards dated December 29, 1990 No. 3469

M. Ostrogorsky, 2008

In order to successfully apply GOST 34, it is necessary to understand how, from the point of view of this set of standards, the automated system is structured. Otherwise, we will not see anything in the guest except a long list of documents with mysterious names, and the requirements for their content will once again convince us that in many wisdom there is a lot of sadness. Therefore, before discussing the documents themselves, we must understand what the subject of documentation is.

Automated system, its functions and tasks

Definition of an automated system

GOST 34.003-90 contains the following definition of an automated system: a system consisting of personnel and a set of automation tools for their activities, implementing information technology to perform established functions. What does this definition actually mean? You can understand this only by reading other definitions of this standard and comparing them with each other. What are we going to do now?

Activity goals

An automated system can only exist where there are personnel engaged in a specific activity. Typically, we are talking about activities whose results are useful to someone, regardless of the tools used. For example, I go to the theater box office for a ticket, and I’m quite happy if the cashier writes it out for me in pen on a form, as long as they let me into the theater using it. The cashier, by and large, also doesn’t care how exactly the ticket is made. She'll be fine with any method as long as it's not too labor-intensive and provides her with the opportunity to sell me a ticket. In other words, she and I have a common goal. GOST 34.003-90 uses the term to denote it purpose of activity. Every time another viewer leaves the window with a ticket in hand, and the theater becomes a little richer, this goal of the activity is achieved.

Functions of the automated system

There can be (and, as a rule, there are) several goals for an activity. Any useful result outside the activity itself can be considered its goal. So, if the cashier not only sells tickets, but also prepares a sales report for management at the end of the working day, drawing up a daily report can be considered as another activity goal.

If we put a computer and a printer on the cashier’s desk, and the cashier’s boss issues an order for her to type tickets and reports in a word processor and print them on the printer, then we will get an automated system. According to modern ideas, it is very primitive; formally it will satisfy the Gost definition. Please note that the goals of the activity have not changed as a result of the implementation of the automated system, only the method of achieving them has changed. What was previously done “just like that” is now done within the framework of an automated system. The set of actions of an automated system aimed at achieving a specific goal, according to GOST 34.003-90, is called its function. Note: no matter how you look at it, the staff is considered part of the system.

The function of an automated system is a fundamental concept in GOST 34. An automated system is considered, first of all, as the sum of its functions and only then as a bunch of “software” and “hardware”. The most important thing is what the system does, and what it consists of is secondary.

The above could lead the reader to the conclusion that each activity goal in an automated system corresponds to one and only one function. Such a system is easy to imagine, but practice is more varied. On the one hand, activities are not always completely automated. Even after the implementation of an automated system, some goals must be achieved manually. On the other hand, since the same result under different conditions can be achieved in different ways, several functions can be aimed at one goal of activity in an automated system, for example, selling a ticket at the box office and selling a ticket over the Internet. In addition, any automated system requires certain maintenance, so we have to introduce the concept of an auxiliary function. A typical example is creating a backup copy of data.

Tasks of the automated system

In the general case, when performing a function, part of the work is performed by staff, and part by technology; say, a ticket is printed automatically and given to the buyer manually by the cashier. A sequence of automatic (sic) actions leading to a result of a given type is called in GOST 34.003-90 task.

Here the definition of the problem is not quoted entirely accurately, but for now this will be enough for us; after all, it is not a shame for anyone to read the standard on their own. It is important that a task is the most clearly formalized part of an automated activity. You can imagine a function that is performed completely automatically, such as the backup mentioned above. In this case, the function is reduced to one task.

The same task can be solved by performing different functions. For example, if an automated system has several functions for selling a ticket, then executing each of them may at some point require the ticket to be printed.

Composition of the automated system

Subsystems

If the automated system is quite complex, it is divided into subsystems. What does it mean, quite complex, it’s quite difficult to say. Systems theory describes different levels and criteria of complexity. In practice, the need to allocate several subsystems in an automated system is often caused by organizational and financial reasons, for example, subsystems are developed and put into operation sequentially.

Although in GOST 34 the term subsystem is used many times, there seems to be no formal definition of this concept there. Experience suggests that a subsystem is a part of an automated system that also satisfies the definition of an automated system, in particular, it has full-fledged functions.

Returning to the ticketing example, we can decide that the automated system consists of two subsystems: a ticketing subsystem and a daily reporting subsystem. Let’s just agree, for greater clarity, that the cashier types the tickets in a text editor, and the reports in spreadsheets.

Components

The identification of activity goals, functions of an automated system and, if necessary, its subsystems is largely subjective and depends on the point of view of the subject who decided to do this. If some result is important in the context of the problem being solved, we can consider it a goal, otherwise ignore it. We will also break the automated system into subsystems in a way that is convenient for us, as long as our decisions do not contradict the content of this concept.

Components are the parts from which we, in objective reality, build an automated system. The system physically consists of its components, so dividing an automated system into components is the most objective.

We purchase each component, install and connect it (if it is equipment), install it (if it is a program) and maintain it separately from other components. We bought and placed a computer on the table - it is a component. We developed a special text editor for typing tickets - another component. Downloaded free spreadsheets from the Internet - again a component. And even the cashier herself, in some way, is also a component of the automated system.

The component composition of an automated system is very important from the point of view of its documentation, since technical documentation for the system as such and for components is handled differently. It generally needs to be developed by different people, and is designed to different standards depending on the type of component.

Types of collateral

One of the most difficult concepts for a novice user of GOST 34 is type of security. What kind of security is this? Can you see or touch it? Sell or buy?

Each type of software combines components or technical solutions of a certain nature. GOST 34 mentions many different types of security; we will not describe each of them sequentially here, but will list only the most noticeable:

information support - all data and metadata with which the system works;
software - all programs that are part of the system;
technical support - all technical means (in other words, equipment, equipment) that are part of the system.

Let us repeat once again, these are not all types of security. We can't even say with certainty that they are the most important. For example, metrological support is of great importance for automated process control systems (APCS). Many automated systems require complex mathematical and linguistic support. But it is difficult to imagine an automated system that would be completely devoid of one of the three types of support listed above (exercise: try it).