Termat dhe përkufizimet e sistemeve të automatizuara. Kërkesat për mbështetjen organizative të sistemeve të automatizuara të kontrollit

GOST 24.104-85 Sisteme të automatizuara të kontrollit. Kërkesa të përgjithshme (Seksioni 3 i zëvendësuar nga GOST 34.603-92) Seksioni 3 zëvendësohet nga GOST 34.603-92 Me Dekret të Komitetit Shtetëror të Standardeve të BRSS, datë 20 dhjetor 1985 Nr. 4632, u vendos data e prezantimit

nga 01/01/1987

Ky standard zbatohet për sistemet e kontrollit të automatizuar (ACS) të të gjitha llojeve (përveç atyre kombëtare) dhe përcakton kërkesat e përgjithshme për ACS në tërësi, funksionet e ACS, trajnimin e personelit dhe llojet e mbështetjes ACS, sigurinë dhe ergonominë, llojet dhe procedurat e testimit gjatë vënies në funksion të ACS, plotësia e sistemit të automatizuar të kontrollit, garancitë.

Standardi nuk përcakton kërkesa për sistemet e automatizuara të kontrollit të përcaktuara nga specifikat e objekteve të kontrollit. Këto kërkesa janë formuluar në specifikimet teknike për krijimin ose zhvillimin e çdo sistemi të automatizuar të kontrollit ose në dokumente të tjera rregullatore dhe teknike të departamentit të klientëve të sistemit të kontrollit të automatizuar.

Kërkesat shtesë për sistemet e kontrollit të automatizuar për proceset teknologjike, sistemet e automatizuara të kontrollit për ndërmarrjet, shoqatat industriale dhe shkencore-prodhuese dhe sistemet e kontrollit të automatizuar të industrisë përcaktohen përkatësisht në shtojcat e detyrueshme 1-3.

Referenca Shtojca 4 ofron shpjegime të disa prej termave të përdorur në standard.

1. KËRKESAT PËR ACS

1.1. Kërkesat për sistemin e automatizuar të kontrollit në përgjithësi

1.1.1. Një sistem kontrolli i automatizuar i çdo lloji duhet të jetë në përputhje me kërkesat e këtij standardi, kërkesat e specifikimeve teknike për krijimin ose zhvillimin e tij (në tekstin e mëtejmë të referuara si specifikimet teknike për sistemin e automatizuar të kontrollit), si dhe kërkesat e rregulloreve dhe rregulloreve dhe zhvillimit të tij. dokumentet teknike në fuqi në departamentin e klientit të sistemit të kontrollit të automatizuar.

1.1.2. Vënia në punë e sistemeve të automatizuara të kontrollit duhet të çojë në rezultate të dobishme teknike, ekonomike, sociale ose të tjera, për shembull:

• zvogëlimi i numrit të personelit drejtues;
• përmirësimin e cilësisë së funksionimit të objektit të kontrollit;
• përmirësimi i cilësisë së menaxhimit etj.

1.1.3. Përmbajtja specifike e kërkesave sipas paragrafëve. 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 janë instaluar në specifikimet teknike për sistemin e automatizuar të kontrollit.

1.1.4. Sistemi i automatizuar i kontrollit duhet të sigurojë arritjen e qëllimeve të krijimit (zhvillimit) të tij të përcaktuara në termat e referencës për sistemin e automatizuar të kontrollit.

1.1.5. Sistemi i automatizuar i kontrollit duhet të sigurojë përputhshmërinë ndërmjet pjesëve të tij, si dhe me sistemet e automatizuara (AS) të ndërlidhura me këtë sistem të automatizuar të kontrollit.

Në rastet kur një sistem kontrolli i automatizuar ose një grup sistemesh kontrolli të automatizuar (AS) krijohet në bazë të një rrjeti kompjuterik, sistemet e protokolleve të ndërveprimit me shumë nivele duhet të përdoren për të siguruar përputhshmërinë midis elementeve të një rrjeti të tillë.

1.1.6. Sistemi i automatizuar i kontrollit në tërësi dhe të gjitha llojet e mbështetjes së tij duhet t'i përshtaten modernizimit, zhvillimit dhe zgjerimit brenda kufijve të kërkesave të përcaktuara në termat e referencës për sistemin e automatizuar të kontrollit.

1.1.7. Besueshmëria e sistemit të kontrollit të automatizuar në tërësi dhe secilit prej funksioneve të tij të automatizuara duhet të jenë të mjaftueshme për të arritur qëllimet e vendosura të funksionimit të sistemit në kushte të caktuara aplikimi.

1.1.8. Përshtatshmëria e sistemit të kontrollit të automatizuar duhet të jetë e mjaftueshme për të arritur qëllimet e vendosura të funksionimit të tij në një gamë të caktuar ndryshimesh në kushtet e aplikimit.

1.1.9. ACS duhet të sigurojë monitorimin e performancës së saktë të funksioneve të automatizuara dhe diagnostikimit, duke treguar vendndodhjen, llojin dhe shkakun e shkeljeve të funksionimit të saktë të SHDSH.

1.1.10. ACS që kanë kanale matëse duhet të kenë aftësinë për të kontrolluar karakteristikat metrologjike të kanaleve matëse.

1.1.11. Sistemi i automatizuar i kontrollit duhet të sigurojë masa mbrojtëse ndaj veprimeve të pasakta të personelit që çojnë në një gjendje emergjente të një objekti ose sistemi kontrolli, kundër ndryshimeve aksidentale dhe shkatërrimit të informacionit dhe programeve, si dhe kundër ndërhyrjeve të paautorizuara.

1.1.12. Çdo informacion që hyn në ACS futet në sistem një herë duke përdorur një kanal hyrës, përveç nëse kjo çon në mospërputhje me kërkesat e përcaktuara në specifikimet teknike për ACS (për besueshmërinë, besueshmërinë, etj.).

1.1.13. Informacioni dalës i të njëjtës përmbajtje semantike duhet të gjenerohet një herë në sistemin e automatizuar të kontrollit, pavarësisht nga numri i marrësve.

1.1.14. Informacioni i përfshirë në bazat e të dhënave ACS duhet të përditësohet në përputhje me shpeshtësinë e përdorimit të tij gjatë kryerjes së funksioneve të sistemit.

1.1.15. Sistemi i automatizuar i kontrollit duhet të mbrohet nga rrjedhjet e informacionit, nëse kjo është e përcaktuar në specifikimet teknike për sistemin e automatizuar të kontrollit.

1.1.16. Emri i ACS duhet të përfshijë emrin e llojit të ACS dhe objektin e kontrollit.

Për shembull:

• Sistemi i kontrollit të procesit për ngrohjen e metalit në një furre metodike;
• sistem i automatizuar i kontrollit organizativ dhe teknologjik në punishten nr. 5;
• Sistemi i kontrollit automatik të uzinës Hammer and Sickle

1.2. Kërkesat për funksionet ACS

1.2.1. Sistemi i automatizuar i kontrollit, në masën e kërkuar, duhet të kryejë automatikisht:

• mbledhjen, përpunimin dhe analizën e informacionit (sinjale, mesazhe, dokumente, etj.) për gjendjen e objektit të kontrollit;
• zhvillimi i veprimeve të kontrollit (programe, plane, etj.);
• transmetimi i veprimeve të kontrollit (sinjale, udhëzime, dokumente) mbi ekzekutimin dhe kontrollin e tij;
• zbatimin dhe kontrollin e veprimeve të kontrollit;
• shkëmbimi i informacionit (dokumente, mesazhe, etj.) me sisteme të automatizuara të ndërlidhura.

1.2.2. Përbërja e funksioneve të automatizuara (detyrat, grupet e detyrave - këtu e tutje të referuara si funksione) të sistemit të kontrollit të automatizuar duhet të sigurojë aftësinë për të kontrolluar objektin përkatës në përputhje me cilindo nga qëllimet e përcaktuara në specifikimet teknike për sistemin e automatizuar të kontrollit.

1.2.3. Përbërja e funksioneve të automatizuara të sistemit të kontrollit të automatizuar dhe shkalla e automatizimit të tyre duhet të justifikohet teknikisht, ekonomikisht dhe (ose) shoqërisht, duke marrë parasysh nevojën për të liruar personelin nga kryerja e veprimeve të përsëritura dhe krijimin e kushteve për përdorimin e tyre krijues. aftësitë në procesin e punës.

1.3. Kërkesat për gatishmërinë e personelit të sistemit të kontrollit të automatizuar

1.3.1. Kualifikimet e personelit të ACS duhet të sigurojnë funksionimin efektiv të sistemit në të gjitha mënyrat e specifikuara.

1.3.2. Personeli i ACS duhet të jetë i përgatitur për të kryer detyrat e tij në përputhje me udhëzimet e mbështetjes organizative.

1.3.3. Çdo person që është pjesë e personelit të sistemit të kontrollit të automatizuar duhet të aplikojë modelet e duhura të informacionit dhe të punojë me mjetet teknike dhe dokumentacionin e përdorur prej tij që përcaktojnë procedurën për veprimtarinë e tij.

1.4. Kërkesat për mbështetjen teknike të sistemeve të automatizuara të kontrollit

1.4.1. Kompleksi i mjeteve teknike të sistemit të kontrollit të automatizuar duhet të jetë i mjaftueshëm për të kryer të gjitha funksionet e automatizuara të sistemit të kontrollit të automatizuar.

1.4.2. Kompleksi i mjeteve teknike të sistemeve të kontrollit të automatizuar duhet të përdorë kryesisht mjete teknike të prodhimit në masë. Nëse është e nevojshme, lejohet përdorimi i mjeteve teknike të prodhimit të vetëm.

1.4.3. Sistemet e përsëritura të kontrollit të automatizuar dhe pjesët e tyre duhet të ndërtohen mbi bazën e mjeteve teknike të unifikuara.

1.4.4. Mjetet teknike ACS duhet të vendosen në përputhje me kërkesat e përmbajtura në dokumentacionin teknik, përfshirë operacional, për to, dhe në mënyrë të tillë që të jetë i përshtatshëm për t'i përdorur ato gjatë funksionimit të ACS dhe kryerja e mirëmbajtjes.

1.4.5. Vendosja e mjeteve teknike të përdorura nga personeli i sistemit të kontrollit të automatizuar gjatë kryerjes së funksioneve të automatizuara duhet të plotësojë kërkesat ergonomike: për pajisjet e prodhimit në përputhje me GOST 12.049-80, për mjetet e paraqitjes së informacionit vizual në përputhje me GOST 21829-76, përfshirë për bordet e përdorimit kolektiv. bërë nga tregues elektrolumineshent që sintetizojnë shenja dixhitale sipas GOST 21837-76.

1.4.6. Mjetet teknike të sistemit të kontrollit të automatizuar të përdorur në ndërveprimin e sistemit të kontrollit të automatizuar me sistemet e tjera duhet të jenë të pajtueshme në ndërfaqet me mjetet teknike përkatëse të këtyre sistemeve dhe sistemet e komunikimit të përdorura.

1.4.7. Sistemi i automatizuar i kontrollit duhet të përdorë mjete teknike me jetëgjatësi të paktën dhjetë vjet. Përdorimi i mjeteve teknike me jetë më të shkurtër shërbimi lejohet vetëm në raste të justifikuara dhe në marrëveshje me klientin e sistemit të kontrollit të automatizuar.

1.4.8. Çdo mjet teknik i sistemit të kontrollit të automatizuar duhet të lejojë zëvendësimin e tij me një mjet të një qëllimi të ngjashëm funksional pa ndonjë ndryshim apo rregullim të projektimit në mjetet teknike të mbetura të sistemit të kontrollit automatik (përveç rasteve të specifikuara në mënyrë specifike në dokumentacionin teknik për sistemi i kontrollit automatik).

1.4.9. Mjetet teknike ACS mund të përdoren vetëm në kushtet e përcaktuara në dokumentacionin operativ për to. Në rastet kur është e nevojshme përdorimi i tyre në një mjedis, parametrat e të cilit tejkalojnë vlerat e lejuara të përcaktuara për këto mjete teknike, duhet të sigurohen masa për të mbrojtur mjetet teknike individuale të sistemit të kontrollit të automatizuar nga ndikimi i faktorëve ndikues të jashtëm.

1.4.10. Sistemi i automatizuar i kontrollit duhet të përdorë teknologji kompjuterike që plotëson kërkesat e përgjithshme teknike në përputhje me GOST 22552-84.

1.4.11. Sistemi i automatizuar i kontrollit duhet të përdorë mjete teknike që korrespondojnë me:

• për rezistencën ndaj faktorëve ndikues të jashtëm - GOST 12997-76 për pajisjet industriale dhe pajisjet e automatizimit GSP, GOST 14254-80 për predhat e produkteve të inxhinierisë elektrike, GOST 17516-72 për produktet e inxhinierisë elektrike në lidhje me ndikimin e faktorëve mekanikë mjedisorë, GOST 21552- për teknologjinë e pajisjeve kompjuterike;
• për parametrat e fuqisë - GOST 12997-76 për pajisjet industriale dhe pajisjet e automatizimit GSP, GOST 21552-84 për pajisjet kompjuterike;
• sipas kategorisë së performancës - GOST 12997-76 për pajisjet industriale dhe pajisjet e automatizimit GSP, GOST 21552-84 për pajisjet kompjuterike.

1.4.12. Mbrojtja e mjeteve teknike të sistemit të kontrollit të automatizuar nga ndikimi i fushave të jashtme elektrike dhe magnetike, si dhe ndërhyrja në qarqet e furnizimit me energji elektrike, duhet të jetë e mjaftueshme që mjetet teknike të përmbushin në mënyrë efektive qëllimin e tyre gjatë funksionimit të sistemit të kontrollit automatik.

1.4.13. Në ACS, në përputhje me kërkesat e përcaktuara nga "Standardet e Gjithë Bashkimit të Ndërhyrjes së Lejueshme Industriale" 1-72 - 9-72 dhe GOST 23450-79, duhet të sigurohen masa për të mbrojtur mjedisin e jashtëm nga ndërhyrja industriale radio e emetuar nga mjetet teknike të ACS gjatë funksionimit, si dhe në momentin e ndezjes dhe fikjes.

1.4.14. Kërkesat e përgjithshme ergonomike për diagramet mnemonike - sipas GOST 21480-76, për pajisjet e numërimit për treguesit vizualë - sipas GOST 22902-78, për tabelat e përdorimit kolektiv në treguesit elektrolumineshent që sintetizojnë karaktere dixhitale - sipas GOST 21837-76 për rreze katodë, tuba për shfaqjen e informacionit vizual - sipas GOST 23144-78.

1.4.15. Kërkesat e përgjithshme ergonomike për çelsat në panelet e kontrollit: çelsat rrotulluese - në përputhje me GOST 22613-77, çelësat e tastierës dhe butonave - në përputhje me GOST 22614-77, lloji "Çelësi i ndërrimit" - në përputhje me GOST 22615-77.

1.4.16. Kërkesat e përgjithshme ergonomike për alarmet e mesazheve parësore zanore janë në përputhje me GOST 21786-76.

1.4.17. Kërkesat e përgjithshme ergonomike që rregullojnë organizimin e vendit të punës, rregullimin relativ të pajisjeve të shfaqjes së informacionit, kontrollet dhe komunikimet brenda vendit të punës - në përputhje me GOST 22269-76, duke përfshirë telekomandat - në përputhje me GOST 23000-76.

1.4.18. Kërkesat e përgjithshme ergonomike për karriget e operatorit në përputhje me GOST 21889-76.

1.4.19. Kërkesat e përgjithshme ergonomike për sallën, kabinat e operatorit dhe rregullimi relativ i sediljeve janë në përputhje me GOST 21958-76.

1.5. Kërkesat e softuerit ACS

1.5.1. Softueri ACS duhet të jetë i mjaftueshëm për të kryer të gjitha funksionet e ACS, të zbatuara duke përdorur teknologjinë kompjuterike, dhe gjithashtu të ketë mjetet për të organizuar të gjitha proceset e nevojshme të përpunimit të të dhënave, duke lejuar ekzekutimin në kohë të të gjitha funksioneve të automatizuara në të gjitha mënyrat e rregulluara të funksionimit të ACS.

1.5.2. Softueri ACS duhet të ketë karakteristikat e mëposhtme:

• mjaftueshmëria funksionale (plotësia);
• besueshmëria (përfshirë rikuperimin, disponueshmërinë e mjeteve për zbulimin e gabimeve);
• përshtatshmëria;
• modifikueshmëria;
• modulariteti i ndërtimit dhe
• lehtësinë e përdorimit.

1.5.3. Softueri ACS duhet të ndërtohet kryesisht në bazë të paketave ekzistuese të softuerit aplikativ dhe programeve të tjera të huazuara nga qeveria, industria dhe fonde të tjera të algoritmeve dhe programeve, të lejojë ngarkimin dhe kontrollimin në pjesë dhe të lejojë zëvendësimin e disa programeve pa korrigjimin e të tjerëve.

1.5.4. Sistemi i automatizuar i kontrollit duhet të përdorë kryesisht sistemet e menaxhimit të bazës së të dhënave (DBMS), të regjistruara në mënyrën e përcaktuar.

1.5.5. Softueri ACS duhet të ndërtohet në atë mënyrë që mungesa e të dhënave individuale të mos ndikojë në performancën e funksioneve të ACS në zbatimin e të cilave këto të dhëna nuk përdoren.

1.5.6. Softueri ACS duhet të ketë mjete për diagnostikimin e harduerit ACS dhe monitorimin e besueshmërisë së informacionit hyrës.

1.5.7. Softueri ACS duhet të zbatojë masa për të mbrojtur kundër gabimeve gjatë futjes dhe përpunimit të informacionit, duke siguruar cilësinë e specifikuar të performancës së funksioneve të ACS.

1.5.8. Softueri i përgjithshëm i sistemit të kontrollit të automatizuar duhet të lejojë konfigurimin e komponentëve të veçantë të softuerit dhe zhvillimin e mëtejshëm të softuerit të sistemit të kontrollit të automatizuar pa ndërprerë procesin e funksionimit të tij. Pjesa e krijuar dhe e ngarkuar tashmë e softuerit duhet të mbrohet nga ndryshimet aksidentale.

1.5.9. Të gjitha programet e veçanta softuerike për një sistem të caktuar kontrolli të automatizuar duhet të jenë të pajtueshëm si me njëri-tjetrin ashtu edhe me softuerin e tij të përgjithshëm.

1.5.10. Dokumentacioni i softuerit operativ për sistemin e kontrollit të automatizuar duhet të jetë në përputhje me standardet ESPD dhe të përmbajë të gjithë informacionin e nevojshëm që personeli i sistemit të kontrollit të automatizuar të përdorë softuerin, për ngarkimin fillestar dhe (ose) gjenerimin e tij, ngarkimin e informacionit nga baza e brendshme e informacionit të makinës, lëshimin e automatizuar. programet e sistemeve të kontrollit dhe kontrollimi i funksionimit të tyre duke përdorur teste të përshtatshme.

1.5.11. Të zhvilluara rishtazi gjatë krijimit të një sistemi specifik kontrolli të automatizuar, produktet softuerike të përfshira në softuerin e tij duhet të regjistrohen në shtet, industri ose fonde të tjera të algoritmeve dhe programeve (sipas rastit).

1.6. Kërkesat për mbështetjen e informacionit të sistemeve të kontrollit të automatizuar

1.6.1. Mbështetja e informacionit të sistemit të kontrollit të automatizuar duhet të jetë e mjaftueshme për të kryer të gjitha funksionet e automatizuara të sistemit të kontrollit të automatizuar.

1.6.2. Për të koduar informacionin e përdorur vetëm në një sistem të caktuar kontrolli të automatizuar, duhet të përdoren klasifikuesit e pranuar nga klienti i sistemit të kontrollit të automatizuar.

1.6.3. Për të koduar informacionin dalës të përdorur në një nivel më të lartë në ACS, duhet të përdoren klasifikuesit e sistemeve të kontrollit të nivelit më të lartë, me përjashtim të rasteve të specifikuara posaçërisht.

1.6.4. Kërkesat e përgjithshme ergonomike për kodimin e informacionit janë në përputhje me GOST 21829-76.

1.6.5. Në sistemin e automatizuar të kontrollit për komunikimin midis pajisjeve të një kompleksi mjetesh teknike duhet të përdoren sa më poshtë:

• sinjalet hyrëse dhe dalëse:
  • elektrike - rrymë dhe tension sipas GOST 26.011-80, me ndryshime diskrete në parametra sipas GOST 26.013-81, të koduar sipas GOST 26.014-81,
  • hidraulike sipas GOST 26.012-80,
  • pneumatike sipas GOST 26.015-81;
• grupe karakteresh alfanumerike sipas GOST 19767-74;
• Kodet 8-bit sipas GOST 19768-74.

1.6.6. Mbështetja e informacionit të sistemit të kontrollit të automatizuar duhet të jetë në përputhje me mbështetjen e informacionit të sistemeve që ndërveprojnë me të, për sa i përket përmbajtjes, sistemit të kodimit, metodave të adresimit, formateve të të dhënave dhe formës së paraqitjes së informacionit të marrë dhe të lëshuar nga sistemi i automatizuar i kontrollit.

1.6.7. Format e dokumenteve të krijuara nga sistemi i automatizuar i kontrollit duhet të jenë në përputhje me kërkesat e standardeve USD ose dokumenteve rregullatore dhe teknike të departamentit të klientit të sistemit të kontrollit të automatizuar.

1.6.8. Format e dokumenteve dhe kornizave video të futura, të nxjerra ose të rregulluara përmes terminaleve ACS duhet të jenë në përputhje me karakteristikat teknike përkatëse të terminaleve.

1.6.9. Tërësia e grupeve të informacionit të sistemeve të kontrollit të automatizuar duhet të organizohet në formën e bazave të të dhënave në media kompjuterike.

1.6.10. Forma e paraqitjes së informacionit dalës të sistemit të kontrollit të automatizuar duhet të bihet dakord me klientin (përdoruesin) e sistemit.

1.6.11. Termat dhe shkurtesat e përdorura në dokumentet dalëse të sistemit të kontrollit të automatizuar duhet të pranohen përgjithësisht në fushën e caktuar lëndore dhe të bien dakord me klientin e sistemit.

1.6.12. Sistemi i automatizuar i kontrollit duhet të sigurojë masat e nevojshme për të kontrolluar dhe përditësuar të dhënat në grupet e informacionit të sistemit të kontrollit të automatizuar, të rivendosë grupet pas dështimit të çdo mjeti teknik të sistemit të kontrollit të automatizuar, si dhe të kontrollojë identitetin e informacionit të të njëjtin emër në bazat e të dhënave.

1.7. Kërkesat për mbështetjen organizative të sistemeve të automatizuara të kontrollit

1.7.1. Mbështetja organizative e sistemit të kontrollit të automatizuar duhet të jetë e mjaftueshme për kryerjen efektive nga personeli i sistemit të kontrollit të automatizuar të detyrave që u janë caktuar në zbatimin e përgjegjësive të automatizuara në zbatimin e funksioneve të automatizuara dhe të lidhura jo të automatizuara të sistemit.

1.7.2. Struktura organizative e sistemit të kontrollit të automatizuar duhet të lejojë kryerjen e të gjitha funksioneve të sistemit të kontrollit të automatizuar, duke marrë parasysh shpërndarjen e tyre midis niveleve të menaxhimit.

1.7.3. Kërkesat për shpërndarjen e përgjegjësive midis personelit të përfshirë në funksionimin e sistemit të kontrollit të automatizuar në kohë reale përcaktohen duke marrë parasysh kërkesat e pikës 11 të shtojcës së detyrueshme 1.

1.7.4. Udhëzimet për mbështetjen organizative të sistemit të kontrollit të automatizuar duhet të përcaktojnë veprimet e personelit të sistemit të kontrollit të automatizuar të nevojshëm për të kryer çdo funksion të automatizuar në të gjitha mënyrat e funksionimit të sistemit të kontrollit të automatizuar, duke marrë parasysh kërkesat e specifikuara për saktësinë dhe shpejtësinë e zbatimit. nga personeli i sistemit të kontrollit të automatizuar të detyrave të tyre funksionale, dhe gjithashtu përmbajnë udhëzime specifike për veprimet në rast situatash emergjente ose shkelje të kushteve normale të funksionimit të sistemit të automatizuar të kontrollit. Kërkesat për përmbajtjen e udhëzimeve janë në përputhje me GOST 24.209-80.

1.7.5. Për çdo funksion të automatizuar që kryhet në ndërveprim të kësaj SHDSH me sisteme të tjera, udhëzimet për personelin e ACS dhe këto sisteme duhet të jenë të ndërlidhura për të gjitha mënyrat e kryerjes së këtij funksioni dhe të përmbajnë udhëzime për veprimet e personelit në rast të dështimeve të mjetet teknike të ACS.

1.8. Kërkesat për mbështetjen gjuhësore të sistemeve të automatizuara të kontrollit

1.8.1. Mbështetja gjuhësore e sistemit të kontrollit të automatizuar duhet të jetë e mjaftueshme për komunikimin midis kategorive të ndryshme të përdoruesve në një formë të përshtatshme për ta me mjetet e automatizimit të sistemit të kontrollit të automatizuar dhe për kryerjen e procedurave për konvertimin dhe paraqitjen makinerike të informacionit të përpunuar në sistemin e automatizuar të kontrollit.

1.8.2. Mbështetja gjuhësore e sistemit të kontrollit të automatizuar duhet të përfshijë:

• ofrohen mjete gjuhësore për të përshkruar çdo informacion të përdorur në sistemin e automatizuar të kontrollit;
• mjetet gjuhësore të përdorura janë të unifikuara;
• janë standardizuar përshkrimet e elementeve të ngjashme të informacionit dhe regjistrimi i strukturave sintaksore;
• Sigurohet komoditeti, paqartësia dhe stabiliteti i komunikimit midis përdoruesve dhe sistemeve të automatizuara të kontrollit;
• sigurohen mjete për korrigjimin e gabimeve që lindin kur përdoruesit komunikojnë me mjetet teknike të sistemit të kontrollit të automatizuar.

1.8.3. Mbështetja gjuhësore e sistemit të kontrollit të automatizuar duhet të pasqyrohet në dokumentacionin (udhëzimet, përshkrimet) e mbështetjes organizative të sistemit të kontrollit të automatizuar në formën e rregullave për komunikimin midis përdoruesve dhe mjeteve teknike të sistemit të kontrollit të automatizuar në të gjitha mënyrat e sistemit. operacion.

1.9. Kërkesat për mbështetje ligjore të sistemeve të automatizuara të kontrollit

Mbështetja ligjore për sistemet e automatizuara të kontrollit duhet të përfshijë një sërë normash ligjore:

• përcaktimin e vlefshmërisë ligjore të informacionit mbi bartësit e të dhënave dhe dokumenteve të përdorura në funksionimin e sistemit të kontrollit të automatizuar dhe të krijuara nga sistemi;
• rregullimin e marrëdhënieve juridike ndërmjet personave që janë pjesë e personelit të SHDSH-së (të drejtat, detyrat dhe përgjegjësitë), si dhe ndërmjet personelit të SHDSH-së dhe personelit të sistemeve që ndërveprojnë me SHDSH-në.

Shënim. Rregullat dhe rregulloret që rrjedhin nga vlefshmëria ligjore e informacionit mbi bartësit e të dhënave dhe normat ligjore duhet të përfshihen në udhëzimet dhe rregulloret e mbështetjes organizative për shërbimet përkatëse të ICS.

1.10. Kërkesat për dokumentacionin operacional për sistemet e automatizuara të kontrollit

1.10.1. Dokumentacioni operacional për SHDSH-në duhet të jetë i mjaftueshëm për vënien në funksion të SHDSH-së dhe për funksionimin efektiv të tij.

1.10.2. Dokumentacioni operacional për sistemin e automatizuar të kontrollit duhet:

• përmbajnë informacione të nevojshme për zhvillimin e shpejtë dhe cilësor dhe funksionimin e duhur të sistemeve të kontrollit të automatizuar;
• të përmbajë udhëzime për aktivitetet e personelit të ACS në situata emergjente ose në rast të shkeljes së kushteve normale të funksionimit të SHDSH;
• nuk përmbajnë dispozita që i nënshtrohen interpretimit të paqartë.

2. KËRKESAT E SIGURISË

2.1. Veprimet e pasakta të personelit të ACS nuk duhet të çojnë në një emergjencë.

2.2. Kërkesat e sigurisë për produktet elektrike të përdorura në sistemet e kontrollit të automatizuar janë në përputhje me GOST 12.2.007.0-75.

2.3. Kërkesat e sigurisë për pajisjet kompjuterike të përdorura në sistemet e kontrollit të automatizuar janë në përputhje me GOST 25861-83.

2.4. Të gjithë elementët e jashtëm të mjeteve teknike të sistemit të kontrollit automatik që janë të ndezur duhet të mbrohen nga kontakti aksidental, dhe vetë mjetet teknike duhet të jenë të tokëzuara ose të bazuara në mënyrë mbrojtëse në përputhje me GOST 12.1.030-81 dhe "Rregullat për pajisjet e furnizimit me energji elektrike". .

2.5. Pajisjet teknike ACS të vendosura në instalime të rrezikshme nga shpërthimi dhe zjarri duhet të plotësojnë kërkesat e "Rregullave të Furnizimit me Energji elektrike".

2.6. Mjetet teknike ACS duhet të instalohen në mënyrë të tillë që të sigurojnë funksionimin dhe mirëmbajtjen e tyre të sigurt.

2.7. Kërkesat e sigurisë duhet të vendosen në një seksion të veçantë të përshkrimeve të punës dhe (ose) udhëzimeve të funksionimit për sistemet e automatizuara të kontrollit dhe të kenë lidhje me udhëzimet e funksionimit për pajisjet teknike.

2.8. Kërkesat e përgjithshme ergonomike për vendet e punës të personelit të sistemit të kontrollit të automatizuar janë në përputhje me GOST 22269-76.

2.9. Kushtet e rehatshme të jetesës për personelin e sistemit të kontrollit të automatizuar duhet të përputhen me standardet aktuale sanitare, kushtet maksimale të lejueshme të jetesës - në përputhje me GOST 12.1.005-76, nivelet e lejuara të ndikimit të faktorëve të rrezikshëm dhe të dëmshëm të prodhimit - në përputhje me GOST 12.0.003-74 .

2.10. Kërkesat e përgjithshme ergonomike për mikroklimën e ambienteve të punës të personelit të sistemit të kontrollit të automatizuar janë në përputhje me GOST 12.1.005-76.

2.11. Nivelet e fuqisë së zhurmës dhe zërit në vendndodhjet e personelit të sistemit të kontrollit të automatizuar nuk duhet të kalojnë vlerat e përcaktuara nga GOST 12.1.003-83 dhe standardet sanitare, ndërsa nivelet e zhurmës dhe fuqisë së zërit të krijuara nga të gjitha burimet, përfshirë mjetet akustike të transmetimi i të dhënave, duhet të merret parasysh.

2.12. Nivelet e ndriçimit të vendeve të punës të personelit të sistemit të kontrollit të automatizuar duhet të korrespondojnë me natyrën dhe kushtet e punës. Duhet të sigurohet mbrojtje kundër shkëlqimit dhe zvogëlimit të shkëlqimit.

2.13. Kërkesat e përgjithshme ergonomike për dridhjet e pajisjeve në vendet e punës të personelit të sistemit të kontrollit të automatizuar janë në përputhje me GOST 12.1.012-78.

2.14. Ngjyrat e sinjalit dhe shenjat e sigurisë sipas GOST 12.4.026-76.

3. LLOJET DHE PROCEDURA E TESTVE KUR VEN NË FUNKSIONIM ACS

Ky seksion zbatohet për të gjitha sistemet e automatizuara të kontrollit, përveç atyre të krijuara me urdhër të Ministrisë së Mbrojtjes.

3.1. Një sistem kontrolli i automatizuar ose një funksion i dorëzuar veçmas i një sistemi kontrolli të automatizuar (në tekstin e mëtejmë i referuar si sistemi i automatizuar i kontrollit), kur e vë në funksionim, duhet t'i nënshtrohet testeve paraprake dhe pranuese, si dhe testeve të parashikuara nga dokumentet rregullatore dhe teknike. në fuqi në departamentin e klientit të sistemit të kontrollit të automatizuar.

3.2. Testimi i pranimit i sistemit të kontrollit të automatizuar duhet të paraprihet nga funksionimi i tij provë në objektin e kontrollit.

3.3. Testet ACS kryhen në përputhje me dokumentin "Programi i testimit", i cili është përgatitur nga zhvilluesi i ACS. Kërkesat për përmbajtjen e programit të testimit janë në përputhje me GOST 24.208-80.

3.4. Testet ACS mund të kryhen në një ose disa faza.

Bazuar në rezultatet e testimit, ACS harton një “Raport Testi”. Kërkesat për përmbajtjen e raportit të testit janë në përputhje me GOST 24.208-80.

Kur testoni një ACS hap pas hapi, "Raporti i Testit" bazuar në rezultatet e fazës së mëparshme duhet të përmbajë një përfundim në lidhje me mundësinë e paraqitjes së ACS në fazën tjetër të testimit.

3.5. Testet paraprake të sistemit të kontrollit të automatizuar

3.5.1. Testet paraprake të sistemit të kontrollit të automatizuar kryhen për të përcaktuar performancën e tij dhe për të zgjidhur çështjen e mundësisë së pranimit të sistemit të kontrollit automatik për funksionimin e provës.

3.5.2. “Programi i testimit” për testimin paraprak të ACS miratohet nga klienti i ACS.

3.5.3. Testet paraprake të ACS organizohen nga klienti dhe kryhen së bashku nga zhvilluesi i ACS dhe klienti.

3.5.4. Komisioni për kryerjen e testeve paraprake të sistemit të kontrollit të automatizuar formohet me urdhër të klientit. Kryetar i komisionit caktohet një përfaqësues i klientit të sistemit të automatizuar të kontrollit.

3.5.6. "Raporti i testit", i hartuar në bazë të rezultateve të testeve paraprake të ACS, jep një përfundim mbi mundësinë e pranimit të ACS për funksionim provë, si dhe një listë të modifikimeve të nevojshme dhe afatet e rekomanduara për zbatimin e tyre.

3.6. Funksionimi provë i sistemeve të kontrollit të automatizuar

3.6.1. Rezultatet e pranimit të SHDSH-së për funksionim provë dokumentohen në “Certifikatën e Pranimit për Funksionim Provë”, të hartuar mbi bazën e “Raportit të Testimit” nga komisioni që ka kryer testimet paraprake të SHDSH-së. Kërkesat për përmbajtjen e aktit janë në përputhje me GOST 24.208-80.

3.6.2. Kohëzgjatja e provës së funksionimit të sistemit të kontrollit të automatizuar përcaktohet nga koha e nevojshme për të verifikuar funksionimin e saktë të sistemit të kontrollit të automatizuar gjatë kryerjes së secilit funksion të automatizuar dhe gatishmërinë e personelit të sistemit të kontrollit të automatizuar për të marrë pjesë në kryerjen e të gjitha funksioneve të automatizuara të sistemi i automatizuar i kontrollit.

3.6.3. Kohëzgjatja minimale e provës së funksionimit të sistemit të kontrollit të automatizuar (përveç sistemit të kontrollit automatik) përpara testimit të pranimit përcaktohet për çdo funksion të automatizuar të sistemit të kontrollit të automatizuar që dorëzohet; duhet të korrespondojë me vlerat e treguara në tabela. Nëse kohëzgjatja totale e ndërprerjeve në vazhdimësinë e një funksioni të automatizuar tejkalon vlerën e specifikuar në tabelë, operacioni provë duhet të vazhdojë derisa të merren rezultate në përputhje me tabelën ose derisa të merret një vendim për ta përfunduar atë.

Lejohet, me marrëveshje me klientin, të dorëzohet ACS për testim pranimi pa funksionim provë të atyre funksioneve të automatizuara, frekuenca e zgjidhjes së të cilave është më pak se një herë në muaj, me kusht që jo vetëm funksione të tilla të jenë të automatizuara në ACS.

Frekuenca e ekzekutimit të funksionit të automatizuar	Kohëzgjatja minimale e funksionimit provë të sistemit të automatizuar të kontrollit përpara testimit të pranimit	Kohëzgjatja totale e lejueshme e ndërprerjeve në vazhdimësinë e ekzekutimit të një funksioni të sistemit të automatizuar të kontrollit të automatizuar
Në mënyrë të vazhdueshme	1 muaj	Jo më shumë se 3 ditë
Një herë në ditë ose më shpesh	Njësoj	Jo më shumë se 10% e numrit të planifikuar të zgjidhjeve
Më pak se një herë në ditë deri në një herë në muaj	3 muaj	Njësoj
Më pak se një herë në muaj deri në një herë në gjashtë muaj	Periudha ndërmjet dy vendimeve të njëpasnjëshme	Ndërprerjet në vazhdimësinë e performancës së funksionit nuk lejohen
Një herë në vit ose më pak	Periudha kohore e nevojshme për të testuar teknologjinë e miratuar për mbledhjen dhe përpunimin e informacionit gjatë një ekzekutimi një herë të funksionit ACS	Njësoj

Shënime:

1. Shkelje e vazhdimësisë së ekzekutimit të një funksioni të automatizuar të një sistemi kontrolli të automatizuar konsiderohet të jetë moskryerja e tij në kohën e përcaktuar në dokumentacionin teknik për sistemin e automatizuar të kontrollit, përveç rasteve kur kjo është shkaktuar nga një shkelje e kushtet e funksionimit të sistemit të automatizuar të kontrollit ose objektit të kontrollit.

2. Nëse kohëzgjatja aktuale e provës së funksionimit të sistemit të kontrollit të automatizuar ishte më e gjatë se koha e treguar në kolonën e dytë të tabelës, atëherë kohëzgjatja totale e ndërprerjes së vazhdimësisë së ekzekutimit për çdo funksion të automatizuar përcaktohet për periudhën kohore. të treguara në tabelë dhe menjëherë para testeve të pranimit.

3.6.4. Gjatë funksionimit provë të ACS, mbahet një regjistër pune në të cilin regjistrohen informacione: për kohëzgjatjen e funksionimit të ACS, mbi rezultatet e monitorimit të funksionimit të saktë të ACS, për dështimet, keqfunksionimet, situatat emergjente, për ndryshimet. në parametrat e objektit të kontrollit dhe rregullimet e vazhdueshme të dokumentacionit teknik.

3.6.5. Bazuar në rezultatet e funksionimit të provës, hartohet një certifikatë e përfundimit të punës për kontrollimin e sistemit të kontrollit të automatizuar në modalitetin e provës. Kërkesat për përmbajtjen e aktit janë në përputhje me GOST 24.208-80.

3.7. Testet e pranimit të ACS

3.7.1. Testet e pranimit të ACS kryhen për të përcaktuar përputhjen e tij me specifikimet teknike për ACS, kërkesat e këtij standardi dhe për të përcaktuar mundësinë e vënies në funksion të ACS.

3.7.2. Në varësi të rëndësisë së objektit të kontrollit dhe sistemit të automatizuar të kontrollit, testet e pranimit mund të jenë:

• qeveria;
• ndërsektorial;
• departamenti

dhe duhet të kryhet nga komitetet përkatëse të pranimit. Komiteti i pranimit formohet me urdhër të ministrisë (departamentit) të klientit të sistemit të automatizuar të kontrollit. Niveli i komitetit të pranimit duhet të përcaktohet në specifikimet teknike për sistemin e automatizuar të kontrollit.

3.7.3. Një përfaqësues i klientit të sistemit të kontrollit të automatizuar emërohet si kryetar i komitetit të pranimit. Komiteti i pranimit duhet të përfshijë përfaqësues të zhvilluesit të ACS.

3.7.4. Puna e komitetit të pranimit nuk përfshin pranimin e ndërtesave, strukturave dhe pajisjeve ndihmëse, krijimi i të cilave u krye në lidhje me krijimin e një sistemi kontrolli të automatizuar. Komisioni kontrollon vetëm disponueshmërinë e certifikatave të pranimit për funksionim dhe plotësimin e kërkesave të përfshira në detyrat e projektimit në pjesët ngjitur të projektit të objektit, të lëshuara gjatë projektimit të sistemit të automatizuar të kontrollit.

3.7.5. Klienti dhe zhvilluesi i paraqesin komitetit të pranimit dokumentacionin e mëposhtëm:

• termat e referencës për krijimin e një sistemi kontrolli të automatizuar;
• draft programi i testimit të pranimit;
• Raporti paraprak i testit ACS;
• certifikatën e pranimit të sistemit të automatizuar të kontrollit për funksionimin provë;
• akt(et) për përfundimin e punës për kontrollin e sistemit të kontrollit të automatizuar në modalitetin e provës së funksionimit;
• dokumentacioni teknik për sistemin e automatizuar të kontrollit (me vendim të komisionit të pranimit).

3.7.6. Përpara paraqitjes për testim pranimi, sistemet e automatizuara të kontrollit me kanale matëse i nënshtrohen certifikimit metrologjik në përputhje me standardet aktuale.

3.7.7. Përpara paraqitjes së ACS për testimin e pranimit, sistemi dhe dokumentacioni teknik i tij duhet të finalizohen në bazë të komenteve të protokollit paraprak të testimit dhe certifikatës së përfundimit të punës për kontrollin e ACS në modalitetin e provës.

Lejohet, me vendim të komisionit të pranimit, të finalizohet dokumentacioni teknik i sistemit të kontrollit të automatizuar pasi të jetë vënë në punë. Afatet për finalizimin e dokumentacionit teknik të sistemit të kontrollit të automatizuar tregohen në raportin e testimit të pranimit të sistemit.

3.7.8. Testet e pranimit të sistemit të kontrollit të automatizuar duhet të kryhen në një objekt kontrolli funksional.

3.7.9. “Programi i testimit” për testimin e pranimit të sistemit të kontrollit të automatizuar duhet të miratohet me vendime të komisionit të pranimit. Koordinimi i programit të testimit të pranimit me klientin e sistemit të kontrollit të automatizuar është i detyrueshëm.

3.7.10. Bazuar në rezultatet e testeve të pranimit, komisioni harton një raport testimi dhe një akt për vënien në funksion të ACS (ose një konkluzion për mospranimin e ACS me një listë të modifikimeve të nevojshme dhe afatet e rekomanduara për zbatimin e tyre). Kërkesat për përmbajtjen e protokollit dhe veprojnë në përputhje me GOST 24.208-80. Kërkesat për përmbajtjen e konkluzionit për mospranimin e sistemit të automatizuar të kontrollit janë të ngjashme me kërkesat për përmbajtjen e aktit për vënien në fuqi të sistemit të kontrollit të automatizuar.

3.7.11. Në rastin e testeve të pranimit hap pas hapi, akti i vënies në punë të sistemit të kontrollit të automatizuar përpilohet në bazë të akteve të vënies në punë të pjesëve individuale të sistemit dhe (ose) "Raporteve të testimit" të të gjithëve. fazat e testimit të pranimit të sistemit të automatizuar të kontrollit.

3.7.12. Data e vënies në punë të sistemit të kontrollit të automatizuar konsiderohet data e nënshkrimit të aktit të vënies në punë nga komisioni i pranimit.

3.7.13. Akti për vënien në fuqi të sistemit të kontrollit të automatizuar miratohet nga ministria (departamenti) i klientit.

4. PLOTËSIA E VËNË NË FUNKSION TË SHDSH

4.1. ACS duhet të përfshijë:

• Mjetet teknike ACS në formën e një kompleksi mjetesh teknike ACS të përgatitura për funksionim;
• pjesë dhe pajisje rezervë (SPTA), instrumente dhe pajisje për testimin e funksionimit, vendosjen e pajisjeve teknike dhe monitorimin e karakteristikave metrologjike të kanaleve matëse të sistemit të kontrollit të automatizuar në masën e parashikuar nga dokumentacioni i projektimit me porosi të rënë dakord me klientin e automatikut sistemi i kontrollit dhe shërbimi i metrologjisë së përdoruesit përsa i përket pajisjeve të testimit;
• dokumentacioni operacional në përputhje me GOST 2.601-68 për secilin prej produkteve të përfshira në CTS ACS;
• të paktën dy kopje të programeve për transportuesit e të dhënave dhe dokumentacionin operacional mbi to në përputhje me GOST 19.101-77, duke marrë parasysh kufizimet dhe shtesat në përputhje me GOST 24.101-80 dhe GOST 24.207-80;
• një formular për softuerin ACS në tërësi ose për softuerin e një funksioni ACS të vënë në veprim veçmas dhe formularët për produktet softuerike (sipas GOST 19.004-80), secila në një kopje. Kërkesat për formularin - sipas GOST 19.501-78;
• dy kopje të dokumentacionit operacional për sistemin e kontrollit të automatizuar në përputhje me GOST 24.101-80, duke përfshirë dokumentacionin e nevojshëm për mbështetjen e informacionit të sistemit të kontrollit të automatizuar (formulari i sistemit të kontrollit të automatizuar në një kopje).

Me marrëveshje ndërmjet zhvilluesit ACS dhe klientit ACS, kompletimi i ACS mund të zgjerohet.

4.2. Stafi i ACS duhet të jetë i pajisur me personel që plotëson kërkesat e pikës 1.3.

4.3. Për të kompletuar sistemin e krijuar të automatizuar të kontrollit, mund të përdoren sa më poshtë, të furnizuara si produkte prodhimi dhe teknike:

• komplekse (komplekse) harduerësh dhe softuerësh me dokumentacion operacional për to në përputhje me GOST 2.601-68;
• produkte softuerike me dokumentacion operacional për to në përputhje me GOST 19.101-77;
• pajisje teknike me dokumentacion operacional për to në përputhje me GOST 2.601-68.

4.4. Procedura për zhvillimin, futjen në prodhim dhe testimin e komponentëve të furnizuar të përdorur në sistemin e automatizuar të kontrollit duhet të jetë në përputhje me standardet shtetërore për sistemin e zhvillimit dhe hedhjes në prodhim të produkteve.

Para se të vihen në prodhim, prototipet e komponentëve i nënshtrohen testeve të pranimit (shtetërore, ndër-departamentale, departamentale).

5. GARANCI

5.1. Zhvilluesi i sistemit të kontrollit të automatizuar garanton përputhjen e sistemit të kontrollit të automatizuar me kërkesat e këtij standardi dhe specifikimet teknike për sistemin e kontrollit automatik, në varësi të pajtueshmërisë së përdoruesit me kushtet dhe rregullat e funksionimit.

5.2. Përputhshmëria e sistemeve të pajisjeve harduerike, softuerike dhe automatizimi të përdorura në sistemet e kontrollit të automatizuar dhe të furnizuara si produkte prodhuese dhe teknike me kërkesat e standardeve dhe specifikimeve për to garantohet nga prodhuesit e këtyre llojeve të produkteve, në varësi të pajtueshmërisë së përdoruesit me funksionimin. kushtet dhe rregullat.

5.3. Periudha e garancisë për ACS llogaritet nga data kur ACS është vënë në punë.

5.4. Periudha e garancisë për ACS duhet të përcaktohet në specifikimet teknike për ACS dhe nuk mund të jetë më pak se 18 muaj.

ANEKSI 1
E detyrueshme

KËRKESA SHTESË PËR SISTEMET E automatizuara të kontrollit të procesit (APCS)

1. Sistemet e kontrollit të procesit në industri dhe në sferën joindustriale duhet të menaxhojnë objektin teknologjik në tërësi dhe të furnizojnë sistemet e ndërlidhura me informacion të besueshëm teknologjik, teknik dhe ekonomik për funksionimin e objektit të kontrollit teknologjik (TOU).

2. Sistemi i automatizuar i kontrollit të procesit duhet të zhvillojë dhe zbatojë veprime kontrolli në sistemin e kontrollit që janë racionale për sa i përket qëllimeve dhe kritereve të kontrollit në kohë reale të procesit teknologjik në objektin e kontrollit.

3. Sistemi i automatizuar i kontrollit të procesit duhet të kryejë funksione kontrolli, informacioni dhe ndihmëse.

4. Sistemi i kontrollit të procesit duhet të jetë i pajtueshëm me të gjitha sistemet e automatizuara (AS) të ndërlidhura me të, të specifikuara në termat e referencës për sistemin e kontrollit të procesit, duke përfshirë sistemet e përfshira në këtë sistem të kontrollit të procesit si pjesë e prodhimit fleksibël të automatizuar, për shembull, Teknologjitë CAD, sisteme të automatizuara të magazinës dhe transportit, AS për përgatitjen teknologjike të prodhimit.

5. Veprimet e kontrollit në sistemin e automatizuar të kontrollit të procesit duhet të gjenerohen automatikisht ose të gjenerohen nga personeli i tij operacional duke përdorur një grup mjetesh automatizimi të përfshira në sistem.

6. Sistemi i automatizuar i kontrollit të procesit duhet të sigurojë kontrollin e objektit në kushte normale, kalimtare dhe para-urgjente të funksionimit të tij, si dhe mbrojtjen ose mbylljen e objektit në rast të një kërcënimi aksidenti.

7. Sistemi i automatizuar i kontrollit të procesit duhet të kryejë funksionin e monitorimit të kryerjes së veprimeve të kontrollit mbi pajisjet teknike dhe sinjalizimin kur organet ekzekutive arrijnë pozicionet e tyre maksimale të lejueshme.

8. Gjatë zbatimit të funksionit të devijimit automatik emergjent të pajisjeve në sistemin e kontrollit të procesit, një alarm për këtë duhet t'i jepet personelit operativ duke përdorur sinjale drite dhe, nëse është e nevojshme, zanore me regjistrim automatik të kohës së fikjes.

9. Si mjetet kryesore teknike të sistemeve të automatizuara të kontrollit të procesit, duhet të jenë produktet e Sistemit Shtetëror të Instrumenteve Industriale dhe Pajisjeve të Automatizimit (GSP), produktet e tjera që plotësojnë kërkesat e standardeve ESSP dhe pajisjet kompjuterike që përputhen me GOST 21552-84. të përdorura.

10. Mjetet teknike të sistemeve të automatizuara të kontrollit të procesit të vendosura në pajisjet e procesit duhet të plotësojnë kërkesat për kushtet e funksionimit të tyre.

11. Përgjegjësitë ndërmjet operatorëve duhet të shpërndahen duke marrë parasysh:

• pjesëmarrja e personelit në kryerjen e funksioneve manuale të sistemit dhe ndërveprimin e tij me sistemet e tjera;
• niveli i lejueshëm i ngarkesës psikofiziologjike dhe emocionale të operatorëve të përcaktuar nga dokumentet normative dhe teknike të industrisë që lidhen me kryerjen e detyrave të caktuara për secilin prej tyre dhe përgjegjësinë e tij për rezultatet përfundimtare dhe të ndërmjetme të punës, si dhe nivelin e kërkuar të veprimtarisë së tij në procesin e punës.

12. Çdo person i përfshirë në staf duhet të ketë:

• njohuri, vëllimi dhe thellësia e të cilave i lejon atij të kryejë veprime (ndërveprime) të përfshira në funksionet përkatëse të automatizuara dhe të ndërlidhura jo të automatizuara të sistemit të automatizuar të kontrollit të procesit, si dhe të marrë vendimet e duhura në situata emergjente ose shkelje të tjera të funksionimit normal. ;
• aftësi të zhvilluara që lejojnë kryerjen e të gjitha veprimeve dhe ndërveprimeve me saktësi dhe shpejtësi të caktuar.

13. Softueri i sistemit të automatizuar të kontrollit të procesit duhet të sigurojë, dhe mbështetja organizative duhet të pasqyrojë, mjete gjuhësore për komunikimin ndërmjet personelit operacional dhe sistemit të automatizuar të kontrollit të procesit, të përshtatshëm dhe të aksesueshëm për personat që nuk kanë kualifikime programuesi.

14. Kodet dhe simbolet e përdorura në sistemin e kontrollit të procesit duhet të jenë të afërta me termat dhe konceptet e përdorura nga personeli teknologjik i objektit të kontrollit dhe nuk duhet të shkaktojnë vështirësi në perceptimin e tyre.

15. Kanalet matëse të sistemit të automatizuar të kontrollit të procesit duhet të kenë karakteristika metrologjike që sigurojnë kryerjen e funksioneve të tij të informacionit me treguesit e përcaktuar në specifikimet teknike për sistemin e automatizuar të kontrollit të procesit.

16. Kërkesat për testimin e sistemeve të automatizuara të kontrollit të procesit

16.1. Testet paraprake të sistemit të automatizuar të kontrollit të procesit kryhen në një pajisje teknike ekzistuese.

16.2. Testet paraprake të funksioneve të sistemit të automatizuar të kontrollit të procesit të nevojshëm për fillimin dhe funksionimin e pajisjeve të procesit mund të kryhen në vend duke përdorur simulatorë.

16.3. Përcaktimi i vlerave aktuale të treguesve të efikasitetit teknik dhe ekonomik dhe besueshmërisë së sistemit të automatizuar të kontrollit të procesit kryhet pas vënies në punë të tij. Koha e funksionimit të sistemit të automatizuar të kontrollit të procesit, e nevojshme për të përcaktuar vlerat aktuale të treguesve të tij, llogaritet sipas metodave të duhura të miratuara në mënyrën e përcaktuar.

SHTOJCA 2
E detyrueshme

KËRKESA SHTESË PËR ACS NGA NDËRMARRJET, PRODHIMI DHE SHOQATAT E KËRKIMIT DHE PRODHIMIT

1. Sistemi i automatizuar i kontrollit duhet të rrisë efikasitetin e prodhimit dhe të veprimtarive ekonomike të ndërmarrjeve, prodhimit ose shoqatave shkencore e prodhuese (në tekstin e mëtejmë si ndërmarrje).

2. Sistemi i kontrollit të automatizuar të ndërmarrjes (ACS) duhet të sigurojë mbledhjen dhe përpunimin e automatizuar të informacionit me përdorimin e gjerë të metodave të optimizimit për detyrat kryesore dhe nënsistemet e kontrollit të nivelit të përgjithshëm të impiantit dhe punishtes, duke përfshirë, nëse është e nevojshme, në kohë reale në telepërpunim. dhe mënyra e dialogut.

3. Sistemi i automatizuar i kontrollit duhet të zbatohet si një grup nënsistemesh që funksionojnë së bashku, ndërveprimi ndërmjet të cilave duhet të ndodhë nëpërmjet një baze të dhënash të përbashkët (të vetme ose të shpërndarë).

4. Mbështetja organizative për sistemet e automatizuara të kontrollit duhet të sigurojë përmirësimin e metodave të menaxhimit dhe strukturës së sistemit të menaxhimit të ndërmarrjes gjatë krijimit dhe zhvillimit të sistemeve të automatizuara të kontrollit.

SHTOJCA 3
E detyrueshme

KËRKESA SHTESË PËR SISTEMET E KONTROLLIT TË automatizuar të industrisë (OACS)

1. OASU duhet të sigurojë:

• përmirësimi i karakteristikave të objektit të kontrollit (rritja e produktivitetit të punës në industri, përmirësimi i cilësisë së produktit, shpërndarja në kohë e produkteve, ulja e kostos së produkteve të prodhuara);
• përmirësimi i proceseve të përpunimit të informacionit (ulja e kostos së përpunimit të informacionit, rritja e besueshmërisë së atyre fillestare, rritja e saktësisë dhe efikasitetit të llogaritjeve);
• përmirësimi i organizimit të funksioneve të menaxhimit (në veçanti, shpërndarja racionale e punës midis departamenteve të aparatit të menaxhimit, qendrave kompjuterike dhe organizatave dhe ndërmarrjeve kërkimore).

2. OASU duhet të automatizojë funksionet e menaxhimit të industrisë, për shembull:

• parashikimi dhe planifikimi i prodhimit dhe burimeve të industrisë;
• menaxhimin e zhvillimit shkencor dhe teknik të industrisë dhe përgatitjen teknike të prodhimit industrial;
• menaxhimi i fuqisë punëtore të industrisë;
• menaxhimi i burimeve materiale të industrisë;
• menaxhimi i ndërtimit të kapitalit në industri;
• menaxhimi i burimeve financiare të industrisë;
• menaxhimin, duke përfshirë menaxhimin operacional, të prodhimit kryesor në nivel industrie, etj.

3. OACS duhet të zbatohet si një grup nënsistemesh që funksionojnë së bashku, ndërveprimi ndërmjet të cilave duhet të ndodhë përmes bazave të të dhënave të përbashkëta.

4. OASU duhet të përfshijë një sistem grumbullimi të të dhënave të bazuar në qendrat kompjuterike të OASU, organizatat dhe ndërmarrjet e industrisë, duke siguruar shpërndarje racionale të informacionit në bazat e të dhënave për zgjidhjen e problemeve ndërvepruese dhe transferimin e informacionit ndërmjet sistemeve nëpërmjet kanaleve të komunikimit dhe në media kompjuterike.

5. OACS duhet të sigurojë një mënyrë interaktive të punës me bazat e të dhënave të sistemit.

6. Krijimi i OASU duhet të çojë në përmirësimin e metodave dhe strukturës së menaxhimit të industrisë.

7. Kohëzgjatja e provës së funksionimit të pjesëve të OACS duhet të sigurojë një kryerje një herë të të gjitha llogaritjeve të nevojshme për të kryer funksionet e automatizuara të pjesës së futur të OACS dhe nuk duhet të kalojë 3 muaj.

Kohëzgjatja specifike e funksionimit provë të OASU përcaktohet me marrëveshje midis zhvilluesit dhe klientit.

SHTOJCA 4
Informacion

SHPJEGIMI I DISA TERMAVE TË PËRDORUR NË KËTË STANDARD

Kompleksi i pajisjeve të automatizimit (CAS)- një grup i furnizuar i grupeve të pajisjeve dhe softuerëve (produkteve) të kontraktuara reciprokisht, të zhvilluara dhe të prodhuara si produkte për qëllime industriale dhe teknike. ASK mund të përfshijë gjithashtu produkte dhe (ose) dokumente të tjera të përfshira në informacione, organizative ose lloje të tjera të mbështetjes për sistemet e automatizuara.

Zgjerimi i sistemeve të automatizuara të kontrollit- një grup masash të marra në sistemin e kontrollit të automatizuar kur zgjeron objektin e tij të kontrollit pa ndryshuar përbërjen e funksioneve të sistemit të kontrollit të automatizuar.

Korniza e videos (në ACS)- imazhi në ekranin e një dokumenti të tubit me rreze katodë të një vizatimi ose teksti mesazhi të përdorur në sistemin e automatizuar të kontrollit.

Kanali matës ACS- një grup i integruar funksionalisht i mjeteve teknike dhe (nëse është e nevojshme) softuerike të dizajnuara për të zbatuar një funksion të thjeshtë matës të sistemit të kontrollit të automatizuar.

Testet paraprake të sistemit të kontrollit të automatizuar- testet e kontrollit të kryera për të përcaktuar mundësinë e pranimit të sistemit të kontrollit të automatizuar për funksionim provë.

Testet e pranimit të ACS- testet e kontrollit të sistemit të kontrollit të automatizuar, të kryera për të përcaktuar përputhjen e tij me specifikimet teknike për krijimin e sistemit të kontrollit të automatizuar, kërkesat e standardeve dhe për të përcaktuar mundësinë e vënies në punë të sistemit të kontrollit të automatizuar.

Testet shtetërore- testet e pranimit të sistemeve të automatizuara të kontrollit të kryera nga komisioni shtetëror.

Testimi ndërsektorial- testet e pranimit të sistemeve të automatizuara të kontrollit të kryera nga një komision i përfaqësuesve të disa ministrive dhe (ose) departamenteve të interesuara.

Testet e departamentit- testet e pranimit të sistemeve të automatizuara të kontrollit të kryera nga një komision i përbërë nga përfaqësues të ministrisë ose departamentit të interesuar.

Redaktori A.I. Lomina
Redaktori teknik N.P. Zamolodchikova
Korrektori E.I. Evteeva
Dorëzuar në setin 16.01.86. Nënshkruar për botim më 04/08/86. E kushtëzuar furrë l. 1.5. E kushtëzuar kr.-ott. 1.5 Botim akademik. l. 1.5.
Qarkullimi 40.000 Çmimi 10 kopekë.
Urdhri "Simboli i Nderit" Shtëpia botuese e standardeve, 123810, Moskë, GSP, korsia Novopresnensky, 3
Lloji. "Moscow Printer", Moskë, korsi Lyalin, 6. Urdhri 1772

Sot do të flasim për standardet e brendshme për dokumentacionin e projektimit. Si funksionojnë këto standarde në praktikë, pse janë të këqija dhe pse janë të mira. Kur zhvillojmë dokumentacion për qeverinë dhe klientët seriozë privatë, zakonisht nuk kemi zgjidhje - pajtueshmëria me standardet përfshihet në kërkesat për dokumentimin e specifikimeve teknike. Në praktikë kam hasur në shembuj të ndryshëm të keqkuptimit të strukturës së standardeve, çfarë duhet të jetë në dokumente dhe pse duhen këto dokumente. Si rezultat, stilolapsat e shkrimtarëve teknikë, analistëve dhe specialistëve ndonjëherë prodhojnë gurë të çmuar, saqë është e paqartë se në çfarë gjendje të vetëdijes janë shkruar. Por në fakt, gjithçka është mjaft e thjeshtë. Një kërkim në Habr nuk ktheu asnjë lidhje me material pak a shumë të plotë mbi këtë temë, kështu që unë propozoj të plotësoni këtë boshllëk të bezdisshëm.

Cilat janë standardet e dokumentacionit?

Në 34 seritë në fjalë, ekzistojnë vetëm 3 standarde kryesore të dokumentacionit:

Standardi më i dashur dhe më popullor për zhvillimin e specifikimeve teknike. E vetmja gjë që nuk duhet të harroni është se është e lidhur ngushtë me standardet e tjera të serisë, dhe nëse keni marrë specifikimet teknike të bëra sipas këtij standardi, këshillohet që t'u përmbaheni standardeve të tjera, edhe nëse nuk ka kërkesa të drejtpërdrejta. për këtë. Të paktën për sa i përket ideologjisë së përgjithshme (për të cilën më poshtë)

Ky është një dokument bazë që ofron një listë të plotë të dokumentacionit GOST 34, rekomandime për kodimin e dokumenteve, cilat faza të projektit i përkasin dokumentet (fazat përshkruhen në GOST 34.601-90), si dhe se si ato mund të kombinohen me njëri-tjetrin .

Në fakt, ky standard është një tabelë e madhe me komente. Mund të futet në Excel për lehtësinë e përdorimit.

Një standard voluminoz që përshkruan përmbajtjen e dokumenteve të projektit me shkallë të ndryshme detajesh. GOST 34.201-89 i lartpërmendur përdoret si indeks.

Ka shumë pyetje dhe interpretime të dispozitave të tij në lidhje me standardin RD 50-34.698-90, të cilat për shkak të paqartësisë së tyre shpesh kuptohen ndryshe nga klienti dhe kontraktori, apo edhe anëtarët e ekipit të projektit. Por, për fat të keq, nuk kemi asgjë më konkrete.

Le të shqyrtojmë tani të mirat dhe të këqijat e standardeve, duke filluar tradicionalisht nga të këqijat.

Disavantazhet e standardeve

Disavantazhi kryesor është i dukshëm për të gjithë - standardet janë të vjetra. Ato përmbajnë një ide të vjetëruar të arkitekturës së një sistemi të automatizuar. Për shembull:

• aplikacione me dy nivele, të përbërë nga një program klient dhe një server DBMS (pa tre ose më shumë aplikacione "nivele", pa Weblogic ose JBoss)
• struktura e tabelave të bazës së të dhënave, duke u përshkruar, do të japë një ide për modelin logjik të të dhënave (fakti që mund të kishte një lloj Hibernate midis aplikacionit dhe bazës së të dhënave dukej si një tepricë e keqe atëherë)
• ndërfaqja e përdoruesit është me një dritare (a ka ndonjë gjë tjetër? Çfarë është një "shfletues"?)
• Ka pak raporte në sistem; ato janë të gjitha në letër dhe të shtypura në një printer matricë me pika.
• Programi që po zhvillohet është i fokusuar në zgjidhjen e “problemit të përpunimit të informacionit”, i cili ka një hyrje dhe dalje të qartë dhe është shumë i specializuar. Përpunimi i informacionit bazohet në një "algoritëm". Ndonjëherë ka disa "algoritme". (Programimi i orientuar nga objekti atëherë sapo po hidhte hapat e tij të parë dhe nuk u konsiderua seriozisht).
• administratori i bazës së të dhënave kupton se çfarë informacioni ka në tabela dhe merr pjesë aktive në redaktimin e drejtorive të sistemit (a ka vërtet një server DBMS për 50 aplikacione të ndryshme?)

Prandaj, standardi ka artefakte si më poshtë:

5.8. Vizatimi i formularit të dokumentit (korniza e videos)
Dokumenti duhet të përmbajë një imazh të formës së dokumentit ose kornizës së videos në përputhje me kërkesat e standardeve shtetërore të sistemit të unifikuar të dokumentacionit R 50-77 dhe shpjegimet e nevojshme.

Çështja e dokumentit është se ndërmarrjet sovjetike përdorën të ashtuquajturat "Zonat e Printimit", ku kishte printera matricë me shpejtësi të lartë, drejtuesit për të cilët shpesh shkruheshin nga vetë inxhinierët. Prandaj, ata duhej të mbanin një regjistër të të gjitha dokumenteve që duheshin printuar për t'u siguruar që dokumentet të dukeshin ashtu siç duhej kur printoheshin.

"Korniza video" është gjithashtu një dokument që u shfaq në një ekran teksti. Ekranet nuk mbështesin gjithmonë karakteret e kërkuara dhe numrin e kërkuar të karaktereve horizontale dhe linjave vertikale (dhe nuk mbështesin fare grafikë). Prandaj, edhe këtu, ishte e nevojshme të koordinohen shtesë format e të gjitha dokumenteve të ekranit.

Tani fjalët "makineogram", "kornizë video", "ADC" nuk na thonë më asgjë. Unë gjithashtu nuk i gjeta në përdorim, megjithëse u diplomova në një institut të specializuar në vitet '90. Kjo ishte koha e shfaqjes së Windows 3.1, ekraneve VGA, disketave me tre inç dhe faqeve të para shtëpiake në internet. Por këto fjalë janë në standard, dhe klienti ndonjëherë kërkon në mënyrë kapriçioze që ne t'i sigurojmë atij një grup të plotë dokumentacioni në përputhje me GOST 34.201-89. Për më tepër, formulime të tilla në ToR migrojnë nga një ministri në tjetrën dhe tashmë janë bërë një lloj shablloni i pashprehur në të cilin përmbajtja është futur.

Pra, dokumenti me emrin budalla "Vizatimi i formularit të dokumentit (korniza video)" në projekt duhet dhe nuk duhet të jetë bosh.

Çfarë është e mirë në standard

Çdo standard është i mirë në atë që lejon klientin dhe kontraktorin të flasin të njëjtën gjuhë dhe siguron një garanci që, të paktën, klienti nuk do të ketë asnjë ankesë "në formë" ndaj rezultateve të transmetuara.

Dhe standardet GOST 34 janë gjithashtu të mira sepse ato u përpiluan nga njerëz të zgjuar, të testuar ndër vite dhe ata kanë një qëllim të qartë - të përshkruajnë në letër sa më plotësisht të jetë e mundur thelbin kompleks abstrakt që përfaqëson çdo sistem kontrolli i automatizuar.

Kur duhet të vendosni me kompetencë një detyrë për kontraktorët perëndimorë që nuk kanë dëgjuar kurrë për standardet tona GOST, mund të mbështeteni gjithashtu në këto standarde, ose më saktë në përmbajtjen dhe përbërësin e tyre semantik. Sepse, e përsëris, garancia e plotësisë së informacionit vlen shumë. Pavarësisht se sa i bëjmë lajka vetes me nivelin e lartë të profesionalizmit tonë, mund të harrojmë të përfshijmë gjëra elementare në kërkesat tona, ndërsa i njëjti GOST 34.602-89 "kujton" gjithçka. Nëse nuk e keni të qartë se si duhet të duket rezultati i punës së kontraktorëve perëndimorë, shikoni kërkesat e dokumentacionit dhe seksionet e rekomanduara. Ju siguroj, është më mirë të mos e mendoni! Me shumë mundësi, ka analoge perëndimore të standardeve tona, në të cilat gjithçka mund të jetë më e plotë, më moderne dhe më e mirë. Fatkeqësisht, nuk jam i njohur me ta, pasi ende nuk ka pasur një rast të vetëm ku standardet tona GOST nuk ishin të mjaftueshme.

Mund të qeshësh me faktin se krijuesit e standardeve nuk dinin asgjë për java ose .NET, për monitorët HD dhe internetin, por nuk do të këshilloja të nënvlerësohej shkalla e punës që ata bënë dhe vlera e saj për komunitetin tonë profesional.

Si të lexoni dhe kuptoni standardet e dokumentacionit sipas serisë GOST 34

Standardi i ndan të gjitha dokumentet përgjatë dy akseve - koha dhe zona e lëndës. Nëse shikoni tabelën 2 në GOST 34.201-89, mund ta shihni qartë këtë ndarje (kolonat "Faza e krijimit" dhe "Pjesë e projektit"

Fazat e krijimit të një sistemi kontrolli të automatizuar

Fazat e krijimit përcaktohen në GOST 34.601-90. Tre prej tyre janë të rëndësishme për dokumentacionin:

• Draft dizajni (ED)
• Dizajni teknik (TP)
• Zhvillimi i dokumentacionit të punës (DD)

Projektim paraprak vijon pas fazës së Specifikimeve Teknike dhe shërben për zhvillimin e zgjidhjeve të projektimit paraprak.

Projekt teknik përshkruan sistemin e ardhshëm nga të gjitha këndvështrimet. Dokumentet në fazën TP duhet, pas leximit, të lënë pas qartësi të plotë në qasjet, metodat, zgjidhjet arkitektonike dhe teknike të propozuara. Në fazën tjetër, do të jetë tepër vonë për të përshkruar qasjet dhe për të justifikuar zgjidhjet teknike, kështu që faza P është çelësi për përfundimin me sukses të punës, pasi të gjitha kërkesat e ndryshme të specifikimeve teknike duhet të pasqyrohen në dokumentet e fazës P. Në fazën P, sistemi mund të mos ekzistojë fare.

Dokumentacioni i punës projektuar për vendosjen, vënien në punë dhe funksionimin e mëtejshëm të sistemit të ri. Këto janë dokumente që përmbajnë informacion shumë specifik që përshkruajnë entitetet ekzistuese fizikisht, në ndryshim nga faza P, e cila përshkruan shkëlqimin e së ardhmes.

Pjesë (seksione) të dokumentacionit të projektit për krijimin e një sistemi kontrolli të automatizuar

Fusha lëndore është e ndarë në “Dispozitat”. Në fillim duket se një ndarje e tillë është e tepërt dhe e panevojshme. Por kur filloni të punoni me këtë paketë mjetesh në praktikë, ideologjia e ngulitur në të bëhet gradualisht e qartë.

Një sistem i automatizuar, siç përcaktohet nga përpiluesit e GOST, është një kombinim i kanaleve të harduerit, softuerit dhe komunikimit që përpunon informacionin që vjen nga burime të ndryshme në përputhje me algoritme të caktuara dhe prodhon rezultate të përpunimit në formën e dokumenteve, strukturave të të dhënave ose veprimeve të kontrollit. Një model primitiv i mitralozit më të thjeshtë.

Për të përshkruar plotësisht këtë "makinë", janë bërë seksionet e mëposhtme (si në vizatim):

Software (MS), duke iu përgjigjur pyetjeve: cila logjikë është e lidhur brenda "kutisë së zezë"? Pse u zgjodhën këto algoritme të veçanta, këto formula të veçanta dhe këta koeficientë të veçantë?

Softueri matematikor nuk di asgjë për procesorët ose bazat e të dhënave. Kjo është një zonë e veçantë abstrakte, vendbanimi i "kuajve sferikë në vakum". Por softueri matematikor mund të lidhet shumë ngushtë me fushën e lëndës, i njohur ndryshe si Real Life. Për shembull, algoritmet e kontrollit për sistemet e kontrollit të trafikut duhet të miratohen nga Inspektorati Shtetëror i Sigurisë së Trafikut përpara se të miratohen nga klienti. Dhe atëherë e kuptoni pse ato janë përfshirë në një libër të veçantë. Sepse askush në policinë e trafikut nuk është i interesuar se me çfarë OS do të funksionojë serveri i aplikacionit, por cila shenjë dhe kufiri i shpejtësisë do të shfaqet në tabelë në shi ose borë është shumë interesante. Ata janë përgjegjës për pjesën e tyre dhe nuk do të nënshkruajnë asgjë tjetër. Nga ana tjetër, kur të nënshkruajnë, nuk do të ketë pikëpyetje për anën teknike të çështjes - pse kanë zgjedhur ato tabela apo semaforë dhe jo të tjera. Mençuria e "paraardhësve" manifestohet pikërisht në raste të tilla praktike.

Mbështetja e informacionit (IS). Një pjesë tjetër e sistemit. Këtë herë kutia e zezë e sistemit tonë është bërë transparente dhe ne shikojmë informacionin që qarkullon në të. Imagjinoni një model të sistemit të qarkullimit të gjakut të njeriut kur të gjitha organet e tjera janë të padukshme. Diçka e tillë është Mbështetja e Informacionit. Ai përshkruan përbërjen dhe rrugët e rrjedhës së informacionit brenda dhe jashtë, organizimin logjik të informacionit në sistem, një përshkrim të librave të referencës dhe sistemeve të kodimit (ata që kanë bërë programe për prodhim e dinë se sa të rëndësishme janë ato). Pjesa kryesore përshkruese bie në fazën e TP, por disa "rudimente" rrjedhin në fazën e RD, si dokumenti "Katalogu i bazës së të dhënave". Është e qartë se më parë përmbante pikërisht atë që shkruhet në titull. Por sot, përpiquni të krijoni një dokument të tillë për një sistem kompleks kompleks, kur shumë shpesh sistemi përdor nënsisteme të blera me depozitat e tyre misterioze të informacionit. Nuk po them as që ky dokument nuk është veçanërisht i nevojshëm tani.

Ose këtu është "Deklarata e mediave të ruajtjes së kompjuterit". Është e qartë se më parë përmbante një numër baterish magnetike ose bobina filmi. Tani çfarë duhet të vendos atje?

Me pak fjalë, në fazën e ZHR-së, dokumentet e Mbështetjes së Informacionit përfaqësojnë një element mjaft të dëmshëm, pasi ato formalisht duhet të ekzistojnë, por nuk ka asgjë të veçantë për t'i mbushur.

Software. Pjesa e preferuar e të gjithëve në dokumentacionin e projektit. Po, vetëm sepse është vetëm një dokument! Dhe pastaj, të gjithë e kuptojnë se çfarë duhet të shkruhet atje. Por gjithsesi do ta përsëris.

Në këtë dokument, ne duhet t'ju tregojmë me ndihmën e cilit softuer ekzekutohen algoritmet e përshkruara në ML, duke përpunuar informacionin e përshkruar në IR. Kjo do të thotë, nuk ka nevojë të kopjoni informacionin nga seksionet e tjera këtu. Këtu jepet arkitektura e sistemit, arsyetimi për teknologjitë e zgjedhura softuerike, përshkrimi i tyre (të gjitha llojet e gjërave të sistemit: gjuhët e programimit, kornizat, sistemet operative, etj.). Gjithashtu në këtë dokument ne përshkruajmë se si organizohen mjetet e përpunimit të informacionit (radhët e mesazheve, ruajtja, mjetet rezervë, zgjidhjet e disponueshmërisë, të gjitha llojet e grupeve të aplikacioneve, etj.). Standardi përmban një përshkrim të hollësishëm të përmbajtjes së këtij dokumenti, të cilin çdo specialist do ta kuptojë.

Mbështetje teknike (TO). Pjesë jo më pak e dashur e dokumentacionit të projektit. Pamja rozë mjegullohet vetëm nga bollëku i dokumenteve që duhen zhvilluar. Në total, standardi kërkon zhvillimin e 22 dokumenteve, nga të cilat 9 janë në fazën e TC.

Fakti është se standardi ofron një përshkrim të të gjithë mbështetjes teknike, duke përfshirë pajisjet kompjuterike dhe rrjetet, sistemet inxhinierike dhe madje edhe pjesën e ndërtimit (nëse kërkohet). Dhe kjo ekonomi rregullohet nga një numër i madh standardesh dhe rregulloresh, të koordinuara në organizata të ndryshme, dhe për këtë arsye është më i përshtatshëm për të ndarë gjithçka në pjesë dhe për të koordinuar (redaktuar) në pjesë. Në të njëjtën kohë, standardi ju lejon të kombinoni disa dokumente me njëri-tjetrin, gjë që ka kuptim nëse e gjithë grupi miratohet nga një person.

Mos harroni gjithashtu se një grup standardesh cilësie nënkupton regjistrimin dhe ruajtjen e dokumenteve teknike, dhe "librat" tanë nga klienti mund të shpërndahen midis arkivave të ndryshme, në varësi të temës së përshkrimit. Ky është një argument tjetër në favor të fragmentimit të dokumentacionit.

Mbështetje organizative (OO). Pasi e kam shtypur dëshirën, normale për një teknik, për ta kaluar këtë pjesë sa më shpejt që të jetë e mundur, përkundrazi, do ta konsideroj më në detaje. Meqenëse, kolegë, kohët e fundit ka pasur disa tendenca të këqija në projekte që kërkojnë sqarime në këtë pjesë.

Në fazën TP, seksioni përmban vetëm një dokument " Përshkrimi i strukturës organizative“, në të cilën duhet t'i tregojmë klientit se për çfarë duhet të përgatitet në drejtim të ndryshimit të strukturës organizative. Papritmas ju duhet të organizoni një departament të ri për të operuar sistemin tuaj, për të prezantuar pozicione të reja, etj.

Në fazën e RD-së shfaqen dokumente të tjera më interesante, të cilat do të doja t'i shqyrtoja veçmas.

Udhëzues Përdorues. Mendoj se komentet janë të panevojshme.

Metodologjia (teknologjia) e projektimit me kompjuter. Nëse është e nevojshme, mund të përfshini një përshkrim të procesit të ndërtimit të softuerit, kontrollit të versionit, testimit, etj. në këtë dokument. Por kjo ndodh nëse klienti në specifikimin teknik dëshiron të montojë personalisht softuerin. Nëse ai nuk e kërkon këtë (dhe nuk paguan për të), atëherë e gjithë kuzhina juaj e brendshme nuk është punë e tij dhe ky dokument nuk ka nevojë të bëhet.

Udhëzime teknologjike. Për shkak të modës për formalizimin e proceseve të biznesit, një klient dinak ndonjëherë përpiqet të fusë rregulloret e funksionimit në këtë dokument. Pra, në asnjë rrethanë nuk duhet ta bëni këtë.

Përshkrimi i proceseve të biznesit, përshkrimet e roleve dhe vendeve të punës, rregulloret e punës - e gjithë kjo është ORD, domethënë dokumentacion organizativ dhe administrativ. I cili është produkt i një projekti konsulence, i cili, me sa kuptoj, nuk është blerë nga ju. Dhe ata blenë një projekt teknik nga ju dhe gjithashtu dokumentacion teknik për të.

Udhëzimi teknologjik është një shtresë midis udhëzimeve të përdorimit dhe manualit të përdorimit. RP përshkruan në detaje Si ju duhet të bëni disa veprime në sistem. Udhëzimi teknologjik thotë se e cila veprimet duhet të kryhen në raste të caktuara që lidhen me funksionimin e sistemit. Përafërsisht, një udhëzim teknologjik është një përmbledhje e shkurtër e RP për një pozicion ose rol specifik. Nëse klienti nuk ka role të formuara ose ai dëshiron që ju të krijoni role dhe kërkesa për punë vetë, përfshini rolet më themelore në dokument, për shembull: operator, operator i lartë, administrator. Komentet e klientit për temën "por nuk është kështu me ne" ose "nuk na pëlqen" duhet të shoqërohen me një listë rolesh dhe një përshkrim të përgjegjësive të punës. Sepse proceset e biznesit ne ne nuk e vendosim atë. Ne jemi këto procese biznesi automatizoj.

Për grabujët e përshkruara do të shkruaj veçmas, me shembuj shumëngjyrësh, pasi kjo nuk është hera e parë që kjo përsëritet në sektorë të ndryshëm të "ekonomisë kombëtare".

Përshkrimi i procesit teknologjik të përpunimit të të dhënave (përfshirë telepërpunimin). Një relike patetike e epokës së shpellës, kur kishte "Operatorë Kompjuterësh" të caktuar posaçërisht, të cilët ushqeheshin me karta me grushta në makinë dhe paketonin një printim të rezultatit në një zarf. Ky udhëzim është për ta. Nuk mund t'ju them saktësisht se çfarë të shkruani në të në shekullin e 21-të. Dil vetë. Gjëja më e mirë është të harroni këtë dokument.

Zgjidhjet në të gjithë sistemin (WSO). Standardi parashikon 17 dokumente në seksionin OP. Së pari, këto janë pothuajse të gjitha dokumentet e fazës paraprake të Projektimit Skematik. Së dyti, këto janë të gjitha llojet e vlerësimeve, llogaritjeve dhe përshkrimeve të shkurtra të funksioneve të automatizuara. Kjo do të thotë, informacione për njerëzit jo nga prodhimi kryesor i IT, por për stafin mbështetës - menaxherët, vlerësuesit, specialistët e blerjeve, ekonomistët, etj.

Dhe së treti, OP përfshin një mega-dokument të quajtur "Shënim Shpjegues për Projektin Teknik", i cili synohet të jetë një lloj Përmbledhje Ekzekutive, por në fakt, shumë projektues fusin të gjithë përmbajtjen e dobishme të fazës TP në të. Një qasje e tillë radikale mund të justifikohet dhe madje të jetë reciprokisht e dobishme si për klientin ashtu edhe për kontraktorin, por në raste të caktuara.

Opsionet për përdorimin e GOST 34

1. Respektimi i plotë dhe i saktë i standardit. Natyrisht, askush nuk do të shkruajë vullnetarisht një re të tillë dokumentesh. Prandaj, një grup i plotë dokumentesh përgatitet vetëm me kërkesë urgjente të klientit, të cilin ai e siguroi në specifikimet teknike dhe gjithashtu i fiksoi me një marrëveshje sipër. Në këtë rast, ju duhet të merrni gjithçka fjalë për fjalë dhe t'i jepni klientit "libra" fizikë, në të cilët do të jenë emrat e dokumenteve nga Tabela 2 e GOST 34.201-89, me përjashtim të atyre krejtësisht të panevojshme, lista e të cilave ju duhet diskutuar dhe siguruar me shkrim. Përmbajtja e dokumenteve duhet gjithashtu, pa asnjë imagjinatë, të jetë në përputhje me RD 50-34.698-90, deri në emrat e seksioneve. Për të bërë që truri i klientit të shpërthejë, ndonjëherë një sistem i madh ndahet në nënsisteme dhe për secilin nënsistem lëshohet dokumentacion i veçantë projektimi. Duket e frikshme dhe nuk i nënshtrohet kontrollit normal me ndihmën e mendjes tokësore. Sidomos në lidhje me integrimin e nënsistemeve. E cila thjeshton shumë pranimin. Gjëja kryesore është që ju vetë të mos ngatërroheni dhe që sistemi juaj të funksionojë ende ashtu siç duhet.
2. Ne thjesht i duam standardet GOST. Kompanitë e mëdha serioze i duan standardet. Sepse i ndihmojnë njerëzit të kuptojnë më mirë njëri-tjetrin. Nëse klienti juaj shquhet për dashurinë e tij ndaj rendit dhe standardizimit, përpiquni t'i përmbaheni ideologjisë standarde GOST kur hartoni dokumente, edhe nëse kjo nuk kërkohet nga specifikimet teknike. Do të kuptoheni dhe aprovoheni më mirë nga specialistët miratues, dhe ju vetë nuk do të harroni të përfshini informacione të rëndësishme në dokumentacion, do të shihni më mirë strukturën e synuar të dokumenteve, do të planifikoni punën e shkrimit të tyre më saktë dhe do të kurseni veten dhe kolegët tuaj shumë nerva dhe para.
3. Nuk na intereson dokumentacioni, përderisa gjithçka funksionon. Shfaqja e zhdukur e klientit të papërgjegjshëm. Një pamje e ngjashme e dokumentacionit mund të gjendet ende tek klientët e vegjël dhe të varfër, si dhe në "idiotokracitë" autoritare të mbetura nga koha e perestrojkës, ku shefi është i rrethuar nga miq besnikë - drejtorë dhe të gjitha çështjet zgjidhen në biseda personale. . Në kushte të tilla, je i lirë të neglizhosh fare dokumentacionin, por më mirë, në fund të fundit, të mos rrëzosh pamjen dhe të paktën të plotësosh skematikisht dokumentacionin me përmbajtje. Nëse jo këtij klienti, atëherë kaloni (shite) tek tjetri.

konkluzioni

Ky artikull kishte të bënte me standardet tona GOST për dokumentimin e sistemeve të automatizuara të kontrollit. GOST-të janë të vjetra, por, siç rezulton, ato janë ende shumë të dobishme në familje. Përveç disa elementeve të dukshme, struktura e dokumentacionit ka vetitë e plotësisë dhe konsistencës, dhe respektimi i standardit eliminon shumë rreziqe të projektit, ekzistencën e të cilave mund të mos jemi të vetëdijshëm në fillim.

Shpresoj se materiali i paraqitur ishte i dobishëm për ju, ose të paktën interesant. Pavarësisht lodhjes së dukshme, dokumentacioni është një punë e rëndësishme dhe e përgjegjshme, në të cilën saktësia është po aq e rëndësishme sa shkrimi i kodit të mirë. Shkruani dokumente të mira, kolegë! Dhe javën tjetër do të shkoj në dy udhëtime pune radhazi, kështu që nuk mund të garantoj publikimin e materialeve të reja (nuk kam një cache, po shkruaj nga koka ime).

Prezantimi

Në botën moderne, çdo ditë shfaqen dhjetëra e qindra programe, aplikacione dhe sisteme të ndryshme informacioni. Ato mund të zhvillohen për sektorin qeveritar ose tregtar, si dhe për përdoruesit e zakonshëm. 90% e të gjithë përdoruesve nuk e lexojnë dokumentacionin, e konsiderojnë atë të mërzitshëm, të lodhshëm dhe jo interesant dhe hap manualin e përdorimit vetëm kur diçka nuk funksionon ose është plotësisht e pamundur ta kuptosh pa udhëzime. Tani është praktikë e zakonshme të dizajnohet ndërfaqja e përdoruesit në mënyrë të tillë që të jetë intuitive dhe përdoruesi të mund ta kuptojë sistemin pa pasur nevojë të lexojë manuale të gjata. Sidoqoftë, kur punoni me klientë të mëdhenj, është pothuajse gjithmonë e nevojshme të paraqisni një paketë të caktuar dokumentesh - manuale, udhëzime, zgjidhje projektimi, të hartuara në përputhje me GOST.
Kur takoni për herë të parë dokumentacionin e shkrimit në përputhje me GOST, jeni të trullosur dhe të tronditur plotësisht, pasi ka "det" të këtyre GOST-ve dhe se si dhe çfarë të shkruani sipas tyre bëhet e paqartë.
Ky artikull diskuton standardet GOST për shkrimin e dokumentacionit dhe pikat e tyre kryesore.

Cilat janë standardet GOST?

Së pari, duhet të kuptoni se cilat janë standardet GOST. Të gjithë e dinë vetëm se GOST është diçka që u zhvillua nën Unionin dhe ka thjesht një numër të pafund të tyre. Unë nxitoj t'ju siguroj se nuk ka shumë GOST për sektorin e IT, dhe të gjithë, megjithë kohën e krijimit, nuk e kanë humbur rëndësinë e tyre.
Para së gjithash, standardet për shkrimin e dokumentacionit ndahen në dy lloje:

1. Standardet ndërkombëtare (ISO, IEEE Std);
2. GOST ruse ose sovjetike.

Standardet ndërkombëtare
Standardet ndërkombëtare përdoren për të zhvilluar dokumentacion në nivel ndërkombëtar. Si rregull, ato nuk janë të lira, pasi ato nuk janë zhvilluar nga organizatat qeveritare, por, ndryshe nga e jona, ato janë zhvilluar mjaft kohët e fundit. Tema e standardeve ndërkombëtare është shumë e gjerë, kështu që do të diskutohet në një artikull tjetër. Disa standarde që janë të lidhura ngushtë me dokumentacionin e shkruar janë gjithashtu të prekura.
Lista e standardeve kryesore ndërkombëtare për shkrimin e dokumentacionit:

1. IEEE Std 1063-2001 “IEEE Standard for Software User Documentation” - standard për shkrimin e manualeve të përdoruesit;
2. IEEE Std 1016-1998 “Praktika e rekomanduar e IEEE për përshkrimet e dizajnit të softuerit” - një standard për të shkruar një përshkrim teknik të një programi;
3. ISO/IEC FDIS 18019:2004 “Udhëzime për hartimin dhe përgatitjen e dokumentacionit të përdoruesit për softuerin e aplikacionit” është një tjetër standard për shkrimin e manualeve të përdoruesit. Ka një numër të madh shembujsh në këtë dokument. Pra, për të thënë, ky është më shumë si një udhëzues për të shkruar një manual përdorimi. Do të jetë veçanërisht e dobishme për specialistët fillestarë;
4. ISO/IEC 26514:2008 “Kërkesat për projektuesit dhe zhvilluesit e dokumentacionit të përdoruesit” është një tjetër standard për projektuesit dhe zhvilluesit e dokumentacionit të përdoruesit.

Në fakt ka shumë standarde ndërkombëtare dhe secili vend ka të vetin, pasi i njëjti standard mund të mos i përshtatet gjithmonë si kompanive evropiane ashtu edhe aziatike.

Standardet ruse
Standardet ruse zhvillohen në nivel shtetëror. Ata janë të gjithë absolutisht falas dhe secila prej tyre është e lehtë për t'u gjetur në internet. Për të shkruar dokumentacionin për programin, përdoren dy seri GOST 19 dhe 34. Janë këto që do të diskutohen më tej.

Cili është ndryshimi midis serive GOST 19 dhe 34?

Pyetja e parë që lind është se si, në përgjithësi, këto GOST 19 dhe 34 ndryshojnë nga njëri-tjetri.
Në GOST 19.781-90 "Sistemi i unifikuar i dokumentacionit të programit. Software për sistemet e përpunimit të informacionit. Termat dhe përkufizimet" tregohen përkufizimet:

1. Program - të dhëna të destinuara për të kontrolluar komponentë të veçantë të një sistemi të përpunimit të informacionit në mënyrë që të zbatohet një algoritëm specifik.
2. Softueri është një grup programesh të sistemit të përpunimit të informacionit dhe dokumenteve programore të nevojshme për funksionimin e këtyre programeve.

Në GOST 34.003-90 "Teknologjia e informacionit. Një grup standardesh për sistemet e automatizuara. Sisteme të automatizuara. Termat dhe përkufizimet" përkufizimi tregohet:

1. Sistemi i automatizuar (AS) - një sistem i përbërë nga personeli dhe një grup mjetesh automatizimi për aktivitetet e tyre, duke zbatuar teknologjinë e informacionit për të kryer funksionet e vendosura.
   Në varësi të llojit të aktivitetit, për shembull, dallohen llojet e mëposhtme të AS: sistemet e automatizuara të kontrollit (ACS), sistemet e projektimit me ndihmën e kompjuterit (CAD), sistemet e automatizuara të kërkimit shkencor (ASRS) dhe të tjera.

Në varësi të llojit të objektit (procesit) të kontrolluar, sistemet e automatizuara të kontrollit ndahen p.sh. në: sisteme të automatizuara të kontrollit të proceseve teknologjike (ACS), sisteme të automatizuara të kontrollit për ndërmarrje (ACS) etj.
GOST 34 gjithashtu bën një ndarje në llojet e mbështetjes AS:

1. Organizative;
2. Metodike;
3. teknike;
4. Matematikore;
5. Software;
6. informative;
7. Gjuhësor;
8. Ligjore;
9. Ergonomike.

Si rezultat, një sistem i automatizuar nuk është një program, por një kompleks i llojeve të softuerit, duke përfshirë softuerin. AS, si rregull, mbart një zgjidhje organizative për një përdorues dhe klient specifik, dhe Programi mund të krijohet dhe të përsëritet për një numër të madh përdoruesish pa u lidhur me ndonjë ndërmarrje.
Prandaj, nëse po zhvilloni dokumentacion për një program që keni krijuar për një ndërmarrje specifike, atëherë GOST juaj është 34. Nëse jeni duke shkruar dokumente për një program masiv, atëherë GOST juaj është 19.

GOST 34

Seria GOST 34 (GOST 34.xxx Standardet e Teknologjisë së Informacionit) përbëhet nga:

1. GOST 34.201-89 Llojet, plotësia dhe përcaktimet e dokumenteve gjatë krijimit të sistemeve të automatizuara - ky standard përcakton llojet, emrin, plotësinë dhe numrin e dokumenteve. Është një nga dokumentet kryesore të serisë GOST 34. Në fakt, ky është një dokument bazë, kështu që fillestarët duhet së pari të njihen me të.
2. GOST 34.320-96 Konceptet dhe terminologjia për skemat konceptuale dhe bazat e informacionit - ky standard përcakton konceptet dhe termat bazë të skemave konceptuale dhe bazave të informacionit, duke mbuluar zhvillimin, përshkrimin dhe zbatimin e skemave konceptuale dhe bazave të informacionit, manipulimin e informacionit, si dhe përshkrimi dhe zbatimi i procesit të informacionit. Standardi përcakton rolin e diagramit konceptual. Dispozitat e përcaktuara në të kanë natyrë këshilluese dhe mund të përdoren për të vlerësuar sistemet e menaxhimit të bazës së të dhënave (DBMS). Ky dokument nuk përshkruan metoda specifike për përdorimin e mjeteve mbështetëse konceptuale të diagramit. Gjuhët e skemës konceptuale të përshkruara në standard nuk duhet të konsiderohen gjuhë standarde.
3. GOST 34.321-96 Teknologjitë e informacionit. Sistemi i standardeve të bazës së të dhënave. Modeli i referencës së qeverisjes - Ky dokument krijon një model referimi për qeverisjen e të dhënave.
   Modeli i referencës përcakton terminologjinë dhe konceptet e përbashkëta që lidhen me të dhënat e sistemeve të informacionit. Koncepte të tilla përdoren për të përcaktuar shërbimet e ofruara nga sistemet e menaxhimit të bazës së të dhënave ose sistemet e fjalorit të të dhënave.
   Modeli i referencës nuk merr parasysh protokollet për menaxhimin e të dhënave.
   Fusha e modelit të referencës përfshin procese që kanë të bëjnë me menaxhimin e të dhënave të qëndrueshme dhe ndërveprimin e tyre me procese të ndryshme nga kërkesat e një sistemi specifik informacioni, si dhe shërbime të përgjithshme të menaxhimit të të dhënave për përcaktimin, ruajtjen, marrjen, përditësimin, futjen, kopjimin. , rivendosjen dhe transmetimin e të dhënave.
4. GOST 34.601-90 Sisteme të automatizuara. Fazat e krijimit - standardi përcakton fazat dhe fazat e krijimit të një AS.
5. GOST 34.602-89 Specifikimet teknike për krijimin e një sistemi të automatizuar (në vend të GOST 24.201-85) - përcakton përbërjen, përmbajtjen, rregullat për hartimin e dokumentit "Kushtet e referencës për krijimin (zhvillimin ose modernizimin) e sistemit. ”
   Ky dokument është një nga dokumentet e përdorura shpesh në serinë GOST 34. Kur zhvilloni specifikimet teknike për këtë GOST, duhet të mbani mend standardet e tjera, edhe nëse ky dokument nuk përmban referenca për këto standarde.
6. GOST 34.603-92 Teknologjia e informacionit. Llojet e testeve të sistemeve të automatizuara - standardi përcakton llojet e testeve të AS (autonome, komplekse, testet e pranimit dhe funksionimin e provës) dhe kërkesat e përgjithshme për zbatimin e tyre.
7. RD 50-34.698-90 Sisteme të automatizuara. Kërkesat për përmbajtjen e dokumenteve janë një nga dokumentet më të rëndësishme të GOST 34, pasi përshkruan përmbajtjen e pothuajse të gjitha dokumenteve, si dhe një përshkrim të secilit paragraf të dokumentit.
8. GOST R ISO/IEC 8824-3-2002 Teknologjia e informacionit. Versioni i parë i shënimit të sintaksës abstrakte - Ky standard është pjesë e versionit 1 të shënimit të sintaksës abstrakte (ASN.1) dhe vendos një shënim për specifikimin e kufizimeve të përcaktuara nga përdoruesi dhe kufizimeve të tabelës.
9. GOST R ISO/IEC 10746-3-2001 Menaxhimi i të dhënave dhe përpunimi i hapur i shpërndarë.
   Në këtë standard:
   • përcaktohet se si specifikohen sistemet e përpunimit të shpërndarë të hapur (ODP) duke përdorur konceptet e prezantuara në GOST R ISO/IEC 10746-2;
   • Janë identifikuar karakteristikat sipas të cilave sistemet i përkasin sistemeve OPO.

   Standardi krijon një kornizë për koordinimin e zhvillimit të standardeve për sistemet ODP.

10. GOST R ISO/IEC 15271-02 Proceset e ciklit jetësor të softuerit - ky GOST nevojitet më shumë, për mendimin tim, për analistët kur hartojnë dhe modelojnë AS.
    Ky dokument është i dobishëm, nga këndvështrimi im, për qëllime thjesht edukative.
11. GOST R ISO/IEC 15910-2002 Procesi për krijimin e dokumentacionit të përdoruesit për një vegël softuerike - përcakton procesin minimal të kërkuar për krijimin e dokumentacionit të përdoruesit të të gjitha llojeve për një mjet softuerësh që ka një ndërfaqe përdoruesi. Këto lloje përfshijnë dokumentacionin e printuar (për shembull, udhëzuesit e përdoruesit dhe kartat e referimit të shpejtë), dokumentacionin në internet, tekstin e ndihmës dhe sistemet e dokumentacionit në internet.

Pra, bazuar në gjithçka që është shkruar më lart, është e qartë se dokumentet kryesore në GOST 34 janë 3: GOST 34.201-89, RD 50-34.698-90 dhe GOST 34.602-89.
Kur zhvilloni një paketë dokumentacioni, së pari, duhet të hapni GOST 34.201-89 dhe të zgjidhni fazën e krijimit: Drafti i projektimit, Dizajni teknik dhe dokumentacioni i punës. Tjetra, duhet të zgjidhni dokumente për zhvillim që korrespondojnë me fazën e krijimit.

Lista e dokumenteve 34 GOST

Fazë krijim	Titulli i dokumentit	Kodi	Pjesë projekti	Prinadi shtrat te projekti por-vlerëso Noah Doku polic tions	Prinadi shtrat te shfrytëzimit tation noah lart kumen tatimet	Udhëzime shtesë
EP	Fletë e projektimit paraprak	EP*	OSE	—	—	—
	Shënim shpjegues Për projektin paraprak	P1	OSE	—	—	—
EP, TP	Grafiku organizativ	CO	OSE	—	—	Lejohet përfshirja e P3 ose PV në dokument
	Diagrami strukturor i kompleksit mjete teknike	C1*	QE	X	—
	Diagrami i strukturës funksionale	C2*	OSE	—	—	Kur zhvilloni dokumente CO, C1, C2, C3 në fazën ES, lejohet përfshirja e tyre në dokumentin P1
	i specializuar (i ri) mjete teknike	NË 9	QE	X	—	Kur zhvillohet në fazën teknike lejohet të përfshijë për dokumentin P2
	Skema e automatizimit	C3*	QE	X	—	—
	Specifikimet teknike për zhvillim i specializuar (i ri) mjete teknike	—	QE	—	—	Projekti nuk përfshin
TP	Detyrat e zhvillimit sanitare dhe seksione të tjera lidhur me projektin me krijimin e një sistemi	—	QE	X	—	Projekti nuk përfshin
	Fletë projektimi teknik	TP*	OSE	—	—	—
	Lista e artikujve të blerë	VP*	OSE	—	—	—
	Lista e sinjaleve hyrëse dhe të dhëna	NË 1	DHE RRETH	—	—	—
	Lista e sinjaleve dalëse (dokumentet)	NË 2	DHE RRETH	—	—	—
	Lista e detyrave të zhvillimit ndërtimi, elektrike, sanitare dhe seksione të tjera lidhur me projektin me krijimin e një sistemi	NË 3	QE	X	—	Lejohet përfshirja e P2 në dokument
	Shënim shpjegues te projekti teknik	P2	OSE	—	—	Përfshin planin e ngjarjes në përgatitjen e një objekti për hyrje sistemet në funksionim
	Përshkrimi i automatizuar funksione	P3	OSE	—	—	—
	Përshkrimi i cilësimit të detyrës (grup detyrash)	P4	OSE	—	—	Lejohet të përfshihet në dokumentet P2 ose P3
	Përshkrimi i informacionit duke siguruar sistemin	P5	DHE RRETH	—	—	—
	Përshkrimi i organizatës bazë informacioni	P6	DHE RRETH	—	—	—
TP	Përshkrimi i sistemeve të klasifikimit dhe kodimi	P7	DHE RRETH	—	—	—
	Përshkrimi i grupit informacion	P8	DHE RRETH	—	—	—
	Përshkrimi i kompleksit mjete teknike	P9	QE	—	—	Për detyrën lejohet të përfshihet në dokumentin 46 sipas GOST 19.101
	Përshkrimi i softuerit dispozitë	PA	NGA	—	—	—
	Përshkrimi i algoritmit (procedura e projektit)	BP	MO	—	—	Lejohet përfshirja e P2, P3 ose P4 në dokumente
	Përshkrimi i organizimit strukturat	PV	OO	—	—	—
	Plani i paraqitjes	C8	QE	X	—	Lejohet përfshirja e P9 në dokument
	Lista e pajisjeve dhe materialeve	—	QE	X	—	—
	Llogaritja e vlerësimit lokal	B2	OSE	X	—	—
TP, RD	Vlerësimi i projektit besueshmëria e sistemit	B1	OSE	—	—	—
	Vizatim i formës së dokumentit (korniza e videos)	C9	DHE RRETH	—	X	Në fazën TP lejohet përfshijë në dokumente P4 ose P5
RD	Lista e mbajtësve origjinalet	PD*	OSE	—	—	—
	Fletë operative dokumentet	ED*	OSE	—	X	—
	Specifikimi i harduerit	NË 4	QE	X	—	—
	Lista e kërkesave në materiale	NË 5	QE	X	—	—
	Inventari i mediave të makinerisë informacion	VM*	DHE RRETH	—	X	—
	Vargu i hyrjes	NË 6	DHE RRETH	—	X	—
RD	Drejtoria e bazës së të dhënave	NË 7	DHE RRETH	—	X	—
	Përbërja e të dhënave dalëse (mesazhe)	NË 8	DHE RRETH	—	X	—
	Vlerësimet lokale	B3	OSE	X	—	—
	Metodologjia (teknologjia) i automatizuar dizajni	I1	OO	—	X	—
	Udhëzime teknologjike	DHE 2	OO	—	X	—
	Udhëzues Përdorues	I3	OO	—	X	—
	Udhëzime për formimin dhe mirëmbajtjen e bazës së të dhënave (grup i të dhënave)	I4	DHE RRETH	—	X	—
	Udhëzimet e funksionimit të KTS	dmth	QE	—	X	—
	Diagrami i kabllove të jashtme	C4*	QE	X	—	Lejohet të kryhet në në formën e tabelave
	Diagrami i lidhjes postimet e jashtme	C5*	QE	X	—	Njësoj
	Tabela e lidhjeve dhe lidhjeve	C6	QE	X	—	—
	Diagrami i ndarjes së sistemit (strukturore)	E1*	QE	—	—	—
	Vizatim i përgjithshëm	NË*	QE	X	—	—
	Vizatimi i instalimit të pajisjeve teknike	SA	QE	X	—	—
	Diagram skematik	SB	QE	X	—	—
	Diagrami strukturor i kompleksit mjete teknike	C1*	QE	X	—	—
	Plani i vendosjes së pajisjeve dhe instalimeve elektrike	C7	QE	X	—	—
	Përshkrimi i teknologjisë procesi i përpunimit të dhëna (përfshirë telepërpunim)	PG	OO	—	X	—
	Përshkrimi i përgjithshëm i sistemit	PD	OSE	—	X	—
	Programi dhe metodologjia e testimit (komponentët, sistemet e automatizimit, nënsistemet, sistemet)	PM*	OSE	—	—	—
	Forma	FO*	OSE	—	X	—
	Pasaporta	PS*	OSE	—	X	—
*Dokumentet kodi i të cilave është vendosur në përputhje me kërkesat e standardeve ESKD

Shënim për tabelën:

1. Shënimet e mëposhtme përdoren në tabelë:
   • EP - dizajn paraprak;
   • TP - projekt teknik;
   • RD - dokumentacioni i punës;
   • OSE - zgjidhje në të gjithë sistemin;
   • OO - vendime për mbështetjen organizative;
   • TO - zgjidhje për mbështetje teknike;
   • IO - zgjidhje për mbështetje informacioni;
   • Software - zgjidhje softuerike;
   • MO - zgjidhje softuerike.
2. Shenja X tregon se ajo i përket vlerësimeve të projektimit ose dokumentacionit operacional.
3. Nomenklatura e dokumenteve me të njëjtin emër përcaktohet në varësi të vendimeve të projektimit të marra gjatë krijimit të sistemit.

Kur të jetë përcaktuar lista e dokumenteve, atëherë në RD 50-34.698-90 duhet të gjeni dokumentet e përzgjedhura dhe t'i zhvilloni ato në mënyrë rigoroze sipas pikave të përcaktuara. Të gjitha pikat e përmbajtjes që tregohen duhet të jenë në dokument.
Nëse Specifikimet Teknike janë duke u zhvilluar, atëherë menjëherë duhet të hapni GOST 34.602-89 dhe të zhvilloni specifikimet teknike në mënyrë rigoroze në përputhje me pikat.

GOST 19

Seria e GOST-ve 19 (GOST 19.xxx Sistemi i Unifikuar i Dokumentacionit të Programit (USPD)) përbëhet nga:

1. 1. GOST 19.001-77 Dispozitat e përgjithshme - një dokument shumë i përgjithshëm, nuk ka përdorim praktik. Prandaj, mund ta kaloni atë.
   2. GOST 19781-90 Termat dhe përkufizimet - një listë e mirë e përkufizimeve në fushën e softuerit për sistemet e përpunimit të informacionit. Ai nuk përmban asgjë më shumë se përkufizime.
   3. GOST 19.101-77 Llojet e programeve dhe dokumenteve të programit - një nga dokumentet kryesore të 19 GOST. Këtu duhet të filloni të punoni me GOST 19, pasi përmban një listë të plotë dhe përcaktimet e dokumenteve GOST.

Lista e dokumenteve 19 GOST

Kodi	Lloji i dokumentit	Fazat e zhvillimit
		Skicë projekti	teknike projekti	Drafti i punës
				komponent	komplekse
—	Specifikim	—	—
05	Lista e mbajtësve origjinalë	—	—	—
12	Teksti i programit	—	—
13	Përshkrimi i programit	—	—
20	Lista e dokumenteve operative	—	—
30	Forma	—	—
31	Përshkrimi i aplikimit	—	—
32	Udhëzuesi i Programuesit të Sistemit	—	—
33	Udhëzues për programues	—	—
34	Manuali i operatorit	—	—
35	Përshkrimi i gjuhës	—	—
46	Manuali Teknik shërbimi	—	—
51	Programi dhe metodologjia e testimit	—	—
81	Shënim shpjegues			—	—
90-99	Dokumente të tjera

Legjenda:
— dokumenti është i detyrueshëm;
— dokumenti është i detyrueshëm për komponentët që kanë përdorim të pavarur;
— nevoja për të hartuar një dokument përcaktohet në fazën e zhvillimit dhe miratimit të specifikimeve teknike;
- - dokumenti nuk është hartuar.

1. GOST 19.102-77 Fazat e zhvillimit - përmban një përshkrim të fazave të zhvillimit. E dobishme për qëllime edukative. Për mendimin tim, nuk ka shumë përfitime praktike.
2. GOST 19.103-77 Përcaktimet e programeve dhe dokumenteve të programit - përmban një përshkrim të caktimit të një numri (kodi) në një dokument. Edhe pas leximit të këtij GOST, mbeten shumë pyetje se si t'i caktoni të njëjtin numër një dokumenti.
3. GOST 19.104-78 Mbishkrimet kryesore - përcakton format, madhësitë, vendndodhjen dhe procedurën për plotësimin e mbishkrimeve kryesore të fletës së miratimit dhe faqes së titullit në dokumentet e programit të parashikuara nga standardet ESPD, pavarësisht nga metodat e zbatimit të tyre. Meqenëse dokumentet 19 GOST janë hartuar në korniza, ky dokument është shumë i rëndësishëm.
4. GOST 19.105-78 Kërkesa të përgjithshme për dokumentet e programit - përcakton kërkesat e përgjithshme për përgatitjen e dokumenteve të programit. Kërkesat janë shumë të përgjithshme. Si rregull, ky GOST pothuajse nuk përdoret për të zhvilluar një dokument, pasi mjafton një GOST special për një dokument, por për njohuri të përgjithshme është akoma më mirë të shikoni këtë GOST një herë.
5. GOST 19.106-78 Kërkesat për dokumentet e programit të ekzekutuara në formë të shtypur - përmban kërkesa për ekzekutimin e të gjitha dokumenteve 19 GOST.
6. GOST 19.201-78 Specifikimet teknike, kërkesat për përmbajtjen dhe dizajnin - përcakton procedurën për ndërtimin dhe përgatitjen e specifikimeve teknike për zhvillimin e një programi ose produkti softuer.

   Klauzolat e specifikimeve teknike të 34 GOST dhe 19 GOST janë të ndryshme.

7. GOST 19.601-78 Rregulla të përgjithshme për dyfishimin, kontabilitetin dhe ruajtjen - rregulla të përgjithshme për dyfishimin, qarkullimin, kontabilitetin dhe ruajtjen e dokumenteve të programit. GOST përshkruan në disa pika se si të sigurohet që dokumentet të mos humbasin.
8. GOST 19.602-78 Rregulla për dyfishimin, kontabilitetin dhe ruajtjen e dokumenteve të programit, ekzekutimet e printimit. Metoda - shtesë në GOST 19.601-78.
9. GOST 19.603-78 Rregulla të përgjithshme për të bërë ndryshime - përcakton rregulla të përgjithshme për të bërë ndryshime në dokumentet e programit. Në thelb, ai përshkruan një algoritëm të gjatë burokratik për të bërë ndryshime në dokumente.
10. GOST 19.604-78 Rregulla për të bërë ndryshime në dokumentet e programit të bëra në shtyp - përshkruan procedurën e punës dhe plotësimit të Fletës së Regjistrimit të Ndryshimeve.

Një listë e GOST-ve të specializuara, domethënë secila prej tyre përshkruan përmbajtjen dhe kërkesat për një dokument specifik:

1. GOST 19.202-78 Specifikimi. Kërkesat për përmbajtjen dhe dizajnin;
2. GOST 19.301-79 Programi dhe metodologjia e testimit. Kërkesat për përmbajtjen dhe dizajnin;
3. GOST 19.401-78 Teksti i programit. Kërkesat për përmbajtjen dhe dizajnin;
4. GOST 19.402-78 Përshkrimi i programit;
5. GOST 19.403-79 Lista e mbajtësve origjinalë;
6. GOST 19.404-79 Shënim shpjegues. Kërkesat për përmbajtjen dhe dizajnin;
7. Formulari GOST 19.501-78. Kërkesat për përmbajtjen dhe dizajnin;
8. GOST 19.502-78 Përshkrimi i aplikimit. Kërkesat për përmbajtjen dhe dizajnin;
9. GOST 19.503-79 Udhëzues për programuesin e sistemit. Kërkesat për përmbajtjen dhe dizajnin;
10. GOST 19.504-79 Udhëzues për programues. Kërkesat për përmbajtjen dhe dizajnin;
11. GOST 19.505-79 Manuali i operatorit. Kërkesat për përmbajtjen dhe dizajnin;
12. GOST 19.506-79 Përshkrimi i gjuhës. Kërkesat për përmbajtjen dhe dizajnin;
13. GOST 19.507-79 Deklarata e dokumenteve operative;
14. Manuali i mirëmbajtjes GOST 19.508-79. Kërkesat për përmbajtjen dhe dizajnin.

Procedura për të punuar me 19 GOST:

1. Në GOST 19.101-77, zgjidhni një dokument dhe kodin e tij sipas fazës së zhvillimit.
2. Sipas GOST 19.103-77, caktoni një numër në dokument.
3. Pastaj, sipas GOST 19.104-78 dhe 19.106-78, hartoni një dokument.
4. Nga lista e specializuar e GOST-ve, duhet të zgjidhni atë që korrespondon me dokumentin që po zhvillohet.

konkluzioni

GOST nuk është e frikshme dhe e lehtë! Gjëja kryesore është të kuptoni se çfarë duhet të shkruhet dhe cili GOST përdoret për këtë. GOST-et tona kryesore 19 dhe 34 për shkrimin e dokumentacionit janë shumë të vjetra, por ende të rëndësishme edhe sot e kësaj dite. Shkrimi i dokumentacionit sipas standardit eliminon shumë çështje midis kontraktorit dhe klientit. Rrjedhimisht, kursen kohë dhe para.

Data e prezantimit 01/01/92

Ky standard zbatohet për sistemet e automatizuara (AS) të përdorura në lloje të ndryshme aktivitetesh (kërkim, dizajn, menaxhim, etj.), Duke përfshirë kombinimet e tyre të krijuara në organizata, shoqata dhe ndërmarrje (në tekstin e mëtejmë të referuara si organizata).

Standardi përcakton fazat dhe fazat e krijimit të një AS. Shtojca 1 tregon përmbajtjen e punës në çdo fazë.

1. Dispozitat e Përgjithshme

2. Fazat dhe fazat e krijimit të një AS

Shtojca 1 (për referencë)

Shtojca 2 (referenca)

1. DISPOZITA TË PËRGJITHSHME

1.1. është një grup punimesh të porositura në kohë, të ndërlidhura, të kombinuara në faza dhe faza, zbatimi i të cilave është i nevojshëm dhe i mjaftueshëm për të krijuar një sistem të automatizuar që plotëson kërkesat e specifikuara.

1.2. Fazat dhe fazat e krijimit të një AS dallohen si pjesë e procesit të krijimit për arsye të planifikimit racional dhe organizimit të punës që përfundon me një rezultat të caktuar.

1.3. Puna për zhvillimin e AS kryhet sipas fazave dhe hapave të përdorur për krijimin e AS.

1.4. Përbërja dhe rregullat për kryerjen e punës në fazat dhe fazat e përcaktuara nga ky standard përcaktohen në dokumentacionin përkatës të organizatave të përfshira në krijimin e llojeve specifike të termocentraleve bërthamore.

Lista e organizatave të përfshira në krijimin e centraleve bërthamore është dhënë në Shtojcën 2.

2. FAZA DHE FAZA E KRIJIMIT TË AS

2.1. Fazat dhe fazat e krijimit të një AS tregohen përgjithësisht në tabelë.

Fazat	Fazat e punës
1. Formimi i kërkesave për folësit	1.1. Inspektimi i objektit dhe arsyetimi për nevojën e krijimit të një centrali bërthamor
	1.2. Formimi i kërkesave të përdoruesve për folësit
	1.3. Përgatitja e një raporti për punën e kryer dhe një aplikim për zhvillimin e një AS (specifikime taktike dhe teknike)
2. Zhvillimi i konceptit të AC	2.1. Studimi i objektit
	2.2. Kryerja e punës së nevojshme kërkimore
	2.3. Zhvillimi i opsioneve të konceptit AC dhe përzgjedhja e një opsioni koncepti AC që plotëson kërkesat e përdoruesit
	2.4. Hartimi i një raporti për punën e kryer
3. Termat e referencës	3.1. Zhvillimi dhe miratimi i specifikimeve teknike për krijimin e centraleve bërthamore
4. Draft dizajn	4.1. Zhvillimi i zgjidhjeve të projektimit paraprak për sistemin dhe pjesët e tij
	4.2. Zhvillimi i dokumentacionit për sistemin e altoparlantëve dhe pjesët e tij
5. Projektim teknik	5.1. Zhvillimi i zgjidhjeve të projektimit për sistemin dhe pjesët e tij
	5.2. Zhvillimi i dokumentacionit për sistemin e altoparlantëve dhe pjesët e tij
	5.3. Zhvillimi dhe ekzekutimi i dokumentacionit për furnizimin e produkteve për plotësimin e NPP-së dhe (ose) kërkesat teknike (specifikimet teknike) për zhvillimin e tyre
	5.4. Zhvillimi i detyrave të projektimit në pjesët ngjitur të projektit të objektit të automatizimit
6. Dokumentacioni i punës	6.1. Zhvillimi i dokumentacionit të punës për sistemin dhe pjesët e tij
	6.2. Zhvillimi ose përshtatja e programeve
7. Inputi dhe veprimi	7.1. Përgatitja e objektit të automatizimit për vënien në punë të NPP
	7.2. Trajnimi i personelit
	7.3. Set i plotë i altoparlantëve me produktet e furnizuara (softuer dhe harduer, softuer dhe sisteme harduerike, produkte informacioni)
	7.4. Punimet e ndertimit dhe instalimit
	7.5. Punimet e komisionimit
	7.6. Kryerja e testeve paraprake
	7.7. Kryerja e operacionit provë
	7.8. Kryerja e testeve të pranimit
8. Mbështetje AC	8.1. Kryerja e punës në përputhje me detyrimet e garancisë
	8.2. Shërbimi pas garancisë

2.2. Fazat dhe etapat e kryera nga organizatat pjesëmarrëse në krijimin e centraleve bërthamore përcaktohen në kontrata dhe specifikime teknike bazuar në këtë standard.

Është e mundur që në të gjitha fazat të përjashtohen fazat e "Dizajnimit të Skicave" dhe fazat individuale të punës, të kombinohen fazat "Dizajnimi teknik" dhe "Dokumentacioni i punës" në një fazë "Dizajnimi i Detajuar Teknik". Në varësi të specifikave të AS që krijohet dhe kushteve për krijimin e tyre, lejohet të kryhen faza individuale të punës përpara përfundimit të fazave të mëparshme, ekzekutimit paralel të fazave të punës ose përfshirjes së fazave të reja të punës.

SHTOJCA 1.Për referencë

1. Në fazën 1.1 “Inspektimi i objektit dhe justifikimi i nevojës për krijimin e një TEC-i”, në rastin e përgjithshëm, kryhet si më poshtë:

• mbledhja e të dhënave për objektin e automatizimit dhe llojet e aktiviteteve të kryera;
• vlerësimi i cilësisë së funksionimit të objektit dhe llojeve të aktiviteteve të kryera, identifikimi i problemeve që mund të zgjidhen duke përdorur mjete automatizimi;
• vlerësimi (teknik, ekonomik, social, etj.) i fizibilitetit të krijimit të një NPP.

2. Në fazën 1.2 “formimi i kërkesave të përdoruesit për folësit” kryhet si më poshtë:

• përgatitja e të dhënave fillestare për formimin e kërkesave për sistemin e automatizuar (karakteristikat e objektit të automatizimit, përshkrimi i kërkesave për sistemin, kufizimet në kostot e pranueshme për zhvillimin, vënien në punë dhe funksionimin, efekti i pritur nga sistemi, kushtet për krijimin dhe funksionimin e sistemit);
• formulimi dhe ekzekutimi i kërkesave të përdoruesve për folësit.

3. Në fazën 1.3 “Plotësimi i një raporti për punën e kryer dhe një aplikim për zhvillimin e një AS (specifikimet taktike dhe teknike)”, një raport për punën e kryer në këtë fazë dhe një aplikim për zhvillimin e një AS (taktike dhe specifikimet teknike) ose një dokument tjetër që e zëvendëson të plotësohen me përmbajtje të ngjashme.

4. Në fazat 2.1 "Studimi i objektit" dhe 2.2 "Kryerja e punës së nevojshme kërkimore", organizata e zhvillimit kryen një studim të hollësishëm të objektit të automatizimit dhe punës së nevojshme kërkimore (R&D) në lidhje me gjetjen e mënyrave dhe vlerësimin e mundësisë së duke zbatuar kërkesat e përdoruesve, harton dhe miraton raporte kërkimore.

5. Në fazën 2.3 “Zhvillimi i opsioneve për konceptin AS dhe përzgjedhja e një opsioni për konceptin AS që plotëson kërkesat e përdoruesit”, në rastin e përgjithshëm, opsionet alternative për konceptin e AS që po krijohet dhe planet për zbatimin e tyre janë. zhvilluar; vlerësimi i burimeve të nevojshme për zbatimin dhe mirëmbajtjen e tyre; vlerësimi i avantazheve dhe disavantazheve të secilit opsion; krahasimi i kërkesave të përdoruesit dhe karakteristikave të sistemit të propozuar dhe përzgjedhja e opsionit optimal; përcaktimin e procedurës për vlerësimin e cilësisë dhe kushteve për pranimin e sistemit; vlerësimi i efekteve të marra nga sistemi.

6. Në fazën 2.4 "Përgatitni një raport mbi punën e kryer", përgatitni dhe hartoni një raport që përmban një përshkrim të punës së kryer në fazë, një përshkrim dhe justifikim të versionit të propozuar të konceptit të sistemit.

7. Në fazën 3.1 “Zhvillimi dhe miratimi i specifikimeve teknike për krijimin e një centrali bërthamor”, zhvillimi, ekzekutimi, koordinimi dhe miratimi i specifikimeve teknike për termocentralin bërthamor dhe, nëse është e nevojshme, specifikimet teknike për pjesë të centralit bërthamor. janë kryer termocentrali.

8. Në fazën 4.1 “Zhvillimi i zgjidhjeve të projektimit paraprak për sistemin dhe pjesët e tij” përcaktojnë: funksionet e AS; funksionet e nënsistemeve, qëllimet dhe efektet e tyre; përbërja e komplekseve të detyrave dhe detyrave individuale; konceptet e bazës së informacionit, struktura e saj e zgjeruar; funksionet e sistemit të menaxhimit të bazës së të dhënave; përbërja e sistemit kompjuterik; funksionet dhe parametrat e softuerit bazë.

9. Në fazën 5.1 “Zhvillimi i zgjidhjeve të projektimit për sistemin dhe pjesët e tij”, ato sigurojnë zhvillimin e zgjidhjeve të përgjithshme për sistemin dhe pjesët e tij, strukturën funksionale-algoritmike të sistemit, funksionet e personelit dhe strukturës organizative, struktura e mjeteve teknike, algoritmeve për zgjidhjen e problemeve dhe gjuhëve të përdorura, për organizimin dhe mbajtjen e një baze informacioni, një sistem klasifikimi dhe kodimi të informacionit, në softuer.

10. Në fazat 4.2 dhe 5.2 “Hartimi i dokumentacionit për NPP-në dhe pjesët e tij”, zhvillimi, ekzekutimi, bashkërendimi dhe miratimi i dokumentacionit kryhet në masën e nevojshme për të përshkruar tërësinë e vendimeve të projektimit të marra dhe të mjaftueshme për të ardhmen. zbatimi i punës për krijimin e NPP-së. Llojet e dokumenteve - sipas GOST 34.201.

11. Në fazën 5.3 "Zhvillimi dhe ekzekutimi i dokumentacionit për furnizimin me produkte për plotësimin e NPP-ve dhe (ose) kërkesat teknike (specifikimet teknike) për zhvillimin e tyre", kryhet përgatitja dhe ekzekutimi i dokumentacionit për furnizimin e produkteve për kompletimin e NPP-ve. ; përcaktimin e kërkesave teknike dhe hartimin e specifikimeve teknike për zhvillimin e produkteve që nuk prodhohen në masë.

12. Në fazën 5.4 "Zhvillimi i detyrave të projektimit në pjesët ngjitur të projektit të automatizimit", ata zhvillojnë, formalizojnë, koordinojnë dhe miratojnë detyrat e projektimit në pjesët ngjitur të projektit të objektit të automatizimit për kryerjen e punëve ndërtimore, elektrike, sanitare dhe punë të tjera përgatitore. te krijimit AC.

13. Në fazën 6.1 “Zhvillimi i dokumentacionit të punës për sistemin dhe pjesët e tij”, hartohet dokumentacioni i punës që përmban të gjithë informacionin e nevojshëm dhe të mjaftueshëm për të siguruar zbatimin e punës për vënien në punë dhe funksionimin e TEC-it, si dhe mirëmbajtjen. nivelin e karakteristikave (cilësisë) operative të sistemit në përputhje me vendimet e miratuara të projektimit, ekzekutimin, koordinimin dhe miratimin e tij. Llojet e dokumenteve - sipas GOST 34.201.

14. Në fazën 6.2 "Zhvillimi ose përshtatja e programeve", zhvillohen programe dhe softuer të sistemit, përzgjedhja, përshtatja dhe (ose) lidhja e softuerit të blerë dhe zhvillimi i dokumentacionit të programit në përputhje me GOST 19.101.

15. Në fazën 7.1 "Përgatitja e objektit të automatizimit për vënien në punë të impiantit", kryhet puna për përgatitjen organizative të objektit të automatizimit për vënien në punë të impiantit, duke përfshirë: zbatimin e zgjidhjeve të projektimit për strukturën organizative të uzinës. bimë; sigurimi i departamenteve të objektit menaxhues me materiale udhëzuese dhe metodologjike; zbatimi i klasifikuesve të informacionit.

16. Në fazën 7.2 “Trajnimi i personelit”, personeli trajnohet dhe kontrollohet aftësia e tyre për të siguruar funksionimin e impiantit.

17. Në fazën “Plotësimi i altoparlantëve me produktet e furnizuara”, sigurojnë marrjen e komponentëve, materialeve dhe produkteve instaluese serike dhe individuale të prodhimit. Është kryer kontrolli i cilësisë së hyrjes.

18. Në fazën 7.4 “Punimet e ndërtimit dhe instalimit” kryhen: punimet për ndërtimin e godinave (lokaleve) të specializuara për të akomoduar pajisjet teknike dhe personelin e NPP-ve; ndërtimi i kanaleve kabllore; kryerja e punës për instalimin e pajisjeve teknike dhe linjave të komunikimit; testimi i pajisjeve teknike të instaluara; dorëzimi i pajisjeve teknike për vënien në punë.

19. Në fazën 7.5 “Kompionimi”, kryejnë rregullime autonome të harduerit dhe softuerit, ngarkojnë informacionin në bazën e të dhënave dhe kontrollojnë sistemin për mirëmbajtjen e tij; konfigurim gjithëpërfshirës i të gjitha mjeteve të sistemit.

20. Në fazën 7.6 “Kryerja e testeve paraprake” kryhet:

• testimi i altoparlantëve për funksionueshmërinë dhe përputhshmërinë me specifikimet teknike në përputhje me programin dhe metodologjinë e testeve paraprake;
• zgjidhja e problemeve dhe bërja e ndryshimeve në dokumentacionin e NPP-së, duke përfshirë dokumentacionin operacional në përputhje me raportin e testimit;
• ekzekutimi i certifikatës së pranimit të NPP-së për funksionim prove.

21. Në fazën 7.7 “Kryerja e funksionimit provë”, kryhet operimi provë i NPP-së; analiza e rezultateve të provës së funksionimit të NPP-së; modifikimi (nëse është e nevojshme) i softuerit AS; rregullim shtesë (nëse është e nevojshme) të pajisjeve teknike të NPP; ekzekutimi i një certifikate të përfundimit të operacionit provues.

22. Në fazën 7.8 “Kryerja e testeve të pranimit” kryhet si më poshtë:

• testimi për pajtueshmërinë me specifikimet teknike në përputhje me programin dhe metodologjinë e testimit të pranimit;
• analiza e rezultateve të testit AS dhe eliminimi i mangësive të identifikuara gjatë testimit;
• ekzekutimin e aktit të pranimit të NPP-së për funksionim të përhershëm.

23. Në fazën 8.1 “Kryerja e punës në përputhje me detyrimet e garancisë”, kryhet puna për eliminimin e mangësive të konstatuara gjatë funksionimit të NPP-së gjatë periudhave të garancisë të përcaktuara, si dhe për të bërë ndryshimet e nevojshme në dokumentacionin për termocentralin.

24. Në fazën 8.2 “Shërbimi pas garancisë” kryhet puna në:

• analiza e funksionimit të sistemit;
• identifikimin e devijimeve të karakteristikave aktuale operative të NPP-së nga vlerat e projektimit;
• përcaktimi i shkaqeve të këtyre devijimeve;
• eliminimin e mangësive të identifikuara dhe sigurimin e stabilitetit të karakteristikave operacionale të NPP-ve;
• duke bërë ndryshimet e nevojshme në dokumentacionin për folësit.

SHTOJCA 2. Referenca

LISTA E ORGANIZATAVE PJESËMARRËSE NË KRIJIMIN E AU

1. Organizata e klientit (përdoruesi) për të cilin do të krijohet TEC-i dhe që siguron financimin, pranimin e punës dhe funksionimin e NPP-së, si dhe zbatimin e punimeve individuale për krijimin e NPP-së.

2. Një organizatë zhvillimi që kryen punë për krijimin e një AS, duke i ofruar klientit një sërë shërbimesh shkencore dhe teknike në faza dhe faza të ndryshme të krijimit, si dhe duke zhvilluar dhe furnizuar softuer dhe harduer të ndryshëm për AS.

3. Një organizatë furnizuese që prodhon dhe furnizon softuer dhe pajisje sipas porosisë së zhvilluesit ose klientit.

4. Organizata-projektues i përgjithshëm i objektit të automatizimit.

5. Organizatat e projektimit të pjesëve të ndryshme të projektit të objektit të automatizimit për kryerjen e punëve ndërtimore, elektrike, sanitare dhe të tjera përgatitore që lidhen me krijimin e termocentralit bërthamor.

6. Ndërtimi, instalimi, vënia në punë dhe organizata të tjera.

Shënime:

1. Në varësi të kushteve për krijimin e NPP-së, janë të mundshme kombinime të ndryshme të funksioneve të klientit, zhvilluesit, furnizuesit dhe organizatave të tjera të përfshira në krijimin e NPP.

2. Fazat dhe fazat e punës që ata kryejnë për krijimin e AS përcaktohen në bazë të këtij standardi.

TË DHËNAT E INFORMACIONIT

1. ZHVILLUAR DHE PARAQITUR nga Komiteti Shtetëror i BRSS për Menaxhimin dhe Standardet e Cilësisë së Produkteve

Zhvilluesit

Yu.H. Vermishev, doktor i inxhinierisë. shkencat; Ya.G. Vilenchik; NË DHE. Voropaev, Doktor i Inxhinierisë. shkencat; L.M. Seidenberg, Ph.D. teknologjisë. shkencat; Yu.B. Irz, Ph.D. teknologjisë. shkencat; V.D. Kostyukov, Dr. teknologjisë. shkencat; M.A. Labutin, kond. teknologjisë. shkencat; N.P. Leskovskaya; I.S. Mityaev; V.F. Popov (udhëheqës i temës); S.V. Garshina; A.I. shurdhim; JUG. Zhukov, Dr. shkencat; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, Dr. shkencat; A.A. Kloçkov; V.Yu. Korolev; NË DHE. Makhnach, Ph.D. teknologjisë. shkencat; S.B. Mikhalev, Doktor i Inxhinierisë. shkencat; V.N. Petrikeviç; V.A. Rakhmanov, Dr. ekon. shkencat; A.A. Ratkoviç; R.S. Sedegov, doktor i ekonomisë. shkencat; N.V. Stepanchikova; ZNJ. Surovet; A.V. Flegentov; L.O. Khvilevsky, Ph.D. teknologjisë. shkencat; QV. Chistov, Dr. ekon. shkencat

2. MIRATUAR DHE HYRË NË FUQI me Rezolutën e Komitetit Shtetëror të BRSS për Menaxhimin e Cilësisë së Produkteve dhe Standardet e datës 29 Dhjetor 1990 Nr. 3469

M. Ostrogorsky, 2008

Për të zbatuar me sukses GOST 34, është e nevojshme të kuptohet se si, nga pikëpamja e këtij grupi standardesh, është strukturuar sistemi i automatizuar. Përndryshe, tek i ftuari nuk do të shohim asgjë përveç një liste të gjatë dokumentesh me emra misterioz, dhe kërkesat për përmbajtjen e tyre do të na bindin edhe një herë se në shumë urtësi ka shumë trishtim. Prandaj, përpara se të diskutojmë vetë dokumentet, duhet të kuptojmë se çfarë është lënda e dokumentacionit.

Sistemi i automatizuar, funksionet dhe detyrat e tij

Përkufizimi i një sistemi të automatizuar

GOST 34.003-90 përmban përkufizimin e mëposhtëm të një sistemi të automatizuar: një sistem i përbërë nga personel dhe një grup mjetesh automatizimi për aktivitetet e tyre, duke zbatuar teknologjinë e informacionit për të kryer funksionet e vendosura. Çfarë do të thotë në të vërtetë ky përkufizim? Këtë mund ta kuptoni vetëm duke lexuar përkufizime të tjera të këtij standardi dhe duke i krahasuar ato me njëri-tjetrin. Çfarë do të bëjmë tani?

Qëllimet e aktivitetit

Një sistem i automatizuar mund të ekzistojë vetëm kur ka personel të angazhuar në një aktivitet specifik. Në mënyrë tipike, ne po flasim për aktivitete, rezultatet e të cilave janë të dobishme për dikë, pavarësisht nga mjetet e përdorura. Për shembull, unë shkoj në arkën e teatrit për një biletë dhe jam shumë i lumtur nëse arkëtari ma shkruan me stilolaps në një formular, për sa kohë që më lejojnë të hyj në teatër duke e përdorur atë. Arkëtarit, në përgjithësi, gjithashtu nuk i intereson se si është bërë saktësisht bileta. Ajo do të jetë mirë me çdo metodë për sa kohë që nuk është shumë intensive dhe i jep asaj mundësinë të më shesë një biletë. Me fjalë të tjera, ajo dhe unë kemi një qëllim të përbashkët. GOST 34.003-90 përdor termin për ta treguar atë qëllimi i veprimtarisë. Sa herë që një tjetër shikues del nga dritarja me biletë në dorë dhe teatri bëhet pak më i pasur, ky synim i aktivitetit realizohet.

Funksionet e sistemit të automatizuar

Mund të ketë (dhe, si rregull, ka) disa qëllime për një aktivitet. Çdo rezultat i dobishëm jashtë vetë aktivitetit mund të konsiderohet si qëllim i tij. Pra, nëse arkëtarja jo vetëm shet bileta, por përgatit edhe një raport shitjeje për eprorët e saj në fund të ditës së punës, hartimi i një raporti ditor mund të konsiderohet si një qëllim tjetër aktiviteti.

Nëse vendosim një kompjuter dhe një printer në tryezën e arkëtarit dhe shefi i arkëtarit lëshon një urdhër që ajo të shtypë biletat dhe raportet në një përpunues teksti dhe t'i printojë ato në printer, atëherë do të marrim një sistem të automatizuar. Sipas ideve moderne, është shumë primitiv; zyrtarisht do të kënaqë përkufizimin Gost. Ju lutemi vini re se qëllimet e aktivitetit nuk kanë ndryshuar si rezultat i zbatimit të sistemit të automatizuar, ka ndryshuar vetëm mënyra e arritjes së tyre. Ajo që bëhej më parë "ashtu si kjo" tani bëhet brenda kornizës së një sistemi të automatizuar. Grupi i veprimeve të një sistemi të automatizuar që synon arritjen e një qëllimi specifik, sipas GOST 34.003-90, quhet i tij funksionin. Shënim: pavarësisht se si e shikoni, stafi konsiderohet pjesë e sistemit.

Funksioni i një sistemi të automatizuar është një koncept themelor në GOST 34. Një sistem i automatizuar konsiderohet, para së gjithash, si shuma e funksioneve të tij dhe vetëm atëherë si një grup "softuerësh" dhe "hardware". Gjëja më e rëndësishme është se çfarë bën sistemi, dhe ajo nga e cila përbëhet është dytësore.

Sa më sipër mund ta çojë lexuesin në përfundimin se çdo qëllim i aktivitetit në një sistem të automatizuar korrespondon me një dhe vetëm një funksion. Një sistem i tillë është i lehtë të imagjinohet, por praktika është më e larmishme. Nga njëra anë, aktivitetet nuk janë gjithmonë plotësisht të automatizuara. Edhe pas zbatimit të një sistemi të automatizuar, disa qëllime duhet të arrihen manualisht. Nga ana tjetër, duke qenë se i njëjti rezultat në kushte të ndryshme mund të arrihet në mënyra të ndryshme, disa funksione mund të synojnë një qëllim aktiviteti në një sistem të automatizuar, për shembull, shitja e një bilete në arkë dhe shitja e një bilete mbi Internet. Përveç kësaj, çdo sistem i automatizuar kërkon mirëmbajtje të caktuar, kështu që ne duhet të prezantojmë konceptin e një funksioni ndihmës. Një shembull tipik është krijimi i një kopje rezervë të të dhënave.

Detyrat e sistemit të automatizuar

Në rastin e përgjithshëm, gjatë kryerjes së një funksioni, një pjesë e punës kryhet nga stafi, dhe një pjesë nga teknologjia; le të themi, një biletë printohet automatikisht dhe i jepet blerësit manualisht nga arkëtari. Një sekuencë veprimesh automatike (sic) që çojnë në një rezultat të një lloji të caktuar quhet në GOST 34.003-90 detyrë.

Këtu përkufizimi i problemit nuk citohet plotësisht, por tani për tani kjo do të na mjaftojë; në fund të fundit, nuk është turp që askush ta lexojë standardin vetë. Është e rëndësishme që një detyrë të jetë pjesa më e qartë e formalizuar e një aktiviteti të automatizuar. Mund të imagjinoni një funksion që kryhet plotësisht automatikisht, siç është kopja rezervë e përmendur më sipër. Në këtë rast, funksioni reduktohet në një detyrë.

E njëjta detyrë mund të zgjidhet duke kryer funksione të ndryshme. Për shembull, nëse një sistem i automatizuar ka disa funksione për shitjen e një bilete, atëherë ekzekutimi i secilit prej tyre në një moment mund të kërkojë printimin e biletës.

Përbërja e sistemit të automatizuar

Nënsistemet

Nëse sistemi i automatizuar është mjaft kompleks, ai ndahet në nënsistemet. Çfarë do të thotë, mjaft komplekse, është mjaft e vështirë të thuhet. Teoria e sistemeve përshkruan nivele dhe kritere të ndryshme të kompleksitetit. Në praktikë, nevoja për të ndarë disa nënsisteme në një sistem të automatizuar shpesh shkaktohet nga arsye organizative dhe financiare, për shembull, nënsistemet zhvillohen dhe vihen në veprim në mënyrë sekuenciale.

Megjithëse në GOST 34 termi nënsistem përdoret shumë herë, duket se nuk ka një përkufizim zyrtar të këtij koncepti atje. Përvoja sugjeron që një nënsistem është një pjesë e një sistemi të automatizuar që gjithashtu plotëson përkufizimin e një sistemi të automatizuar, në veçanti, ai ka funksione të plota.

Duke iu rikthyer shembullit të biletave, mund të vendosim që sistemi i automatizuar përbëhet nga dy nënsisteme: një nënsistem biletash dhe një nënsistem raportimi ditor. Le të biem dakord, për qartësi më të madhe, që arkëtari i shkruan biletat në një redaktues teksti dhe raportet në fletëllogaritëse.

Komponentët

Identifikimi i qëllimeve të veprimtarisë, funksioneve të një sistemi të automatizuar dhe, nëse është e nevojshme, nënsistemeve të tij është kryesisht subjektiv dhe varet nga këndvështrimi i subjektit që vendosi ta bëjë këtë. Nëse ndonjë rezultat është i rëndësishëm në kontekstin e problemit që zgjidhet, ne mund ta konsiderojmë atë një qëllim, përndryshe ta shpërfillim atë. Ne gjithashtu do ta ndajmë sistemin e automatizuar në nënsisteme në një mënyrë të përshtatshme për ne, për sa kohë që vendimet tona nuk bien ndesh me përmbajtjen e këtij koncepti.

Komponentët janë pjesët nga të cilat ne, në realitet objektiv, ndërtojmë një sistem të automatizuar. Sistemi fizikisht përbëhet nga komponentët e tij, kështu që ndarja e një sistemi të automatizuar në komponentë është më objektivi.

Ne blejmë çdo komponent, e instalojmë dhe e lidhim atë (nëse është pajisje), e instalojmë (nëse është program) dhe e mirëmbajmë veçmas nga komponentët e tjerë. Blemë dhe vendosëm një kompjuter në tavolinë - është një komponent. Ne zhvilluam një redaktues të veçantë teksti për shtypjen e biletave - një komponent tjetër. Tabelat e shkarkuara falas nga Interneti - përsëri një komponent. Dhe madje edhe vetë arkëtarja, në një farë mënyre, është gjithashtu një komponent i sistemit të automatizuar.

Përbërja përbërëse e një sistemi të automatizuar është shumë e rëndësishme nga pikëpamja e dokumentacionit të tij, pasi dokumentacioni teknik për sistemin si i tillë dhe për komponentët trajtohet ndryshe. Në përgjithësi, ai duhet të zhvillohet nga njerëz të ndryshëm dhe është projektuar me standarde të ndryshme në varësi të llojit të komponentit.

Llojet e kolateralit

Një nga konceptet më të vështira për një përdorues fillestar të GOST 34 është lloji i sigurisë. Çfarë lloj sigurie është kjo? A mund ta shihni apo prekni atë? Shitet apo blej?

Çdo lloj softueri kombinon komponentë ose zgjidhje teknike të një natyre të caktuar. GOST 34 përmend shumë lloje të ndryshme sigurie; ne nuk do të përshkruajmë secilën prej tyre në mënyrë sekuenciale këtu, por do të rendisim vetëm më të dukshmet:

• mbështetje informative - të gjitha të dhënat dhe meta të dhënat me të cilat funksionon sistemi;
• softuer - të gjitha programet që janë pjesë e sistemit;
• mbështetje teknike - të gjitha mjetet teknike (me fjalë të tjera, pajisjet, pajisjet) që janë pjesë e sistemit.

Le të përsërisim edhe një herë, këto nuk janë të gjitha llojet e sigurisë. As që mund të themi me siguri se ato janë më të rëndësishmet. Për shembull, mbështetja metrologjike ka një rëndësi të madhe për sistemet e automatizuara të kontrollit të procesit (APCS). Shumë sisteme të automatizuara kërkojnë mbështetje komplekse matematikore dhe gjuhësore. Por është e vështirë të imagjinohet një sistem i automatizuar që do të ishte plotësisht i lirë nga një nga tre llojet e mbështetjes të listuara më sipër (ushtrim: provojeni).