Termeni și definiții ale sistemelor automate. Cerințe pentru suportul organizațional al sistemelor de control automatizate

GOST 24.104-85 Sisteme de control automate. Cerințe generale (secțiunea 3 înlocuită cu GOST 34.603-92) Secțiunea 3 înlocuită cu GOST 34.603-92 Prin Decretul Comitetului de Stat pentru Standarde al URSS din 20 decembrie 1985 nr. 4632, a fost stabilită data introducerii

din 01/01/1987

Acest standard se aplică sistemelor de control automat (ACS) de toate tipurile (cu excepția celor naționale) și stabilește cerințe generale pentru ACS în ansamblu, funcțiile ACS, pregătirea personalului și tipurile de suport ACS, siguranță și ergonomie, tipuri și proceduri de testare la punerea în funcțiune a ACS, integralitatea sistemului de control automatizat, garanții.

Standardul nu stabilește cerințe pentru sistemele de control automatizate determinate de specificul obiectelor de control. Aceste cerințe sunt formulate în specificațiile tehnice pentru crearea sau dezvoltarea fiecărui sistem de control automatizat sau în alte documente de reglementare și tehnice ale departamentului de clienți al sistemului de control automatizat.

Cerințe suplimentare pentru sistemele de control automatizat pentru procese tehnologice, sistemele de control automatizat pentru întreprinderi, asociații industriale și științifice-producție și sistemele de control automatizat specifice industriei sunt stabilite în anexele obligatorii 1-3, respectiv.

Anexa 4 de referință oferă explicații pentru unii dintre termenii utilizați în standard.

1. CERINȚE PENTRU ACS

1.1. Cerințe pentru sistemul de control automatizat în general

1.1.1. Un sistem de control automatizat de orice tip trebuie să respecte cerințele prezentului standard, cerințele specificațiilor tehnice pentru crearea sau dezvoltarea sa (denumite în continuare specificațiile tehnice pentru sistemul de control automatizat), precum și cerințele de reglementare și documente tehnice în vigoare în departamentul clientului sistemului de control automatizat.

1.1.2. Punerea în funcțiune a sistemelor de control automate ar trebui să conducă la rezultate tehnice, economice, sociale sau de altă natură utile, de exemplu:

• reducerea numărului de personal de conducere;
• imbunatatirea calitatii functionarii obiectului de control;
• îmbunătățirea calității managementului etc.

1.1.3. Conținutul specific al cerințelor prevăzute la paragrafe. 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 sunt instalate în specificațiile tehnice pentru sistemul de control automatizat.

1.1.4. Sistemul de control automatizat trebuie să asigure atingerea obiectivelor creării (dezvoltării) acestuia stabilite în caietul de sarcini pentru sistemul de control automatizat.

1.1.5. Sistemul de control automatizat trebuie să asigure compatibilitatea între părțile sale, precum și cu sistemele automatizate (AS) interconectate cu acest sistem de control automatizat.

În cazurile în care un sistem de control automatizat sau un set de sisteme de control automatizat (AS) este creat pe baza unei rețele de calculatoare, trebuie utilizate sisteme de protocol de interacțiune pe mai multe niveluri pentru a asigura compatibilitatea între elementele unei astfel de rețele.

1.1.6. Sistemul de control automatizat în ansamblu și toate tipurile de suport al acestuia trebuie adaptate la modernizare, dezvoltare și extindere în limitele cerințelor specificate în caietul de sarcini pentru sistemul de control automatizat.

1.1.7. Fiabilitatea sistemului de control automatizat în ansamblu și fiecare dintre funcțiile sale automatizate trebuie să fie suficientă pentru a atinge obiectivele stabilite ale funcționării sistemului în condiții de aplicare date.

1.1.8. Adaptabilitatea sistemului de control automatizat trebuie să fie suficientă pentru a atinge obiectivele stabilite ale funcționării acestuia într-un interval dat de modificări ale condițiilor de aplicare.

1.1.9. ACS trebuie să asigure monitorizarea performanței corecte a funcțiilor automate și a diagnosticului, indicând locația, tipul și cauza încălcărilor funcționării corecte a ACS.

1.1.10. ACS-urile care au canale de măsurare trebuie să aibă capacitatea de a controla caracteristicile metrologice ale canalelor de măsurare.

1.1.11. Sistemul de control automat trebuie să ofere măsuri de protecție împotriva acțiunilor incorecte ale personalului care conduc la starea de urgență a unui obiect sau a sistemului de control, împotriva modificărilor accidentale și distrugerii informațiilor și programelor, precum și împotriva intervențiilor neautorizate.

1.1.12. Orice informație care intră în ACS este introdusă în sistem o singură dată folosind un canal de intrare, cu excepția cazului în care aceasta duce la nerespectarea cerințelor stabilite în specificațiile tehnice pentru ACS (de fiabilitate, fiabilitate etc.).

1.1.13. Informațiile de ieșire cu același conținut semantic trebuie generate în sistemul de control automat o singură dată, indiferent de numărul de destinatari.

1.1.14. Informațiile conținute în bazele de date ACS trebuie să fie actualizate în conformitate cu frecvența de utilizare a acestora la îndeplinirea funcțiilor sistemului.

1.1.15. Sistemul de control automatizat trebuie protejat de scurgerile de informații, dacă acest lucru este stipulat în specificațiile tehnice pentru sistemul de control automatizat.

1.1.16. Numele ACS trebuie să includă numele tipului de ACS și al obiectului de control.

De exemplu:

• Sistem de control al procesului pentru încălzirea metalului într-un cuptor metodic;
• sistem de control organizatoric si tehnologic automatizat in atelierul nr.5;
• Sistem de control automat al fabricii de ciocan și seceră

1.2. Cerințe pentru funcțiile ACS

1.2.1. Sistemul de control automatizat, în măsura necesară, trebuie să efectueze automat:

• colectarea, prelucrarea și analiza informațiilor (semnale, mesaje, documente etc.) despre starea obiectului de control;
• dezvoltarea acțiunilor de control (programe, planuri etc.);
• transmiterea acțiunilor de control (semnale, instrucțiuni, documente) asupra execuției și controlului acesteia;
• implementarea și controlul acțiunilor de control;
• schimbul de informații (documente, mesaje etc.) cu sisteme automate interconectate.

1.2.2. Alcătuirea funcțiilor automatizate (sarcini, seturi de sarcini - denumite în continuare funcții) ale sistemului de control automatizat trebuie să asigure capacitatea de a controla obiectul corespunzător în conformitate cu oricare dintre scopurile stabilite în specificațiile tehnice pentru sistemul de control automatizat.

1.2.3. Compoziția funcțiilor automate ale sistemului de control automatizat și gradul de automatizare a acestora trebuie să fie justificate din punct de vedere tehnic, economic și (sau) social, ținând cont de necesitatea de a elibera personalul de la efectuarea de acțiuni repetitive și de a crea condiții de utilizare a creației lor. abilități în procesul de muncă.

1.3. Cerințe pentru pregătirea personalului sistemului de control automatizat

1.3.1. Calificările personalului ACS trebuie să asigure funcționarea eficientă a sistemului în toate modurile specificate.

1.3.2. Personalul ACS trebuie să fie pregătit să își îndeplinească sarcinile în conformitate cu instrucțiunile de sprijin organizațional.

1.3.3. Fiecare persoană care face parte din personalul sistemului de control automatizat trebuie să aplice modele informaționale adecvate și să lucreze cu mijloacele tehnice și documentația utilizată de acesta care determină procedura activităților sale.

1.4. Cerințe pentru suportul tehnic al sistemelor automate de control

1.4.1. Complexul de mijloace tehnice ale sistemului de control automatizat trebuie să fie suficient pentru a îndeplini toate funcțiile automatizate ale sistemului de control automatizat.

1.4.2. Complexul de mijloace tehnice ale sistemelor de control automate ar trebui să utilizeze în principal mijloace tehnice de producție în masă. Dacă este necesar, este permisă utilizarea mijloacelor tehnice de producție unică.

1.4.3. Sistemele de control automate replicate și părțile acestora trebuie construite pe baza unor mijloace tehnice unificate.

1.4.4. Mijloacele tehnice ACS trebuie amplasate în conformitate cu cerințele cuprinse în documentația tehnică, inclusiv operațională, pentru acestea și în așa fel încât să fie convenabilă utilizarea lor în timpul funcționării ACS și efectuarea întreținerii.

1.4.5. Amplasarea mijloacelor tehnice utilizate de personalul sistemului de control automat atunci când execută funcții automate trebuie să îndeplinească cerințe ergonomice: pentru echipamentele de producție în conformitate cu GOST 12.049-80, pentru mijloacele de prezentare a informațiilor vizuale în conformitate cu GOST 21829-76, inclusiv pentru plăci de utilizare colectivă realizat din indicatori electroluminescenți care sintetizează semne digitale conform GOST 21837-76.

1.4.6. Mijloacele tehnice ale sistemului de control automatizat utilizate în interacțiunea sistemului de control automat cu alte sisteme trebuie să fie compatibile în interfețe cu mijloacele tehnice corespunzătoare ale acestor sisteme și cu sistemele de comunicații utilizate.

1.4.7. Sistemul de control automat trebuie să utilizeze mijloace tehnice cu o durată de viață de cel puțin zece ani. Utilizarea mijloacelor tehnice cu o durată de viață mai scurtă este permisă numai în cazuri justificate și de comun acord cu clientul sistemului de control automatizat.

1.4.8. Oricare dintre mijloacele tehnice ale sistemului de control automat trebuie să permită înlocuirea acestuia cu un mijloc cu un scop funcțional similar, fără modificări de proiectare sau ajustări ale mijloacelor tehnice rămase ale sistemului de control automat (cu excepția cazurilor specificate în mod specific în documentația tehnică pentru sistem de control automat).

1.4.9. Mijloacele tehnice ACS pot fi utilizate numai în condițiile specificate în documentația operațională a acestora. În cazurile în care este necesară utilizarea lor într-un mediu ai cărui parametri depășesc valorile admisibile stabilite pentru aceste mijloace tehnice, trebuie prevăzute măsuri pentru protejarea mijloacelor tehnice individuale ale sistemului de control automat de influența factorilor externi de influență.

1.4.10. Sistemul de control automat trebuie să utilizeze tehnologie computerizată care îndeplinește cerințele tehnice generale în conformitate cu GOST 22552-84.

1.4.11. Sistemul de control automat trebuie să utilizeze mijloace tehnice corespunzătoare:

• pentru rezistența la factorii de influență externi - GOST 12997-76 pentru dispozitive industriale și echipamente de automatizare GSP, GOST 14254-80 pentru carcase de produse de inginerie electrică, GOST 17516-72 pentru produse de inginerie electrică privind impactul factorilor de mediu mecanici, GOST 21552-84 pentru tehnologia echipamentelor de calcul;
• pentru parametrii de putere - GOST 12997-76 pentru dispozitive industriale și echipamente de automatizare GSP, GOST 21552-84 pentru echipamente informatice;
• după categoria de performanță - GOST 12997-76 pentru dispozitive industriale și echipamente de automatizare GSP, GOST 21552-84 pentru echipamente informatice.

1.4.12. Protecția mijloacelor tehnice ale sistemului de control automat de influența câmpurilor electrice și magnetice externe, precum și interferența în circuitele de alimentare cu energie electrică trebuie să fie suficientă pentru ca mijloacele tehnice să își îndeplinească eficient scopul în timpul funcționării sistemului de control automat.

1.4.13. În ACS, în conformitate cu cerințele stipulate de „Standardele comunitare de interferență industrială permisă” 1-72 - 9-72 și GOST 23450-79, trebuie prevăzute măsuri pentru a proteja mediul extern de interferențele radio industriale emise de mijloacele tehnice ale ACS în timpul funcționării, precum și în momentul pornirii și opririi.

1.4.14. Cerințe ergonomice generale pentru diagramele mnemonice - conform GOST 21480-76, pentru dispozitive de numărare pentru indicatoare vizuale - conform GOST 22902-78, pentru plăci de utilizare colectivă pe indicatoare electroluminescente digitale de sinteză a caracterelor - conform GOST 21837-76, pentru raze catodice tuburi pentru afișarea informațiilor vizuale - conform GOST 23144-78.

1.4.15. Cerințe ergonomice generale pentru întrerupătoarele de pe panourile de control: întrerupătoare rotative - în conformitate cu GOST 22613-77, întrerupătoare cu tastatură și buton - în conformitate cu GOST 22614-77, tip „Comutator cu comutator” - în conformitate cu GOST 22615-77.

1.4.16. Cerințele ergonomice generale pentru alarmele cu mesaje primare sonore sunt în conformitate cu GOST 21786-76.

1.4.17. Cerințe ergonomice generale care reglementează organizarea locului de muncă, aranjarea relativă a dispozitivelor de afișare a informațiilor, comenzile și comunicațiile la locul de muncă - în conformitate cu GOST 22269-76, inclusiv telecomenzi - în conformitate cu GOST 23000-76.

1.4.18. Cerințe ergonomice generale pentru scaunele de operator în conformitate cu GOST 21889-76.

1.4.19. Cerințele ergonomice generale pentru sală, cabinele operatorului și aranjarea relativă a scaunelor sunt în conformitate cu GOST 21958-76.

1.5. Cerințe software ACS

1.5.1. Software-ul ACS trebuie să fie suficient pentru a îndeplini toate funcțiile ACS, implementate folosind tehnologia computerizată și, de asemenea, să aibă mijloacele necesare pentru a organiza toate procesele necesare de prelucrare a datelor, permițând executarea la timp a tuturor funcțiilor automate în toate modurile de funcționare reglementate ale ACS.

1.5.2. Software-ul ACS trebuie să aibă următoarele proprietăți:

• suficiență funcțională (completitudine);
• fiabilitate (inclusiv restabilirea, disponibilitatea instrumentelor de detectare a erorilor);
• adaptabilitate;
• modificarea;
• modularitatea construcției și
• ușurință în utilizare.

1.5.3. Software-ul ACS ar trebui să fie construit în primul rând pe baza pachetelor de aplicații software existente și a altor programe împrumutate de la guvern, industrie și alte fonduri de algoritmi și programe, să permită încărcarea și verificarea părților și să permită înlocuirea unor programe fără corectarea altora.

1.5.4. Sistemul de control automat ar trebui să utilizeze în primul rând sisteme de management al bazelor de date (DBMS), înregistrate în modul prescris.

1.5.5. Software-ul ACS trebuie construit în așa fel încât absența datelor individuale să nu afecteze performanța funcțiilor ACS în implementarea cărora aceste date nu sunt utilizate.

1.5.6. Software-ul ACS trebuie să aibă instrumente pentru diagnosticarea hardware-ului ACS și monitorizarea fiabilității informațiilor de intrare.

1.5.7. Software-ul ACS trebuie să implementeze măsuri de protecție împotriva erorilor la introducerea și prelucrarea informațiilor, asigurând calitatea specificată a performanței funcțiilor ACS.

1.5.8. Software-ul general al sistemului de control automat ar trebui să permită configurarea componentelor software speciale și dezvoltarea în continuare a software-ului sistemului de control automatizat fără a întrerupe procesul de funcționare a acestuia. Partea deja generată și încărcată a software-ului trebuie protejată de modificări accidentale.

1.5.9. Toate programele software speciale pentru un anumit sistem automat de control trebuie să fie compatibile atât între ele, cât și cu software-ul general al acestuia.

1.5.10. Documentația software operațională pentru sistemul de control automatizat trebuie să respecte standardele ESPD și să conțină toate informațiile necesare pentru ca personalul sistemului de control automatizat să utilizeze software-ul, pentru încărcarea și (sau) generarea inițială a acestuia, încărcarea informațiilor din baza internă de informații a mașinii, lansarea automată. programele sistemelor de control și verificarea funcționării acestora cu ajutorul unor teste adecvate.

1.5.11. Nou dezvoltate în timpul creării unui sistem de control automatizat specific, produsele software incluse în software-ul acestuia trebuie să fie înregistrate în stat, industrie sau alte fonduri de algoritmi și programe (după caz).

1.6. Cerințe pentru suportul informațional al sistemelor de control automatizate

1.6.1. Suportul informatic al sistemului de control automatizat trebuie să fie suficient pentru a îndeplini toate funcțiile automatizate ale sistemului de control automatizat.

1.6.2. Pentru a codifica informațiile utilizate numai într-un anumit sistem de control automatizat, trebuie să se utilizeze clasificatoare acceptate de clientul sistemului de control automatizat.

1.6.3. Pentru a codifica informațiile de ieșire utilizate la un nivel superior în ACS, trebuie să se utilizeze clasificatoare ale sistemelor de control de nivel superior, cu excepția cazurilor special specificate.

1.6.4. Cerințele ergonomice generale pentru codarea informațiilor sunt în conformitate cu GOST 21829-76.

1.6.5. Următoarele trebuie utilizate în sistemul de control automat pentru comunicarea între dispozitivele unui complex de mijloace tehnice:

• semnale de intrare si iesire:
  • electrice - curent și tensiune conform GOST 26.011-80, cu modificări discrete ale parametrilor conform GOST 26.013-81, codificați conform GOST 26.014-81,
  • hidraulic conform GOST 26.012-80,
  • pneumatic conform GOST 26.015-81;
• seturi de caractere alfanumerice conform GOST 19767-74;
• Coduri pe 8 biți conform GOST 19768-74.

1.6.6. Suportul informatic al sistemului de control automatizat trebuie sa fie compatibil cu suportul informatic al sistemelor care interactioneaza cu acesta, din punct de vedere al continutului, sistemului de codificare, metodelor de adresare, formatelor de date si forma de prezentare a informatiilor primite si emise de sistemul de control automatizat.

1.6.7. Formele documentelor create de sistemul de control automatizat trebuie să respecte cerințele standardelor USD sau documentelor de reglementare și tehnice ale departamentului clientului sistemului de control automat.

1.6.8. Formele documentelor și cadrele video introduse, scoase sau ajustate prin terminalele ACS trebuie să fie în concordanță cu caracteristicile tehnice relevante ale terminalelor.

1.6.9. Totalitatea rețelelor de informații ale sistemelor de control automatizate trebuie organizate sub formă de baze de date pe suport informatic.

1.6.10. Forma de prezentare a informațiilor de ieșire a sistemului de control automat trebuie convenită cu clientul (utilizatorul) sistemului.

1.6.11. Termenii și abrevierile utilizate în documentele de ieșire ale sistemului de control automat trebuie să fie general acceptați în domeniul dat și convenite cu clientul sistemului.

1.6.12. Sistemul de control automatizat trebuie să prevadă măsurile necesare pentru controlul și actualizarea datelor din matricele de informații ale sistemului de control automat, restabilirea matricelor după defecțiunea oricăror mijloace tehnice ale sistemului de control automat, precum și controlul identității informațiilor din același nume în bazele de date.

1.7. Cerințe pentru suportul organizațional al sistemelor de control automatizate

1.7.1. Suportul organizatoric al sistemului automatizat de control trebuie să fie suficient pentru îndeplinirea efectivă de către personalul sistemului de control automatizat a atribuțiilor care îi sunt atribuite în implementarea responsabilităților automatizate în implementarea funcțiilor automatizate și neautomatizate aferente sistemului.

1.7.2. Structura organizatorică a sistemului de control automatizat trebuie să permită îndeplinirea tuturor funcțiilor sistemului de control automatizat, ținând cont de repartizarea acestora între nivelurile de conducere.

1.7.3. Cerințele de repartizare a responsabilităților între personalul implicat în funcționarea sistemului de control automatizat în timp real sunt determinate ținând cont de cerințele clauzei 11 din Anexa 1 obligatorie.

1.7.4. Instrucțiunile pentru sprijinul organizațional al sistemului de control automat trebuie să determine acțiunile personalului sistemului de control automat necesare pentru a îndeplini fiecare funcție automată în toate modurile de funcționare ale sistemului de control automat, ținând cont de cerințele specificate pentru precizia și viteza de implementare. de către personalul sistemului de control automatizat a atribuțiilor lor funcționale și, de asemenea, conțin instrucțiuni specifice privind acțiunile în cazul unor situații de urgență sau încălcarea condițiilor normale de funcționare a sistemului de control automatizat. Cerințele pentru conținutul instrucțiunilor sunt în conformitate cu GOST 24.209-80.

1.7.5. Pentru fiecare funcție automatizată care este efectuată în interacțiunea acestui ACS cu alte sisteme, instrucțiunile către personalul ACS și aceste sisteme trebuie să fie interconectate pentru toate modurile de îndeplinire a acestei funcții și să conțină instrucțiuni privind acțiunile personalului în cazul defecțiunilor mijloacele tehnice ale ACS.

1.8. Cerințe pentru suportul lingvistic al sistemelor de control automatizate

1.8.1. Suportul lingvistic al sistemului de control automatizat trebuie să fie suficient pentru comunicarea între diverse categorii de utilizatori într-o formă convenabilă acestora cu instrumentele de automatizare a sistemului de control automatizat și pentru efectuarea procedurilor de conversie și reprezentare automată a informațiilor prelucrate în sistemul de control automatizat.

1.8.2. Suportul lingvistic al sistemului de control automat ar trebui să includă:

• sunt furnizate instrumente lingvistice pentru a descrie orice informație utilizată în sistemul de control automatizat;
• mijloacele lingvistice folosite sunt unificate;
• au fost standardizate descrierile elementelor similare de informare și înregistrarea structurilor sintactice;
• Se asigură comoditatea, neechivocitatea și stabilitatea comunicării între utilizatori și sistemele de control automatizate;
• sunt prevăzute mijloace pentru corectarea erorilor care apar atunci când utilizatorii comunică cu mijloacele tehnice ale sistemului de control automatizat.

1.8.3. Suportul lingvistic al sistemului de control automat trebuie să se reflecte în documentația (instrucțiuni, descrieri) suport organizațional al sistemului de control automat sub forma regulilor de comunicare între utilizatori și mijloacele tehnice ale sistemului de control automat în toate modurile de sistem. Operațiune.

1.9. Cerințe pentru suportul juridic al sistemelor de control automatizate

Asistența juridică pentru sistemele de control automatizate ar trebui să includă un set de norme legale:

• determinarea valabilității legale a informațiilor despre suporturile de date și documentele utilizate în funcționarea sistemului de control automatizat și create de sistem;
• reglementarea raporturilor juridice dintre persoanele care fac parte din personalul ACS (drepturi, îndatoriri și responsabilități), precum și între personalul ACS și personalul sistemelor care interacționează cu ACS.

Notă. Regulile și reglementările care decurg din valabilitatea legală a informațiilor despre suporturile de date și reglementările legale trebuie incluse în instrucțiunile și reglementările de suport organizațional pentru serviciile ICS relevante.

1.10. Cerințe pentru documentația operațională pentru sistemele automate de control

1.10.1. Documentația operațională pentru ACS trebuie să fie suficientă pentru punerea în funcțiune a ACS și pentru funcționarea sa eficientă.

1.10.2. Documentația operațională pentru sistemul de control automat trebuie:

• conțin informații necesare pentru dezvoltarea rapidă și de înaltă calitate și funcționarea corectă a sistemelor de control automatizate;
• conțin instrucțiuni privind activitățile personalului ACS în situații de urgență sau în caz de încălcare a condițiilor normale de funcționare ale ACS;
• nu conțin prevederi care să fie supuse interpretării ambigue.

2. CERINȚE DE SIGURANȚĂ

2.1. Acțiunile incorecte ale personalului ACS nu ar trebui să conducă la o urgență.

2.2. Cerințele de siguranță pentru produsele electrice utilizate în sistemele de control automate sunt în conformitate cu GOST 12.2.007.0-75.

2.3. Cerințele de securitate pentru echipamentele informatice utilizate în sistemele de control automate sunt în conformitate cu GOST 25861-83.

2.4. Toate elementele externe ale mijloacelor tehnice ale sistemului de control automat care sunt alimentate trebuie protejate împotriva contactului accidental, iar mijloacele tehnice în sine trebuie împământate sau împământate de protecție în conformitate cu GOST 12.1.030-81 și „Reguli pentru dispozitivele de alimentare cu energie electrică”. .

2.5. Echipamentele tehnice ACS situate în instalații cu pericol de explozie și incendiu trebuie să îndeplinească cerințele „Regulilor de alimentare cu energie”.

2.6. Mijloacele tehnice ACS trebuie instalate astfel încât să asigure funcționarea și întreținerea lor în siguranță.

2.7. Cerințele de siguranță trebuie să fie stabilite într-o secțiune specială a fișelor postului și (sau) instrucțiunilor de operare pentru sistemele de control automate și să aibă legături către instrucțiunile de operare pentru echipamentele tehnice.

2.8. Cerințele ergonomice generale pentru locurile de muncă ale personalului sistemului de control automat sunt în conformitate cu GOST 22269-76.

2.9. Condițiile de viață confortabile pentru personalul sistemului de control automat trebuie să respecte standardele sanitare actuale, condițiile maxime de viață permise - în conformitate cu GOST 12.1.005-76, nivelurile permise de influență a factorilor de producție periculoși și nocivi - în conformitate cu GOST 12.0.003-74 .

2.10. Cerințele ergonomice generale pentru microclimatul spațiilor de lucru ale personalului sistemului de control automat sunt în conformitate cu GOST 12.1.005-76.

2.11. Nivelurile de zgomot și putere sonoră în locațiile personalului sistemului de control automat nu trebuie să depășească valorile stabilite de GOST 12.1.003-83 și standardele sanitare, în timp ce nivelurile de zgomot și puterea sonoră create de toate sursele, inclusiv de mijloacele acustice de transmisia de date, trebuie luată în considerare.

2.12. Nivelurile de iluminare ale locurilor de muncă ale personalului sistemului de control automat trebuie să corespundă naturii și condițiilor de lucru. Trebuie asigurată protecție împotriva orbirii și reducerea orbirii.

2.13. Cerințele ergonomice generale pentru vibrațiile echipamentelor la locurile de muncă ale personalului sistemului de control automat sunt în conformitate cu GOST 12.1.012-78.

2.14. Culorile semnalului și semnele de siguranță conform GOST 12.4.026-76.

3. TIPURI ȘI PROCEDURA DE ÎNCERCĂRI LA PUNERAREA ACS ÎN FUNCȚIONARE

Această secțiune se aplică tuturor sistemelor de control automatizate, cu excepția celor create prin ordin al Ministerului Apărării.

3.1. Un sistem de control automat sau o funcție livrată separat a unui sistem de control automat (denumit în continuare sistem de control automat), la punerea în funcțiune, trebuie să fie supus unor teste preliminare și de recepție, precum și încercări prevăzute de documentele de reglementare și tehnice. în vigoare în departamentul clientului sistemului de control automatizat.

3.2. Testarea de acceptare a sistemului de control automat trebuie să fie precedată de operarea de probă a acestuia la unitatea de control.

3.3. Testele ACS sunt efectuate în conformitate cu documentul „Programul de testare”, care este pregătit de dezvoltatorul ACS. Cerințele pentru conținutul programului de testare sunt în conformitate cu GOST 24.208-80.

3.4. Testele ACS pot fi efectuate în una sau mai multe etape.

Pe baza rezultatelor testelor, ACS întocmește un „Raport de testare”. Cerințele pentru conținutul raportului de testare sunt în conformitate cu GOST 24.208-80.

La testarea unui ACS pas cu pas, „Raportul de testare” bazat pe rezultatele etapei precedente ar trebui să conțină o concluzie despre posibilitatea de a transmite ACS la următoarea etapă de testare.

3.5. Teste preliminare ale sistemului de control automatizat

3.5.1. Testele preliminare ale sistemului de control automat sunt efectuate pentru a determina performanța acestuia și pentru a rezolva problema posibilității de a accepta sistemul de control automat pentru funcționarea de probă.

3.5.2. „Programul de testare” pentru testarea preliminară a ACS este aprobat de clientul ACS.

3.5.3. Testele preliminare ale ACS sunt organizate de client și efectuate în comun de dezvoltatorul ACS și client.

3.5.4. Comisia pentru efectuarea testelor preliminare ale sistemului de control automat se formează la ordinul clientului. Președinte al comisiei este desemnat un reprezentant al clientului sistemului de control automatizat.

3.5.6. „Raportul de testare”, întocmit pe baza rezultatelor testelor preliminare ale ACS, oferă o concluzie cu privire la posibilitatea acceptării ACS pentru funcționarea de probă, precum și o listă cu modificările necesare și termenele recomandate pentru implementarea acestora.

3.6. Funcționare de probă a sistemelor de control automate

3.6.1. Rezultatele acceptării ACS pentru funcționare de probă sunt documentate în „Certificatul de acceptare pentru funcționare de probă”, întocmit pe baza „Raportului de testare” de către comisia care a efectuat testele preliminare ale ACS. Cerințele pentru conținutul actului sunt în conformitate cu GOST 24.208-80.

3.6.2. Durata de testare a sistemului de control automat este determinată de timpul necesar pentru verificarea funcționării corecte a sistemului de control automat la îndeplinirea fiecărei funcții automatizate și de disponibilitatea personalului sistemului de control automat de a participa la îndeplinirea tuturor funcțiilor automate ale sistemul de control automatizat.

3.6.3. Durata minimă de funcționare de probă a sistemului de control automat (cu excepția sistemului de control automat) înainte de testarea de recepție este determinată pentru fiecare funcție automată a sistemului de control automat care este depusă; aceasta trebuie să corespundă valorilor indicate în masa. În cazul în care durata totală a întreruperilor continuității unei funcții automate depășește valoarea specificată în tabel, operațiunea de probă trebuie continuată până la obținerea rezultatelor în concordanță cu tabelul sau până când se ia decizia de încetare a acesteia.

Este permisă, prin acord cu clientul, depunerea ACS pentru testarea de acceptare fără funcționare de probă a acelor funcții automate a căror frecvență de soluție este mai mică de o dată pe lună, cu condiția ca în ACS nu numai astfel de funcții să fie automatizate.

Frecvența execuției automate a funcției	Durata minimă de funcționare de probă a sistemului de control automat înainte de testarea de acceptare	Durata totală admisă a întreruperilor continuității execuției unei funcție a sistemului automatizat de control automat
Continuu	1 lună	Nu mai mult de 3 zile
O dată pe zi sau mai des	La fel	Nu mai mult de 10% din numărul planificat de soluții
Mai puțin de o dată pe zi până la o dată pe lună	3 luni	La fel
Mai puțin de o dată pe lună până la o dată la șase luni	Perioada dintre două decizii consecutive	Nu sunt permise întreruperi ale continuității performanței funcției
O dată pe an sau mai puțin	Perioada de timp necesară pentru a testa tehnologia adoptată pentru colectarea și procesarea informațiilor în timpul unei execuții unice a funcției ACS	La fel

Note:

1. O încălcare a continuității executării unei funcții automate a unui sistem de control automat este considerată a fi neefectuarea acesteia la momentul specificat în documentația tehnică a sistemului de control automat, cu excepția cazului în care aceasta este cauzată de o încălcare a condiţiile de funcţionare ale sistemului de control automat sau ale obiectului de control.

2. În cazul în care durata efectivă a funcționării de probă a sistemului de control automatizat a fost mai mare decât timpul indicat în a doua coloană a tabelului, atunci durata totală a întreruperii continuității execuției pentru fiecare funcție automatizată este determinată pentru perioada de timp. indicate în tabel și imediat premergătoare testelor de recepție.

3.6.4. În timpul funcționării de probă a ACS, se ține un jurnal de lucru în care se înregistrează informații: despre durata de funcționare a ACS, despre rezultatele monitorizării funcționării corecte a ACS, despre defecțiuni, defecțiuni, situații de urgență, despre modificări. în parametrii obiectului de control și ajustări în curs ale documentației tehnice.

3.6.5. Pe baza rezultatelor operațiunii de probă se întocmește un certificat de finalizare a lucrărilor de verificare a sistemului de control automatizat în modul de funcționare de probă. Cerințele pentru conținutul actului sunt în conformitate cu GOST 24.208-80.

3.7. Teste de acceptare ACS

3.7.1. Testele de acceptare ale ACS sunt efectuate pentru a determina conformitatea acestuia cu specificațiile tehnice pentru ACS, cerințele acestui standard și pentru a determina posibilitatea punerii în funcțiune a ACS.

3.7.2. În funcție de importanța obiectului de control și a sistemului de control automatizat, testele de acceptare pot fi:

• guvern;
• interdepartamental;
• departamental

și trebuie efectuată de comitetele de acceptare relevante. Comitetul de acceptare se formează prin ordin al ministerului (departamentului) clientului sistemului de control automatizat. Nivelul comitetului de acceptare trebuie stabilit în specificațiile tehnice pentru sistemul de control automatizat.

3.7.3. Un reprezentant al clientului sistemului de control automat este desemnat ca președinte al comitetului de acceptare. Comitetul de acceptare trebuie să includă reprezentanți ai dezvoltatorului ACS.

3.7.4. Activitatea comitetului de acceptare nu include acceptarea clădirilor, structurilor și echipamentelor auxiliare, a căror creare a fost realizată în legătură cu crearea unui sistem de control automat. Comisia verifică doar disponibilitatea certificatelor de acceptare pentru funcționare și îndeplinirea cerințelor cuprinse în sarcinile de proiectare în părțile adiacente ale proiectului instalației, emise în timpul proiectării sistemului de control automat.

3.7.5. Clientul și dezvoltatorul prezintă comitetului de acceptare următoarea documentație:

• termeni de referință pentru crearea unui sistem de control automatizat;
• proiect de program de testare de acceptare;
• Raportul preliminar de testare ACS;
• certificat de acceptare a sistemului de control automatizat pentru funcționare de probă;
• act(e) la finalizarea lucrărilor de verificare a sistemului de control automatizat în regim de funcționare de probă;
• documentatia tehnica pentru sistemul de control automatizat (prin decizie a comisiei de receptie).

3.7.6. Înainte de a fi depuse pentru testarea de recepție, sistemele de control automatizate cu canale de măsurare sunt supuse certificării metrologice în conformitate cu standardele în vigoare.

3.7.7. Înainte de prezentarea ACS pentru testarea de recepție, sistemul și documentația sa tehnică trebuie finalizate pe baza comentariilor protocolului de testare preliminară și a certificatului de finalizare a lucrărilor de verificare a ACS în modul de funcționare de probă.

Se permite, prin hotărâre a comisiei de recepție, finalizarea documentației tehnice a sistemului de control automatizat după ce a fost pus în funcțiune. Termenele de finalizare a documentației tehnice a sistemului de control automatizat sunt indicate în procesul-verbal de testare a sistemului.

3.7.8. Testele de recepție ale sistemului de control automat trebuie să fie efectuate la o unitate de control funcțională.

3.7.9. „Programul de testare” pentru testarea de acceptare a sistemului de control automatizat trebuie aprobat prin deciziile comisiei de acceptare. Coordonarea programului de testare a recepției cu clientul sistemului de control automat este obligatorie.

3.7.10. Pe baza rezultatelor testelor de acceptare, comisia întocmește un raport de testare și un act privind punerea în funcțiune a ACS (sau o concluzie privind neacceptarea ACS cu o listă a modificărilor necesare și a termenelor recomandate pentru implementarea acestora). Cerințe pentru conținutul protocolului și acționează în conformitate cu GOST 24.208-80. Cerințele privind conținutul încheierii privind neacceptarea sistemului de control automatizat sunt similare cu cerințele pentru conținutul actului de punere în aplicare a sistemului de control automatizat.

3.7.11. În cazul încercărilor de recepție etapă, actul de punere în funcțiune a sistemului de control automatizat se întocmește pe baza actelor de punere în funcțiune a părților individuale ale sistemului și (sau) „Rapoarte de testare” a tuturor etapele testării de acceptare a sistemului de control automatizat.

3.7.12. Data punerii în funcțiune a sistemului de control automatizat este considerată a fi data semnării actului de punere în funcțiune de către comisia de recepție.

3.7.13. Actul de punere în aplicare a sistemului de control automatizat este aprobat de ministerul (departamentul) clientului.

4. COMPLETITUDINEA ACS PUNSĂ ÎN FUNCȚIONARE

4.1. ACS ar trebui să includă:

• Mijloace tehnice ACS sub forma unui complex de mijloace tehnice ACS pregătite pentru exploatare;
• piese de schimb și dispozitive (SPTA), instrumente și dispozitive pentru testarea operabilității, amenajarea echipamentelor tehnice și monitorizarea caracteristicilor metrologice ale canalelor de măsurare ale sistemului de control automatizat în măsura prevăzută de documentația de proiectare personalizată convenită cu clientul automatului; sistem de control și serviciul de metrologie al utilizatorului în ceea ce privește echipamentele de testare;
• documentație operațională în conformitate cu GOST 2.601-68 pentru fiecare dintre produsele incluse în CTS ACS;
• cel puțin două copii ale programelor pe suporturile de date și documentația operațională a acestora în conformitate cu GOST 19.101-77, ținând cont de restricțiile și completările în conformitate cu GOST 24.101-80 și GOST 24.207-80;
• un formular pentru software-ul ACS ca întreg sau pentru software-ul unei funcții ACS puse în funcțiune separat și formulare pentru produse software (conform GOST 19.004-80), fiecare într-o singură copie. Cerințe pentru formular - conform GOST 19.501-78;
• două copii ale documentației operaționale pentru sistemul de control automatizat în conformitate cu GOST 24.101-80, inclusiv documentația necesară pentru suportul informativ al sistemului de control automatizat (formularul sistemului de control automatizat într-o singură copie).

Prin acord între dezvoltatorul ACS și clientul ACS, caracterul complet al ACS poate fi extins.

4.2. Personalul ACS trebuie să aibă personal care îndeplinește cerințele clauzei 1.3.

4.3. Pentru a completa sistemul de control automat creat, se pot folosi următoarele, furnizate ca produse de producție și tehnice:

• complex (complexe) de hardware și software cu documentație operațională pentru acestea în conformitate cu GOST 2.601-68;
• produse software cu documentație operațională pentru acestea în conformitate cu GOST 19.101-77;
• echipamente tehnice cu documentație operațională pentru ei în conformitate cu GOST 2.601-68.

4.4. Procedura de dezvoltare, lansare în producție și testare a componentelor furnizate utilizate în sistemul de control automatizat trebuie să respecte standardele de stat pentru sistemul de dezvoltare și lansare a produselor în producție.

Înainte de a fi puse în producție, prototipurile componentelor sunt supuse unor teste de acceptare (de stat, interdepartamentale, departamentale).

5. GARANȚIE

5.1. Dezvoltatorul sistemului de control automat garantează conformitatea sistemului de control automat cu cerințele prezentului standard și cu specificațiile tehnice pentru sistemul de control automat, sub rezerva respectării de către utilizator a condițiilor și regulilor de funcționare.

5.2. Conformitatea hardware-ului, software-ului și a sistemelor de echipamente de automatizare utilizate în sistemele de control automatizate și furnizate ca produse de producție și tehnice cu cerințele standardelor și specificațiilor pentru acestea este garantată de producătorii acestor tipuri de produse, sub rezerva respectării de către utilizator a condițiilor de operare. conditii si reguli.

5.3. Perioada de garanție pentru ACS se calculează de la data punerii în funcțiune a ACS.

5.4. Perioada de garanție pentru ACS trebuie stabilită în specificațiile tehnice pentru ACS și nu poate fi mai mică de 18 luni.

ANEXA 1
Obligatoriu

CERINȚE SUPLIMENTARE PENTRU SISTEME DE CONTROL AUTOMAT DE PROCESE (APCS)

1. Sistemele de control al proceselor din industrie și din sfera neindustrială trebuie să gestioneze obiectul tehnologic în ansamblu și să furnizeze sistemelor interconectate informații tehnologice și tehnice și economice fiabile despre funcționarea obiectului de control tehnologic (UT).

2. Sistemul automat de control al proceselor trebuie să dezvolte și să implementeze acțiuni de control asupra sistemului tehnic de control care să fie raționale în ceea ce privește obiectivele și criteriile de control în timp real al procesului tehnologic din obiectul de control.

3. Sistemul automat de control al procesului trebuie să îndeplinească funcții de control, informare și auxiliare.

4. Sistemul de control al procesului trebuie să fie compatibil cu toate sistemele automatizate (AS) interconectate cu acesta, specificate în termenii de referință pentru sistemul de control al procesului, inclusiv sistemele incluse în acest sistem de control al procesului ca parte a producției automate flexibile, de exemplu, Tehnologii CAD, sisteme automate de depozitare și transport, AS pentru pregătirea tehnologică a producției.

5. Acțiunile de control în sistemul automat de control al proceselor trebuie să fie generate automat sau generate de personalul operațional al acestuia folosind un set de instrumente de automatizare incluse în sistem.

6. Sistemul automat de control al procesului trebuie să asigure controlul instalației în condiții normale, tranzitorii și de pre-urgență ale funcționării acesteia, precum și protecția sau oprirea instalației în cazul amenințării unui accident.

7. Sistemul automat de control al proceselor trebuie să îndeplinească funcția de monitorizare a executării acțiunilor de control asupra echipamentelor tehnice și să semnalizeze când organele executive își ating pozițiile maxime admisibile.

8. La implementarea funcției de deviere automată de urgență a echipamentului în sistemul de control al procesului, trebuie furnizată o alarmă despre aceasta personalului de exploatare folosind semnale luminoase și, dacă este necesar, sonore cu înregistrarea automată a timpului de oprire.

9. Ca principal mijloc tehnic al sistemelor automate de control al proceselor, ar trebui să fie produse ale Sistemului de stat de instrumente industriale și echipamente de automatizare (GSP), alte produse care îndeplinesc cerințele standardelor ESSP și echipamente informatice care respectă GOST 21552-84. folosit.

10. Mijloacele tehnice ale sistemelor automate de control al procesului amplasate pe echipamentele de proces trebuie să îndeplinească cerințele pentru condițiile de funcționare ale acestora.

11. Responsabilitățile între operatori ar trebui repartizate ținând cont de:

• participarea personalului la îndeplinirea funcțiilor manuale ale sistemului și interacțiunea acestuia cu alte sisteme;
• nivelul admisibil de încărcare psihofiziologică și emoțională a operatorilor stabilit de documentele normative și tehnice ale industriei asociate cu îndeplinirea atribuțiilor atribuite fiecăruia dintre aceștia și responsabilitatea acestuia pentru rezultatele finale și intermediare ale muncii, precum și nivelul cerut al activității sale în curs de lucru.

12. Fiecare persoană inclusă în personal trebuie să aibă:

• cunoștințe, al căror volum și profunzime îi permit să efectueze acțiuni (interacțiuni) incluse în funcțiile corespunzătoare automate și interconectate neautomatizate ale sistemului automat de control al procesului, precum și să ia deciziile corecte în situații de urgență sau alte încălcări ale funcționării normale. ;
• abilități dezvoltate care permit efectuarea tuturor acțiunilor și interacțiunilor cu precizie și viteză specificate.

13. Software-ul sistemului automat de control al proceselor trebuie să ofere, iar suportul organizațional să reflecte, instrumente lingvistice de comunicare între personalul operațional și sistemul automat de control al proceselor, convenabile și accesibile persoanelor care nu au calificare de programator.

14. Codurile și simbolurile utilizate în sistemul de control al procesului trebuie să fie apropiate de termenii și conceptele folosite de personalul tehnologic al obiectului de control și să nu provoace dificultăți în perceperea acestora.

15. Canalele de măsurare ale sistemului automat de control al proceselor trebuie să aibă caracteristici metrologice care să asigure îndeplinirea funcțiilor de informare ale acestuia cu indicatorii specificați în specificațiile tehnice pentru sistemul automat de control al procesului.

16. Cerințe pentru testarea sistemelor automate de control al procesului

16.1. Testele preliminare ale sistemului automat de control al procesului sunt efectuate pe un echipament tehnic existent.

16.2. Testele preliminare ale funcțiilor sistemului automat de control al procesului necesare pentru pornirea și rularea echipamentelor de proces pot fi efectuate la fața locului cu ajutorul simulatoarelor.

16.3. Determinarea valorilor reale ale indicatorilor de eficiență tehnică și economică și fiabilitate a sistemului automat de control al procesului se efectuează după punerea sa în funcțiune. Timpul de funcționare al sistemului automat de control al procesului, necesar pentru determinarea valorilor reale ale indicatorilor acestuia, se calculează conform metodelor adecvate aprobate în modul prescris.

ANEXA 2
Obligatoriu

CERINȚE SUPLIMENTARE PENTRU ACS DE ÎNTREPRINDERI, ASOCIAȚII DE PRODUCȚIE ȘI CERCETARE ȘI PRODUCȚIE

1. Sistemul de control automatizat trebuie să crească eficiența producției și a activităților economice ale întreprinderilor, producției sau asociațiilor științifice și de producție (denumite în continuare întreprinderi).

2. Sistemul de control automatizat al întreprinderii (ACS) trebuie să asigure colectarea și prelucrarea automată a informațiilor cu utilizarea pe scară largă a metodelor de optimizare pentru sarcinile principale și subsisteme de control ale nivelului general de fabrică și atelier, inclusiv, dacă este necesar, în timp real în teleprocesare. și modul de dialog.

3. Sistemul de control automatizat trebuie implementat ca un set de subsisteme care funcționează în comun, a căror interacțiune trebuie să aibă loc printr-o bază de date comună (unică sau distribuită).

4. Sprijinul organizațional pentru sistemele de control automatizate ar trebui să prevadă îmbunătățirea metodelor de management și a structurii sistemului de management al întreprinderii în timpul creării și dezvoltării sistemelor de control automatizate.

ANEXA 3
Obligatoriu

CERINȚE SUPLIMENTARE PENTRU SISTEME DE CONTROL AUTOMATIZATE DIN INDUSTRIE (OACS)

1. OASU trebuie să asigure:

• îmbunătățirea caracteristicilor obiectului de control (creșterea productivității muncii în industrie, îmbunătățirea calității produselor, livrarea la timp a produselor, reducerea costului produselor fabricate);
• îmbunătățirea proceselor de prelucrare a informațiilor (reducerea costului procesării informațiilor, creșterea fiabilității celor inițiale, creșterea preciziei și eficienței calculelor);
• îmbunătățirea organizării funcțiilor de management (în special, distribuția rațională a muncii între departamentele aparatului de management, centrele de calcul și organizațiile și întreprinderile de cercetare).

2. OASU trebuie să automatizeze funcțiile de management al industriei, de exemplu:

• prognozarea și planificarea producției și resurselor industriei;
• managementul dezvoltării științifice și tehnice a industriei și pregătirea tehnică a producției industriale;
• managementul forței de muncă din industrie;
• managementul resurselor materiale ale industriei;
• managementul construcțiilor de capital în industrie;
• gestionarea resurselor financiare ale industriei;
• managementul, inclusiv managementul operațional, al producției principale la nivel de industrie etc.

3. OACS ar trebui implementat ca un set de subsisteme care funcționează în comun, interacțiunea dintre care ar trebui să aibă loc prin baze de date comune.

4. OASU trebuie să includă un sistem de colectare a datelor bazat pe centrele de calcul ale OASU, organizațiilor și întreprinderilor din industrie, care să asigure distribuirea rațională a informațiilor în baze de date pentru rezolvarea problemelor de interacțiune și transferul de informații între sisteme prin canale de comunicare și pe medii informatice.

5. OACS trebuie să ofere un mod interactiv de lucru cu bazele de date de sistem.

6. Crearea OASU ar trebui să conducă la îmbunătățirea metodelor și structurii managementului industriei.

7. Durata exploatării de probă a părților OACS trebuie să asigure efectuarea unică a tuturor calculelor necesare îndeplinirii funcțiilor automate ale părții introduse a OACS și nu trebuie să depășească 3 luni.

Durata specifică de funcționare de probă a OASU este stabilită prin acord între dezvoltator și client.

ANEXA 4
informație

EXPLICAȚIA UNOR TERMENI UTILIZAȚI ÎN ACEST STANDARD

Complex de echipamente de automatizare (CAS)- un set furnizat de seturi de hardware și software (produse) convenite de comun acord, dezvoltate și fabricate ca produse în scopuri industriale și tehnice. KSA poate include și alte produse și (sau) documente incluse în informații, organizare sau alte tipuri de suport pentru sistemele automate.

Extinderea sistemelor de control automatizate- un set de măsuri luate în sistemul de control automatizat la extinderea obiectului său de control fără modificarea compoziției funcțiilor sistemului de control automatizat.

Cadru video (în ACS)- imaginea pe ecranul unui document cu tub catodic a unui desen sau text de mesaj utilizat în sistemul de control automat.

Canal de măsurare ACS- un set integrat funcțional de instrumente tehnice și (dacă este necesar) software concepute pentru a implementa o funcție simplă de măsurare a sistemului de control automatizat.

Teste preliminare ale sistemului de control automatizat- teste de control efectuate pentru determinarea posibilitatii de acceptare a sistemului de control automatizat pentru functionare de proba.

Teste de acceptare ACS- teste de control ale sistemului de control automatizat, efectuate pentru a determina conformitatea acestuia cu specificatiile tehnice pentru realizarea sistemului de control automatizat, cerintele standardelor si pentru a determina posibilitatea punerii in functiune a sistemului de control automatizat.

Teste de stat- teste de acceptare a sistemelor automate de control efectuate de comisia de stat.

Testare interdepartamentală- teste de acceptare a sistemelor automate de control efectuate de o comisie de reprezentanți ai mai multor ministere și (sau) departamente interesate.

Teste departamentale- teste de acceptare a sistemelor automate de control efectuate de o comisie de reprezentanti ai ministerului sau departamentului interesat.

Editorul A.I. Lomina
Editor tehnic N.P. Zamolodchikova
Corector E.I. Evteeva
Livrat la set 16/01/86. Semnat pentru publicare la 04/08/86. Condiţional cuptor l. 1.5. Condiţional cr.-ott. 1.5 Ed. academic. l. 1.5.
Tiraj 40.000 Pret 10 copeici.
Ordinul „Insigna de onoare” Editura standardelor, 123810, Moscova, GSP, strada Novopresnensky, 3
Tip. „Imprimanta Moscova”, Moscova, strada Lyalin, 6. Ordinul 1772

Astăzi vom vorbi despre standardele interne pentru documentația de proiectare. Cum funcționează aceste standarde în practică, de ce sunt rele și de ce sunt bune. Atunci când dezvoltăm documentație pentru guvern și clienți privați serioși, de obicei nu avem de ales - conformitatea cu standardele este inclusă în cerințele pentru documentarea specificațiilor tehnice. În practică, am întâlnit diverse exemple de neînțelegere a structurii standardelor, ce ar trebui să fie în documente și de ce sunt necesare aceste documente. Drept urmare, pixurile scriitorilor tehnici, analiștilor și specialiștilor produc uneori astfel de pietre prețioase încât nu este clar în ce stare de conștiință au fost scrise. Dar, de fapt, totul este destul de simplu. O căutare pe Habr nu a returnat niciun link către material mai mult sau mai puțin complet pe această temă, așa că îmi propun să umplem acest gol enervant.

Ce sunt standardele de documentare?

În seria 34 în cauză, există doar 3 standarde principale de documentare:

Cel mai iubit și popular standard pentru dezvoltarea specificațiilor tehnice. Singurul lucru pe care nu trebuie să-l uitați este că este strâns legat de alte standarde ale seriei, iar dacă ați primit specificații tehnice realizate conform acestui standard, este foarte recomandabil să respectați alte standarde, chiar dacă nu există cerințe directe. pentru aceasta. Cel puțin în ceea ce privește ideologia generală (despre care mai jos)

Acesta este un document de bază care oferă o listă completă a documentației GOST 34, recomandări pentru codificarea documentelor, etapele de proiect cărora le aparțin documentele (etapele sunt descrise în GOST 34.601-90), precum și modul în care pot fi combinate între ele. .

De fapt, acest standard este un tabel mare cu comentarii. Poate fi pus în Excel pentru ușurință în utilizare.

Un standard voluminos care descrie conținutul documentelor de proiect cu diferite grade de detaliu. GOST 34.201-89 menționat mai sus este folosit ca index.

Există multe întrebări și interpretări ale prevederilor acestuia cu privire la standardul RD 50-34.698-90, care, datorită vagului lor, sunt adesea înțelese diferit de către client și antreprenor, sau chiar membrii echipei de proiect. Dar, din păcate, nu avem nimic mai concret.

Să luăm acum în considerare avantajele și dezavantajele standardelor, începând în mod tradițional cu dezavantajele.

Dezavantajele standardelor

Principalul dezavantaj este evident pentru toată lumea - standardele sunt vechi. Ele conțin o idee învechită a arhitecturii unui sistem automatizat. De exemplu:

• aplicații pe două niveluri, constând dintr-un program client și un server DBMS (fără trei sau mai multe aplicații „nivel”, fără Weblogic sau JBoss)
• structura tabelelor bazei de date, fiind descrisă, va da o idee despre modelul logic de date (faptul că ar putea exista un fel de Hibernare între aplicație și baza de date părea un exces rău atunci)
• interfața cu utilizatorul este cu o singură fereastră (mai există ceva? Ce este un „browser”?)
• Există puține rapoarte în sistem; toate sunt pe hârtie și tipărite pe o imprimantă cu matrice de puncte.
• Programul în curs de dezvoltare este axat pe rezolvarea „problemei de procesare a informațiilor”, care are o intrare și o ieșire clare și este foarte specializată. Procesarea informațiilor se bazează pe un „algoritm”. Uneori există mai mulți „algoritmi”. (Programarea orientată pe obiecte făcea atunci doar primii pași și nu a fost luată în considerare în mod serios).
• administratorul bazei de date înțelege ce informații sunt în tabele și participă activ la editarea directoarelor sistemului (există într-adevăr un server DBMS pentru 50 de aplicații diferite?)

În consecință, standardul are artefacte precum următoarele:

5.8. Desenul formularului de document (cadru video)
Documentul trebuie să conțină o imagine a formei documentului sau a cadrului video în conformitate cu cerințele standardelor de stat ale sistemului de documentare unificat R 50-77 și explicațiile necesare.

Ideea documentului este că întreprinderile sovietice foloseau așa-numitele „zone de imprimare”, unde existau imprimante matrice de mare viteză, driverele pentru care erau adesea scrise de către inginerii înșiși. Prin urmare, au trebuit să mențină un registru cu toate documentele care trebuiau tipărite pentru a se asigura că documentele arată așa cum ar trebui la imprimare.

„Cadru video” este, de asemenea, un document care a fost afișat pe un afișaj text. Ecranele nu au acceptat întotdeauna caracterele necesare și numărul necesar de caractere orizontale și linii verticale (și nu au suportat deloc grafice). Prin urmare, și aici a fost necesară coordonarea suplimentară a formularelor tuturor documentelor de ecran.

Acum cuvintele „machineogramă”, „cadru video”, „ADC” nu ne mai spun nimic. Nici eu nu le-am găsit în uz, deși am absolvit un institut de specialitate în anii 90. Acesta a fost momentul apariției Windows 3.1, a ecranelor VGA, a dischetelor de trei inci și a primelor site-uri de internet interne. Dar aceste cuvinte sunt în standard, iar clientul solicită uneori capricios să îi oferim un set complet de documentație în conformitate cu GOST 34.201-89. Mai mult, astfel de formulări din ToR migrează de la un minister la altul și au devenit deja un fel de șablon nerostit în care este introdus conținutul.

Deci, documentul cu numele stupid „Desenul formularului de document (cadru video)” din proiect ar trebui și nu trebuie să fie gol.

Ce este bun în standard

Orice standard este bun prin faptul că permite clientului și contractantului să vorbească aceeași limbă și oferă o garanție că, cel puțin, clientul nu va avea nicio reclamație „în formă” la rezultatele transmise.

Și standardele GOST 34 sunt bune și pentru că au fost întocmite de oameni inteligenți, testate de-a lungul anilor și au un scop clar - să descrie pe hârtie cât mai complet esența complexă abstractă pe care o reprezintă orice sistem de control automatizat.

Când trebuie să stabiliți cu competență o sarcină pentru contractorii occidentali care nu au auzit niciodată de standardele noastre GOST, vă puteți baza și pe aceste standarde, sau mai degrabă pe conținutul și componenta semantică a acestora. Pentru că, repet, garanția completității informațiilor valorează mult. Indiferent cât de mult ne linguim cu nivelul înalt al profesionalismului nostru, este posibil să uităm să includem lucruri elementare în cerințele noastre, în timp ce același GOST 34.602-89 „îți aduce aminte” totul. Dacă nu vă este clar cum ar trebui să arate rezultatul muncii antreprenorilor occidentali, uitați-vă la cerințele de documentare și la secțiunile recomandate. Te asigur, e mai bine să nu te gândești la asta! Cel mai probabil, există analogi occidentali ai standardelor noastre, în care totul poate fi mai complet, mai modern și mai bun. Din păcate, nu sunt familiarizat cu ele, deoarece nu a existat încă un singur caz în care standardele noastre GOST nu au fost suficiente.

Puteți râde de faptul că creatorii de standarde nu știau nimic despre java sau .NET, despre monitoare HD și Internet, dar nu aș sfătui să subestimați amploarea muncii pe care le-au făcut și valoarea acesteia pentru comunitatea noastră profesională.

Cum să citiți și să înțelegeți standardele de documentare conform GOST seria 34

Standardul împarte toate documentele pe două axe - timp și domeniu. Dacă vă uitați la Tabelul 2 din GOST 34.201-89, puteți vedea clar această diviziune (coloanele „Etapa de creare” și „Parte din proiect”

Etapele creării unui sistem de control automatizat

Etapele creației sunt definite în GOST 34.601-90. Trei dintre ele sunt relevante pentru documentare:

• Proiect de proiect (ED)
• Proiectare tehnică (TP)
• Elaborarea documentației de lucru (DD)

Proiectare preliminară urmează după etapa Specificațiilor tehnice și servește la dezvoltarea soluțiilor preliminare de proiectare.

Proiect tehnic descrie viitorul sistem din toate unghiurile. Documentele aflate în etapa de TP ar trebui, după citire, să lase în urmă o claritate deplină în abordările, metodele, soluțiile arhitecturale și tehnice propuse. La următoarea fază, va fi prea târziu pentru a descrie abordările și a justifica soluțiile tehnice, astfel încât faza P este cheia pentru finalizarea cu succes a lucrării, deoarece toată varietatea de cerințe ale specificațiilor tehnice trebuie să fie reflectată în documentele fazei P. În faza P, este posibil ca sistemul să nu existe deloc.

Documentatie de lucru conceput pentru implementarea cu succes, punerea în funcțiune și funcționarea ulterioară a noului sistem. Acestea sunt documente care conțin informații foarte specifice care descriu entități existente fizic, spre deosebire de faza P, care descrie splendoarea viitoare.

Părți (secțiuni) ale documentației de proiect pentru crearea unui sistem de control automatizat

Tematica este împărțită în „Dispoziții”. La început se pare că o astfel de împărțire este redundantă și inutilă. Dar când începeți să lucrați cu acest set de instrumente în practică, ideologia încorporată în el devine treptat clară.

Un sistem automatizat, așa cum este definit de compilatorii GOST, este o combinație de hardware, software și canale de comunicare care prelucrează informații provenind din diferite surse în conformitate cu anumiți algoritmi și produce rezultate de prelucrare sub formă de documente, structuri de date sau acțiuni de control. Un model primitiv al celei mai simple mitraliere.

Pentru a descrie pe deplin această „mașină”, sunt realizate următoarele secțiuni (ca în desen):

Software (MS), răspunzând la întrebările: ce logică este conectată în interiorul „cutiei negre”? De ce au fost aleși acești algoritmi, formulele și coeficienții?

Software-ul matematic nu știe nimic despre procesoare sau baze de date. Aceasta este o zonă abstractă separată, locuința „cailor sferici în vid”. Dar software-ul matematic poate fi foarte strâns legat de aria subiectului, alias Viața Reală. De exemplu, algoritmii de control pentru sistemele de control al traficului trebuie aprobați de către Inspectoratul de Stat pentru Siguranța Circulației înainte de a fi aprobați de către client. Și atunci înțelegeți de ce sunt incluse într-o carte separată. Pentru că nimeni din poliția rutieră nu este interesat de ce sistem de operare va rula serverul de aplicații, dar ce semn și limita de viteză vor apărea pe tablă în ploaie sau zăpadă este foarte interesant. Ei sunt responsabili pentru partea lor și nu vor semna nimic altceva. Pe de altă parte, atunci când au semnat, nu vor fi întrebări despre latura tehnică a problemei - de ce au ales acele panouri sau semafoare și nu altele. Înțelepciunea „strămoșilor” se manifestă tocmai în astfel de cazuri practice.

Suport informațional (IS). O altă porțiune din sistem. De data aceasta, cutia neagră a sistemului nostru este transparentă și ne uităm la informațiile care circulă în ea. Imaginați-vă un model al sistemului circulator uman când toate celelalte organe sunt invizibile. Ceva de genul acesta este Suportul de informații. Descrie compoziția și rutele fluxului de informații în interior și în exterior, organizarea logică a informațiilor în sistem, o descriere a cărților de referință și a sistemelor de codificare (cei care au realizat programe pentru producție știu cât de importante sunt acestea). Partea descriptivă principală se încadrează în etapa TP, dar unele „rudimente” curg în etapa RD, cum ar fi documentul „Catalog baze de date”. Este clar că anterior conținea exact ceea ce este scris în titlu. Dar astăzi, încercați să creați un astfel de document pentru un sistem complex complex, când de foarte multe ori sistemul utilizează subsisteme achiziționate cu propriile lor depozite de informații misterioase. Nici măcar nu spun că acest document nu este deosebit de necesar acum.

Sau aici este „Declarația despre mediile de stocare a computerului”. Este clar că anterior conținea un număr de tobe magnetice sau bobine de film. Acum ce ar trebui să pun acolo?

Pe scurt, în faza RD, documentele Suport Informațional reprezintă un rudiment destul de dăunător, întrucât formal ar trebui să existe, dar nu există nimic special cu care să le umplem.

Software. Partea preferată a tuturor din documentația proiectului. Da, fie doar pentru că este doar un document! Și apoi, toată lumea înțelege ce trebuie scris acolo. Dar o voi repeta oricum.

În acest document, trebuie să vă spunem cu ajutorul cărui software sunt executați algoritmii descriși în ML, procesând informațiile descrise în IR. Adică, nu este nevoie să duplicați informațiile din alte secțiuni aici. Aici este prezentată arhitectura sistemului, rațiunea tehnologiilor software selectate, descrierea acestora (tot felul de lucruri de sistem: limbaje de programare, cadre, sisteme de operare etc.). De asemenea, în acest document descriem modul în care sunt organizate instrumentele de procesare a informațiilor (cozi de mesaje, stocare, instrumente de backup, soluții de disponibilitate, tot felul de pool-uri de aplicații etc.). Standardul conține o descriere detaliată a conținutului acestui document, pe care orice specialist o va înțelege.

Suport tehnic (TO). O parte nu mai puțin iubită a documentației proiectului. Tabloul roz nu este decât întunecat de abundența documentelor care trebuie dezvoltate. În total, standardul necesită elaborarea a 22 de documente, dintre care 9 sunt în stadiul de TC.

Faptul este că standardul oferă o descriere a întregului suport tehnic, inclusiv hardware și rețele de computer, sisteme de inginerie și chiar partea de construcție (dacă este necesar). Și această economie este reglementată de un număr mare de standarde și reglementări, coordonate în diferite organizații și, prin urmare, este mai convenabil să împărțiți totul în părți și să coordonați (editați) în părți. În același timp, standardul vă permite să combinați unele documente între ele, ceea ce are sens dacă întregul grup este aprobat de o singură persoană.

De asemenea, nu uitați că un set de standarde de calitate presupune înregistrarea și stocarea documentelor tehnice, iar „cărțile” noastre de la client pot fi distribuite în diferite arhive, în funcție de subiectul descrierii. Acesta este un alt argument în favoarea fragmentării documentației.

Suport organizațional (OO). După ce am suprimat dorința, normală pentru un techie, de a trece peste această secțiune cât mai repede posibil, dimpotrivă, o voi lua în considerare mai detaliat. De vreme ce, colegilor, în ultima perioadă au existat unele tendințe proaste în proiecte care necesită clarificări în această secțiune.

La etapa TP, secțiunea conține un singur document „ Descrierea structurii organizatorice„, în care trebuie să spunem clientului pentru ce ar trebui să se pregătească în ceea ce privește schimbarea structurii organizatorice. Dintr-o dată trebuie să organizați un nou departament pentru a vă opera sistemul, să introduceți noi poziții etc.

La etapa RD apar și alte documente, mai interesante, pe care aș vrea să le iau în considerare separat.

Manualul utilizatorului. Comentariile sunt inutile, cred.

Metodologia (tehnologia) proiectării asistate de calculator. Dacă este necesar, puteți include în acest document o descriere a procesului de construire a software-ului, control al versiunilor, testare etc. Dar asta dacă clientul din specificația tehnică dorește să asambleze personal software-ul. Dacă nu cere acest lucru (și nu plătește pentru asta), atunci întreaga bucătărie internă nu este treaba lui și acest document nu trebuie făcut.

Instructiuni tehnologice. Datorită modului de formalizare a proceselor de afaceri, un client viclean încearcă uneori să introducă reglementări de operare în acest document. Deci, sub nicio formă nu trebuie să faci asta.

Descrierea proceselor de afaceri, fișele de rol și posturi, regulamente de muncă - toate acestea sunt ORD, adică documentație organizatorică și administrativă. Care este produsul unui proiect de consultanță, care, din câte am înțeles, nu a fost achiziționat de la dumneavoastră. Și ți-au cumpărat un proiect tehnic și, de asemenea, documentația tehnică pentru el.

Instrucțiunea tehnologică este un strat între instrucțiunile de utilizare și manualul de utilizare. RP descrie în detaliu Cum trebuie să faceți anumite acțiuni în sistem. Instrucțiunea tehnologică spune că care acțiunile trebuie efectuate în anumite cazuri legate de funcționarea sistemului. În linii mari, o instrucțiune tehnologică este un scurt rezumat al RP pentru o anumită poziție sau rol. Dacă clientul nu are roluri formate sau dorește să vă creați singur roluri și cerințe de post, includeți în document cele mai elementare roluri, de exemplu: operator, operator senior, administrator. Comentariile clientului cu privire la subiectul „dar nu e așa la noi” sau „nu ne place” ar trebui să fie însoțite de o listă de roluri și de o descriere a responsabilităților postului. Pentru că procesele de afaceri noi nu o punem. Suntem aceste procese de afaceri automatiza.

Voi scrie separat despre greblele descrise, cu exemple colorate, deoarece nu este prima dată când acest lucru se repetă în diferite sectoare ale „economiei naționale”.

Descrierea procesului tehnologic de prelucrare a datelor (inclusiv teleprocesare). O relicvă jalnică a epocii peșterilor, când existau „operatori de computer” special desemnați, care introduceau carduri perforate la mașină și împachetau o imprimare a rezultatului într-un plic. Această instrucțiune este pentru ei. Nu vă pot spune exact ce să scrieți în el în secolul 21. Ieși singur. Cel mai bun lucru este să uiți de acest document.

Soluții la nivel de sistem (WSO). Standardul prevede 17 documente în secțiunea OP. În primul rând, acestea sunt aproape toate documentele fazei preliminare de proiectare schematică. În al doilea rând, acestea sunt tot felul de estimări, calcule și scurte descrieri ale funcțiilor automate. Adică informații pentru oameni nu din producția IT principală, ci pentru personalul suport - manageri, estimatori, specialiști în achiziții, economiști etc.

Și în al treilea rând, PO include un mega-document numit „Notă explicativă pentru proiectul tehnic”, care se dorește a fi un fel de rezumat executiv, dar, de fapt, mulți designeri introduc în el tot conținutul util al etapei TP. O astfel de abordare radicală poate fi justificată și chiar reciproc avantajoasă atât pentru client, cât și pentru antreprenor, dar în anumite cazuri.

Opțiuni pentru utilizarea GOST 34

1. Respectarea deplină și exactă la standard. Desigur, nimeni nu va scrie în mod voluntar un astfel de nor de documente. Prin urmare, un set complet de documente este pregătit doar la cererea urgentă a clientului, pe care acesta le-a asigurat în specificațiile tehnice și, de asemenea, a fixat cu un acord deasupra. În acest caz, trebuie să luați totul la propriu și să oferiți clientului „cărți” fizice, pe care vor fi numele documentelor din Tabelul 2 din GOST 34.201-89, cu excepția celor complet inutile, a căror listă trebuie să discute și să se asigure în scris. Conținutul documentelor trebuie, de asemenea, să respecte, fără nicio imaginație, RD 50-34.698-90, până la denumirile secțiilor. Pentru a face creierul clientului să explodeze, uneori un sistem mare este împărțit în subsisteme și se eliberează documentație de proiectare separată pentru fiecare subsistem. Arată terifiant și nu este supus controlului normal cu ajutorul minții pământești. În special în ceea ce privește integrarea subsistemelor. Ceea ce simplifică foarte mult acceptarea. Principalul lucru este că tu însuți nu te confuzi și că sistemul tău încă funcționează așa cum ar trebui.
2. Ne plac standardele GOST. Companiile mari serioase iubesc standardele. Pentru că îi ajută pe oameni să se înțeleagă mai bine. Dacă clientul dvs. este remarcat pentru dragostea lui pentru ordine și standardizare, încercați să respectați ideologia standard GOST atunci când dezvoltați documente, chiar dacă acest lucru nu este cerut de specificațiile tehnice. Veți fi mai bine înțeles și aprobat de specialiștii autorizați și nu veți uita să includeți informații importante în documentație, veți vedea mai bine structura țintă a documentelor, veți planifica mai precis munca de scriere a acestora și vă veți salva și colegii tăi o mulțime de nervi și bani.
3. Nu ne pasă de documentare, atâta timp cât totul funcționează. Aspectul dispărut al clientului iresponsabil. O viziune similară asupra documentației poate fi găsită încă în rândul clienților mici și săraci, precum și în „idiotocrațiile” autoritare rămase din timpul perestroikei, unde șeful este înconjurat de prieteni loiali - directori, iar toate problemele sunt rezolvate în conversații personale. . În astfel de condiții, sunteți liber să neglijați documentația cu totul, dar este mai bine, până la urmă, să nu doborâți vederea și să completați cel puțin schematic documentația cu conținut. Dacă nu acestui client, atunci transmiteți-l (vindeți-l) următorului.

Concluzie

Acest articol a fost despre standardele noastre GOST pentru documentarea sistemelor de control automatizate. GOST-urile sunt vechi, dar, după cum se dovedește, sunt încă foarte utile în gospodărie. În afară de unele rudimente evidente, structura documentației are proprietăți de completitudine și consistență, iar aderarea la standard elimină multe riscuri ale proiectului, de a căror existență este posibil să nu fim conștienți la început.

Sper că materialul prezentat v-a fost de folos, sau măcar interesant. În ciuda oboselii aparente, documentarea este o muncă importantă și responsabilă, în care acuratețea este la fel de importantă ca și scrierea unui cod bun. Scrieți documente bune, colegi! Și săptămâna viitoare merg în două călătorii de afaceri la rând, așa că nu pot garanta publicarea de materiale noi (nu am un cache, scriu din cap).

Introducere

În lumea modernă, zeci și sute de programe, aplicații și sisteme de informații diferite apar în fiecare zi. Ele pot fi dezvoltate pentru sectorul guvernamental sau comercial, precum și pentru utilizatorii obișnuiți. 90% dintre toți utilizatorii nu citesc documentația, o consideră plictisitoare, plictisitoare și neinteresantă și deschid manualul de utilizare numai atunci când ceva nu funcționează sau este complet imposibil să-l înțelegi fără instrucțiuni. Acum este o practică obișnuită să proiectați interfața cu utilizatorul în așa fel încât să fie intuitivă, iar utilizatorul să poată înțelege sistemul fără a fi nevoie să citească manuale lungi. Cu toate acestea, atunci când lucrați cu clienți mari, este aproape întotdeauna necesar să trimiteți un anumit pachet de documente - manuale, instrucțiuni, soluții de proiectare, elaborate în conformitate cu GOST.
Când întâlniți prima scriere a documentației în conformitate cu GOST, sunteți uluit și complet șocat, deoarece există „mare” de aceste GOST și cum și ce să scrieți în conformitate cu ele devine neclar.
Acest articol discută standardele GOST pentru scrierea documentației și punctele lor principale.

Care sunt standardele GOST?

În primul rând, trebuie să înțelegeți ce sunt standardele GOST. Toată lumea știe doar că GOST este ceva care a fost dezvoltat sub Uniune și pur și simplu există un număr nesfârșit. Mă grăbesc să vă asigur că nu există multe GOST-uri pentru sectorul IT și toate acestea, în ciuda timpului lor de creare, nu și-au pierdut relevanța.
În primul rând, standardele pentru scrierea documentației sunt împărțite în două tipuri:

1. Standarde internaționale (ISO, IEEE Std);
2. GOST rusești sau sovietice.

Standarde internaționale
Standardele internaționale sunt utilizate pentru a dezvolta documentație la nivel internațional. De regulă, ele nu sunt gratuite, deoarece nu sunt dezvoltate de organizații guvernamentale, dar, spre deosebire de a noastră, au fost dezvoltate destul de recent. Tema standardelor internaționale este foarte larg, așa că va fi discutată într-un alt articol. Mai multe standarde care sunt strâns legate de redactarea documentației sunt, de asemenea, atinse.
Lista principalelor standarde internaționale pentru scrierea documentației:

1. IEEE Std 1063-2001 „IEEE Standard for Software User Documentation” - standard pentru scrierea manualelor de utilizare;
2. IEEE Std 1016-1998 „IEEE Recommended Practice for Software Design Descriptions” - un standard pentru scrierea unei descrieri tehnice a unui program;
3. ISO/IEC FDIS 18019:2004 „Linii directoare pentru proiectarea și pregătirea documentației de utilizare pentru software-ul aplicației” este un alt standard pentru scrierea manualelor de utilizare. Există un număr mare de exemple în acest document. Ca să spunem așa, acesta este mai degrabă un ghid pentru scrierea unui manual de utilizare. Va fi util în special pentru specialiștii începători;
4. ISO/IEC 26514:2008 „Cerințe pentru proiectanții și dezvoltatorii de documentație pentru utilizator” este un alt standard pentru proiectanții și dezvoltatorii de documentație pentru utilizator.

De fapt, există o mulțime de standarde internaționale și fiecare țară are propriile sale, deoarece același standard poate să nu se potrivească întotdeauna atât companiilor europene, cât și asiatice.

standardele rusești
Standardele rusești sunt dezvoltate la nivel de stat. Toate sunt absolut gratuite și fiecare dintre ele este ușor de găsit pe Internet. Pentru a scrie documentația pentru program, sunt utilizate două serii de GOST-uri 19 și 34. Acestea vor fi discutate în continuare.

Care este diferența dintre seria GOST 19 și 34?

Prima întrebare care apare este cum, în general, aceste GOST-uri 19 și 34 diferă unele de altele.
În GOST 19.781-90 „Sistem unificat de documentare a programului. Software pentru sisteme de procesare a informațiilor. Termeni și definiții” sunt indicate definițiile:

1. Program - date destinate controlului unor componente specifice ale unui sistem de procesare a informațiilor în vederea implementării unui anumit algoritm.
2. Software-ul este un set de programe ale sistemului de procesare a informațiilor și documente de program necesare pentru funcționarea acestor programe.

În GOST 34.003-90 „Tehnologia informației. Set de standarde pentru sisteme automate. Sisteme automatizate. Termeni și definiții” se indică definiția:

1. Sistem automatizat (AS) - un sistem format din personal și un set de instrumente de automatizare pentru activitățile acestora, implementând tehnologia informației pentru a îndeplini funcțiile stabilite.
   În funcție de tipul de activitate, de exemplu, se disting următoarele tipuri de AS: sisteme automate de control (ACS), sisteme de proiectare asistată de calculator (CAD), sisteme automate de cercetare științifică (ASRS) și altele.

În funcție de tipul de obiect (proces) controlat, sistemele de control automatizate se împart, de exemplu, în: sisteme de control automatizate pentru procese tehnologice (ACS), sisteme de control automatizate pentru întreprinderi (ACS) etc.
GOST 34 face, de asemenea, o împărțire în tipuri de suport AS:

1. organizatoric;
2. Metodic;
3. Tehnic;
4. Matematic;
5. Software;
6. informativ;
7. Lingvistic;
8. Legal;
9. Ergonomic.

Ca urmare, un sistem automatizat nu este un program, ci un complex de tipuri de software, inclusiv software. AS, de regulă, oferă o soluție organizațională pentru un anumit utilizator și client, iar Programul poate fi creat și replicat pentru un număr mare de utilizatori fără a fi legat de nicio întreprindere.
Prin urmare, dacă dezvoltați documentație pentru un program pe care l-ați creat pentru o anumită întreprindere, atunci GOST este 34. Dacă scrieți documente pentru un program de masă, atunci GOST este 19.

GOST 34

Seria GOST 34 (GOST 34.xxx Standarde de tehnologie a informației) constă din:

1. GOST 34.201-89 Tipurile, caracterul complet și denumirea documentelor la crearea sistemelor automate - acest standard stabilește tipurile, numele, caracterul complet și numărul documentelor. Este unul dintre documentele principale ale seriei GOST 34. De fapt, acesta este un document de bază, așa că începătorii trebuie să se familiarizeze mai întâi cu el.
2. GOST 34.320-96 Concepte și terminologie pentru scheme conceptuale și baze de informații - acest standard stabilește conceptele și termenii de bază ai schemelor conceptuale și bazelor de informații, acoperind dezvoltarea, descrierea și aplicarea schemelor conceptuale și a bazelor de informații, manipularea informațiilor, precum și descrierea si implementarea procesului de informare. Standardul definește rolul diagramei conceptuale. Prevederile cuprinse în acesta sunt de natură consultativă și pot fi utilizate pentru evaluarea sistemelor de management al bazelor de date (DBMS). Acest document nu descrie metode specifice de utilizare a instrumentelor de suport pentru diagrame conceptuale. Limbile de schemă conceptuală descrise în standard nu ar trebui să fie considerate limbi standard.
3. GOST 34.321-96 Tehnologii informaționale. Sistem de standarde de baze de date. Model de referință de guvernare - Acest document stabilește un model de referință de guvernanță a datelor.
   Modelul de referință definește terminologia și conceptele comune legate de datele sistemelor informaționale. Astfel de concepte sunt folosite pentru a defini serviciile furnizate de sistemele de management al bazelor de date sau sistemele de dicționar de date.
   Modelul de referință nu ia în considerare protocoalele pentru gestionarea datelor.
   Sfera de aplicare a modelului de referință include procese care se ocupă de gestionarea datelor persistente și interacțiunea acestora cu procese altele decât cerințele unui sistem informatic specific, precum și servicii generale de gestionare a datelor pentru definirea, stocarea, preluarea, actualizarea, introducerea, copierea. , restaurarea și transmiterea datelor.
4. GOST 34.601-90 Sisteme automate. Etapele creării - standardul stabilește etapele și etapele creării unui AS.
5. GOST 34.602-89 Specificații tehnice pentru crearea unui sistem automat (În locul GOST 24.201-85) - stabilește compoziția, conținutul, regulile de întocmire a documentului „Termeni de referință pentru crearea (dezvoltarea sau modernizarea) sistemului. ”
   Acest document este unul dintre documentele utilizate frecvent din seria GOST 34. Când dezvoltați specificațiile tehnice pentru acest GOST, ar trebui să vă amintiți despre alte standarde, chiar dacă acest document nu conține referințe la aceste standarde.
6. GOST 34.603-92 Tehnologia informației. Tipuri de teste ale sistemelor automate - standardul stabilește tipuri de teste ale AS (autonome, complexe, teste de acceptare și funcționare de probă) și cerințe generale pentru implementarea acestora.
7. RD 50-34.698-90 Sisteme automatizate. Cerințele pentru conținutul documentelor sunt unul dintre cele mai importante documente ale GOST 34, deoarece descrie conținutul aproape tuturor documentelor, precum și o descriere a fiecărui paragraf al documentului.
8. GOST R ISO/IEC 8824-3-2002 Tehnologia informației. Notație de sintaxă abstractă Versiunea unu - Acest standard face parte din Notația de sintaxă abstractă Versiunea 1 (ASN.1) și stabilește o notație pentru specificarea constrângerilor definite de utilizator și a constrângerilor de tabel.
9. GOST R ISO/IEC 10746-3-2001 Managementul datelor și procesarea distribuită deschisă.
   În acest standard:
   • se determină modul în care sunt specificate sistemele de procesare distribuită deschisă (ODP) folosind conceptele introduse în GOST R ISO/IEC 10746-2;
   • Au fost identificate caracteristicile conform cărora sistemele aparțin sistemelor OPO.

   Standardul stabilește un cadru pentru coordonarea dezvoltării standardelor pentru sistemele ODP.

10. GOST R ISO/IEC 15271-02 Procesele ciclului de viață al software-ului - acest GOST este necesar mai mult, în opinia mea, pentru analiști atunci când proiectează și modelează AS.
    Acest document este util, din punctul meu de vedere, în scop pur educativ.
11. GOST R ISO/IEC 15910-2002 Proces pentru crearea documentației utilizator pentru un instrument software - definește procesul minim necesar pentru crearea documentației utilizator de toate tipurile pentru un instrument software care are o interfață cu utilizatorul. Aceste tipuri includ documentație tipărită (de exemplu, ghiduri de utilizare și carduri de referință rapidă), documentație online, text de ajutor și sisteme de documentare online.

Deci, pe baza a tot ceea ce este scris mai sus, este clar că principalele documente din GOST 34 sunt 3: GOST 34.201-89, RD 50-34.698-90 și GOST 34.602-89.
Când dezvoltați un pachet de documentație, mai întâi, trebuie să deschideți GOST 34.201-89 și să selectați etapa de creare: proiectare, proiectare tehnică și documentație de lucru. În continuare, ar trebui să selectați documente pentru dezvoltare care corespund etapei de creare.

Lista documentelor 34 GOST

Etapă creare	Titlul documentului	Cod	Parte proiect	Prinad pat la proiect dar-estimare Noah Doku poliţist țiuni	Prinad pat la exploatare tare noah sus kumen tații	Instructiuni aditionale
EP	Fișă de proiect preliminar	EP*	SAU	—	—	—
	Notă explicativă La proiectul preliminar	P1	SAU	—	—	—
EP, TP	Organigrama	CO	SAU	—	—	Este permisă includerea P3 sau PV în document
	Schema structurală a complexului mijloace tehnice	C1*	ACEA	X	—
	Diagrama structurii funcționale	C2*	SAU	—	—	La elaborarea documentelor CO, C1, C2, C3 în stadiul ES, este permisă includerea lor în documentul P1
	specializat (nou) mijloace tehnice	LA 9	ACEA	X	—	La dezvoltarea la stadiul tehnic permis să includă la documentul P2
	Schema de automatizare	C3*	ACEA	X	—	—
	Specificații tehnice pentru dezvoltare specializat (nou) mijloace tehnice	—	ACEA	—	—	Proiectul nu include
TP	Sarcini de dezvoltare sanitare şi alte secțiuni legate de proiect cu crearea unui sistem	—	ACEA	X	—	Proiectul nu include
	Fișă de proiect tehnic	TP*	SAU	—	—	—
	Lista articolelor achiziționate	VP*	SAU	—	—	—
	Lista semnalelor de intrare și date	ÎN 1	ȘI DESPRE	—	—	—
	Lista semnalelor de ieșire (documente)	LA 2	ȘI DESPRE	—	—	—
	Lista sarcinilor de dezvoltare constructii, electrice, sanitare şi alte secțiuni legate de proiect cu crearea unui sistem	LA 3	ACEA	X	—	Este permisă includerea P2 în document
	Notă explicativă la proiectul tehnic	P2	SAU	—	—	Include planul evenimentului la pregătirea unui obiect pentru intrare sisteme în funcţiune
	Descrierea automată funcții	P3	SAU	—	—	—
	Descrierea setarii sarcinii (set de sarcini)	P4	SAU	—	—	Permis să includă la documentele P2 sau P3
	Descrierea informațiilor asigurarea sistemului	P5	ȘI DESPRE	—	—	—
	Descrierea organizației baza de informatii	P6	ȘI DESPRE	—	—	—
TP	Descrierea sistemelor de clasificare și codificare	P7	ȘI DESPRE	—	—	—
	Descrierea matricei informație	P8	ȘI DESPRE	—	—	—
	Descrierea complexului mijloace tehnice	P9	ACEA	—	—	Pentru sarcină este permisă includerea în documentul 46 conform GOST 19.101
	Descrierea software-ului dispoziţie	PA	DE	—	—	—
	Descrierea algoritmului (procedura de proiect)	PB	MO	—	—	Este permisă includerea P2, P3 sau P4 în documente
	Descrierea organizațională structurilor	PV	OO	—	—	—
	Planul de amenajare	C8	ACEA	X	—	Este permisă includerea P9 în document
	Lista de echipamente si materiale	—	ACEA	X	—	—
	Calcul de deviz local	B2	SAU	X	—	—
TP, RD	Evaluarea proiectului fiabilitatea sistemului	B1	SAU	—	—	—
	Desenul formularului documentului (cadru video)	C9	ȘI DESPRE	—	X	La stadiul TP este permis include în documente P4 sau P5
RD	Lista titularilor originale	DP*	SAU	—	—	—
	Fișa de operare documente	ED*	SAU	—	X	—
	Specificații hardware	LA 4	ACEA	X	—	—
	Lista cerințelor în materiale	LA 5	ACEA	X	—	—
	Inventarul media de mașini informație	VM*	ȘI DESPRE	—	X	—
	Matrice de intrare	LA 6	ȘI DESPRE	—	X	—
RD	Directorul bazei de date	LA 7	ȘI DESPRE	—	X	—
	Compoziția datelor de ieșire (mesaje)	LA 8	ȘI DESPRE	—	X	—
	Estimări locale	B3	SAU	X	—	—
	Metodologie (tehnologie) automatizate proiecta	I1	OO	—	X	—
	Instructiuni tehnologice	ȘI 2	OO	—	X	—
	Manualul utilizatorului	I3	OO	—	X	—
	Instructiuni de formare si întreținerea bazei de date (set de date)	I4	ȘI DESPRE	—	X	—
	Instrucțiuni de utilizare KTS	IE	ACEA	—	X	—
	Schema cablajului extern	C4*	ACEA	X	—	Permis să fie efectuat în sub formă de tabele
	Schema de conectare postări externe	C5*	ACEA	X	—	La fel
	Tabel de conexiuni și conexiuni	C6	ACEA	X	—	—
	Diagrama de diviziune a sistemului (structural)	E1*	ACEA	—	—	—
	Desen general	ÎN*	ACEA	X	—	—
	Desen montaj echipament tehnic	SA	ACEA	X	—	—
	Diagramă schematică	SB	ACEA	X	—	—
	Schema structurală a complexului mijloace tehnice	C1*	ACEA	X	—	—
	Planul de amenajare a echipamentelor și cablajului	C7	ACEA	X	—	—
	Descrierea tehnologică proces de prelucrare date (inclusiv teleprocesare)	PG	OO	—	X	—
	Descrierea generală a sistemului	PD	SAU	—	X	—
	Programul și metodologia de testare (componente, sisteme de automatizare, subsisteme, sisteme)	P.M*	SAU	—	—	—
	Formă	FO*	SAU	—	X	—
	Pașaport	PS*	SAU	—	X	—
*Documente al căror cod este stabilit în conformitate cu cerințele standardelor ESKD

Notă la tabel:

1. În tabel sunt utilizate următoarele notații:
   • EP - proiect preliminar;
   • TP - proiectare tehnică;
   • RD - documentație de lucru;
   • SAU - soluții la nivel de sistem;
   • OO - decizii privind suportul organizatoric;
   • TO - soluții pentru suport tehnic;
   • IO - soluții pentru suport informațional;
   • Software - soluții software;
   • MO - soluții software.
2. Semnul X indică faptul că aparține devizelor de proiectare sau documentației operaționale.
3. Nomenclatorul documentelor cu același nume se stabilește în funcție de deciziile de proiectare luate în timpul creării sistemului.

Când lista de documente a fost stabilită, atunci în RD 50-34.698-90 ar trebui să găsiți documentele selectate și să le dezvoltați strict conform punctelor specificate. Toate punctele de conținut care sunt indicate trebuie să fie în document.
Dacă specificațiile tehnice sunt în curs de dezvoltare, atunci trebuie să deschideți imediat GOST 34.602-89 și să dezvoltați specificațiile tehnice strict în conformitate cu punctele.

GOST 19

Seria de GOST-uri 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) constă din:

1. 1. GOST 19.001-77 Dispoziții generale - un document prea general, nu are nicio utilitate practică. Prin urmare, puteți sări peste el.
   2. GOST 19781-90 Termeni și definiții - o listă bună de definiții în domeniul software-ului pentru sistemele de procesare a informațiilor. Nu conține nimic mai mult decât definiții.
   3. GOST 19.101-77 Tipuri de programe și documente de program - unul dintre principalele documente ale 19 GOST. Aici ar trebui să începeți să lucrați cu GOST 19, deoarece conține o listă completă și denumiri ale documentelor GOST.

Lista documentelor 19 GOST

Cod	Tipul documentului	Etape de dezvoltare
		Sketchy proiect	Tehnic proiect	Proiect de lucru
				componentă	complex
—	Specificație	—	—
05	Lista deținătorilor originali	—	—	—
12	Textul programului	—	—
13	Descrierea programului	—	—
20	Lista documentelor operaționale	—	—
30	Formă	—	—
31	Descrierea aplicației	—	—
32	Ghidul programatorului de sistem	—	—
33	Ghidul programatorului	—	—
34	Manual de utilizare	—	—
35	Descrierea limbii	—	—
46	Manual tehnic serviciu	—	—
51	Programul de testare și metodologia	—	—
81	Notă explicativă			—	—
90-99	Alte documente

Legendă:
— documentul este obligatoriu;
— documentul este obligatoriu pentru componentele care au utilizare independentă;
— necesitatea întocmirii unui document este determinată în stadiul de elaborare și aprobare a specificațiilor tehnice;
- - documentul nu este întocmit.

1. GOST 19.102-77 Etape de dezvoltare - conține o descriere a etapelor de dezvoltare. Util în scopuri educaționale. După părerea mea, nu are prea multe beneficii practice.
2. GOST 19.103-77 Denumiri de programe și documente de program - conține o descriere a atribuirii unui număr (cod) unui document. Chiar și după citirea acestui GOST, rămân o mulțime de întrebări despre cum să atribuiți același număr unui document.
3. GOST 19.104-78 Inscripții principale - stabilește formele, dimensiunile, locația și procedura de completare a principalelor inscripții ale fișei de aprobare și paginii de titlu în documentele programului prevăzute de standardele DEPD, indiferent de modalitățile de implementare a acestora. Deoarece documentele 19 GOST sunt întocmite în cadre, acest document este foarte important.
4. GOST 19.105-78 Cerințe generale pentru documentele programului - stabilește cerințe generale pentru pregătirea documentelor programului. Cerințele sunt prea generale. De regulă, acest GOST aproape că nu este folosit pentru a dezvolta un document, deoarece un GOST special pentru un document este suficient, dar pentru cunoștințe generale este mai bine să cercetați acest GOST o dată.
5. GOST 19.106-78 Cerințe pentru documentele programului executate în formă tipărită - conține cerințe pentru executarea tuturor documentelor 19 GOST.
6. GOST 19.201-78 Specificații tehnice, cerințe pentru conținut și proiectare - stabilește procedura de construire și pregătire a specificațiilor tehnice pentru dezvoltarea unui program sau a unui produs software.

   Clauzele specificațiilor tehnice ale 34 GOST și 19 GOST sunt diferite.

7. GOST 19.601-78 Reguli generale de duplicare, contabilitate și stocare - reguli generale de duplicare, circulație, contabilitate și stocare a documentelor programului. GOST descrie în mai multe puncte cum să vă asigurați că documentele nu sunt pierdute.
8. GOST 19.602-78 Reguli pentru duplicarea, contabilizarea și stocarea documentelor de program, execuții de tipărire. Metodă - adăugare la GOST 19.601-78.
9. GOST 19.603-78 Reguli generale pentru efectuarea modificărilor - stabilește reguli generale pentru efectuarea modificărilor documentelor programului. În esență, descrie un algoritm birocratic lung pentru efectuarea modificărilor documentelor.
10. GOST 19.604-78 Reguli pentru efectuarea modificărilor documentelor de program făcute în format tipărit - descrie procedura de lucru și completare a fișei de înregistrare a modificărilor.

O listă de GOST-uri specializate, adică fiecare dintre ele descrie conținutul și cerințele pentru un anumit document:

1. Specificație GOST 19.202-78. Cerințe pentru conținut și design;
2. GOST 19.301-79 Programul de testare și metodologia. Cerințe pentru conținut și design;
3. GOST 19.401-78 Textul programului. Cerințe pentru conținut și design;
4. GOST 19.402-78 Descrierea programului;
5. GOST 19.403-79 Lista deținătorilor originali;
6. GOST 19.404-79 Notă explicativă. Cerințe pentru conținut și design;
7. GOST 19.501-78 Form. Cerințe pentru conținut și design;
8. GOST 19.502-78 Descrierea aplicației. Cerințe pentru conținut și design;
9. GOST 19.503-79 Ghidul programatorului de sistem. Cerințe pentru conținut și design;
10. GOST 19.504-79 Ghidul programatorului. Cerințe pentru conținut și design;
11. GOST 19.505-79 Manual de utilizare. Cerințe pentru conținut și design;
12. GOST 19.506-79 Descrierea limbii. Cerințe pentru conținut și design;
13. GOST 19.507-79 Declarația documentelor operaționale;
14. GOST 19.508-79 Manual de întreținere. Cerințe pentru conținut și design.

Procedura de lucru cu 19 GOST:

1. În GOST 19.101-77, selectați un document și codul acestuia în funcție de stadiul de dezvoltare.
2. Conform GOST 19.103-77, atribuiți un număr documentului.
3. Apoi, conform GOST-urilor 19.104-78 și 19.106-78, întocmește un document.
4. Din lista specializată de GOST-uri, ar trebui să-l selectați pe cel care corespunde documentului în curs de dezvoltare.

Concluzie

GOST nu este înfricoșător și ușor! Principalul lucru este să înțelegeți ce trebuie scris și ce GOST este folosit pentru aceasta. Principalele noastre GOST 19 și 34 pentru scrierea documentației sunt foarte vechi, dar încă relevante până în prezent. Redactarea documentației conform standardului elimină multe probleme dintre antreprenor și client. În consecință, economisește timp și bani.

Data introducerii 01/01/92

Acest standard se aplică sistemelor automatizate (AS) utilizate în diferite tipuri de activități (cercetare, proiectare, management etc.), inclusiv combinațiile acestora create în organizații, asociații și întreprinderi (denumite în continuare organizații).

Standardul stabilește etapele și etapele creării unui AS. Anexa 1 prezintă conținutul lucrării în fiecare etapă.

1. Dispoziții generale

2. Etapele și etapele creării unui AS

Anexa 1 (pentru referință)

Anexa 2 (referință)

1. DISPOZIȚII GENERALE

1.1. este un ansamblu de lucrări ordonate în timp, interconectate, combinate în etape și faze, a căror implementare este necesară și suficientă pentru a crea un sistem automatizat care să îndeplinească cerințele specificate.

1.2. Etapele și fazele creării unui AS se disting ca părți ale procesului de creare din motive de planificare rațională și organizare a muncii care se încheie cu un rezultat dat.

1.3. Lucrările privind dezvoltarea AS se desfășoară în funcție de etapele și etapele utilizate pentru crearea AS.

1.4. Compoziția și regulile de realizare a lucrărilor la etapele și etapele stabilite de prezentul standard sunt determinate în documentația relevantă a organizațiilor implicate în crearea unor tipuri specifice de centrale nucleare.

Lista organizațiilor implicate în crearea centralelor nucleare este prezentată în Anexa 2.

2. ETAPE ŞI ETAPE DE CREARE A AS

2.1. Etapele și etapele creării unui AS sunt prezentate în general în tabel.

Etape	Etapele muncii
1. Formarea cerințelor pentru vorbitori	1.1. Inspecția instalației și justificarea necesității creării unei centrale nucleare
	1.2. Formarea cerințelor utilizatorilor pentru difuzoare
	1.3. Întocmirea unui raport asupra lucrărilor efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)
2. Dezvoltarea conceptului AC	2.1. Studiind obiectul
	2.2. Efectuarea lucrărilor de cercetare necesare
	2.3. Dezvoltarea opțiunilor de concept AC și selectarea unei opțiuni de concept AC care satisface cerințele utilizatorului
	2.4. Întocmirea unui proces-verbal asupra lucrărilor efectuate
3. Termeni de referință	3.1. Elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare
4. Proiect de proiect	4.1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
	4.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
5. Proiectare tehnică	5.1. Dezvoltarea de soluții de proiectare pentru sistem și piesele sale
	5.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
	5.3. Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora
	5.4. Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului unității de automatizare
6. Documentație de lucru	6.1. Elaborarea documentației de lucru pentru sistem și părțile sale
	6.2. Dezvoltarea sau adaptarea programelor
7. Intrare și acțiune	7.1. Pregatirea obiectului de automatizare pentru punerea in functiune a CNE
	7.2. Instruirea personalului
	7.3. Set complet de difuzoare cu produsele furnizate (software și hardware, sisteme software și hardware, produse informatice)
	7.4. Lucrari de constructii si montaj
	7.5. Lucrări de punere în funcțiune
	7.6. Efectuarea de teste preliminare
	7.7. Efectuarea operațiunii de probă
	7.8. Efectuarea testelor de acceptare
8. Suport AC	8.1. Efectuarea lucrărilor în conformitate cu obligațiile de garanție
	8.2. Service post garantie

2.2. Etapele și reperele realizate de organizațiile care participă la crearea centralelor nucleare sunt stabilite în contracte și specificații tehnice bazate pe acest standard.

Este posibil să excludeți etapa „Proiectare schiță” și etapele individuale de lucru în toate etapele, pentru a combina etapele „Proiectare tehnică” și „Documentație de lucru” într-o singură etapă de „Proiectare tehnică detaliată”. În funcție de specificul AS care se creează și de condițiile pentru crearea acestora, este permisă efectuarea unor etape individuale de lucru înainte de finalizarea etapelor anterioare, execuția paralelă a etapelor de lucru sau includerea de noi etape de lucru.

ANEXA 1. Pentru referință

1. La etapa 1.1 „Inspecția instalației și justificarea necesității creării unei CNE”, în cazul general, se efectuează următoarele:

• colectarea datelor despre obiectul automatizării și tipurile de activități desfășurate;
• evaluarea calității de funcționare a unității și a tipurilor de activități desfășurate, identificarea problemelor care pot fi rezolvate cu ajutorul instrumentelor de automatizare;
• evaluarea (tehnică, economică, socială etc.) a fezabilității creării unei centrale nucleare.

2. La etapa 1.2 „formarea cerințelor utilizatorilor pentru difuzoare” se efectuează următoarele:

• pregătirea datelor inițiale pentru formarea cerințelor pentru sistemul automatizat (caracteristicile obiectului de automatizare, descrierea cerințelor pentru sistem, limitări ale costurilor acceptabile pentru dezvoltare, punere în funcțiune și exploatare, efectul așteptat de la sistem, condițiile de creare și funcționarea sistemului);
• formularea și executarea cerințelor utilizatorilor pentru difuzoare.

3. La etapa 1.3 „Completarea unui raport cu privire la lucrările efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)”, un raport cu privire la lucrările efectuate în această etapă și o cerere pentru dezvoltarea unui AS (tactica și specificațiile tehnice) sau alt document care îl înlocuiește sunt completate cu conținut similar.

4. La etapele 2.1 „Studiul obiectului” și 2.2 „Efectuarea lucrărilor de cercetare necesare”, organizația de dezvoltare realizează un studiu detaliat al obiectului de automatizare și lucrările de cercetare necesare (C&D) legate de găsirea modalităților și evaluarea posibilității de implementarea cerințelor utilizatorilor, întocmește și aprobă rapoarte de cercetare.

5. La etapa 2.3 „Elaborarea opțiunilor pentru conceptul AS și selectarea unei opțiuni pentru conceptul AS care să îndeplinească cerințele utilizatorului”, în cazul general, se creează opțiuni alternative pentru conceptul AS și planuri pentru implementarea acestora. dezvoltat; evaluarea resurselor necesare pentru implementarea și întreținerea acestora; evaluarea avantajelor și dezavantajelor fiecărei opțiuni; compararea cerințelor utilizatorilor și a caracteristicilor sistemului propus și selectarea opțiunii optime; stabilirea procedurii de evaluare a calitatii si conditiilor de acceptare a sistemului; evaluarea efectelor obţinute din sistem.

6. La etapa 2.4 „Întocmește un raport asupra lucrărilor efectuate”, întocmește și întocmește un raport care să conțină o descriere a lucrărilor efectuate la etapa, o descriere și o justificare a versiunii propuse a conceptului de sistem.

7. La etapa 3.1 „Elaborarea și aprobarea specificațiilor tehnice pentru realizarea unei centrale nucleare”, elaborarea, execuția, coordonarea și aprobarea specificațiilor tehnice pentru centrala nucleară și, dacă este cazul, specificațiile tehnice pentru părți ale centralei nucleare. centrale electrice sunt executate.

8. La etapa 4.1 „Elaborarea soluțiilor preliminare de proiectare pentru sistem și părțile sale” se determină: funcțiile AS; funcțiile subsistemelor, scopurile și efectele acestora; alcătuirea complexelor de sarcini și a sarcinilor individuale; concepte ale bazei de informații, structura sa extinsă; funcții ale sistemului de management al bazelor de date; compoziția sistemului de calcul; funcțiile și parametrii software-ului de bază.

9. La etapa 5.1 „Elaborarea soluțiilor de proiectare pentru sistem și părțile sale”, acestea asigură dezvoltarea de soluții generale pentru sistem și părțile sale, structura funcțional-algoritmică a sistemului, funcțiile personalului și structura organizatorică, structura mijloacelor tehnice, algoritmi de rezolvare a problemelor și limbajele utilizate, privind organizarea și menținerea unei baze de informații, a unui sistem de clasificare și codificare a informațiilor, pe software.

10. La etapele 4.2 și 5.2 „Elaborarea documentației pentru CNE și părțile sale”, elaborarea, execuția, coordonarea și aprobarea documentației se efectuează în măsura în care este necesar pentru a descrie setul complet de decizii de proiectare luate și suficient pentru continuarea implementarea lucrărilor de creare a CNE. Tipuri de documente - conform GOST 34.201.

11. La etapa 5.3 „Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora”, se realizează pregătirea și execuția documentației pentru furnizarea produselor pentru completarea CNE. ; determinarea cerințelor tehnice și întocmirea specificațiilor tehnice pentru dezvoltarea produselor care nu sunt produse în serie.

12. La etapa 5.4 „Elaborarea sarcinilor de proiectare în părțile adiacente ale proiectului de automatizare”, ei elaborează, formalizează, coordonează și aprobă sarcini de proiectare în părțile adiacente ale proiectului obiect de automatizare pentru efectuarea lucrărilor de construcții, electrice, sanitare și a altor lucrări pregătitoare aferente la creația AC.

13. La etapa 6.1 „Elaborarea documentației de lucru pentru sistem și părțile acestuia”, se elaborează documentația de lucru care conține toate informațiile necesare și suficiente pentru a asigura implementarea lucrărilor de punere în funcțiune și funcționare a CNE, precum și pentru menținerea acestuia. nivelul caracteristicilor operaționale (calității) sistemului în conformitate cu deciziile de proiectare adoptate, execuția, coordonarea și aprobarea acestuia. Tipuri de documente - conform GOST 34.201.

14. La etapa 6.2 „Dezvoltarea sau adaptarea programelor”, sunt dezvoltate programe și software de sistem, selectarea, adaptarea și (sau) conectarea software-ului achiziționat și dezvoltarea documentației programului în conformitate cu GOST 19.101.

15. La etapa 7.1 „Pregătirea obiectului de automatizare pentru punerea în funcțiune a instalației”, se lucrează la pregătirea organizatorică a obiectului de automatizare pentru punerea în funcțiune a instalației, inclusiv: implementarea soluțiilor de proiectare pentru structura organizatorică a instalației. plantă; furnizarea departamentelor unității de management cu materiale didactice și metodologice; implementarea clasificatoarelor de informații.

16. La etapa 7.2 „Instruirea personalului”, personalul este instruit și se verifică capacitatea acestuia de a asigura funcționarea instalației.

17. La etapa „Completarea difuzoarelor cu produse furnizate” asigură primirea componentelor de producție în serie și individuale, materialelor și produselor de instalare. Se efectuează controlul de calitate la intrare.

18. La etapa 7.4 „Lucrări de construcție și instalare” se efectuează: lucrări de construcție a clădirilor (incintelor) specializate pentru găzduirea echipamentelor tehnice și a personalului CNE; construirea de canale de cablu; efectuarea de lucrări la instalarea echipamentelor tehnice și a liniilor de comunicație; testarea echipamentelor tehnice instalate; livrarea echipamentelor tehnice pentru punerea în funcțiune.

19. La etapa 7.5 „Dare în funcțiune”, efectuează reglarea autonomă a hardware-ului și software-ului, încărcarea informațiilor în baza de date și verificarea sistemului de întreținere a acesteia; configurarea completă a tuturor instrumentelor de sistem.

20. La etapa 7.6 „Efectuarea testelor preliminare” se efectuează următoarele:

• testarea difuzoarelor pentru funcționarea și conformitatea cu specificațiile tehnice în conformitate cu programul și metodologia încercărilor preliminare;
• depanarea și efectuarea de modificări la documentația CNE, inclusiv documentația operațională în conformitate cu raportul de testare;
• executarea unui certificat de acceptare a CNE pentru exploatare de probă.

21. La etapa 7.7 „Efectuarea operațiunii de probă” se efectuează exploatarea de probă a CNE; analiza rezultatelor exploatării de probă a CNE; modificarea (dacă este necesar) a software-ului AS; ajustarea suplimentară (dacă este necesar) a echipamentelor tehnice CNE; executarea unui certificat de finalizare a operațiunii de probă.

22. La etapa 7.8 „Efectuarea testelor de acceptare” se efectuează următoarele:

• testarea conformității cu specificațiile tehnice în conformitate cu programul și metodologia de testare de acceptare;
• analiza rezultatelor testelor AS și eliminarea deficiențelor identificate în timpul testării;
• executarea unui act de acceptare a CNE în exploatare permanentă.

23. La etapa 8.1 „Efectuarea lucrărilor în conformitate cu obligațiile de garanție” se efectuează lucrări pentru eliminarea deficiențelor identificate în timpul funcționării CNE în perioadele de garanție stabilite, precum și pentru efectuarea modificărilor necesare în documentația pentru CNE.

24. La etapa 8.2 „Service post-garanție” se lucrează la:

• analiza funcționării sistemului;
• identificarea abaterilor caracteristicilor efective de exploatare ale CNE de la valorile de proiectare;
• stabilirea cauzelor acestor abateri;
• eliminarea deficiențelor identificate și asigurarea stabilității caracteristicilor operaționale a CNE;
• efectuarea modificărilor necesare în documentația pentru vorbitori.

ANEXA 2. Referință

LISTA ORGANIZAȚILOR PARTICIPANTE LA CREAREA AU

1. Organizația client (utilizator) pentru care va fi creat CNE și care asigură finanțarea, acceptarea lucrărilor și funcționarea CNE, precum și realizarea lucrărilor individuale de realizare a CNE.

2. O organizație de dezvoltare care desfășoară lucrări la crearea unui AS, oferind clientului un set de servicii științifice și tehnice în diferite etape și etape de creare, precum și dezvoltarea și furnizarea diverselor software și hardware pentru AS.

3. O organizație furnizor care produce și furnizează software și hardware la comanda dezvoltatorului sau clientului.

4. Organizație-proiectant general al instalației de automatizare.

5. Organizații de proiectare a diferitelor părți ale proiectului instalației de automatizare pentru realizarea lucrărilor de construcție, electrice, sanitare și alte lucrări pregătitoare legate de crearea centralei nucleare.

6. Construcție, instalare, punere în funcțiune și alte organizații.

Note:

1. În funcție de condițiile de creare a CNE, sunt posibile diferite combinații de funcții ale clientului, dezvoltatorului, furnizorului și altor organizații implicate în crearea CNE.

2. Etapele și fazele lucrării pe care le efectuează pentru crearea AS sunt determinate pe baza acestui standard.

DATE INFORMAȚII

1. DEZVOLTAT ȘI INTRODUS de Comitetul de Stat al URSS pentru managementul calității produselor și standarde

DEZVOLTATORII

Yu.H. Vermishev, doctor în inginerie. științe; Da.G. Vilenchik; IN SI. Voropaev, doctor în inginerie. științe; L.M. Seidenberg, Ph.D. tehnologie. științe; Yu.B. Irz, Ph.D. tehnologie. științe; V.D. Kostyukov, Ph.D. tehnologie. științe; M.A. Labutin, cond. tehnologie. științe; N.P. Leskovskaia; ESTE. Mitiaev; V.F. Popov (conducător de subiect); S.V. Garshina; A.I. Surditate; SUD. Jukov, Ph.D. științe; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, Ph.D. științe; A.A. Klochkov; V.Yu. Korolev; IN SI. Makhnach, Ph.D. tehnologie. științe; S.B. Mihailev, doctor în inginerie. științe; V.N. Petrikevici; V.A. Rakhmanov, Ph.D. econ. științe; A.A. Ratkovici; R.S. Sedegov, doctor în economie. științe; N.V. Stepanchikova; DOMNIȘOARĂ. Surovets; A.V. Flegentov; L.O. Khvilevsky, Ph.D. tehnologie. științe; VC. Chistov, Ph.D. econ. stiinte

2. APROBAT ȘI INTRAT ÎN VIGOARE prin Rezoluția Comitetului de Stat al URSS pentru Managementul Calității Produselor și Standarde din 29 decembrie 1990 Nr. 3469

M. Ostrogorsky, 2008

Pentru a aplica cu succes GOST 34, este necesar să înțelegem cum, din punctul de vedere al acestui set de standarde, este structurat sistemul automatizat. În caz contrar, nu vom vedea nimic în invitat decât o listă lungă de documente cu nume misterioase, iar cerințele pentru conținutul lor ne vor convinge încă o dată că în multe înțelepciuni există multă tristețe. Prin urmare, înainte de a discuta documentele în sine, trebuie să înțelegem care este subiectul documentării.

Sistem automatizat, funcțiile și sarcinile acestuia

Definirea unui sistem automatizat

GOST 34.003-90 conține următoarea definiție a unui sistem automatizat: un sistem format din personal și un set de instrumente de automatizare pentru activitățile lor, implementând tehnologia informației pentru a îndeplini funcțiile stabilite. Ce înseamnă de fapt această definiție? Puteți înțelege acest lucru doar citind alte definiții ale acestui standard și comparându-le între ele. Ce vei face acum?

Obiectivele activității

Un sistem automatizat poate exista doar acolo unde există personal angajat într-o anumită activitate. De obicei, vorbim despre activități ale căror rezultate sunt utile cuiva, indiferent de instrumentele folosite. De exemplu, merg la casa de bilete a teatrului pentru un bilet și sunt destul de fericit dacă casieria îmi scrie cu stiloul pe un formular, atâta timp cât mă lasă să intru în teatru folosindu-l. Casierului, în general, nici nu îi pasă cum exact este făcut biletul. O să fie bine cu orice metodă, atâta timp cât nu necesită multă muncă și îi oferă posibilitatea de a-mi vinde un bilet. Cu alte cuvinte, ea și cu mine avem un scop comun. GOST 34.003-90 folosește termenul pentru a-l desemna scopul activității. De fiecare dată când un alt spectator părăsește fereastra cu un bilet în mână, iar teatrul devine puțin mai bogat, acest scop al activității este atins.

Funcțiile sistemului automatizat

Pot exista (și, de regulă, există) mai multe obiective pentru o activitate. Orice rezultat util în afara activității în sine poate fi considerat scopul său. Așadar, dacă casieria nu numai că vinde bilete, ci întocmește și un raport de vânzări pentru management la sfârșitul zilei de lucru, întocmirea unui raport zilnic poate fi considerată un alt scop de activitate.

Dacă punem un computer și o imprimantă pe biroul casieriei, iar șeful casieriei îi dă ordin să introducă bilete și rapoarte într-un procesor de text și să le imprime pe imprimantă, atunci vom obține un sistem automat. Potrivit ideilor moderne, este foarte primitiv; formal va satisface definiția Gost. Vă rugăm să rețineți că obiectivele activității nu s-au schimbat ca urmare a implementării sistemului automatizat, s-a schimbat doar modalitatea de realizare a acestora. Ceea ce se făcea anterior „așa” se face acum în cadrul unui sistem automatizat. Setul de acțiuni ale unui sistem automatizat care vizează atingerea unui obiectiv specific, conform GOST 34.003-90, se numește funcţie. Notă: indiferent de modul în care îl priviți, personalul este considerat parte a sistemului.

Funcția unui sistem automatizat este un concept fundamental în GOST 34. Un sistem automatizat este considerat, în primul rând, ca suma funcțiilor sale și abia apoi ca o grămadă de „software” și „hardware”. Cel mai important lucru este ceea ce face sistemul și în ce constă este secundar.

Cele de mai sus ar putea conduce cititorul la concluzia că fiecărui scop de activitate într-un sistem automatizat îi corespunde una și o singură funcție. Un astfel de sistem este ușor de imaginat, dar practica este mai variată. Pe de o parte, activitățile nu sunt întotdeauna complet automatizate. Chiar și după implementarea unui sistem automatizat, unele obiective trebuie atinse manual. Pe de altă parte, deoarece același rezultat în condiții diferite poate fi atins în moduri diferite, mai multe funcții pot fi îndreptate către un singur scop de activitate într-un sistem automat, de exemplu, vânzarea unui bilet la casa de bilete și vânzarea unui bilet peste Internet. În plus, orice sistem automatizat necesită o anumită întreținere, așa că trebuie să introducem conceptul de funcție auxiliară. Un exemplu tipic este crearea unei copii de rezervă a datelor.

Sarcinile sistemului automatizat

În cazul general, la îndeplinirea unei funcții, o parte din muncă este efectuată de personal, iar o parte de tehnologie; să zicem, un bilet este tipărit automat și dat cumpărătorului manual de către casier. O secvență de acțiuni automate (sic) care conduc la un rezultat de un anumit tip este numită în GOST 34.003-90 sarcină.

Aici definiția problemei nu este citată în întregime, dar deocamdată acest lucru va fi suficient pentru noi; la urma urmei, nu este o rușine pentru nimeni să citească singur standardul. Este important ca o sarcină să fie partea cea mai clar oficializată a unei activități automatizate. Vă puteți imagina o funcție care este efectuată complet automat, cum ar fi backup-ul menționat mai sus. În acest caz, funcția este redusă la o singură sarcină.

Aceeași sarcină poate fi rezolvată prin îndeplinirea unor funcții diferite. De exemplu, dacă un sistem automatizat are mai multe funcții pentru vânzarea unui bilet, atunci executarea fiecăreia dintre ele poate necesita la un moment dat tipărirea biletului.

Compoziția sistemului automatizat

Subsisteme

Dacă sistemul automatizat este destul de complex, acesta este împărțit în subsisteme. Ce înseamnă, destul de complex, destul de greu de spus. Teoria sistemelor descrie diferite niveluri și criterii de complexitate. În practică, nevoia de a aloca mai multe subsisteme într-un sistem automat este adesea cauzată de motive organizaționale și financiare, de exemplu, subsistemele sunt dezvoltate și puse în funcțiune secvenţial.

Deși în GOST 34 termenul subsistem este folosit de multe ori, nu pare să existe o definiție formală a acestui concept acolo. Experiența sugerează că un subsistem este o parte a unui sistem automatizat care satisface și definiția unui sistem automatizat, în special, are funcții cu drepturi depline.

Revenind la exemplul de ticketing, putem decide că sistemul automatizat este format din două subsisteme: un subsistem de ticketing și un subsistem de raportare zilnică. Să fim de acord, pentru mai multă claritate, că casierul scrie biletele într-un editor de text și rapoartele în foi de calcul.

Componente

Identificarea scopurilor de activitate, funcțiile unui sistem automatizat și, dacă este necesar, a subsistemelor acestuia este în mare măsură subiectivă și depinde de punctul de vedere al subiectului care a decis să facă acest lucru. Dacă un rezultat este important în contextul problemei care se rezolvă, îl putem considera un scop, altfel îl ignorăm. De asemenea, vom sparge sistemul automatizat în subsisteme într-un mod care ne este convenabil, atâta timp cât deciziile noastre nu contrazic conținutul acestui concept.

Componentele sunt părțile din care noi, în realitate obiectivă, construim un sistem automatizat. Sistemul constă fizic din componentele sale, astfel că împărțirea unui sistem automatizat în componente este cea mai obiectivă.

Cumpărăm fiecare componentă, o instalăm și conectăm (dacă este echipament), o instalăm (dacă este un program) și o întreținem separat de celelalte componente. Am cumpărat și am așezat un computer pe masă - este o componentă. Am dezvoltat un editor de text special pentru tastarea biletelor - o altă componentă. Foi de calcul gratuite descărcate de pe Internet - din nou o componentă. Și chiar și casiera însăși, într-un fel, este, de asemenea, o componentă a sistemului automatizat.

Compoziția componentelor unui sistem automatizat este foarte importantă din punct de vedere al documentației sale, deoarece documentația tehnică pentru sistem ca atare și pentru componente este tratată diferit. În general, trebuie să fie dezvoltat de oameni diferiți și este proiectat la standarde diferite, în funcție de tipul de componentă.

Tipuri de garanții

Unul dintre cele mai dificile concepte pentru un utilizator începător al GOST 34 este tip de securitate. Ce fel de securitate este aceasta? Îl poți vedea sau atinge? Vinde sau cumpara?

Fiecare tip de software combină componente sau soluții tehnice de o anumită natură. GOST 34 menționează multe tipuri diferite de securitate; nu le vom descrie pe fiecare secvențial aici, ci le vom enumera doar pe cele mai vizibile:

• suport informațional - toate datele și metadatele cu care funcționează sistemul;
• software - toate programele care fac parte din sistem;
• suport tehnic - toate mijloacele tehnice (cu alte cuvinte, echipamente, echipamente) care fac parte din sistem.

Să repetăm ​​încă o dată, acestea nu sunt toate tipurile de securitate. Nici măcar nu putem spune cu certitudine că sunt cele mai importante. De exemplu, suportul metrologic este de mare importanță pentru sistemele automate de control al proceselor (APCS). Multe sisteme automate necesită un suport matematic și lingvistic complex. Dar este greu de imaginat un sistem automatizat care să fie complet lipsit de unul dintre cele trei tipuri de suport enumerate mai sus (exercițiu: încercați).