Pojmy a definície automatizovaných systémov. Požiadavky na organizačné zabezpečenie automatizovaných riadiacich systémov

GOST 24.104-85 Automatizované riadiace systémy. Všeobecné požiadavky (oddiel 3 nahradený GOST 34.603-92) Oddiel 3 nahradený GOST 34.603-92 Výnosom Štátneho výboru pre normy ZSSR z 20. decembra 1985 č. 4632 bol stanovený dátum zavedenia

od 01.01.1987

Táto norma platí pre automatizované riadiace systémy (ACS) všetkých typov (okrem národných) a stanovuje všeobecné požiadavky na ACS ako celok, funkcie ACS, školenie personálu a typy podpory ACS, bezpečnosť a ergonómiu, typy a postupy skúšania pri uvádzaní ACS do prevádzky, úplnosť automatizovaného riadiaceho systému, záruky.

Norma nestanovuje požiadavky na automatizované riadiace systémy určené špecifikami objektov riadenia. Tieto požiadavky sú formulované v technických špecifikáciách pre tvorbu alebo vývoj každého automatizovaného riadiaceho systému alebo v iných regulačných a technických dokumentoch zákazníckeho oddelenia automatizovaného riadiaceho systému.

Dodatočné požiadavky na automatizované systémy riadenia technologických procesov, automatizované systémy riadenia pre podniky, priemyselné a vedecko-výrobné združenia a priemyselné automatizované systémy riadenia sú ustanovené v povinných prílohách 1-3, resp.

Referenčná príloha 4 poskytuje vysvetlenia niektorých pojmov používaných v norme.

1. POŽIADAVKY NA ACS

1.1. Požiadavky na automatizovaný riadiaci systém vo všeobecnosti

1.1.1. Automatizovaný riadiaci systém akéhokoľvek typu musí spĺňať požiadavky tejto normy, požiadavky technických špecifikácií na jeho vytvorenie alebo vývoj (ďalej len technické špecifikácie pre automatizovaný riadiaci systém), ako aj požiadavky regulačných a technické dokumenty platné v oddelení objednávateľa automatizovaného riadiaceho systému.

1.1.2. Uvedenie automatizovaných riadiacich systémov do prevádzky by malo viesť k užitočným technickým, ekonomickým, sociálnym alebo iným výsledkom, napríklad:

• zníženie počtu riadiacich pracovníkov;
• zlepšenie kvality fungovania riadiaceho objektu;
• zlepšenie kvality riadenia a pod.

1.1.3. Konkrétny obsah požiadaviek podľa ods. 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 sú inštalované v technických špecifikáciách pre automatizovaný riadiaci systém.

1.1.4. Automatizovaný riadiaci systém musí zabezpečovať dosiahnutie cieľov jeho tvorby (vývoja) stanovených v zadávacích podmienkach pre automatizovaný riadiaci systém.

1.1.5. Automatizovaný riadiaci systém musí zabezpečiť kompatibilitu medzi svojimi časťami, ako aj s automatizovanými systémami (AS) prepojenými s týmto automatizovaným riadiacim systémom.

V prípadoch, keď je na báze počítačovej siete vytvorený automatizovaný riadiaci systém alebo súbor automatizovaných riadiacich systémov (AS), musia byť na zabezpečenie kompatibility medzi prvkami takejto siete použité viacúrovňové systémy interakčných protokolov.

1.1.6. Automatizovaný riadiaci systém ako celok a všetky druhy jeho podpory musia byť prispôsobené modernizácii, rozvoju a rozširovaniu v medziach požiadaviek uvedených v zadávacích podmienkach pre automatizovaný riadiaci systém.

1.1.7. Spoľahlivosť automatizovaného riadiaceho systému ako celku a každej jeho automatizovanej funkcie musí byť dostatočná na dosiahnutie stanovených cieľov prevádzky systému za daných aplikačných podmienok.

1.1.8. Adaptabilita automatizovaného riadiaceho systému musí byť dostatočná na dosiahnutie stanovených cieľov jeho prevádzky v danom rozsahu zmien aplikačných podmienok.

1.1.9. ACS musí zabezpečiť monitorovanie správneho výkonu automatizovaných funkcií a diagnostiky s uvedením miesta, typu a príčiny narušenia správneho fungovania ACS.

1.1.10. ACS, ktoré majú meracie kanály, musia mať schopnosť kontrolovať metrologické charakteristiky meracích kanálov.

1.1.11. Automatizovaný riadiaci systém musí zabezpečovať ochranné opatrenia pred nesprávnym konaním personálu vedúcim k havarijnému stavu objektu alebo riadiaceho systému, pred náhodnými zmenami a zničením informácií a programov, ako aj pred neoprávneným zásahom.

1.1.12. Všetky informácie vstupujúce do ACS sa do systému vložia raz pomocou jedného vstupného kanála, pokiaľ to nevedie k nesplneniu požiadaviek stanovených v technických špecifikáciách pre ACS (na spoľahlivosť, spoľahlivosť atď.).

1.1.13. Výstupné informácie rovnakého sémantického obsahu musia byť vygenerované v automatizovanom riadiacom systéme raz, bez ohľadu na počet príjemcov.

1.1.14. Informácie obsiahnuté v databázach ACS sa musia aktualizovať v súlade s frekvenciou ich používania pri vykonávaní systémových funkcií.

1.1.15. Automatizovaný riadiaci systém musí byť chránený pred únikom informácií, ak je to uvedené v technických špecifikáciách pre automatizovaný riadiaci systém.

1.1.16. Názov ACS musí obsahovať názov typu ACS a riadiaceho objektu.

Napríklad:

• Systém riadenia procesu na ohrev kovu v metodickej peci;
• organizačný a technologický automatizovaný riadiaci systém v dielni č. 5;
• Automatický riadiaci systém závodu Hammer and Sickle

1.2. Požiadavky na funkcie ACS

1.2.1. Automatizovaný riadiaci systém musí v požadovanom rozsahu automaticky vykonávať:

• zhromažďovanie, spracovanie a analýza informácií (signálov, správ, dokumentov atď.) o stave riadiaceho objektu;
• vypracovanie kontrolných akcií (programov, plánov atď.);
• prenos kontrolných úkonov (signálov, pokynov, dokumentov) o vykonaní a jeho kontrole;
• vykonávanie a kontrola kontrolných akcií;
• výmena informácií (dokumentov, správ a pod.) s prepojenými automatizovanými systémami.

1.2.2. Zloženie automatizovaných funkcií (úloh, súborov úloh - ďalej len funkcie) automatizovaného riadiaceho systému musí zabezpečiť schopnosť riadiť zodpovedajúci objekt v súlade s ktorýmkoľvek z cieľov stanovených v technických špecifikáciách pre automatizovaný riadiaci systém.

1.2.3. Zloženie automatizovaných funkcií automatizovaného riadiaceho systému a stupeň ich automatizácie musia byť technicky, ekonomicky a (alebo) sociálne opodstatnené, berúc do úvahy potrebu oslobodiť personál od vykonávania opakujúcich sa činností a vytvoriť podmienky na využitie ich tvorivých schopností. schopnosti v pracovnom procese.

1.3. Požiadavky na pripravenosť personálu automatizovaného riadiaceho systému

1.3.1. Kvalifikácia personálu ACS musí zabezpečiť efektívne fungovanie systému vo všetkých špecifikovaných režimoch.

1.3.2. Personál ACS musí byť pripravený vykonávať svoje povinnosti v súlade s pokynmi organizačnej podpory.

1.3.3. Každá osoba, ktorá je súčasťou personálu automatizovaného riadiaceho systému, musí aplikovať vhodné informačné modely a pracovať s ňou používanými technickými prostriedkami a dokumentáciou, ktoré určujú postup pri jej činnosti.

1.4. Požiadavky na technickú podporu automatizovaných riadiacich systémov

1.4.1. Komplex technických prostriedkov automatizovaného riadiaceho systému musí postačovať na vykonávanie všetkých automatizovaných funkcií automatizovaného riadiaceho systému.

1.4.2. Komplex technických prostriedkov automatizovaných riadiacich systémov by mal využívať najmä technické prostriedky sériovej výroby. V prípade potreby je povolené použitie technických prostriedkov jednotlivej výroby.

1.4.3. Replikované automatizované riadiace systémy a ich časti musia byť postavené na báze jednotných technických prostriedkov.

1.4.4. Technické prostriedky ACS musia byť umiestnené v súlade s požiadavkami obsiahnutými v technickej, vrátane prevádzkovej, dokumentácii k nim, a to tak, aby bolo vhodné ich používať počas prevádzky ACS a vykonávať údržbu.

1.4.5. Umiestnenie technických prostriedkov používaných personálom automatizovaného riadiaceho systému pri vykonávaní automatizovaných funkcií musí spĺňať ergonomické požiadavky: pre výrobné zariadenia v súlade s GOST 12.049-80, pre prostriedky na prezentáciu vizuálnych informácií v súlade s GOST 21829-76, vrátane tabúľ pre kolektívne použitie vyrobené z elektroluminiscenčných indikátorov syntetizujúcich digitálne znaky podľa GOST 21837-76.

1.4.6. Technické prostriedky automatizovaného riadiaceho systému používané v interakcii automatizovaného riadiaceho systému s inými systémami musia byť kompatibilné v rozhraniach s príslušnými technickými prostriedkami týchto systémov a použitými komunikačnými systémami.

1.4.7. Automatizovaný riadiaci systém musí využívať technické prostriedky so životnosťou najmenej desať rokov. Použitie technických prostriedkov s kratšou životnosťou je povolené len v odôvodnených prípadoch a po dohode s objednávateľom automatizovaného riadiaceho systému.

1.4.8. Ktorýkoľvek z technických prostriedkov automatizovaného riadiaceho systému musí umožňovať jeho výmenu za prostriedok s obdobným funkčným účelom bez akýchkoľvek konštrukčných zmien alebo úprav na zostávajúcich technických prostriedkoch automatického riadiaceho systému (okrem prípadov osobitne špecifikovaných v technickej dokumentácii pre automatický riadiaci systém).

1.4.9. Technické prostriedky ACS možno použiť len za podmienok uvedených v prevádzkovej dokumentácii k nim. V prípadoch, keď je potrebné ich použiť v prostredí, ktorého parametre prekračujú prípustné hodnoty ustanovené pre tieto technické prostriedky, musia byť zabezpečené opatrenia na ochranu jednotlivých technických prostriedkov automatizovaného riadiaceho systému pred vplyvom vonkajších ovplyvňujúcich faktorov.

1.4.10. Automatizovaný riadiaci systém musí využívať výpočtovú techniku, ktorá spĺňa všeobecné technické požiadavky v súlade s GOST 22552-84.

1.4.11. Automatizovaný riadiaci systém musí využívať technické prostriedky zodpovedajúce:

• pre odolnosť voči vonkajším ovplyvňujúcim faktorom - GOST 12997-76 pre priemyselné zariadenia a automatizačné zariadenia GSP, GOST 14254-80 pre plášte elektrotechnických výrobkov, GOST 17516-72 pre elektrotechnické výrobky, pokiaľ ide o vplyv mechanických faktorov prostredia, GOST 21552-84 pre výpočtovú techniku;
• pre výkonové parametre - GOST 12997-76 pre priemyselné zariadenia a automatizačné zariadenia GSP, GOST 21552-84 pre počítačové vybavenie;
• podľa výkonnostnej kategórie - GOST 12997-76 pre priemyselné zariadenia a automatizačné zariadenia GSP, GOST 21552-84 pre počítačové vybavenie.

1.4.12. Ochrana technických prostriedkov automatizovaného riadiaceho systému pred vplyvom vonkajších elektrických a magnetických polí, ako aj rušením napájacích obvodov musí byť dostatočná na to, aby technické prostriedky efektívne plnili svoj účel pri prevádzke automatického riadiaceho systému.

1.4.13. V ACS, v súlade s požiadavkami stanovenými „Normami All-Union pre prípustné priemyselné rušenie“ 1-72 - 9-72 a GOST 23450-79, musia byť zabezpečené opatrenia na ochranu vonkajšieho prostredia pred priemyselným rádiovým rušením vyžarovaným technické prostriedky ACS počas prevádzky, ako aj v momente zapnutia a vypnutia.

1.4.14. Všeobecné ergonomické požiadavky na mnemotechnické schémy - podľa GOST 21480-76, na počítacie zariadenia pre vizuálne indikátory - podľa GOST 22902-78, na spoločné použitie dosky na digitálnych elektroluminiscenčných indikátoroch syntetizujúcich znaky - podľa GOST 21837-76, pre katódový lúč trubice na zobrazovanie vizuálnych informácií - podľa GOST 23144-78.

1.4.15. Všeobecné ergonomické požiadavky na spínače na ovládacích paneloch: otočné spínače - v súlade s GOST 22613-77, klávesnicové a tlačidlové spínače - v súlade s GOST 22614-77, typ "Prepínač" - v súlade s GOST 22615-77.

1.4.16. Všeobecné ergonomické požiadavky na zvukové alarmy primárnych správ sú v súlade s GOST 21786-76.

1.4.17. Všeobecné ergonomické požiadavky upravujúce organizáciu pracoviska, vzájomné usporiadanie zariadení na zobrazovanie informácií, ovládacích prvkov a komunikácie na pracovisku - v súlade s GOST 22269-76 vrátane diaľkových ovládačov - v súlade s GOST 23000-76.

1.4.18. Všeobecné ergonomické požiadavky na stoličky operátora v súlade s GOST 21889-76.

1.4.19. Všeobecné ergonomické požiadavky na halu, kabíny obsluhy a vzájomné usporiadanie sedadiel sú v súlade s GOST 21958-76.

1.5. Požiadavky na softvér ACS

1.5.1. Softvér ACS musí byť dostatočný na vykonávanie všetkých funkcií ACS, implementovaný pomocou počítačovej technológie, a tiež musí mať prostriedky na organizáciu všetkých požadovaných procesov spracovania údajov, čo umožňuje včasné vykonávanie všetkých automatizovaných funkcií vo všetkých regulovaných prevádzkových režimoch ACS.

1.5.2. Softvér ACS musí mať nasledujúce vlastnosti:

• funkčná dostatočnosť (úplnosť);
• spoľahlivosť (vrátane obnoviteľnosti, dostupnosti nástrojov na zisťovanie chýb);
• prispôsobivosť;
• modifikovateľnosť;
• modulárnosť konštrukcie a
• jednoduchosť použitia.

1.5.3. Softvér ACS by mal byť primárne postavený na základe existujúcich aplikačných softvérových balíkov a iných programov požičaných od vlády, priemyslu a iných zdrojov algoritmov a programov, umožňovať načítanie a kontrolu častí a umožniť výmenu niektorých programov bez opravy iných.

1.5.4. Automatizovaný riadiaci systém by mal primárne využívať systémy riadenia databáz (DBMS), registrované predpísaným spôsobom.

1.5.5. Softvér ACS musí byť vybudovaný tak, aby absencia jednotlivých údajov neovplyvnila výkon funkcií ACS, pri implementácii ktorých sa tieto údaje nepoužívajú.

1.5.6. Softvér ACS musí mať nástroje na diagnostiku hardvéru ACS a monitorovanie spoľahlivosti vstupných informácií.

1.5.7. Softvér ACS musí implementovať opatrenia na ochranu pred chybami pri zadávaní a spracovávaní informácií, ktoré zabezpečujú špecifikovanú kvalitu výkonu funkcií ACS.

1.5.8. Všeobecný softvér automatizovaného riadiaceho systému by mal umožniť konfiguráciu špeciálnych softvérových komponentov a ďalší vývoj softvéru automatizovaného riadiaceho systému bez prerušenia procesu jeho fungovania. Už vygenerovaná a načítaná časť softvéru musí byť chránená pred náhodnými zmenami.

1.5.9. Všetky špeciálne softvérové ​​programy pre konkrétny automatizovaný riadiaci systém musia byť kompatibilné navzájom aj s jeho všeobecným softvérom.

1.5.10. Prevádzková softvérová dokumentácia pre automatizovaný riadiaci systém musí spĺňať normy ESPD a obsahovať všetky informácie potrebné pre personál automatizovaného riadiaceho systému na používanie softvéru, na jeho prvotné načítanie a (alebo) generovanie, načítanie informácií z internej informačnej základne stroja, spustenie automatizovaného programy riadiacich systémov a kontrola ich fungovania pomocou vhodných testov.

1.5.11. Novo vyvinuté pri vytváraní špecifického automatizovaného riadiaceho systému, softvérové ​​produkty zahrnuté v jeho softvéri musia byť registrované v štátnych, priemyselných alebo iných fondoch algoritmov a programov (podľa potreby).

1.6. Požiadavky na informačnú podporu automatizovaných riadiacich systémov

1.6.1. Informačná podpora automatizovaného riadiaceho systému musí byť dostatočná na vykonávanie všetkých automatizovaných funkcií automatizovaného riadiaceho systému.

1.6.2. Na zakódovanie informácií používaných len v danom automatizovanom riadiacom systéme sa musia použiť klasifikátory akceptované zákazníkom automatizovaného riadiaceho systému.

1.6.3. Na zakódovanie výstupných informácií používaných na vyššej úrovni do ACS sa musia použiť klasifikátory riadiacich systémov vyššej úrovne, s výnimkou špeciálne špecifikovaných prípadov.

1.6.4. Všeobecné ergonomické požiadavky na kódovanie informácií sú v súlade s GOST 21829-76.

1.6.5. Na komunikáciu medzi zariadeniami komplexu technických prostriedkov sa v automatizovanom riadiacom systéme musí použiť:

• vstupné a výstupné signály:
  • elektrické - prúd a napätie podľa GOST 26.011-80, s diskrétnymi zmenami parametrov podľa GOST 26.013-81, kódované podľa GOST 26.014-81,
  • hydraulické podľa GOST 26.012-80,
  • pneumatické podľa GOST 26.015-81;
• sady alfanumerických znakov podľa GOST 19767-74;
• 8-bitové kódy podľa GOST 19768-74.

1.6.6. Informačná podpora automatizovaného systému riadenia musí byť kompatibilná s informačnou podporou systémov s ním interagujúcich, a to z hľadiska obsahu, systému kódovania, spôsobov adresovania, formátov údajov a formy prezentácie informácií prijímaných a vydávaných automatizovaným systémom riadenia.

1.6.7. Formuláre dokumentov vytváraných automatizovaným systémom riadenia musia zodpovedať požiadavkám štandardov USD alebo regulačných a technických dokumentov útvaru objednávateľa automatizovaného systému riadenia.

1.6.8. Formy dokumentov a video snímok zadávané, výstupné alebo upravované prostredníctvom terminálov ACS musia byť v súlade s príslušnými technickými charakteristikami terminálov.

1.6.9. Všetky informačné polia automatizovaných riadiacich systémov musia byť organizované vo forme databáz na počítačových médiách.

1.6.10. Formu prezentácie výstupných informácií automatizovaného riadiaceho systému je potrebné dohodnúť so zákazníkom (používateľom) systému.

1.6.11. Pojmy a skratky použité vo výstupných dokumentoch automatizovaného riadiaceho systému musia byť v danej tematickej oblasti všeobecne akceptované a odsúhlasené so zákazníkom systému.

1.6.12. Automatizovaný riadiaci systém musí poskytovať potrebné opatrenia na kontrolu a aktualizáciu údajov v informačných poliach automatizovaného riadiaceho systému, obnovu polí po zlyhaní akýchkoľvek technických prostriedkov automatizovaného riadiaceho systému, ako aj kontrolu identity informácií rovnaké meno v databázach.

1.7. Požiadavky na organizačné zabezpečenie automatizovaných riadiacich systémov

1.7.1. Organizačná podpora automatizovaného riadiaceho systému musí byť dostatočná na to, aby pracovníci automatizovaného riadiaceho systému efektívne plnili úlohy, ktoré im boli pridelené pri implementácii automatizovaných zodpovedností pri implementácii automatizovaných a súvisiacich neautomatizovaných funkcií systému.

1.7.2. Organizačná štruktúra automatizovaného riadiaceho systému musí umožňovať výkon všetkých funkcií automatizovaného riadiaceho systému s prihliadnutím na ich rozdelenie medzi riadiace úrovne.

1.7.3. Požiadavky na rozdelenie zodpovedností medzi personál zapojený do prevádzky automatizovaného riadiaceho systému v reálnom čase sa určujú s prihliadnutím na požiadavky bodu 11 povinného dodatku 1.

1.7.4. Pokyny na organizačné zabezpečenie automatizovaného riadiaceho systému musia určovať úkony personálu automatizovaného riadiaceho systému potrebné na vykonávanie každej automatizovanej funkcie vo všetkých režimoch prevádzky automatizovaného riadiaceho systému s prihliadnutím na špecifikované požiadavky na presnosť a rýchlosť implementácie. zo strany personálu automatizovaného riadiaceho systému ich funkčných povinností, a tiež obsahujú špecifické pokyny na činnosti v prípade núdzových situácií alebo porušenia bežných prevádzkových podmienok automatizovaného riadiaceho systému. Požiadavky na obsah pokynov sú v súlade s GOST 24.209-80.

1.7.5. Pre každú automatizovanú funkciu, ktorá sa vykonáva v interakcii tohto ACS s inými systémami, musia byť pokyny pre personál ACS a tieto systémy prepojené pre všetky režimy vykonávania tejto funkcie a musia obsahovať pokyny o činnosti personálu v prípade porúch technické prostriedky ACS.

1.8. Požiadavky na jazykovú podporu automatizovaných riadiacich systémov

1.8.1. Jazyková podpora automatizovaného riadiaceho systému musí byť dostatočná na komunikáciu medzi rôznymi kategóriami používateľov vo forme, ktorá im vyhovuje, s nástrojmi automatizácie automatizovaného riadiaceho systému a na vykonávanie postupov na konverziu a strojovú reprezentáciu informácií spracovávaných v automatizovanom riadiacom systéme.

1.8.2. Jazyková podpora automatizovaného riadiaceho systému by mala zahŕňať:

• sú poskytnuté jazykové nástroje na opis akýchkoľvek informácií používaných v automatizovanom riadiacom systéme;
• používané jazykové prostriedky sú jednotné;
• popisy podobných prvkov informácií a záznam syntaktických štruktúr boli štandardizované;
• Je zabezpečená pohodlnosť, jednoznačnosť a stabilita komunikácie medzi užívateľmi a automatizovanými riadiacimi systémami;
• sú k dispozícii prostriedky na opravu chýb, ktoré vznikajú pri komunikácii používateľov s technickými prostriedkami automatizovaného riadiaceho systému.

1.8.3. Jazyková podpora automatizovaného riadiaceho systému sa musí premietnuť do dokumentácie (návodov, popisov) organizačného zabezpečenia automatizovaného riadiaceho systému vo forme pravidiel komunikácie medzi užívateľmi a technickými prostriedkami automatizovaného riadiaceho systému vo všetkých režimoch systému. prevádzka.

1.9. Požiadavky na právnu podporu automatizovaných riadiacich systémov

Právna podpora pre automatizované riadiace systémy by mala zahŕňať súbor právnych noriem:

• určenie právnej platnosti informácií na dátových nosičoch a dokumentoch používaných pri prevádzke automatizovaného kontrolného systému a vytvorených systémom;
• upravujúce právne vzťahy medzi ľuďmi, ktorí sú súčasťou personálu ACS (práva, povinnosti a zodpovednosti), ako aj medzi personálom ACS a personálom systémov interagujúcich s ACS.

Poznámka. Pravidlá a predpisy vyplývajúce z právnej platnosti informácií na dátových nosičoch a právne normy musia byť obsiahnuté v pokynoch a predpisoch organizačného zabezpečenia pre príslušné služby ICS.

1.10. Požiadavky na prevádzkovú dokumentáciu pre automatizované riadiace systémy

1.10.1. Prevádzková dokumentácia ACS musí byť dostatočná na uvedenie ACS do prevádzky a na jej efektívne fungovanie.

1.10.2. Prevádzková dokumentácia pre automatizovaný riadiaci systém musí:

• obsahovať informácie potrebné pre rýchly a kvalitný vývoj a správnu činnosť automatizovaných riadiacich systémov;
• obsahovať pokyny o činnosti personálu ACS v núdzových situáciách alebo v prípade porušenia bežných prevádzkových podmienok ACS;
• neobsahujú ustanovenia, ktoré podliehajú nejednoznačnému výkladu.

2. BEZPEČNOSTNÉ POŽIADAVKY

2.1. Nesprávne konanie personálu ACS by nemalo viesť k núdzovej situácii.

2.2. Bezpečnostné požiadavky na elektrické výrobky používané v automatizovaných riadiacich systémoch sú v súlade s GOST 12.2.007.0-75.

2.3. Bezpečnostné požiadavky na počítačové vybavenie používané v automatizovaných riadiacich systémoch sú v súlade s GOST 25861-83.

2.4. Všetky vonkajšie prvky technických prostriedkov automatického riadiaceho systému, ktoré sú pod napätím, musia byť chránené pred náhodným kontaktom a samotné technické prostriedky musia byť uzemnené alebo ochranne uzemnené v súlade s GOST 12.1.030-81 a „Pravidlami pre napájacie zariadenia“. .

2.5. Technické zariadenia ACS umiestnené v inštaláciách s nebezpečenstvom výbuchu a požiaru musia spĺňať požiadavky „Pravidiel napájania“.

2.6. Technické prostriedky ACS musia byť inštalované tak, aby bola zabezpečená ich bezpečná prevádzka a údržba.

2.7. Bezpečnostné požiadavky musia byť stanovené v osobitnej časti popisov práce a (alebo) prevádzkových pokynov pre automatizované riadiace systémy a musia mať prepojenia na prevádzkové pokyny pre technické zariadenia.

2.8. Všeobecné ergonomické požiadavky na pracoviská personálu automatizovaného riadiaceho systému sú v súlade s GOST 22269-76.

2.9. Pohodlné životné podmienky pre zamestnancov automatizovaného riadiaceho systému musia spĺňať súčasné hygienické normy, maximálne prípustné životné podmienky - v súlade s GOST 12.1.005-76, prípustné úrovne vplyvu nebezpečných a škodlivých výrobných faktorov - v súlade s GOST 12.0.003-74 .

2.10. Všeobecné ergonomické požiadavky na mikroklímu pracovných priestorov personálu automatizovaného riadiaceho systému sú v súlade s GOST 12.1.005-76.

2.11. Hladiny hluku a akustického výkonu v miestach personálu automatizovaného riadiaceho systému by nemali prekročiť hodnoty stanovené GOST 12.1.003-83 a hygienickými normami, zatiaľ čo hladiny hluku a akustického výkonu vytvorené všetkými zdrojmi, vrátane akustických prostriedkov prenos údajov, treba vziať do úvahy.

2.12. Úrovne osvetlenia pracovísk personálu automatizovaného riadiaceho systému musia zodpovedať charakteru a pracovným podmienkam. Musí byť zabezpečená ochrana proti oslneniu a redukcia oslnenia.

2.13. Všeobecné ergonomické požiadavky na vibrácie zariadení na pracoviskách personálu automatizovaného riadiaceho systému sú v súlade s GOST 12.1.012-78.

2.14. Signálne farby a bezpečnostné značky podľa GOST 12.4.026-76.

3. TYPY A POSTUP SKÚŠOK PRI UVEDENÍ ACS DO PREVÁDZKY

Táto časť sa vzťahuje na všetky automatizované riadiace systémy okrem tých, ktoré boli vytvorené na základe príkazu ministerstva obrany.

3.1. Automatizovaný riadiaci systém alebo samostatne dodávaná funkcia automatizovaného riadiaceho systému (ďalej len automatizovaný riadiaci systém) musí pri uvedení do prevádzky prejsť predbežnými a akceptačnými skúškami, ako aj skúškami ustanovenými regulačnými a technickými dokumentmi. v platnosti v oddelení objednávateľa automatizovaného riadiaceho systému.

3.2. Preberacej skúške automatizovaného riadiaceho systému musí predchádzať jeho skúšobná prevádzka na pracovisku kontroly.

3.3. Testy ACS sa vykonávajú v súlade s dokumentom „Testovací program“, ktorý pripravuje vývojár ACS. Požiadavky na obsah testovacieho programu sú v súlade s GOST 24.208-80.

3.4. Testy ACS sa môžu vykonávať v jednej alebo niekoľkých etapách.

Na základe výsledkov testu ACS vypracuje „Správu o teste“. Požiadavky na obsah skúšobného protokolu sú v súlade s GOST 24.208-80.

Pri testovaní ACS krok za krokom by „Správa o teste“ založená na výsledkoch predchádzajúcej fázy mala obsahovať záver o možnosti predloženia ACS do ďalšej fázy testovania.

3.5. Predbežné testy automatizovaného riadiaceho systému

3.5.1. Vykonávajú sa predbežné skúšky automatizovaného riadiaceho systému, aby sa zistila jeho výkonnosť a vyriešila sa otázka možnosti prijatia automatického riadiaceho systému do skúšobnej prevádzky.

3.5.2. „Testovací program“ na predbežné testovanie ACS schvaľuje zákazník ACS.

3.5.3. Predbežné testy ACS organizuje zákazník a vykonáva ich spoločne vývojár ACS a zákazník.

3.5.4. Komisia na vykonanie predbežných skúšok automatizovaného riadiaceho systému je tvorená na objednávku zákazníka. Za predsedu komisie je určený zástupca objednávateľa automatizovaného riadiaceho systému.

3.5.6. „Skúšobný protokol“, vypracovaný na základe výsledkov predbežných skúšok ACS, poskytuje záver o možnosti prijatia ACS do skúšobnej prevádzky, ako aj zoznam potrebných úprav a odporúčané termíny ich implementácie.

3.6. Skúšobná prevádzka automatizovaných riadiacich systémov

3.6.1. Výsledky prevzatia ACS do skúšobnej prevádzky sú zdokumentované v „Osvedčení o prevzatí do skúšobnej prevádzky“, vyhotovenom na základe „Skúšobného protokolu“ komisiou, ktorá vykonala predbežné skúšky ACS. Požiadavky na obsah zákona sú v súlade s GOST 24.208-80.

3.6.2. Dĺžka skúšobnej prevádzky automatizovaného riadiaceho systému je určená časom potrebným na overenie správnej funkcie automatizovaného riadiaceho systému pri vykonávaní každej automatizovanej funkcie a pripravenosťou personálu automatizovaného riadiaceho systému podieľať sa na výkone všetkých automatizovaných funkcií riadiaceho systému. automatizovaný riadiaci systém.

3.6.3. Minimálna dĺžka skúšobnej prevádzky automatizovaného riadiaceho systému (okrem automatického riadiaceho systému) pred akceptačným testom je určená pre každú predloženú automatizovanú funkciu automatizovaného riadiaceho systému, musí zodpovedať hodnotám uvedeným v tabuľky. Ak celkové trvanie prerušení kontinuity automatizovanej funkcie presiahne hodnotu uvedenú v tabuľke, skúšobná prevádzka musí pokračovať, kým sa nedosiahnu výsledky v súlade s tabuľkou alebo kým sa nerozhodne o jej ukončení.

Po dohode so zákazníkom je povolené predložiť ACS na akceptačné testovanie bez skúšobnej prevádzky tých automatizovaných funkcií, ktorých frekvencia riešenia je menšia ako 1x za mesiac, za predpokladu, že nielen takéto funkcie sú v ACS automatizované.

Frekvencia vykonávania automatizovaných funkcií	Minimálne trvanie skúšobnej prevádzky automatizovaného riadiaceho systému pred akceptačným testovaním	Prípustné celkové trvanie prerušení kontinuity vykonávania funkcie automatizovaného automatizovaného riadiaceho systému
Nepretržite	1 mesiac	Nie viac ako 3 dni
Raz denne alebo častejšie	To isté	Nie viac ako 10 % z plánovaného počtu riešení
Menej ako raz za deň až raz za mesiac	3 mesiace	To isté
Menej ako raz za mesiac až raz za šesť mesiacov	Obdobie medzi dvoma po sebe nasledujúcimi rozhodnutiami	Narušenie kontinuity výkonu funkcie nie je dovolené
Raz za rok alebo menej	Čas potrebný na testovanie prijatej technológie na zber a spracovanie informácií počas jednorazového vykonania funkcie ACS	To isté

Poznámky:

1. Za porušenie kontinuity vykonávania automatizovanej funkcie automatizovaného riadiaceho systému sa považuje jej nevykonanie v čase uvedenom v technickej dokumentácii k automatizovanému riadiacemu systému, ak to nie je spôsobené porušením zákona č. prevádzkové podmienky automatizovaného riadiaceho systému alebo riadiaceho objektu.

2. Ak bola skutočná doba trvania skúšobnej prevádzky automatizovaného riadiaceho systému dlhšia ako doba uvedená v druhom stĺpci tabuľky, potom sa celková doba trvania prerušenia kontinuity vykonávania pre každú automatizovanú funkciu určí za obdobie uvedené v tabuľke a bezprostredne pred akceptačnými skúškami.

3.6.4. Počas skúšobnej prevádzky ACS sa vedie pracovný denník, do ktorého sa zaznamenávajú informácie: o dobe trvania prevádzky ACS, o výsledkoch sledovania správneho fungovania ACS, o poruchách, poruchách, havarijných situáciách, o zmenách v parametroch objektu riadenia a priebežných úpravách technickej dokumentácie.

3.6.5. Na základe výsledkov skúšobnej prevádzky je vystavené osvedčenie o vykonaní prác na kontrole automatizovaného riadiaceho systému v režime skúšobnej prevádzky. Požiadavky na obsah zákona sú v súlade s GOST 24.208-80.

3.7. Akceptačné testy ACS

3.7.1. Preberacie skúšky ACS sa vykonávajú na zistenie zhody s technickými špecifikáciami pre ACS, požiadavkami tejto normy a na určenie možnosti uvedenia ACS do prevádzky.

3.7.2. V závislosti od dôležitosti riadiaceho objektu a automatizovaného riadiaceho systému môžu byť akceptačné testy:

• vláda;
• medzirezortné;
• rezortný

a musia ho vykonať príslušné akceptačné komisie. Preberaciu komisiu tvorí príkaz ministerstva (odboru) objednávateľa automatizovaného riadiaceho systému. Úroveň akceptačnej komisie musí byť stanovená v technických špecifikáciách pre automatizovaný riadiaci systém.

3.7.3. Za predsedu preberacej komisie je určený zástupca objednávateľa automatizovaného riadiaceho systému. Akceptačná komisia musí zahŕňať zástupcov vývojára ACS.

3.7.4. Práca preberacej komisie nezahŕňa preberanie budov, stavieb a pomocných zariadení, ktorých tvorba bola realizovaná v súvislosti s vytvorením automatizovaného riadiaceho systému. Komisia kontroluje iba dostupnosť potvrdení o prevzatí do prevádzky a splnenie požiadaviek obsiahnutých v projektových zadaniach v priľahlých častiach projektu zariadenia, vydaných pri projektovaní automatizovaného riadiaceho systému.

3.7.5. Zákazník a vývojár predložia akceptačnému výboru nasledujúcu dokumentáciu:

• zadávacie podmienky na vytvorenie automatizovaného riadiaceho systému;
• návrh akceptačného testovacieho programu;
• predbežná správa o teste ACS;
• osvedčenie o prevzatí automatizovaného riadiaceho systému do skúšobnej prevádzky;
• úkony o ukončení prác na kontrole automatizovaného riadiaceho systému v režime skúšobnej prevádzky;
• technická dokumentácia k automatizovanému riadiacemu systému (na základe rozhodnutia akceptačnej komisie).

3.7.6. Automatizované riadiace systémy s meracími kanálmi sú pred odovzdaním na kolaudáciu podrobené metrologickej certifikácii podľa platných noriem.

3.7.7. Pred predložením ACS na kolaudačné skúšky je potrebné dopracovať systém a jeho technickú dokumentáciu na základe pripomienok k protokolu o predbežnej skúške a certifikátu o ukončení prác na preskúšaní ACS v režime skúšobnej prevádzky.

Na základe rozhodnutia preberacieho výboru je povolené finalizovať technickú dokumentáciu automatizovaného riadiaceho systému po jeho uvedení do prevádzky. Termíny dokončenia technickej dokumentácie automatizovaného riadiaceho systému sú uvedené v protokole o preberacej skúške systému.

3.7.8. Akceptačné testy automatizovaného riadiaceho systému sa musia vykonávať vo funkčnom kontrolnom zariadení.

3.7.9. „Testovací program“ pre akceptačné testovanie automatizovaného riadiaceho systému musí byť schválený rozhodnutiami akceptačného výboru. Koordinácia programu akceptačného testovania so zákazníkom automatizovaného riadiaceho systému je povinná.

3.7.10. Na základe výsledkov kolaudačných skúšok komisia vypracuje protokol o skúške a zákon o uvedení AKS do prevádzky (prípadne záver o neprevzatí ACS so zoznamom potrebných úprav a odporúčanými termínmi ich realizácie). Požiadavky na obsah protokolu a konať v súlade s GOST 24.208-80. Požiadavky na obsah záveru o neakceptovaní automatizovaného riadiaceho systému sú obdobné ako požiadavky na obsah zákona o uvedení automatizovaného riadiaceho systému do účinnosti.

3.7.11. V prípade akceptačných skúšok po etapách sa akt uvedenia automatizovaného riadiaceho systému do prevádzky vypracúva na základe aktov uvedenia do prevádzky jednotlivých častí systému a (alebo) „Skúšobných protokolov“ všetkých etapy akceptačného testovania automatizovaného riadiaceho systému.

3.7.12. Za dátum uvedenia automatizovaného riadiaceho systému do prevádzky sa považuje dátum podpísania aktu o uvedení do prevádzky preberacou komisiou.

3.7.13. Zákon o uvedení automatizovaného riadiaceho systému do platnosti schvaľuje ministerstvo (odbor) objednávateľa.

4. ÚPLNOSŤ UVEDENIA DO PREVÁDZKY ACS

4.1. ACS by mal zahŕňať:

• technické prostriedky ACS vo forme komplexu technických prostriedkov ACS pripravených na prevádzku;
• náhradné diely a prístroje (SPTA), prístroje a zariadenia na skúšanie prevádzkyschopnosti, nastavovanie technických zariadení a sledovanie metrologických charakteristík meracích kanálov automatizovaného riadiaceho systému v rozsahu stanovenom zákazkovou projektovou dokumentáciou dohodnutou s objednávateľom automatu. riadiaci systém a užívateľská metrologická služba z hľadiska testovacích zariadení;
• prevádzková dokumentácia v súlade s GOST 2.601-68 pre každý z produktov zahrnutých v CTS ACS;
• najmenej dve kópie programov na dátových nosičoch a prevádzková dokumentácia k nim v súlade s GOST 19.101-77, berúc do úvahy obmedzenia a dodatky v súlade s GOST 24.101-80 a GOST 24.207-80;
• formulár pre softvér ACS ako celok alebo pre softvér funkcie ACS uvedený do prevádzky samostatne a formuláre pre softvérové ​​produkty (podľa GOST 19.004-80), každý v jednej kópii. Požiadavky na formulár - podľa GOST 19.501-78;
• dve kópie prevádzkovej dokumentácie pre automatizovaný riadiaci systém v súlade s GOST 24.101-80 vrátane potrebnej dokumentácie pre informačnú podporu automatizovaného riadiaceho systému (formulár automatizovaného riadiaceho systému v jednom vyhotovení).

Po dohode medzi vývojárom ACS a zákazníkom ACS je možné rozšíriť kompletnosť ACS.

4.2. Personál ACS musí mať personál, ktorý spĺňa požiadavky článku 1.3.

4.3. Na dokončenie vytvoreného automatizovaného riadiaceho systému je možné použiť, dodávané ako výrobné a technické produkty:

• komplex (komplexy) hardvéru a softvéru s prevádzkovou dokumentáciou k nim v súlade s GOST 2.601-68;
• softvérové ​​produkty s prevádzkovou dokumentáciou k nim v súlade s GOST 19.101-77;
• technické vybavenie s prevádzkovou dokumentáciou k nim v súlade s GOST 2.601-68.

4.4. Postup vývoja, uvedenia do výroby a testovania dodávaných komponentov používaných v automatizovanom systéme riadenia musí zodpovedať štátnym normám pre systém vývoja a nábehu produktov do výroby.

Prototypy komponentov sú pred uvedením do výroby podrobené akceptačným (štátnym, medzirezortným, rezortným) skúškam.

5. ZÁRUKA

5.1. Vývojár automatizovaného riadiaceho systému garantuje súlad automatizovaného riadiaceho systému s požiadavkami tejto normy a technickými špecifikáciami pre automatický riadiaci systém pri dodržaní prevádzkových podmienok a pravidiel zo strany užívateľa.

5.2. Súlad hardvéru, softvéru a systémov automatizačných zariadení používaných v automatizovaných riadiacich systémoch a dodávaných ako výrobné a technické produkty s požiadavkami noriem a špecifikácií na ne je garantovaný výrobcami týchto typov výrobkov za predpokladu, že používateľ dodržiava prevádzkové podmienky a pravidlá.

5.3. Záručná doba na ACS sa počíta odo dňa uvedenia ACS do prevádzky.

5.4. Záručná doba pre ACS musí byť stanovená v technických špecifikáciách pre ACS a nemôže byť kratšia ako 18 mesiacov.

PRÍLOHA 1
Povinné

ĎALŠIE POŽIADAVKY NA SYSTÉMY AUTOMATICKÉHO RIADENIA PROCESOV (APCS)

1. Systémy riadenia procesov v priemysle a v nepriemyselnej sfére musia riadiť technologický objekt ako celok a dodávať prepojeným systémom spoľahlivé technologicko-technické a ekonomické informácie o prevádzke objektu technologického riadenia (TOU).

2. Automatizovaný systém riadenia procesov musí v reálnom čase technologického procesu v objekte riadenia vyvíjať a implementovať kontrolné činnosti na systéme technickej kontroly, ktoré sú racionálne z hľadiska cieľov a kritérií kontroly.

3. Automatizovaný systém riadenia procesov musí vykonávať riadiace, informačné a pomocné funkcie.

4. Systém riadenia procesov musí byť kompatibilný so všetkými s ním prepojenými automatizovanými systémami (AS), špecifikovanými v zadávacích podmienkach pre systém riadenia procesov, vrátane systémov zahrnutých do tohto systému riadenia procesov ako súčasť flexibilnej automatizovanej výroby, napr. CAD technológie, automatizované skladové a dopravné systémy, AS pre technologickú prípravu výroby.

5. Kontrolné akcie v automatizovanom systéme riadenia procesov musia byť generované automaticky alebo generované jeho prevádzkovým personálom pomocou súboru automatizačných nástrojov zahrnutých v systéme.

6. Automatizovaný systém riadenia procesov musí zabezpečiť riadenie zariadenia za normálnych, prechodných a predhavarijných podmienok jeho prevádzky, ako aj ochranu alebo odstavenie zariadenia v prípade hrozby havárie.

7. Automatizovaný systém riadenia procesov musí vykonávať funkciu sledovania vykonávania kontrolných úkonov na technickom zariadení a signalizovať, kedy výkonné orgány dosiahnu maximálne prípustné polohy.

8. Pri implementácii funkcie núdzového automatického vychýlenia zariadenia v systéme riadenia procesu musí byť o tom zabezpečený poplach pre obsluhujúci personál svetelnými a prípadne zvukovými signálmi s automatickou registráciou času odstávky.

9. Ako hlavné technické prostriedky automatizovaných systémov riadenia procesov by mali byť produkty Štátneho systému priemyselných prístrojov a automatizačných zariadení (GSP), ďalšie produkty, ktoré spĺňajú požiadavky noriem ESSP, a počítačové vybavenie, ktoré je v súlade s GOST 21552-84. použité.

10. Technické prostriedky automatizovaných systémov riadenia procesov umiestnené na technologických zariadeniach musia spĺňať požiadavky na ich prevádzkové podmienky.

11. Zodpovednosti medzi prevádzkovateľmi by sa mali rozdeliť s ohľadom na:

• účasť personálu na vykonávaní manuálnych funkcií systému a jeho interakcie s inými systémami;
• prípustná úroveň psychofyziologického a emocionálneho zaťaženia operátorov stanovená normatívnymi a technickými dokumentmi v odvetví spojenú s plnením povinností pridelených každému z nich a jeho zodpovednosťou za konečné a priebežné výsledky práce, ako aj požadovaná úroveň jeho činnosti v procese práce.

12. Každá osoba zahrnutá do personálu musí mať:

• znalosti, ktorých objem a hĺbka mu umožňuje vykonávať akcie (interakcie) zahrnuté v zodpovedajúcich automatizovaných a vzájomne prepojených neautomatizovaných funkciách automatizovaného systému riadenia procesov, ako aj robiť správne rozhodnutia v núdzových situáciách alebo iných porušeniach bežnej prevádzky ;
• vyvinuté zručnosti, ktoré umožňujú vykonávať všetky akcie a interakcie so špecifikovanou presnosťou a rýchlosťou.

13. Softvér automatizovaného systému riadenia procesov musí poskytovať a organizačná podpora musí odrážať jazykové nástroje na komunikáciu medzi prevádzkovým personálom a automatizovaným systémom riadenia procesov, pohodlné a dostupné osobám bez programátorskej kvalifikácie.

14. Kódy a symboly používané v systéme riadenia procesov by mali byť blízke termínom a konceptom používaným technologickým personálom riadiaceho objektu a nemali by spôsobovať ťažkosti pri ich vnímaní.

15. Meracie kanály automatizovaného systému riadenia procesov musia mať metrologické charakteristiky, ktoré zabezpečujú výkon jeho informačných funkcií s ukazovateľmi uvedenými v technických špecifikáciách pre automatizovaný systém riadenia procesov.

16. Požiadavky na testovanie automatizovaných systémov riadenia procesov

16.1. Predbežné testy automatizovaného systému riadenia procesov sa vykonávajú na existujúcom technickom zariadení.

16.2. Predbežné testy funkcií automatizovaného systému riadenia procesov potrebných na spustenie a zábeh technologických zariadení je možné vykonať na mieste pomocou simulátorov.

16.3. Stanovenie skutočných hodnôt ukazovateľov technickej a ekonomickej efektívnosti a spoľahlivosti automatizovaného systému riadenia procesov sa vykonáva po jeho uvedení do prevádzky. Prevádzkový čas automatizovaného systému riadenia procesu, potrebný na určenie skutočných hodnôt jeho ukazovateľov, sa vypočíta podľa príslušných metód schválených predpísaným spôsobom.

DODATOK 2
Povinné

DODATOČNÉ POŽIADAVKY PRE ACS PODNIKY, VÝROBNÉ A VÝSKUMNÉ A VÝROBNÉ ZDRUŽENIA

1. Automatizovaný systém riadenia musí zvyšovať efektívnosť výrobných a ekonomických činností podnikov, výrobných alebo vedeckých a výrobných združení (ďalej len podniky).

2. Podnikový automatizovaný riadiaci systém (ACS) musí poskytovať automatizovaný zber a spracovanie informácií so širokým využitím optimalizačných metód pre hlavné úlohy a riadiace podsystémy všeobecnej úrovne závodu a dielne, vrátane, ak je to potrebné, v reálnom čase pri teleprocesingu. a dialógovom režime.

3. Automatizovaný riadiaci systém musí byť implementovaný ako súbor spoločne fungujúcich subsystémov, ktorých interakcia musí prebiehať prostredníctvom spoločnej (jednotnej alebo distribuovanej) databázy.

4. Organizačná podpora automatizovaných systémov riadenia by mala zabezpečiť zlepšenie metód riadenia a štruktúry systému riadenia podniku pri tvorbe a vývoji automatizovaných systémov riadenia.

DODATOK 3
Povinné

DODATOČNÉ POŽIADAVKY NA PRIEMYSEL AUTOMATIZOVANÉ SYSTÉMY RIADENIA (OACS)

1. OASU musí zabezpečiť:

• zlepšenie charakteristík objektu kontroly (zvýšenie produktivity práce v priemysle, zlepšenie kvality výrobkov, včasné dodanie výrobkov, zníženie nákladov na vyrábané výrobky);
• zlepšenie procesov spracovania informácií (zníženie nákladov na spracovanie informácií, zvýšenie spoľahlivosti počiatočných, zvýšenie presnosti a efektívnosti výpočtov);
• zlepšenie organizácie riadiacich funkcií (najmä racionálne rozdelenie práce medzi oddelenia riadiaceho aparátu, výpočtové strediská a výskumné organizácie a podniky).

2. OASU musí automatizovať funkcie riadenia odvetvia, napríklad:

• predpovedanie a plánovanie priemyselnej výroby a zdrojov;
• riadenie vedecko-technického rozvoja priemyslu a technickej prípravy priemyselnej výroby;
• riadenie pracovnej sily v priemysle;
• riadenie priemyselných materiálnych zdrojov;
• riadenie investičnej výstavby v priemysle;
• riadenie finančných zdrojov priemyslu;
• riadenie, vrátane operatívneho riadenia, hlavnej výroby na úrovni odvetvia a pod.

3. OACS by sa mal implementovať ako súbor spoločne fungujúcich subsystémov, ktorých interakcia by mala prebiehať prostredníctvom spoločných databáz.

4. OASU musí obsahovať systém zberu dát založený na výpočtových strediskách OASU, organizácií a podnikov v priemysle, zabezpečujúci racionálnu distribúciu informácií v databázach na riešenie interagujúcich problémov a prenos informácií medzi systémami prostredníctvom komunikačných kanálov a na počítačových médiách.

5. OACS musí poskytovať interaktívny režim práce so systémovými databázami.

6. Vytvorenie OASU by malo viesť k zlepšeniu metód a štruktúry riadenia priemyslu.

7. Dĺžka skúšobnej prevádzky častí OACS musí zabezpečiť jednorazové vykonanie všetkých výpočtov potrebných na vykonávanie automatizovaných funkcií zavádzanej časti OACS a nemala by presiahnuť 3 mesiace.

Konkrétna dĺžka skúšobnej prevádzky OASU je stanovená dohodou medzi developerom a objednávateľom.

DODATOK 4
Informácie

VYSVETLENIE NIEKTORÝCH POJMOV POUŽITÝCH V TOMTO ŠTANDARDE

Komplex automatizačných zariadení (CAS)- dodaný súbor vzájomne dohodnutých súborov hardvéru a softvéru (produktov), ​​vyvinutých a vyrobených ako produkty na priemyselné a technické účely. KSA môže zahŕňať aj iné produkty a (alebo) dokumenty zahrnuté v informačnej, organizačnej alebo inej podpore pre automatizované systémy.

Rozšírenie automatizovaných riadiacich systémov- súbor opatrení vykonaných v automatizovanom riadiacom systéme pri rozširovaní jeho riadiaceho objektu bez zmeny zloženia funkcií automatizovaného riadiaceho systému.

Snímka videa (v ACS)- obrázok na obrazovke dokumentu katódovej trubice s nákresom alebo textom správy používaný v automatizovanom riadiacom systéme.

Merací kanál ACS- funkčne integrovaný súbor technických a (v prípade potreby) softvérových nástrojov určených na implementáciu jednej jednoduchej meracej funkcie automatizovaného riadiaceho systému.

Predbežné testy automatizovaného riadiaceho systému- vykonávané kontrolné skúšky na zistenie možnosti prijatia automatizovaného riadiaceho systému do skúšobnej prevádzky.

Akceptačné testy ACS- kontrolné skúšky automatizovaného riadiaceho systému, vykonávané na zistenie jeho súladu s technickými špecifikáciami na vytvorenie automatizovaného riadiaceho systému, požiadavkami noriem a na zistenie možnosti uvedenia automatizovaného riadiaceho systému do prevádzky.

Štátne testy- akceptačné skúšky automatizovaných riadiacich systémov vykonávané štátnou komisiou.

Medzirezortné testovanie- akceptačné testy automatizovaných riadiacich systémov vykonávané komisiou zástupcov viacerých zainteresovaných ministerstiev a (alebo) rezortov.

Rezortné testy- akceptačné testy automatizovaných riadiacich systémov vykonávané komisiou zástupcov zainteresovaného ministerstva alebo rezortu.

Redaktor A.I. Lomina
Technický redaktor N.P. Zamolodčiková
Korektor E.I. Evteeva
Dodané do súpravy 16.01.86. Podpísané na zverejnenie 04/08/86. Podmienené rúra l. 1.5. Podmienené kr.-ott. 1.5 Akademické vyd. l. 1.5.
Náklad 40 000 Cena 10 kopejok.
Objednávka "Odznak cti" Vydavateľstvo noriem, 123810, Moskva, GSP, Novopresnensky lane, 3
Typ. "Moskovská tlačiareň", Moskva, Lyalin lane, 6. Objednávka 1772

Dnes budeme hovoriť o domácich normách pre projektovú dokumentáciu. Ako tieto normy fungujú v praxi, prečo sú zlé a prečo sú dobré. Pri vypracovaní dokumentácie pre vládnych a serióznych súkromných zákazníkov väčšinou nemáme na výber – súlad s normami je súčasťou požiadaviek na dokumentáciu technických špecifikácií. V praxi som sa stretol s rôznymi príkladmi nepochopenia štruktúry noriem, čo by v dokumentoch malo byť a prečo sú tieto dokumenty potrebné. Výsledkom je, že perá technických spisovateľov, analytikov a špecialistov niekedy vytvárajú také skvosty, že nie je jasné, v akom stave vedomia boli napísané. Ale v skutočnosti je všetko celkom jednoduché. Hľadanie na Habr nevrátilo žiadne odkazy na viac-menej úplný materiál na túto tému, preto navrhujem vyplniť túto nepríjemnú medzeru.

Čo sú štandardy dokumentácie?

V predmetnej sérii 34 existujú iba 3 hlavné štandardy dokumentácie:

Najobľúbenejší a najobľúbenejší štandard pre vývoj technických špecifikácií. Jediná vec, na ktorú by ste nemali zabúdať, je, že je úzko prepojená s ostatnými normami série, a ak ste dostali technické špecifikácie vyrobené podľa tejto normy, je veľmi vhodné dodržiavať ďalšie normy, aj keď neexistujú žiadne priame požiadavky. pre to. Aspoň z hľadiska všeobecnej ideológie (o ktorej nižšie)

Toto je základný dokument, ktorý poskytuje úplný zoznam dokumentácie GOST 34, odporúčania pre kódovanie dokumentov, do ktorých fáz projektu dokumenty patria (štádiá sú opísané v GOST 34.601-90), ako aj to, ako ich možno kombinovať s navzájom.

V skutočnosti je tento štandard veľkou tabuľkou s komentármi. Pre jednoduché použitie ho možno vložiť do Excelu.

Objemný štandard, ktorý popisuje obsah projektových dokumentov s rôznym stupňom detailov. Ako index sa používa vyššie uvedený GOST 34.201-89.

Ohľadom normy RD 50-34.698-90 existuje veľa otázok a výkladov jej ustanovení, ktoré sú pre svoju vágnosť často rozdielne chápané zo strany objednávateľa a zhotoviteľa, prípadne aj členov projektového tímu. Ale, žiaľ, nemáme nič konkrétnejšie.

Uvažujme teraz o výhodách a nevýhodách noriem, tradične začínajúc nevýhodami.

Nevýhody noriem

Hlavná nevýhoda je zrejmá každému - normy sú staré. Obsahujú zastaranú predstavu o architektúre automatizovaného systému. Napríklad:

• dvojvrstvové aplikácie pozostávajúce z klientskeho programu a servera DBMS (žiadne tri alebo viac „vrstvových“ aplikácií, žiadne Weblogic alebo JBoss)
• popísaná štruktúra databázových tabuliek poskytne predstavu o logickom dátovom modeli (skutočnosť, že medzi aplikáciou a databázou môže byť nejaký druh hibernácie, sa vtedy zdala ako zlý exces)
• používateľské rozhranie je jednooknové (je niečo iné? Čo je to „prehliadač“?)
• V systéme je málo správ, všetky sú papierové a vytlačené na ihličkovej tlačiarni.
• Vyvíjaný program je zameraný na riešenie „problému spracovania informácií“, ktorý má jasný vstup a výstup a je vysoko špecializovaný. Spracovanie informácií je založené na „algoritme“. Niekedy existuje niekoľko „algoritmov“. (Objektovo orientované programovanie vtedy ešte len robilo prvé kroky a vážne sa o ňom neuvažovalo).
• správca databázy rozumie, aké informácie sú v tabuľkách a aktívne sa podieľa na úprave systémových adresárov (naozaj existuje jeden DBMS server pre 50 rôznych aplikácií?)

V súlade s tým má štandard artefakty, ako sú tieto:

5.8. Výkres formulára dokumentu (rámček videa)
Dokument musí obsahovať vyobrazenie podoby dokumentu alebo videozáznamu v súlade s požiadavkami štátnych noriem jednotného dokumentačného systému R 50-77 a potrebné vysvetlivky.

Zmyslom dokumentu je, že sovietske podniky používali takzvané „oblasti tlače“, kde boli vysokorýchlostné maticové tlačiarne, ktorých ovládače často písali samotní inžinieri. Museli preto viesť register všetkých dokumentov, ktoré bolo potrebné vytlačiť, aby dokumenty pri tlači vyzerali tak, ako majú.

„Video rám“ je tiež dokument, ktorý bol zobrazený na textovom displeji. Displeje nie vždy podporovali požadované znaky a požadovaný počet vodorovných znakov a zvislých čiar (a už vôbec nie grafiku). Preto aj tu bolo potrebné dodatočne zladiť formy všetkých obrazovkových dokumentov.

Teraz nám slová „strojový gram“, „video rám“, „ADC“ už nič nehovoria. Tiež som ich nenašiel v používaní, hoci som v 90. rokoch vyštudoval špecializovaný ústav. Vtedy sa objavil Windows 3.1, VGA displeje, trojpalcové diskety a prvé domáce internetové stránky. Ale tieto slová sú v norme a zákazník niekedy svojvoľne požaduje, aby sme mu poskytli kompletnú dokumentáciu v súlade s GOST 34.201-89. Navyše, takéto formulácie v ZP migrujú z jedného ministerstva na druhé a už sa stali akousi nevyslovenou šablónou, do ktorej je vtĺkaný obsah.

Takže dokument s hlúpym názvom „Výkres formulára dokumentu (videorámček)“ v projekte by mal a nemal byť prázdny.

Čo je dobré v štandarde

Akýkoľvek štandard je dobrý v tom, že umožňuje zákazníkovi a dodávateľovi hovoriť rovnakým jazykom a poskytuje záruku, že prinajmenšom zákazník nebude mať žiadne sťažnosti „vo forme“ na prenášané výsledky.

A normy GOST 34 sú dobré aj preto, že ich zostavili šikovní ľudia, rokmi otestovaní a majú jasný cieľ – čo najúplnejšie popísať na papieri komplexnú abstraktnú podstatu, ktorú predstavuje každý automatizovaný riadiaci systém.

Keď potrebujete kompetentne zadať úlohu pre západných dodávateľov, ktorí nikdy nepočuli o našich normách GOST, môžete sa spoľahnúť aj na tieto normy, respektíve na ich obsahovú a sémantickú zložku. Pretože, opakujem, záruka úplnosti informácií stojí za veľa. Bez ohľadu na to, ako veľmi si lichotíme vysokou úrovňou našej profesionality, môžeme zabudnúť zahrnúť základné veci do našich požiadaviek, zatiaľ čo ten istý GOST 34.602-89 si „pamätá“ všetko. Ak vám nie je jasné, ako by mal vyzerať výsledok práce západných dodávateľov, pozrite si požiadavky na dokumentáciu a odporúčané časti. Uisťujem vás, že je lepšie na to nemyslieť! S najväčšou pravdepodobnosťou existujú západné analógy našich štandardov, v ktorých môže byť všetko úplnejšie, modernejšie a lepšie. Žiaľ, nepoznám ich, keďže ešte nebol jediný prípad, kedy by naše normy GOST nestačili.

Môžete sa pousmiať nad tým, že tvorcovia štandardov nevedeli nič o jave alebo .NET, o HD monitoroch a internete, ale neodporúčal by som podceňovať rozsah ich práce a jej hodnotu pre našu odbornú komunitu.

Ako čítať a porozumieť normám dokumentácie podľa GOST série 34

Norma rozdeľuje všetky dokumenty podľa dvoch osí – časovej a tematickej. Ak sa pozriete na tabuľku 2 v GOST 34.201-89, môžete jasne vidieť toto rozdelenie (stĺpce „Fáza tvorby“ a „Časť projektu“

Etapy vytvárania automatizovaného riadiaceho systému

Etapy tvorby sú definované v GOST 34.601-90. Tri z nich sú relevantné pre dokumentáciu:

• Návrh návrhu (ED)
• Technický dizajn (TP)
• Vypracovanie pracovnej dokumentácie (DD)

Predbežný návrh nasleduje po fáze technických špecifikácií a slúži na vypracovanie predbežných konštrukčných riešení.

Technický projekt opisuje budúci systém zo všetkých uhlov pohľadu. Dokumenty v štádiu TP by mali po prečítaní zanechať úplnú prehľadnosť v navrhovaných prístupoch, metódach, architektonických a technických riešeniach. V ďalšej fáze bude príliš neskoro na opis prístupov a zdôvodnenie technických riešení, takže fáza P je kľúčom k úspešnému dokončeniu práce, pretože všetky rôzne požiadavky technických špecifikácií musia byť zohľadnené v dokumentoch fázy P Vo fáze P nemusí systém vôbec existovať.

Pracovná dokumentácia navrhnutý pre úspešné nasadenie, uvedenie do prevádzky a ďalšiu prevádzku nového systému. Ide o dokumenty obsahujúce veľmi špecifické informácie, ktoré popisujú fyzicky existujúce entity, na rozdiel od fázy P, ktorá opisuje budúcu nádheru.

Časti (sekcie) projektovej dokumentácie na vytvorenie automatizovaného riadiaceho systému

Predmet je rozdelený na „Ustanovenia“. Spočiatku sa zdá, že takéto rozdelenie je nadbytočné a zbytočné. Ale keď začnete pracovať s touto súpravou nástrojov v praxi, ideológia, ktorá je v nej zakotvená, sa postupne vyjasní.

Automatizovaný systém, ako ho definovali kompilátori GOST, je kombináciou hardvéru, softvéru a komunikačných kanálov, ktoré spracovávajú informácie prichádzajúce z rôznych zdrojov v súlade s určitými algoritmami a vytvárajú výsledky spracovania vo forme dokumentov, dátových štruktúr alebo kontrolných akcií. Primitívny model najjednoduchšieho guľometu.

Na úplný popis tohto „stroja“ sú vytvorené nasledujúce časti (ako na obrázku):

softvér (MS) odpovedaním na otázky: aká logika je pevne zakomponovaná do „čiernej skrinky“? Prečo boli zvolené tieto konkrétne algoritmy, tieto konkrétne vzorce a tieto konkrétne koeficienty?

Matematický softvér nevie nič o procesoroch alebo databázach. Toto je samostatná abstraktná oblasť, sídlo „guľových koní vo vákuu“. Ale matematický softvér môže veľmi úzko súvisieť s oblasťou predmetu, aka Real Life. Napríklad riadiace algoritmy pre systémy riadenia dopravy musia byť pred schválením zákazníkom schválené Štátnym inšpektorátom bezpečnosti dopravy. A potom pochopíte, prečo sú zahrnuté v samostatnej knihe. Pretože nikoho z dopravnej polície nezaujíma, na akom operačnom systéme bude aplikačný server bežať, ale to, aká značka a rýchlostný limit sa objaví na tabuli v daždi alebo snehu, je veľmi zaujímavé. Sú zodpovední za svoju časť a nič iné podpisovať nechystajú. Na druhej strane pri podpise nebudú žiadne otázky o technickej stránke veci – prečo si vybrali práve tie tabule alebo semafory a nie iné. V takýchto praktických prípadoch sa presne prejavuje múdrosť „predkov“.

Informačná podpora (IS). Ďalší kúsok systému. Tentoraz je čierna skrinka nášho systému priehľadná a my sa pozeráme na informácie, ktoré v nej kolujú. Predstavte si model ľudského obehového systému, keď sú všetky ostatné orgány neviditeľné. Niečo také je informačná podpora. Popisuje zloženie a cesty toku informácií vo vnútri a vonku, logickú organizáciu informácií v systéme, popis referenčných kníh a kódovacích systémov (tí, čo robili programy na výrobu, vedia, aké sú dôležité). Hlavná popisná časť spadá do fázy TP, ale niektoré „základy“ prechádzajú do fázy RD, ako napríklad dokument „Katalóg databázy“. Je jasné, že predtým obsahoval presne to, čo je napísané v názve. Ale dnes skúste takýto dokument vytvoriť pre zložitý komplexný systém, keď veľmi často systém využíva zakúpené podsystémy s vlastnými tajomnými informačnými skladmi. Ani nehovorím, že tento dokument teraz nie je zvlášť potrebný.

Alebo tu je „Vyhlásenie o pamäťovom médiu počítača“. Je zrejmé, že predtým obsahoval množstvo magnetických bubnov alebo kotúčov filmu. Čo tam mám teraz dať?

Stručne povedané, vo fáze RD dokumenty informačnej podpory predstavujú dosť škodlivý základ, pretože formálne by mali existovať, ale nie je potrebné ich napĺňať.

softvér. Všetkých obľúbená časť projektovej dokumentácie. Áno, už len preto, že ide len o jeden dokument! A potom každý pochopí, čo tam treba napísať. Ale aj tak to zopakujem.

V tomto dokumente vám musíme povedať, pomocou ktorého softvéru sa vykonávajú algoritmy opísané v ML, pričom spracovávajú informácie opísané v IR. To znamená, že tu nie je potrebné duplikovať informácie z iných sekcií. Tu je uvedená architektúra systému, zdôvodnenie zvolených softvérových technológií, ich popis (všetky druhy systémových vecí: programovacie jazyky, frameworky, operačné systémy atď.). V tomto dokumente tiež popisujeme, ako sú usporiadané nástroje na spracovanie informácií (fronty správ, úložisko, nástroje na zálohovanie, riešenia dostupnosti, všetky druhy aplikačných oblastí atď.). Norma obsahuje podrobný popis obsahu tohto dokumentu, ktorému bude rozumieť každý odborník.

Technická podpora (TO). Nemenej milovaná súčasť projektovej dokumentácie. Ružový obraz je len zahmlený množstvom dokumentov, ktoré je potrebné vypracovať. Celkovo štandard vyžaduje vypracovanie 22 dokumentov, z ktorých 9 je v štádiu TC.

Faktom je, že norma poskytuje popis všetkej technickej podpory vrátane počítačového hardvéru a sietí, inžinierskych systémov a dokonca aj stavebnej časti (ak je to potrebné). A táto ekonomika je regulovaná obrovským množstvom noriem a predpisov, koordinovaných v rôznych organizáciách, a preto je pohodlnejšie všetko rozdeliť na časti a skoordinovať (upraviť) po častiach. Norma zároveň umožňuje niektoré dokumenty navzájom kombinovať, čo dáva zmysel, ak celú kopu schvaľuje jedna osoba.

Nezabudnite tiež, že súbor noriem kvality zahŕňa zaznamenávanie a uchovávanie technických dokumentov a naše „knihy“ od zákazníka môžu byť distribuované do rôznych archívov v závislosti od predmetu popisu. Toto je ďalší argument v prospech fragmentácie dokumentácie.

Organizačná podpora (OO). Po potlačení túžby, normálnej pre technikov, čo najrýchlejšie preskočiť túto časť, naopak, zvážim ju podrobnejšie. Odkedy, kolegovia, nedávno sa v projektoch vyskytli zlé trendy, ktoré si vyžadujú objasnenie v tejto časti.

V štádiu TP sekcia obsahuje iba jeden dokument “ Popis organizačnej štruktúry“, v ktorej musíme zákazníkovi povedať, na čo sa má pripraviť v zmysle zmeny organizačnej štruktúry. Zrazu potrebujete zorganizovať nové oddelenie na prevádzku vášho systému, zaviesť nové pozície atď.

Vo fáze RD sa objavujú ďalšie, zaujímavejšie dokumenty, ktoré by som chcel zvážiť samostatne.

Užívateľská príručka. Komentáre sú podľa mňa zbytočné.

Metodika (technológia) počítačom podporovaného projektovania. V prípade potreby môžete do tohto dokumentu zahrnúť popis procesu tvorby softvéru, kontroly verzií, testovania atď. Ale to v prípade, ak si zákazník v technickej špecifikácii želá softvér osobne zostaviť. Ak to nevyžaduje (a neplatí za to), potom nie je jeho záležitosťou celá vaša vnútorná kuchyňa a tento dokument nie je potrebné robiť.

Technologické pokyny. Kvôli móde formalizácie obchodných procesov sa niekedy prefíkaný zákazník snaží do tohto dokumentu napchať prevádzkové predpisy. Takže toto by ste za žiadnych okolností nemali robiť.

Opis obchodných procesov, popisy úloh a práce, pracovné predpisy – to všetko je ORD, teda organizačná a administratívna dokumentácia. Čo je produktom konzultačného projektu, ktorý, pokiaľ som pochopil, nebol zakúpený u vás. A kúpili od vás technický projekt a k nemu aj technickú dokumentáciu.

Technologický návod je vrstva medzi návodom na obsluhu a návodom na použitie. Podrobne popisuje RP Ako musíte vykonať určité akcie v systéme. Hovorí to technologický návod ktoréčinnosti sa musia vykonať v určitých prípadoch súvisiacich s prevádzkou systému. Zhruba povedané, technologická inštrukcia je krátky prehľad RP pre konkrétnu pozíciu alebo rolu. Ak zákazník nemá vytvorené roly alebo chce, aby ste roly a pracovné požiadavky vytvárali sami, zahrňte do dokumentu najzákladnejšie roly, napríklad: operátor, senior operátor, administrátor. Komentáre zákazníka na tému „ale u nás to tak nie je“ alebo „nám sa to nepáči“ by malo byť doplnené zoznamom rolí a popisom pracovných povinností. Pretože obchodné procesy my nedávame to. My sme tieto obchodné procesy automatizovať.

O popísaných hrablíach budem písať samostatne s pestrými príkladmi, keďže to nie je prvýkrát, čo sa to v rôznych odvetviach „národného hospodárstva“ opakuje.

Popis technologického procesu spracovania dát (vrátane teleprocessingu). Úbohý pozostatok jaskynného veku, keď tam boli špeciálne určení „počítači operátori“, ktorí dávali dierne štítky do stroja a zabalili výtlačok výsledku do obálky. Tento návod je pre nich. Nemôžem vám presne povedať, čo do nej napísať v 21. storočí. Vypadni sami. Najlepšie je na tento dokument zabudnúť.

Systémové riešenia (WSO). Norma počíta so 17 dokladmi v časti OP. Po prvé, toto sú takmer všetky dokumenty prípravnej fázy Schematic Design. Po druhé, sú to všetky druhy odhadov, výpočtov a stručných popisov automatizovaných funkcií. Teda informácie pre ľudí nie z hlavnej IT produkcie, ale pre pomocný personál – manažérov, odhadcov, nákupných špecialistov, ekonómov atď.

A do tretice OP obsahuje megadokument s názvom “Vysvetlivka k technickému projektu”, ktorý má byť akýmsi Executive Summary, no v skutočnosti doň mnohí dizajnéri strčia všetok užitočný obsah etapy TP. Takýto radikálny prístup môže byť opodstatnený a dokonca obojstranne výhodný pre objednávateľa aj zhotoviteľa, avšak v určitých prípadoch.

Možnosti použitia GOST 34

1. Úplné a presné dodržiavanie normy. Prirodzene, takýto oblak dokumentov nikto dobrovoľne nenapíše. Kompletný súbor podkladov sa preto vyhotovuje až na urgentnú žiadosť zákazníka, ktorú si zabezpečil v technických špecifikáciách a navrch dohodol. V tomto prípade musíte brať všetko doslovne a dať zákazníkovi fyzické „knihy“, na ktorých budú názvy dokumentov z tabuľky 2 GOST 34.201-89, s výnimkou úplne nepotrebných, ktorých zoznam musia písomne ​​prerokovať a zabezpečiť. Obsah dokumentov musí tiež bez akejkoľvek predstavivosti zodpovedať RD 50-34.698-90, až po názvy sekcií. Aby zákazníkovi vybuchol mozog, niekedy sa veľký systém rozdelí na podsystémy a pre každý podsystém sa vydá samostatná projektová dokumentácia. Vyzerá hrôzostrašne a nepodlieha bežnej kontrole pomocou pozemskej mysle. Najmä pokiaľ ide o integráciu podsystémov. Čo výrazne zjednodušuje prijatie. Hlavné je, aby ste sa vy sami nezmýlili a aby váš systém stále fungoval tak, ako má.
2. Jednoducho milujeme normy GOST. Vážne veľké spoločnosti milujú štandardy. Pretože pomáhajú ľuďom lepšie si porozumieť. Ak je váš zákazník známy svojou láskou k poriadku a štandardizácii, snažte sa pri tvorbe dokumentov dodržiavať štandardnú ideológiu GOST, aj keď to technické špecifikácie nevyžadujú. Schvaľujúci špecialisti vám budú lepšie rozumieť a schvaľovať a vy sami nezabudnete zahrnúť dôležité informácie do dokumentácie, lepšie uvidíte cieľovú štruktúru dokumentov, presnejšie si naplánujete prácu pri ich písaní a ušetríte si svojim kolegom veľa nervov a peňazí.
3. Nestaráme sa o dokumentáciu, pokiaľ všetko funguje. Miznúci vzhľad nezodpovedného zákazníka. Podobný pohľad na dokumentáciu možno stále nájsť medzi malými a chudobnými zákazníkmi, ako aj v autoritárskych „idiotokraciách“, ktoré zostali z čias perestrojky, kde je šéf obklopený lojálnymi priateľmi - režisérmi a všetky problémy sa riešia v osobných rozhovoroch. . V takýchto podmienkach môžete dokumentáciu úplne zanedbávať, ale je predsa len lepšie nezraziť zrak a dokumentáciu aspoň schematicky doplniť obsahom. Ak nie tomuto zákazníkovi, tak ho odovzdajte (predajte) ďalšiemu.

Záver

Tento článok sa týkal našich noriem GOST pre dokumentáciu automatizovaných riadiacich systémov. GOST sú staré, ale ako sa ukázalo, v domácnosti sú stále veľmi užitočné. Štruktúra dokumentácie má odhliadnuc od niektorých samozrejmých základov vlastnosti úplnosti a konzistentnosti a dodržanie štandardu eliminuje mnohé riziká projektu, o ktorých existencii si najskôr nemusíme byť vedomí.

Dúfam, že prezentovaný materiál bol pre vás užitočný alebo aspoň zaujímavý. Napriek zjavnej únavnosti je dokumentácia dôležitou a zodpovednou prácou, pri ktorej je presnosť rovnako dôležitá ako písanie dobrého kódu. Napíšte dobré dokumenty, kolegovia! A budúci týždeň idem na dve služobné cesty za sebou, takže zverejnenie nových materiálov nemôžem zaručiť (nemám cache, píšem z hlavy).

Úvod

V modernom svete sa denne objavujú desiatky a stovky rôznych programov, aplikácií a informačných systémov. Môžu byť vyvinuté pre vládny alebo komerčný sektor, ako aj pre bežných používateľov. 90% všetkých používateľov nečíta dokumentáciu, považuje ju za nudnú, zdĺhavú a nezaujímavú a používateľskú príručku otvára až vtedy, keď niečo nefunguje alebo je úplne nemožné na to prísť bez návodu. Teraz je bežnou praxou navrhnúť používateľské rozhranie tak, aby bolo intuitívne a používateľ mohol pochopiť systém bez toho, aby musel čítať dlhé návody. Pri práci s veľkými zákazníkmi je však takmer vždy potrebné predložiť určitý balík dokumentov - príručky, pokyny, konštrukčné riešenia vypracované v súlade s GOST.
Keď sa prvýkrát stretnete s písaním dokumentácie v súlade s GOST, ste ohromení a úplne šokovaní, pretože existuje „more“ týchto GOST a nie je jasné, ako a čo podľa nich písať.
Tento článok sa zaoberá normami GOST pre písanie dokumentácie a ich hlavnými bodmi.

Aké sú normy GOST?

Najprv musíte pochopiť, aké sú normy GOST. Každý vie, že GOST je niečo, čo bolo vyvinuté v rámci Únie a je ich jednoducho nekonečné množstvo. Ponáhľam sa vás uistiť, že pre sektor IT nie je veľa GOST a všetky, napriek času ich vytvorenia, nestratili svoj význam.
Po prvé, štandardy pre písanie dokumentácie sú rozdelené do dvoch typov:

1. Medzinárodné normy (ISO, IEEE Std);
2. Ruské alebo sovietske GOST.

Medzinárodné normy
Na vypracovanie dokumentácie na medzinárodnej úrovni sa používajú medzinárodné normy. Spravidla nie sú zadarmo, pretože ich nevyvíjajú vládne organizácie, ale na rozdiel od našich boli vyvinuté pomerne nedávno. Téma medzinárodných štandardov je veľmi široká, preto sa jej budeme venovať v inom článku. Dotkne sa aj niekoľkých noriem, ktoré úzko súvisia s písaním dokumentácie.
Zoznam hlavných medzinárodných štandardov pre písanie dokumentácie:

1. IEEE Std 1063-2001 “IEEE Standard for Software User Documentation” - štandard pre písanie užívateľských manuálov;
2. IEEE Std 1016-1998 “IEEE Odporúčaná prax pre popisy návrhov softvéru” – štandard pre písanie technického popisu programu;
3. ISO/IEC FDIS 18019:2004 „Pokyny pre návrh a prípravu používateľskej dokumentácie pre aplikačný softvér“ je ďalším štandardom pre písanie používateľských príručiek. V tomto dokumente je veľké množstvo príkladov. Takpovediac je to skôr návod na písanie užívateľskej príručky. Bude to užitočné najmä pre začínajúcich špecialistov;
4. ISO/IEC 26514:2008 „Požiadavky na dizajnérov a vývojárov užívateľskej dokumentácie“ je ďalšou normou pre dizajnérov a vývojárov užívateľskej dokumentácie.

V skutočnosti existuje veľa medzinárodných štandardov a každá krajina má svoje vlastné, keďže rovnaký štandard nemusí vždy vyhovovať európskym aj ázijským spoločnostiam.

Ruské štandardy
Ruské normy sa vyvíjajú na štátnej úrovni. Všetky sú úplne zadarmo a každý z nich sa dá ľahko nájsť na internete. Na písanie dokumentácie k programu sa používajú dve série GOST 19 a 34. Práve o nich sa bude ďalej diskutovať.

Aký je rozdiel medzi GOST sériami 19 a 34?

Prvá otázka, ktorá vzniká, je, ako sa tieto GOST 19 a 34 vo všeobecnosti navzájom líšia.
V GOST 19.781-90 „Jednotný systém programovej dokumentácie. Softvér pre systémy spracovania informácií. Termíny a definície“ sú uvedené definície:

1. Program - dáta určené na riadenie špecifických komponentov systému spracovania informácií za účelom implementácie špecifického algoritmu.
2. Softvér je súbor programov systému na spracovanie informácií a programových dokumentov potrebných na fungovanie týchto programov.

V GOST 34.003-90 „Informačné technológie. Súbor noriem pre automatizované systémy. Automatizované systémy. Termíny a definície“ definícia je uvedená:

1. Automatizovaný systém (AS) - systém pozostávajúci z personálu a súboru automatizačných nástrojov pre ich činnosť, implementujúci informačné technológie na vykonávanie stanovených funkcií.
   Podľa druhu činnosti sa rozlišujú napríklad tieto typy AS: automatizované riadiace systémy (ACS), počítačové systémy projektovania (CAD), automatizované systémy vedeckého výskumu (ASRS) a iné.

Podľa typu riadeného objektu (procesu) sa automatizované systémy riadenia delia napríklad na: automatizované systémy riadenia technologických procesov (ACS), automatizované systémy riadenia pre podniky (ACS) atď.
GOST 34 tiež delí na typy podpory AS:

1. Organizačné;
2. Metodický;
3. Technické;
4. matematické;
5. Softvér;
6. Informačné;
7. lingvistické;
8. právne;
9. Ergonomický.

Výsledkom je, že automatizovaný systém nie je program, ale komplex typov softvéru vrátane softvéru. AS spravidla nesie organizačné riešenie pre konkrétneho užívateľa a zákazníka a Program môže byť vytvorený a replikovaný pre veľký počet užívateľov bez toho, aby bol viazaný na akýkoľvek podnik.
Preto, ak vyvíjate dokumentáciu pre program, ktorý ste vytvorili pre konkrétny podnik, potom je váš GOST 34. Ak píšete dokumenty pre hromadný program, potom je váš GOST 19.

GOST 34

Séria GOST 34 (Normy informačných technológií GOST 34.xxx) pozostáva z:

1. GOST 34.201-89 Typy, úplnosť a označenia dokumentov pri vytváraní automatizovaných systémov - táto norma stanovuje typy, názov, úplnosť a čísla dokumentov. Je to jeden z hlavných dokumentov série GOST 34. V skutočnosti ide o základný dokument, takže začiatočníci sa s ním musia najskôr zoznámiť.
2. GOST 34.320-96 Koncepty a terminológia pre koncepčné schémy a informačné bázy - táto norma stanovuje základné pojmy a termíny koncepčných schém a informačných báz, ktoré zahŕňajú vývoj, popis a aplikáciu koncepčných schém a informačných báz, manipuláciu s informáciami, ako aj popis a realizácia informačného procesu. Norma definuje úlohu pojmového diagramu. Ustanovenia v ňom uvedené majú poradný charakter a možno ich použiť na hodnotenie systémov správy databáz (DBMS). Tento dokument nepopisuje špecifické metódy na používanie nástrojov na podporu koncepčných diagramov. Jazyky koncepčných schém popísané v norme by sa nemali považovať za štandardné jazyky.
3. GOST 34.321-96 Informačné technológie. Systém databázových štandardov. Referenčný model riadenia – Tento dokument stanovuje referenčný model riadenia údajov.
   Referenčný model definuje spoločnú terminológiu a pojmy súvisiace s údajmi informačných systémov. Takéto pojmy sa používajú na definovanie služieb poskytovaných systémami správy databáz alebo systémami údajových slovníkov.
   Referenčný model nezohľadňuje protokoly na správu údajov.
   Rozsah referenčného modelu zahŕňa procesy, ktoré sa zaoberajú správou perzistentných údajov a ich interakciou s procesmi odlišnými od požiadaviek konkrétneho informačného systému, ako aj všeobecné služby správy údajov na definovanie, ukladanie, vyhľadávanie, aktualizáciu, zadávanie, kopírovanie , obnovenie a prenos dát.
4. GOST 34.601-90 Automatizované systémy. Etapy tvorby - norma stanovuje etapy a etapy tvorby AS.
5. GOST 34.602-89 Technické špecifikácie na vytvorenie automatizovaného systému (Namiesto GOST 24.201-85) - stanovuje zloženie, obsah, pravidlá pre vypracovanie dokumentu „Zadávacie podmienky pre vytvorenie (vývoj alebo modernizáciu) systému. “
   Tento dokument je jedným z často používaných dokumentov v sérii GOST 34. Pri vývoji technických špecifikácií pre tento GOST by ste mali pamätať na iné normy, aj keď tento dokument neobsahuje odkazy na tieto normy.
6. GOST 34.603-92 Informačné technológie. Typy testov automatizovaných systémov - norma stanovuje typy testov AS (autonómne, komplexné, akceptačné testy a skúšobná prevádzka) a všeobecné požiadavky na ich implementáciu.
7. RD 50-34.698-90 Automatizované systémy. Požiadavky na obsah dokumentov sú jedným z najdôležitejších dokumentov GOST 34, pretože popisuje obsah takmer všetkých dokumentov, ako aj popis každého odseku dokumentu.
8. GOST R ISO/IEC 8824-3-2002 Informačné technológie. Abstract Syntax Notation Version One – Tento štandard je súčasťou Abstract Syntax Notation Version 1 (ASN.1) a vytvára notáciu pre špecifikáciu užívateľom definovaných obmedzení a obmedzení tabuliek.
9. GOST R ISO/IEC 10746-3-2001 Správa údajov a otvorené distribuované spracovanie.
   V tomto štandarde:
   • určuje sa, ako sú špecifikované systémy otvoreného distribuovaného spracovania (ODP) pomocou pojmov zavedených v GOST R ISO/IEC 10746-2;
   • Boli identifikované charakteristiky, podľa ktorých systémy patria do systémov OPO.

   Norma vytvára rámec pre koordináciu vývoja noriem pre systémy ODP.

10. GOST R ISO/IEC 15271-02 Procesy životného cyklu softvéru - tento GOST je podľa môjho názoru potrebný viac pre analytikov pri navrhovaní a modelovaní AS.
    Tento dokument je z môjho pohľadu užitočný na čisto vzdelávacie účely.
11. GOST R ISO/IEC 15910-2002 Proces vytvárania užívateľskej dokumentácie pre softvérový nástroj - definuje minimálny požadovaný proces vytvárania užívateľskej dokumentácie všetkých typov pre softvérový nástroj, ktorý má užívateľské rozhranie. Tieto typy zahŕňajú tlačenú dokumentáciu (napríklad používateľské príručky a rýchle referenčné karty), online dokumentáciu, text pomocníka a online dokumentačné systémy.

Takže na základe všetkého napísaného vyššie je zrejmé, že hlavné dokumenty v GOST 34 sú 3: GOST 34.201-89, RD 50-34.698-90 a GOST 34.602-89.
Pri vývoji balíka dokumentácie musíte najskôr otvoriť GOST 34.201-89 a vybrať fázu vytvorenia: Návrh návrhu, Technický návrh a Pracovná dokumentácia. Ďalej by ste mali vybrať dokumenty na vývoj, ktoré zodpovedajú štádiu vytvorenia.

Zoznam dokumentov 34 GOST

Etapa tvorba	Názov dokumentu	kód	Časť projektu	Prinad posteľ do projektu ale-odhad Noah Doku policajt cie	Prinad posteľ do vykorisťovanie stanica noah hore kumen staníc	Ďalšie pokyny
EP	Hárok predbežného návrhu	EP*	ALEBO	—	—	—
	Vysvetľujúca poznámka K predbežnému návrhu	P1	ALEBO	—	—	—
EP, TP	Organizačná schéma	CO	ALEBO	—	—	Do dokumentu je povolené zahrnúť P3 alebo PV
	Schéma štruktúry komplexu technické prostriedky	C1*	TO	X	—
	Schéma funkčnej štruktúry	C2*	ALEBO	—	—	Pri vývoji dokumentov CO, C1, C2, C3 v štádiu ES je povolené zahrnúť ich do dokumentu P1
	špecializované (nové) technické prostriedky	O 9	TO	X	—	Pri vývoji v technickom štádiu povolené zahrnúť do dokumentu P2
	Schéma automatizácie	C3*	TO	X	—	—
	Technické špecifikácie pre vývoj špecializované (nové) technické prostriedky	—	TO	—	—	Projekt nezahŕňa
TP	Rozvojové úlohy sanitárne a ďalšie sekcie súvisiaci s projektom s vytvorením systému	—	TO	X	—	Projekt nezahŕňa
	Technický návrhový list	TP*	ALEBO	—	—	—
	Zoznam zakúpených položiek	viceprezident*	ALEBO	—	—	—
	Zoznam vstupných signálov a údaje	V 1	A O	—	—	—
	Zoznam výstupných signálov (Dokumenty)	AT 2	A O	—	—	—
	Zoznam vývojových úloh stavebníctvo, elektro, sanitárne a ďalšie sekcie súvisiaci s projektom s vytvorením systému	AT 3	TO	X	—	Do dokumentu je povolené zahrnúť P2
	Vysvetľujúca poznámka k technickému projektu	P2	ALEBO	—	—	Zahŕňa plán udalosti o príprave objektu na zadanie systémy do prevádzky
	Popis automat funkcie	P3	ALEBO	—	—	—
	Popis nastavenia úlohy (súbor úloh)	P4	ALEBO	—	—	Povolené zahrnúť na dokumenty P2 alebo P3
	Popis informácií zabezpečenie systému	P5	A O	—	—	—
	Popis organizácie informačnú základňu	P6	A O	—	—	—
TP	Popis klasifikačných systémov a kódovanie	P7	A O	—	—	—
	Popis poľa informácie	P8	A O	—	—	—
	Popis komplexu technické prostriedky	P9	TO	—	—	Pre úlohu je povolené zahrnúť do dokumentu 46 podľa GOST 19.101
	Popis softvéru ustanovenie	PA	BY	—	—	—
	Popis algoritmu (projektový postup)	PB	MO	—	—	V dokumentoch je povolené uvádzať P2, P3 alebo P4
	Popis organizačného štruktúry	PV	OO	—	—	—
	Plán rozloženia	C8	TO	X	—	Do dokumentu je povolené zahrnúť P9
	Zoznam vybavenia a materiálov	—	TO	X	—	—
	Výpočet miestneho odhadu	B2	ALEBO	X	—	—
TP, RD	Hodnotenie projektu spoľahlivosť systému	B1	ALEBO	—	—	—
	Výkres formulára dokumentu (rámček videa)	C9	A O	—	X	V štádiu TP je to povolené zahrnúť do dokumentov P4 alebo P5
RD	Zoznam držiteľov originály	DP*	ALEBO	—	—	—
	Operačný list Dokumenty	ED*	ALEBO	—	X	—
	Hardvérová špecifikácia	AT 4	TO	X	—	—
	Zoznam požiadaviek v materiáloch	O 5	TO	X	—	—
	Inventár strojových médií informácie	VM*	A O	—	X	—
	Vstupné pole	O 6	A O	—	X	—
RD	Databázový adresár	O 7	A O	—	X	—
	Zloženie výstupných údajov (správy)	O 8	A O	—	X	—
	Miestne odhady	B3	ALEBO	X	—	—
	Metodológia (technológia) automatizované dizajn	I1	OO	—	X	—
	Technologické pokyny	A 2	OO	—	X	—
	Užívateľská príručka	I3	OO	—	X	—
	Návod na formovanie a údržba databázy (množina údajov)	I4	A O	—	X	—
	Návod na obsluhu KTS	IE	TO	—	X	—
	Schéma externého zapojenia	C4*	TO	X	—	Povolené vykonávať v vo forme tabuliek
	Schéma zapojenia externé príspevky	C5*	TO	X	—	To isté
	Tabuľka spojení a spojení	C6	TO	X	—	—
	Schéma delenia systému (štrukturálne)	E1*	TO	—	—	—
	Všeobecná kresba	IN*	TO	X	—	—
	Inštalačný výkres technického zariadenia	SA	TO	X	—	—
	Schematický diagram	SB	TO	X	—	—
	Schéma štruktúry komplexu technické prostriedky	C1*	TO	X	—	—
	Plán rozmiestnenia zariadenia a rozvodov	C7	TO	X	—	—
	Popis technologických proces spracovania údaje (vrátane teleprocessing)	PG	OO	—	X	—
	Všeobecný popis systému	PD	ALEBO	—	X	—
	Testovací program a metodika (komponenty, automatizačné systémy, subsystémy, systémy)	POPOLUDNIE*	ALEBO	—	—	—
	Formulár	FO*	ALEBO	—	X	—
	pas	PS*	ALEBO	—	X	—
*Dokumenty, ktorých kód je nastavený v súlade s požiadavkami noriem ESKD

Poznámka k tabuľke:

1. V tabuľke sa používajú nasledujúce označenia:
   • EP - predbežný návrh;
   • TP - technický projekt;
   • RD - pracovná dokumentácia;
   • OR - celosystémové riešenia;
   • OO - rozhodnutia o organizačnom zabezpečení;
   • TO - riešenia pre technickú podporu;
   • IO - riešenia pre informačnú podporu;
   • Softvér - softvérové ​​riešenia;
   • MO - softvérové ​​riešenia.
2. Znak X označuje, že patrí k projektovým odhadom alebo prevádzkovej dokumentácii.
3. Nomenklatúra dokumentov s rovnakým názvom sa stanovuje v závislosti od návrhových rozhodnutí prijatých počas vytvárania systému.

Po určení zoznamu dokumentov by ste mali v RD 50-34.698-90 nájsť vybrané dokumenty a rozvinúť ich presne podľa špecifikovaných bodov. Všetky uvedené body obsahu musia byť v dokumente.
Ak sa technické špecifikácie vyvíjajú, musíte okamžite otvoriť GOST 34.602-89 a vypracovať technické špecifikácie presne v súlade s bodmi.

GOST 19

Séria GOST 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) pozostáva z:

1. 1. GOST 19.001-77 Všeobecné ustanovenia - príliš všeobecný dokument, nemá praktické využitie. Preto ho môžete preskočiť.
   2. GOST 19781-90 Termíny a definície - dobrý zoznam definícií v oblasti softvéru pre systémy spracovania informácií. Neobsahuje nič viac ako definície.
   3. GOST 19.101-77 Typy programov a programových dokumentov - jeden z hlavných dokumentov 19 GOST. Tu by ste mali začať pracovať s GOST 19, pretože obsahuje úplný zoznam a označenia dokumentov GOST.

Zoznam dokumentov 19 GOST

kód	Typ dokumentu	Vývojové štádiá
		útržkovité projektu	Technická projektu	Pracovný návrh
				komponent	komplexné
—	Špecifikácia	—	—
05	Zoznam pôvodných držiteľov	—	—	—
12	Text programu	—	—
13	Popis programu	—	—
20	Zoznam prevádzkových dokumentov	—	—
30	Formulár	—	—
31	Popis aplikácie	—	—
32	Príručka systémového programátora	—	—
33	Príručka programátora	—	—
34	Návod na obsluhu	—	—
35	Popis jazyka	—	—
46	Technická príručka služby	—	—
51	Testovací program a metodika	—	—
81	Vysvetľujúca poznámka			—	—
90-99	Ostatné dokumenty

Legenda:
— dokument je povinný;
— dokument je povinný pre komponenty, ktoré sa používajú nezávisle;
— potreba vypracovať dokument je určená v štádiu vývoja a schvaľovania technických špecifikácií;
- dokument nie je vyhotovený.

1. GOST 19.102-77 Etapy vývoja - obsahuje popis etáp vývoja. Užitočné na vzdelávacie účely. Podľa mňa to nemá veľký praktický prínos.
2. GOST 19.103-77 Označenia programov a programových dokumentov - obsahuje popis priradenia čísla (kódu) dokumentu. Aj po prečítaní tohto GOST zostáva veľa otázok o tom, ako priradiť rovnaké číslo dokumentu.
3. GOST 19.104-78 Hlavné nápisy - stanovuje formy, veľkosti, umiestnenie a postup vypĺňania hlavných nápisov schvaľovacieho listu a titulnej strany v programových dokumentoch stanovených normami ESPD bez ohľadu na spôsoby ich implementácie. Keďže dokumenty 19 GOST sú zostavené v rámoch, tento dokument je veľmi dôležitý.
4. GOST 19.105-78 Všeobecné požiadavky na programové dokumenty – stanovuje všeobecné požiadavky na prípravu programových dokumentov. Požiadavky sú príliš všeobecné. Spravidla sa tento GOST takmer nepoužíva na vývoj dokumentu, pretože stačí špeciálny GOST pre dokument, ale pre všeobecné znalosti je stále lepšie sa do tohto GOST pozrieť raz.
5. GOST 19.106-78 Požiadavky na programové dokumenty vykonávané v tlačenej forme - obsahuje požiadavky na vykonávanie všetkých dokumentov 19 GOST.
6. GOST 19.201-78 Technické špecifikácie, požiadavky na obsah a dizajn – stanovuje postup konštrukcie a prípravy technických špecifikácií pre vývoj programu alebo softvérového produktu.

   Ustanovenia technických špecifikácií 34 GOST a 19 GOST sú odlišné.

7. GOST 19.601-78 Všeobecné pravidlá pre rozmnožovanie, účtovanie a skladovanie - všeobecné pravidlá pre rozmnožovanie, obeh, účtovanie a ukladanie programových dokumentov. GOST v niekoľkých bodoch popisuje, ako zabezpečiť, aby sa dokumenty nestratili.
8. GOST 19.602-78 Pravidlá pre duplikáciu, účtovanie a ukladanie programových dokumentov, tlač. Metóda - dodatok k GOST 19.601-78.
9. GOST 19.603-78 Všeobecné pravidlá pre vykonávanie zmien - stanovuje všeobecné pravidlá pre vykonávanie zmien v programových dokumentoch. V podstate popisuje dlhý byrokratický algoritmus na vykonávanie zmien v dokumentoch.
10. GOST 19.604-78 Pravidlá na vykonávanie zmien v programových dokumentoch vykonaných v tlači - popisuje postup práce a vypĺňania registračného listu zmien.

Zoznam špecializovaných GOST, to znamená, že každá z nich popisuje obsah a požiadavky na konkrétny dokument:

1. Špecifikácia GOST 19.202-78. Požiadavky na obsah a dizajn;
2. GOST 19.301-79 Testovací program a metodika. Požiadavky na obsah a dizajn;
3. GOST 19.401-78 Text programu. Požiadavky na obsah a dizajn;
4. GOST 19.402-78 Popis programu;
5. GOST 19.403-79 Zoznam pôvodných držiteľov;
6. GOST 19.404-79 Vysvetlivka. Požiadavky na obsah a dizajn;
7. Formulár GOST 19.501-78. Požiadavky na obsah a dizajn;
8. GOST 19.502-78 Popis aplikácie. Požiadavky na obsah a dizajn;
9. GOST 19.503-79 Príručka systémového programátora. Požiadavky na obsah a dizajn;
10. GOST 19.504-79 Príručka programátora. Požiadavky na obsah a dizajn;
11. GOST 19.505-79 Návod na obsluhu. Požiadavky na obsah a dizajn;
12. GOST 19.506-79 Popis jazyka. Požiadavky na obsah a dizajn;
13. GOST 19.507-79 Výpis prevádzkových dokumentov;
14. GOST 19.508-79 Návod na údržbu. Požiadavky na obsah a dizajn.

Postup pri práci s 19 GOST:

1. V GOST 19.101-77 vyberte dokument a jeho kód podľa štádia vývoja.
2. Podľa GOST 19.103-77 priraďte dokumentu číslo.
3. Potom podľa GOST 19.104-78 a 19.106-78 vypracujte dokument.
4. Zo špecializovaného zoznamu GOST by ste mali vybrať ten, ktorý zodpovedá vyvíjanému dokumentu.

Záver

GOST nie je strašidelný a jednoduchý! Hlavná vec je pochopiť, čo je potrebné napísať a ktorý GOST sa na to používa. Naše hlavné GOST 19 a 34 na písanie dokumentácie sú veľmi staré, ale dodnes sú relevantné. Písanie dokumentácie podľa normy odstraňuje mnohé problémy medzi zhotoviteľom a objednávateľom. V dôsledku toho šetrí čas a peniaze.

Dátum zavedenia 01/01/92

Táto norma sa vzťahuje na automatizované systémy (AS) používané v rôznych typoch činností (výskum, projektovanie, riadenie atď.), vrátane ich kombinácií vytvorených v organizáciách, združeniach a podnikoch (ďalej len organizácie).

Norma stanovuje etapy a etapy vytvárania AS. V prílohe 1 je uvedený obsah práce v každej fáze.

1. Všeobecné ustanovenia

2. Etapy a etapy tvorby AS

Dodatok 1 (pre referenciu)

Dodatok 2 (odkaz)

1. VŠEOBECNÉ USTANOVENIA

1.1. je súbor prác časovo objednaných, vzájomne prepojených, spojených do etáp a fáz, ktorých realizácia je potrebná a postačujúca na vytvorenie automatizovaného systému, ktorý spĺňa stanovené požiadavky.

1.2. Etapy a fázy tvorby AS sa rozlišujú ako súčasti procesu tvorby z dôvodov racionálneho plánovania a organizácie práce končiacej daným výsledkom.

1.3. Práce na vývoji AS prebiehajú podľa etáp a krokov použitých na vytvorenie AS.

1.4. Zloženie a pravidlá pre vykonávanie prác v etapách a etapách ustanovených touto normou sú určené v príslušnej dokumentácii organizácií podieľajúcich sa na vytváraní konkrétnych typov jadrových elektrární.

Zoznam organizácií zapojených do vytvárania jadrových elektrární je uvedený v prílohe 2.

2. ETAPA A ETAPA VZNIKU AS

2.1. Fázy a fázy vytvárania AS sú vo všeobecnosti uvedené v tabuľke.

Etapy	Etapy práce
1. Formovanie požiadaviek na rečníkov	1.1. Kontrola zariadenia a zdôvodnenie potreby vytvorenia jadrovej elektrárne
	1.2. Formovanie požiadaviek používateľov na reproduktory
	1.3. Vypracovanie správy o vykonanej práci a žiadosti o vývoj AS (taktické a technické špecifikácie)
2. Vývoj koncepcie AC	2.1. Štúdium objektu
	2.2. Vykonávanie potrebných výskumných prác
	2.3. Vývoj možností koncepcie AC a výber možnosti koncepcie AC, ktorá spĺňa požiadavky užívateľov
	2.4. Vypracovanie protokolu o vykonanej práci
3. Referenčné podmienky	3.1. Vypracovanie a schválenie technických špecifikácií pre výstavbu jadrových elektrární
4. Návrh návrhu	4.1. Vývoj predbežných konštrukčných riešení systému a jeho častí
	4.2. Vypracovanie dokumentácie k reproduktorovej sústave a jej časti
5. Technické prevedenie	5.1. Vývoj konštrukčných riešení systému a jeho častí
	5.2. Vypracovanie dokumentácie k reproduktorovej sústave a jej časti
	5.3. Vypracovanie a vyhotovenie dokumentácie na dodávku produktov na dostavbu JE a (alebo) technických požiadaviek (technických špecifikácií) na ich vypracovanie
	5.4. Vývoj projektových úloh v priľahlých častiach projektu automatizačného zariadenia
6. Pracovná dokumentácia	6.1. Vypracovanie pracovnej dokumentácie pre systém a jeho časti
	6.2. Vývoj alebo prispôsobenie programov
7. Vstup a akcia	7.1. Príprava objektu automatizácie na uvedenie JE do prevádzky
	7.2. Školenie personálu
	7.3. Kompletná sada reproduktorov s dodávanými produktmi (softvér a hardvér, softvérové ​​a hardvérové ​​systémy, informačné produkty)
	7.4. Stavebné a inštalačné práce
	7.5. Kolaudačné práce
	7.6. Vykonávanie predbežných testov
	7.7. Vykonávanie skúšobnej prevádzky
	7.8. Vykonávanie akceptačných skúšok
8. AC podpora	8.1. Vykonávanie prác v súlade so záručnými povinnosťami
	8.2. Pozáručný servis

2.2. Etapy a míľniky vykonávané organizáciami podieľajúcimi sa na výstavbe jadrových elektrární sú stanovené v zmluvách a technických špecifikáciách založených na tejto norme.

Vo všetkých fázach je možné vylúčiť fázu „Návrh skice“ a jednotlivé fázy prác, spojiť fázy „Technický návrh“ a „Pracovná dokumentácia“ do jednej fázy „Podrobný technický návrh“. V závislosti od špecifík vytváraných AS a podmienok pre ich vznik je povolené vykonávať jednotlivé etapy prác pred ukončením predchádzajúcich etáp, súbežné vykonávanie etáp prác, prípadne zaraďovanie nových etáp prác.

DODATOK 1.Pre referenciu

1. V etape 1.1 „Kontrola zariadenia a zdôvodnenie potreby vytvorenia JE“ sa vo všeobecnom prípade vykonáva:

• zhromažďovanie údajov o objekte automatizácie a typoch vykonávaných činností;
• hodnotenie kvality fungovania zariadenia a druhov vykonávaných činností, identifikácia problémov, ktoré je možné riešiť pomocou automatizačných nástrojov;
• posúdenie (technického, ekonomického, sociálneho, atď.) realizovateľnosti vytvorenia JE.

2. Vo fáze 1.2 „tvorba užívateľských požiadaviek na reproduktory“ sa vykonáva nasledovné:

• príprava prvotných podkladov pre tvorbu požiadaviek na automatizovaný systém (charakteristika objektu automatizácie, popis požiadaviek na systém, obmedzenia prijateľných nákladov na vývoj, uvedenie do prevádzky a prevádzku, efekt očakávaný od systému, podmienky na vytvorenie a prevádzka systému);
• formulácia a realizácia požiadaviek používateľov na reproduktory.

3. V etape 1.3 „Vypracovanie správy o vykonanej práci a žiadosti o vývoj AS (taktické a technické špecifikácie)“, správu o práci vykonanej v tejto fáze a žiadosť o vývoj AS (taktické a technické špecifikácie) alebo iný dokument, ktorý ho nahrádza, sú doplnené podobným obsahom.

4. V etapách 2.1 „Štúdium objektu“ a 2.2 „Vykonanie potrebných výskumných prác“ vývojová organizácia vykonáva podrobnú štúdiu objektu automatizácie a potrebné výskumné práce (R&D) súvisiace s hľadaním spôsobov a hodnotením možnosti implementuje požiadavky užívateľov, vypracúva a schvaľuje výskumné správy.

5. V etape 2.3 „Vývoj možností koncepcie AS a výber možnosti koncepcie AS, ktorá spĺňa požiadavky užívateľa“ sú vo všeobecnosti alternatívne možnosti vytváranej koncepcie AS a plány ich implementácie. vyvinuté; posúdenie potrebných zdrojov na ich realizáciu a údržbu; posúdenie výhod a nevýhod každej možnosti; porovnanie užívateľských požiadaviek a vlastností navrhovaného systému a výber optimálnej možnosti; určenie postupu posudzovania kvality a podmienok na akceptovanie systému; hodnotenie účinkov získaných zo systému.

6. V etape 2.4 „Vypracovať správu o vykonanej práci“ pripraviť a vypracovať správu obsahujúcu popis vykonanej práce v etape, popis a zdôvodnenie navrhovanej verzie koncepcie systému.

7. V etape 3.1 „Vypracovanie a schvaľovanie technických špecifikácií pre výstavbu jadrovej elektrárne“ vypracovanie, realizácia, koordinácia a schvaľovanie technických špecifikácií jadrovej elektrárne a v prípade potreby technických špecifikácií častí jadrovej elektrárne elektráreň sa vykonávajú.

8. V etape 4.1 „Vývoj predbežných konštrukčných riešení pre systém a jeho časti“ určiť: funkcie AS; funkcie subsystémov, ich ciele a účinky; skladba komplexov úloh a jednotlivých úloh; koncepcie informačnej základne, jej rozšírenej štruktúry; funkcie systému správy databáz; zloženie počítačového systému; funkcie a parametre základného softvéru.

9. V etape 5.1 „Vývoj konštrukčných riešení systému a jeho častí“ zabezpečujú vypracovanie všeobecných riešení systému a jeho častí, funkčno-algoritmickej štruktúry systému, funkcií personálnej a organizačnej štruktúry, štruktúra technických prostriedkov, algoritmy na riešenie problémov a používané jazyky, na organizovanie a udržiavanie informačnej základne, systém klasifikácie a kódovania informácií, na softvéri.

10. V etapách 4.2 a 5.2 „Vypracovanie dokumentácie pre JE a jej časti“ sa vykonáva vypracovanie, vyhotovenie, koordinácia a schválenie dokumentácie v rozsahu potrebnom na opísanie celého súboru prijatých projektových rozhodnutí a postačujúceho na ďalšie realizácia prác na vytvorení JE. Typy dokumentov - podľa GOST 34.201.

11. V etape 5.3 „Vypracovanie a vyhotovenie dokumentácie na dodávku produktov dostavby JE a (alebo) technických požiadaviek (technických špecifikácií) na ich vypracovanie“ sa realizuje príprava a vyhotovenie dokumentácie na dodávku produktov dostavby JE. ; stanovenie technických požiadaviek a vypracovanie technických špecifikácií pre vývoj produktov, ktoré nie sú sériovo vyrábané.

12. V etape 5.4 „Vypracovanie projektových úloh v susedných častiach projektu automatizácie“ vypracúvajú, formalizujú, koordinujú a schvaľujú projektové úlohy v susedných častiach projektu objektu automatizácie na vykonávanie stavebných, elektrických, sanitárnych a iných prípravných prác súvisiacich k vytvoreniu AC.

13. V etape 6.1 „Vypracovanie pracovnej dokumentácie pre systém a jeho časti“ je vypracovaná pracovná dokumentácia obsahujúca všetky potrebné a dostatočné informácie na zabezpečenie realizácie prác na uvádzaní JE do prevádzky a jej prevádzky, ako aj na udržiavanie úroveň prevádzkových charakteristík (kvality) systému v súlade s prijatými projektovými rozhodnutiami, jeho vykonávanie, koordinácia a schvaľovanie. Typy dokumentov - podľa GOST 34.201.

14. V etape 6.2 „Vývoj alebo adaptácia programov“ sa vyvíjajú programy a systémový softvér, výber, adaptácia a (alebo) prepojenie zakúpeného softvéru a vývoj programovej dokumentácie v súlade s GOST 19.101.

15. V etape 7.1 „Príprava objektu automatizácie na uvedenie závodu do prevádzky“ sa pracuje na organizačnej príprave objektu automatizácie na uvedenie závodu do prevádzky, vrátane: realizácie projektových riešení organizačnej štruktúry závodu. rastlina; poskytovanie inštruktážnych a metodických materiálov útvarom riadiaceho zariadenia; implementácia klasifikátorov informácií.

16. V etape 7.2 „Školenie personálu“ sa vyškolí personál a overí sa jeho schopnosť zabezpečiť fungovanie závodu.

17. V etape „Dopĺňanie reproduktorov dodanými výrobkami“ zabezpečujú príjem sériových a individuálnych výrobných komponentov, materiálov a inštalačných produktov. Vykonáva sa vstupná kontrola kvality.

18. V etape 7.4 „Stavebné a inštalačné práce“ sa vykonávajú: práce na výstavbe špecializovaných budov (areálov) na umiestnenie technického vybavenia a personálu JE; výstavba káblových kanálov; vykonávanie prác na inštalácii technických zariadení a komunikačných liniek; testovanie inštalovaných technických zariadení; dodávka technického zariadenia na uvedenie do prevádzky.

19. V etape 7.5 „Uvedenie do prevádzky“ vykonajú autonómne nastavenie hardvéru a softvéru, načítajú informácie do databázy a skontrolujú, či je systém udržiavaný; komplexné nastavenie všetkých systémových nástrojov.

20. V etape 7.6 „Vykonávanie predbežných testov“ sa vykonáva nasledovné:

• testovanie prevádzkyschopnosti a zhody reproduktorov s technickými špecifikáciami v súlade s programom a metodikou predbežných testov;
• odstraňovanie porúch a vykonávanie zmien v dokumentácii JE vrátane prevádzkovej dokumentácie v súlade so správou o skúške;
• vyhotovenie osvedčenia o kolaudácii JE do skúšobnej prevádzky.

21. V etape 7.7 „Vykonávanie skúšobnej prevádzky“ sa vykonáva skúšobná prevádzka JE; analýza výsledkov skúšobnej prevádzky JE; úprava (ak je to potrebné) softvéru AS; dodatočná úprava (v prípade potreby) technického vybavenia JE; vyhotovenie osvedčenia o absolvovaní skúšobnej prevádzky.

22. V etape 7.8 „Vykonávanie akceptačných testov“ sa vykonáva nasledovné:

• testovanie zhody s technickými špecifikáciami v súlade s akceptačným testovacím programom a metodikou;
• analýza výsledkov AS testov a odstránenie nedostatkov zistených počas testovania;
• vykonanie aktu o prevzatí JE do trvalej prevádzky.

23. V etape 8.1 „Vykonávanie prác v súlade so záručnými povinnosťami“ sa vykonávajú práce na odstránení nedostatkov zistených pri prevádzke JE v stanovených záručných lehotách a na vykonaní potrebných zmien v dokumentácii JE.

24. V etape 8.2 „Pozáručný servis“ sa vykonávajú práce na:

• analýza fungovania systému;
• zisťovanie odchýlok skutočných prevádzkových charakteristík JE od projektovaných hodnôt;
• stanovenie príčin týchto odchýlok;
• odstránenie zistených nedostatkov a zabezpečenie stability prevádzkových charakteristík JE;
• vykonanie potrebných zmien v dokumentácii k reproduktorom.

DODATOK 2. Odkaz

ZOZNAM ORGANIZÁCIÍ PODIEĽAJÚCICH SA NA TVORENÍ AU

1. Zákaznícka organizácia (užívateľ), pre ktorú bude JE vytvorená a ktorá zabezpečuje financovanie, preberanie prác a prevádzku JE, ako aj realizáciu jednotlivých prác na vytvorení JE.

2. Vývojová organizácia, ktorá vykonáva práce na vytvorení AS, poskytuje zákazníkovi súbor vedeckých a technických služieb v rôznych štádiách a štádiách tvorby, ako aj vyvíja a dodáva rôzny softvér a hardvér pre AS.

3. Dodávateľská organizácia, ktorá vyrába a dodáva softvér a hardvér na objednávku vývojára alebo zákazníka.

4. Organizačno-generálny projektant automatizačného zariadenia.

5. Projektové organizácie rôznych častí projektu automatizačného zariadenia na vykonávanie stavebných, elektrických, sanitárnych a iných prípravných prác súvisiacich s vytvorením jadrovej elektrárne.

6. Výstavba, inštalácia, uvedenie do prevádzky a iné organizácie.

Poznámky:

1. V závislosti od podmienok tvorby JE sú možné rôzne kombinácie funkcií objednávateľa, developera, dodávateľa a iných organizácií podieľajúcich sa na tvorbe JE.

2. Etapy a fázy práce, ktorú vykonávajú pri vytváraní AS, sú určené na základe tohto štandardu.

INFORMAČNÉ ÚDAJE

1. VYVINUTÉ A ZAVEDENÉ Štátnym výborom ZSSR pre riadenie kvality výrobkov a normy

VÝVOJÁRI

Yu.H. Vermishev, doktor inžinierstva. vedy; Ya.G. Vilenchik; IN AND. Voropajev, doktor inžinierstva. vedy; L.M. Seidenberg, Ph.D. tech. vedy; Yu.B. Irz, Ph.D. tech. vedy; V.D. Kosťukov, PhD. tech. vedy; M.A. Labutín, kond. tech. vedy; N.P. Leskovskaja; JE. Mityaev; V.F. Popov (vedúci témy); S.V. Garshina; A.I. hluchota; JUH. Žukov, PhD. vedy; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, PhD. vedy; A.A. Klochkov; V.Yu. Korolev; IN AND. Machnáč, PhD. tech. vedy; S.B. Michalev, doktor inžinierstva. vedy; V.N. Petrikevič; V.A. Rakhmanov, PhD. ekon. vedy; A.A. Ratkovič; R.S. Sedegov, doktor ekonómie. vedy; N.V. Stepanchikova; PANI. Surovets; A.V. Flegentov; L.O. Chvilevskij, PhD. tech. vedy; VC. Chistov, PhD. ekon. vedy

2. SCHVÁLENÉ A NADOBUDNUTÉ ÚČINNOSTI uznesením Štátneho výboru ZSSR pre riadenie a normy kvality výrobkov z 29. decembra 1990 č. 3469

M. Ostrogorskij, 2008

Aby bolo možné úspešne aplikovať GOST 34, je potrebné pochopiť, ako je z hľadiska tohto súboru noriem štruktúrovaný automatizovaný systém. Inak v hosťovi okrem dlhého zoznamu dokumentov so záhadnými menami neuvidíme nič a požiadavky na ich obsah nás opäť presvedčia, že v mnohých múdrostiach je veľa smútku. Preto pred diskusiou o samotných dokumentoch musíme pochopiť, čo je predmetom dokumentácie.

Automatizovaný systém, jeho funkcie a úlohy

Definícia automatizovaného systému

GOST 34.003-90 obsahuje nasledujúcu definíciu automatizovaného systému: systém pozostávajúci z personálu a súboru automatizačných nástrojov pre ich činnosti, implementujúci informačné technológie na vykonávanie zavedených funkcií. Čo táto definícia vlastne znamená? Pochopíte to len tak, že si prečítate iné definície tohto štandardu a porovnáte ich medzi sebou. Čo budeme teraz robiť?

Ciele činnosti

Automatizovaný systém môže existovať len tam, kde sú pracovníci zapojení do konkrétnej činnosti. Zvyčajne hovoríme o činnostiach, ktorých výsledky sú pre niekoho užitočné, bez ohľadu na použité nástroje. Napríklad idem do pokladne divadla pre lístok a som celkom rád, keď mi ho pokladníčka vypíše perom na tlačivo, pokiaľ ma s ním pustia do divadla. Pokladník sa vo všeobecnosti tiež nestará o to, ako presne je lístok vyrobený. Vystačí si s akoukoľvek metódou, pokiaľ to nebude príliš náročné na prácu a poskytne jej príležitosť predať mi lístok. Inými slovami, ona a ja máme spoločný cieľ. GOST 34.003-90 používa termín na jeho označenie účel činnosti. Zakaždým, keď od okna odíde ďalší divák s lístkom v ruke a divadlo o niečo bohatne, tento cieľ aktivity sa naplní.

Funkcie automatizovaného systému

Aktivita môže mať (a spravidla existuje) niekoľko cieľov. Za jej cieľ možno považovať akýkoľvek užitočný výsledok mimo samotnej činnosti. Ak teda pokladníčka nielen predáva lístky, ale na konci pracovného dňa pripravuje prehľad o predaji pre svojich nadriadených, zostavenie denného prehľadu možno považovať za ďalší cieľ činnosti.

Ak postavíme na pokladničný stôl počítač a tlačiareň a šéf pokladníčky jej vydá príkaz napísať lístky a zostavy v textovom procesore a vytlačiť ich na tlačiarni, získame automatizovaný systém. Podľa moderných predstáv je to veľmi primitívne, formálne bude vyhovovať definícii Gosta. Upozorňujeme, že ciele aktivity sa v dôsledku implementácie automatizovaného systému nezmenili, zmenil sa len spôsob ich dosahovania. To, čo sa predtým robilo „len tak“, sa teraz robí v rámci automatizovaného systému. Súbor činností automatizovaného systému zameraných na dosiahnutie konkrétneho cieľa sa podľa GOST 34.003-90 nazýva jeho funkciu. Poznámka: bez ohľadu na to, ako sa na to pozeráte, personál je považovaný za súčasť systému.

Funkcia automatizovaného systému je základným pojmom v GOST 34. Automatizovaný systém sa v prvom rade považuje za súhrn jeho funkcií a až potom za súbor „softvéru“ a „hardvéru“. Najdôležitejšie je, čo systém robí, a to, z čoho pozostáva, je druhoradé.

Vyššie uvedené by mohlo viesť čitateľa k záveru, že každému cieľu činnosti v automatizovanom systéme zodpovedá jedna a len jedna funkcia. Takýto systém si možno ľahko predstaviť, no prax je pestrejšia. Na jednej strane nie sú činnosti vždy úplne automatizované. Aj po implementácii automatizovaného systému treba niektoré ciele dosahovať manuálne. Na druhej strane, keďže rovnaký výsledok za rôznych podmienok možno dosiahnuť rôznymi spôsobmi, viacero funkcií môže byť zameraných na jeden cieľ činnosti v automatizovanom systéme, napríklad predaj lístka v pokladni a predaj lístka cez internet. internet. Okrem toho každý automatizovaný systém vyžaduje určitú údržbu, takže musíme zaviesť koncept pomocnej funkcie. Typickým príkladom je vytvorenie záložnej kópie údajov.

Úlohy automatizovaného systému

Vo všeobecnom prípade pri vykonávaní funkcie časť práce vykonáva personál a časť technológia, povedzme, lístok sa vytlačí automaticky a kupujúcemu ho dá manuálne pokladník. Postupnosť automatických (sic) akcií vedúcich k výsledku daného typu sa nazýva GOST 34.003-90 úloha.

Definícia problému tu nie je úplne presne citovaná, ale zatiaľ nám to postačí, veď nie je hanbou, aby si niekto normu prečítal sám. Je dôležité, aby úloha bola najjasnejšie formalizovanou súčasťou automatizovanej činnosti. Môžete si predstaviť funkciu, ktorá sa vykonáva úplne automaticky, ako je napríklad záloha spomenutá vyššie. V tomto prípade je funkcia zredukovaná na jednu úlohu.

Rovnakú úlohu možno vyriešiť vykonaním rôznych funkcií. Napríklad, ak má automatizovaný systém niekoľko funkcií na predaj lístka, potom vykonanie každej z nich môže v určitom bode vyžadovať vytlačenie lístka.

Zloženie automatizovaného systému

Subsystémy

Ak je automatizovaný systém dosť zložitý, delí sa na subsystémy. Čo to znamená, dosť zložité, je dosť ťažké povedať. Teória systémov popisuje rôzne úrovne a kritériá zložitosti. V praxi je potreba alokácie viacerých subsystémov v automatizovanom systéme často spôsobená organizačnými a finančnými dôvodmi, napríklad subsystémy sa vyvíjajú a uvádzajú do prevádzky postupne.

Hoci v GOST 34 sa pojem subsystém používa mnohokrát, zdá sa, že neexistuje žiadna formálna definícia tohto pojmu. Skúsenosti naznačujú, že podsystém je súčasťou automatizovaného systému, ktorý zároveň spĺňa definíciu automatizovaného systému, najmä má plnohodnotné funkcie.

Ak sa vrátime k príkladu predaja lístkov, môžeme sa rozhodnúť, že automatizovaný systém pozostáva z dvoch podsystémov: podsystému na vydávanie lístkov a podsystému denných správ. Pre lepšiu prehľadnosť sa dohodnime na tom, že pokladník zadáva lístky v textovom editore a zostavy do tabuliek.

Komponenty

Identifikácia cieľov činnosti, funkcií automatizovaného systému a v prípade potreby aj jeho podsystémov je do značnej miery subjektívna a závisí od uhla pohľadu subjektu, ktorý sa tak rozhodol. Ak je nejaký výsledok dôležitý v kontexte riešeného problému, môžeme ho považovať za cieľ, inak ho ignorovať. Automatizovaný systém tiež rozdelíme na podsystémy spôsobom, ktorý nám vyhovuje, pokiaľ naše rozhodnutia nebudú v rozpore s obsahom tohto konceptu.

Komponenty sú časti, z ktorých v objektívnej realite staviame automatizovaný systém. Systém sa fyzicky skladá zo svojich komponentov, takže rozdelenie automatizovaného systému na komponenty je najobjektívnejšie.

Každý komponent zakúpime, nainštalujeme a pripojíme (ak ide o zariadenie), nainštalujeme (ak ide o program) a udržiavame oddelene od ostatných komponentov. Kúpili sme a položili na stôl počítač - je to komponent. Vyvinuli sme špeciálny textový editor na písanie lístkov – ďalší komponent. Stiahnuté bezplatné tabuľky z internetu - opäť komponent. A dokonca aj samotná pokladníčka je istým spôsobom súčasťou automatizovaného systému.

Komponentová skladba automatizovaného systému je veľmi dôležitá z hľadiska jeho dokumentácie, keďže s technickou dokumentáciou pre systém ako taký a pre komponenty sa narába rozdielne. Vo všeobecnosti ho musia vyvinúť rôzni ľudia a je navrhnutý podľa rôznych štandardov v závislosti od typu komponentu.

Druhy kolaterálu

Jedným z najťažších konceptov pre začínajúceho používateľa GOST 34 je typ zabezpečenia. Čo je to za bezpečnosť? Môžete to vidieť alebo sa ho dotknúť? Predať alebo kúpiť?

Každý typ softvéru kombinuje komponenty alebo technické riešenia určitého charakteru. GOST 34 uvádza mnoho rôznych typov zabezpečenia; nebudeme tu popisovať každý z nich postupne, ale uvedieme len tie najpozoruhodnejšie:

• informačná podpora - všetky údaje a metadáta, s ktorými systém pracuje;
• softvér - všetky programy, ktoré sú súčasťou systému;
• technická podpora - všetky technické prostriedky (inými slovami vybavenie, vybavenie), ktoré sú súčasťou systému.

Zopakujme si ešte raz, nie sú to všetky typy zabezpečenia. Nemôžeme ani s istotou povedať, že sú najdôležitejšie. Napríklad metrologická podpora má veľký význam pre automatizované systémy riadenia procesov (APCS). Mnohé automatizované systémy vyžadujú komplexnú matematickú a jazykovú podporu. Je však ťažké predstaviť si automatizovaný systém, ktorý by bol úplne zbavený jedného z troch typov podpory uvedených vyššie (cvičenie: vyskúšajte).