Определение на ръка за гост. Пилотно функциониране на автоматизираната система за управление. Изисквания за тестване на автоматизирани системи за управление на процесите

М. Острогорски, 2008

За да се приложи успешно GOST 34, е необходимо да се разбере как от гледна точка на този набор от стандарти е подредена автоматизирана система. В противен случай няма да видим нищо в гостите, освен дълъг списък от документи с мистериозни имена, а изискванията за тяхното съдържание за пореден път ще ни убедят, че в много мъдрости има много мъка. Следователно, преди да обсъждаме самите документи, трябва да разберем какво представлява предметът на документацията.

Автоматизирана система, нейните функции и задачи

Определение за автоматизирана система

GOST 34.003-90 съдържа следното определение за автоматизирана система: система, състояща се от персонал и набор от инструменти за автоматизация за нейните дейности, която реализира информационна технология за изпълнение на установени функции. Какво всъщност означава това определение? Можете да разберете това само като прочетете другите дефиниции на този стандарт и ги сравните едно с друго. Какво ще правим сега.

Цели на дейността

Автоматизирана система може да съществува само когато има персонал, ангажиран с конкретна дейност. обикновено, идваза дейности, резултатите от които са полезни за някого, независимо от използваните инструменти. Аз например кандидатствам в касата за билет и ще ми е добре касиерката да ми го изпише с химикал на бланка, за да ме пуснат в залата с него. Касиерът, като цяло, също не се интересува как да направи билет. Всеки метод ще й подхожда, стига да не е твърде трудоемък и да й дава възможност да ми продаде билет. С други думи, ние имаме обща цел с нея. В GOST 34.003-90 терминът се използва за обозначаването му цел на дейността... Всеки път, когато друг зрител напусне прозореца с билет в ръка и театърът стане малко по-богат, тази цел на дейност се постига.

Автоматизирани системни функции

Може да има (и като правило има) няколко цели на дейност. Всеки резултат, който е полезен извън самата дейност, може да се счита за негова цел. Така че, ако касиерката не само продава билет, но и изготвя отчет за продажбите за своите началници в края на работния ден, изготвянето на ежедневен отчет може да се счита за друга цел на дейността.

Ако поставим компютър и принтер на масата за касиерката, а началникът на касата й издаде заповед да напише билети и отчети в текстов редактор и да ги отпечата на принтер, тогава получаваме автоматизирана система. Според съвременните възгледи той е много примитивен, формално ще удовлетвори дефиницията на Гост. Моля, имайте предвид, че целите на дейността не са се променили в резултат на внедряването на автоматизираната система, промени се само начинът за постигането им. Това, което се правеше "просто така", сега се прави в рамките на автоматизирана система. Наборът от действия на автоматизирана система, насочени към постигане на конкретна цел, съгласно GOST 34.003-90, се нарича това функция... Забележка: Каквото и да мислите за това, персоналът се счита за част от системата.

Функцията на автоматизираната система е основно понятие в GOST 34. Автоматизираната система се разглежда преди всичко като сбор от нейните функции и едва след това като куп "софтуер" и "хардуер". Най-важното е, че това, което прави системата и от какво се състои, е второстепенно.

Изложеното по-горе може да доведе читателя до извода, че една и само една функция отговаря на всяка цел на дейност в автоматизирана система. Такава система е лесно да си представим, но практиката е по-разнообразна. От една страна, дейностите не винаги са напълно автоматизирани. Дори след въвеждането на автоматизирана система някои цели трябва да се постигат ръчно. От друга страна, тъй като същият резултат в различни условиямогат да бъдат постигнати по различни начини, няколко функции могат да бъдат насочени към една цел на дейност в автоматизирана система, например продажба на билет на касата и продажба на билет в Интернет. Освен това всяка автоматизирана система изисква определена поддръжка, така че е необходимо да се въведе концепцията за спомагателна функция. Типичен пример- създаване архивиранеданни.

Задачи на автоматизираната система

В общия случай, при изпълнение на функция, част от работата се извършва от персонал, а част от работата се извършва от оборудване, например билет се отпечатва автоматично и се издава на купувача от касиери ръчно. Последователността от автоматични (sic) действия, водещи до резултат от даден тип, се нарича в GOST 34.003-90 задача.

Тук определението на проблема не е цитирано съвсем точно, но засега ще ни е достатъчно и това в крайна сметка не е срамно някой сам да прочете стандарта. Важно е задачата да е най-ясно формализираната част от автоматизираната дейност. Може да си представим функция, изпълнявана напълно автоматично, например тази, спомената по-горе архивиране... В този случай функцията се свежда до една задача.

Една и съща задача може да бъде решена чрез изпълнение на различни функции. Например, ако една автоматизирана система има няколко функции за продажба на билет, тогава изпълнението на всяка от тях може в даден момент да изисква разпечатването на билета.

Състав на автоматизираната система

Подсистеми

Ако автоматизираната система е достатъчно сложна, тя се разделя на подсистеми... Какво означава, достатъчно трудно, достатъчно трудно да се каже. Теорията на системите описва различни ниваи критерии за сложност. На практика необходимостта от разделяне на няколко подсистеми в автоматизирана система често е причинена от организационни и финансови причини, например подсистемите се разработват и пускат в експлоатация последователно.

Въпреки че в GOST 34 терминът подсистема се използва много пъти, изглежда, че няма официално определение на това понятие. Опитът диктува, че подсистемата е част от автоматизирана система, която също отговаря на определението за автоматизирана система, по-специално има пълноценни функции.

Връщайки се към примера за продажба на билети, можем да решим, че автоматизираната система се състои от две подсистеми: подсистема за продажба на билети и подсистема за генериране на ежедневни отчети. Нека само за по-голяма яснота се съгласим, че касиерът въвежда билетите в текстов редактор и отчита в електронни таблици.

Компоненти

Разпределението на целите на дейността, функциите на автоматизирана система и, ако е необходимо, на нейните подсистеми е до голяма степен субективно и зависи от гледната точка на субекта, който е решил да направи това. Ако някакъв резултат е важен в контекста на решавания проблем, можем да го считаме за цел и в противен случай да го игнорираме. Ние също така ще разбием автоматизираната система на подсистеми, както е удобно за нас, стига нашите решения да не противоречат на съдържанието на тази концепция.

Компонентите са частите, в които се намираме обективна реалностизграждане на автоматизирана система. Системата физически се състои от своите компоненти, така че разделянето на автоматизирана система на компоненти е най-обективното.

Ние закупуваме, монтираме и свързваме всеки компонент (ако е оборудване), инсталираме (ако е програма) и обслужваме отделно от останалите компоненти. Купихме и поставихме компютър на масата - това е компонент. Разработихме специален текстов редактор за набор от билети - друг компонент. Изтеглени безплатни електронни таблици от интернет - отново компонент. И дори самата касиерка по някакъв начин също е компонент на автоматизирана система.

Компонентният състав на една автоматизирана система е много важен от гледна точка на нейната документация, тъй като техническата документация за системата като такава и компонентите се третират различно. Най-общо казано, трябва да се развива различни хора, и е проектиран според различни стандарти в зависимост от вида на компонента.

Видове обезпечения

Една от най-трудните концепции за начинаещ потребител на GOST 34 е вид сигурност... Що за сигурност е това? Можете ли да го видите или докоснете? Продавам или Купувам?

Всеки вид поддръжка съчетава компоненти или технически решения от определено естество. GOST 34 споменава много различни видоверазпоредба, тук няма да описваме последователно всеки от тях, а ще изброим само най-забележимите:

информационна поддръжка - всички данни и метаданни, с които работи системата;
софтуер – всички програми, които са част от системата;
техническа поддръжка - всичко технически средства(с други думи, оборудване, апаратура), които са част от системата.

Повтаряме още веднъж, това не са всички видове обезпечения. Дори не можем да кажем със сигурност, че те са най-важните. Например за автоматизирани системи за управление технологични процеси(APCS) метрологичната поддръжка е от голямо значение. Много автоматизирани системи изискват сложна математическа и езикова поддръжка. Но е трудно да си представим автоматизирана система, която би била напълно лишена от един от трите типа поддръжка, изброени по-горе (упражнение: опитайте).

GOST 34.601-90 Информационни технологии. Набор от стандарти за автоматизирани системи. Автоматизирани системи. Етапи на създаване.

G O S U D A R S T V E N Y S T A N D A R T S O Y Z A S S R

Дата на въвеждане
от 01.01.1992г

Този стандарт се прилага за автоматизирани системи (AS), използвани в различни видоведейности (изследователска, проектантска, управленска и др.), включително техните комбинации, създадени в организации, сдружения и предприятия (наричани по-нататък - организации).

Стандартът установява етапите и етапите на създаване на високоговорител. Приложение 1 съдържа съдържанието на работата на всеки етап.

1. ОБЩИ РАЗПОРЕДБИ

1.1. Процесът на създаване на AU е съвкупност от подредени във времето, взаимосвързани, обединени в етапи и етапи на работа, чието изпълнение е необходимо и достатъчно за създаване на AU, отговарящ на посочените изисквания.

1.2. Етапите и етапите на създаване на AU се разграничават като част от процеса на създаване от съображения за рационално планиране и организация на работата, завършваща с даден резултат.

1.3. Работата по разработването на АС се извършва според етапите и етапите, използвани за създаване на АС.

1.4. Съставът и правилата за извършване на работа на етапите и етапите, установени с този стандарт, се определят в съответната документация на организациите, участващи в създаването на конкретни видове атомни електроцентрали.

Списъкът на организациите, участващи в работата по създаването на АС, е даден в Приложение 2.

2. ЕТАПИ И ЕТАПИ НА СЪЗДАВАНЕ НА АС

2.1. Етапите и етапите на създаване на AU в общия случай са показани в таблицата.

	Етапи на работа
1. Формиране на изисквания към АС	1.1. Обследване на съоръжението и обосновка на необходимостта от създаване на АЕЦ. 1.2. Формиране на потребителски изисквания към високоговорителя. 1.3. Регистрация на отчет за извършената работа и заявление за разработване на АС (тактически техническо задание)
2. Разработване на концепцията за АС.	2.1. Проучване на обекта. 2.2. Извършване на необходимата изследователска работа. 2.3. Разработване на опции за концепция на високоговорителя, отговаряща на изискванията на потребителя. 2.4. Регистрация на отчет за извършената работа.
3. Техническо задание.	Разработване и утвърждаване на технически спецификации за създаване на АС.
4. Идеен проект.	4.1. Разработване на идейни проектни решения за системата и нейните части. 4.2. Разработване на документация за АС и неговите части.
5. Технически проект.	5.1. Разработване на дизайнерски решения за системата и нейните части. 5.2. Разработване на документация за АС и неговите части. 5.3. Разработване и изпълнение на документация за доставка на продукти за попълване на АС и (или) Технически изисквания(технически спецификации) за тяхното разработване. 5.4. Разработване на проектни задания в прилежащите части на проекта на обекта за автоматизация.
6. Работна документация.	6.1. Разработване на работна документация за системата и нейните части. 6.2. Разработване или адаптиране на програми.
7. Пускане в експлоатация.	7.1. Подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ. 7.2. Обучение на персонала. 7.3. Комплектуване на високоговорителна система с доставените продукти (софтуер и хардуер, софтуерни и хардуерни комплекси, информационни продукти). 7.4. Строително-монтажни работи. 7.5. Пусконаладъчни работи. 7.6. Предварителни тестове. 7.7. Пробна експлоатация. 7.8. Тестове за приемане.
8. Акомпанимент на АС	8.1. Изпълнение на работата в съответствие с гаранционните задължения. 8.2. Следгаранционно обслужване.

2.2. Етапи Етапите, извършвани от организациите – участници в работата по създаването на АС, са установени в договори и техническо задание на базата на този стандарт.

Разрешено е да се изключи етапът „Проектиране“ и отделни етапи на работа на всички етапи, да се комбинират етапите „Технически проект“ и „Работна документация“ в един етап „Проект за технически проект“. В зависимост от спецификата на създаваните ядрени системи и условията за тяхното създаване се допуска извършване на отделни етапи на работа преди завършване на предишните етапи, успоредно във времето изпълнение на етапи на работа, включване на нови етапи на работа .

ПРИЛОЖЕНИЕ 1
(справка)

1. На етап 1.1. „Проучване на съоръжението и обосновка на необходимостта от създаване в атомната електроцентрала” в общия случай се извършва:

а) събиране на данни за обекта на автоматизация и извършените дейности;
б) оценка на качеството на функционирането на обекта и извършваните дейности, идентифициране на проблеми, които могат да бъдат решени чрез автоматизация;
в) оценка (технико-икономическа, социална и др.) на осъществимостта на създаване на АС.

2. На етап 1.2. „Формиране на потребителски изисквания за АС“ се извършва:

а) подготовка на изходни данни за формиране на изискванията на АС (характеристики на обекта за автоматизация, описание на изискванията към системата, ограничаване на допустимите разходи за разработка, въвеждане в експлоатация и експлоатация, очакван ефект от системата, условия за създаване и функциониране на системата);
б) формулирането и изпълнението на потребителските изисквания за AU.

3. На етап 1.3. „Съставяне на отчет за извършената работа и заявление за разработване на АС (техническа и техническа задача)“ извършва изпълнението на отчет за извършената работа на този етап и заявление за разработване на AU (тактически и техническо задание) или друг документ, който го заменя с подобно съдържание.

4. На етапи 2.1. „Обектно изследване“ и 2.2. Организацията-разработчик "Провеждане на научноизследователска работа" извършва подробно проучване на обекта за автоматизация и необходимата изследователска работа (R&D), свързана с намиране на начини и оценка на възможността за изпълнение на изискванията на потребителите, изготвяне и одобряване на доклади за научноизследователска и развойна дейност.

5. На етап 2.3. „Разработване на варианти на концепцията на АС и избор на версия на концепцията на АС, която удовлетворява изискванията на потребителя“ в общия случай, разработване на алтернативни варианти на концепцията на създадения AU и планове за тяхното изпълнение; оценка на необходимите ресурси за тяхното изпълнение и поддържане; оценка на предимствата и недостатъците на всеки вариант; определяне на реда за оценка на качеството и условията за приемане на системата; оценка на ефектите, получени от системата.

6. На етап 2.4. „Изготвяне на отчет за извършената работа” изготвя и съставя протокол, съдържащ описание на извършената работа на етапа на описание и обосновка на предложения вариант на концепцията на системата.

7. На етап 3.1. „Разработване и утвърждаване на техническото задание за създаване на атомна електроцентрала“ извършва разработването, изпълнението, съгласуването и утвърждаването на техническото задание за атомната електроцентрала и при необходимост технически спецификации за частта от атомна електроцентрала.

8. На етап 4.1. „Разработване на идейни проектни решения за системата и нейните части“ определя: функциите на АС; функции на подсистемите, техните цели и ефекти; състава на комплекси от задачи и индивидуални задачи; концепцията за информационна база, нейната разширена структура; Функции на системата за управление на база данни; състава на изчислителната система; функции и параметри на основния софтуер.

9. На етап 5.1. „Разработване на проектни решения за системата и нейните части“ осигурява разработването на общи решения за системата и нейните части, функционалната и алгоритмичната структура на системата, за функциите на персонала и организационна структура, по структурата на техническите средства, по алгоритми за решаване на проблеми и използваните езици, по организацията и поддържането на информационната база, системата за класификация и кодиране на информацията, по софтуера.

10. На етапи 4.2. и 5.2. „Разработване на документация за АЕЦ и нейните части“ извършва разработването, изпълнението, съгласуването и одобряването на документация в количеството, необходимо за описване на пълния набор от приети проектни решения и достатъчно за по-нататъшна работа по създаването на АЕЦ. Видове документи - съгласно GOST 34.201-89.

11. На етап 5.3. "Разработване и изпълнение на документация за доставка на продукти за завършване на АЕЦ и (или) технически изисквания (технически спецификации) за тяхното разработване" извършват: подготовка и изпълнение на документация за доставка на продукти за завършване на АЕЦ; определяне на технически изисквания и изготвяне на технически спецификации за разработване на продукти, които не се произвеждат масово.

12. На етап 5.4 "Разработване на задания за проектиране в съседни части на проекта на обекта за автоматизация" извършва разработването, регистрирането, съгласуването и одобряването на задания за проектиране в съседни части на проекта на обекта за автоматизация за строителство, ел., санитарен и други подготвителна работасвързани със създаването на АС.

13. На етап 6.1 "Разработване на работна документация за системата и нейните части" се разработва работната документация, съдържаща цялата необходима и достатъчна информация за осигуряване извършването на работата по пускането в експлоатация на АЕЦ и нейната експлоатация, както и за поддържане нивото на експлоатационни характеристики (качество) на системата в съответствие с приетите проектни решения, нейното проектиране, координиране и одобрение. Видове документи в съответствие с GOST 34.201-89.

14. На етап 6.2 "Разработване или адаптиране на програми" се разработват програми и софтуер на системата, избор, адаптация и (или) обвързване на закупения софтуер, разработване на софтуерна документация в съответствие с GOST 19.101.

15. На етап 7.1 "Подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ" се извършват работи по организационната подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ, включително:

изпълнение на проектни решения за организационната структура на завода;
осигуряване на подразделения на обекта на управление с инструктивно-методически материали;
въвеждане на класификатори на информация.

16. На етап 7.2 "Обучение на персонала" се обучава персоналът и се проверява способността му да осигури работата на АЕЦ.

17. На етап 7.3 „Попълване на АС с доставените продукти (софтуер и хардуер, софтуерни и хардуерни комплекси, информационни продукти)“ осигуряват получаването на партидни и единични производствени компоненти, материали и инсталационни продукти, извършват входящ контролтехните качества.

18. На етап 7.4 "СМР" извършват:

изпълнение на работи по изграждане на специализирани сгради (помещения) за разполагане на техническо оборудване и персонал на АЕЦ;
изграждане на кабелни канали;
изпълнение на работи по монтаж на технически средства и комуникационни линии;
тестване на монтирано техническо оборудване;
доставка на технически средства за въвеждане в експлоатация.

19. На етап 7.5 "Въвеждане в експлоатация" извършете:

автономна настройка на хардуера и софтуера,
зареждане на информация в базата данни и проверка на системата за нейното поддържане;
комплексна настройка на всички средства на системата.

20. На етап 7.6 "Провеждане на предварителни изпитвания" се извършва:

а) тестове на АС за работоспособност и съответствие с техническото задание в съответствие с програмата и методиката на предварителните изпитвания;
б) отстраняване на неизправности и изменения в документацията за АЕЦ, включително експлоатационната документация в съответствие с протокола от изпитването;
в) регистрация на удостоверението за приемане на атомната електроцентрала за опитна експлоатация.

21. На етап 7.7 "Опитна експлоатация" извършете:

опитна експлоатация на АЕЦ;
анализ на резултатите от експерименталната експлоатация на АЕЦ;
ревизия (ако е необходимо) софтуер AC;
допълнителна настройка (при необходимост) на техническите средства на атомната електроцентрала;
регистрация на акт за завършване на пробна експлоатация.

22. На етап 7.8 "Приемателни тестове" извършват:

а) изпитвания за съответствие с техническите спецификации в съответствие с програмата и методиката на приемо-предавателните изпитвания;
б) анализ на резултатите от изпитването на AU и отстраняване на недостатъци, установени по време на изпитването;
в) регистрация на удостоверението за приемане на АЕЦ в постоянна експлоатация.

23. На етап 8.1 "Изпълнение на работа в съответствие с гаранционните задължения" се извършва работа по отстраняване на недостатъците, установени при експлоатацията на АЕЦ през установените гаранционни срокове, като прави необходимите промени в документацията за АС.

24. На етап 8.2 "Следгаранционно обслужване" се извършва работа по:

а) анализ на функционирането на системата;
б) идентифициране на отклонения на действителните експлоатационни характеристики на АЕЦ от проектните стойности;
в) установяване на причините за тези отклонения;
г) отстраняване на констатираните недостатъци и осигуряване на стабилност на експлоатационните характеристики на АЕЦ;
д) извършване на необходимите промени в документацията за АС.

ПРИЛОЖЕНИЕ 2
(справка)

СПИСЪК НА ОРГАНИЗАЦИИТЕ, УЧАСТВАЩИ В РАБОТАТА ПО СЪЗДАВАНЕТО НА АС.

1. Организация-клиент (потребител), за която се създава АС и която осигурява финансиране, приемане на работа и експлоатация на АС, както и изпълнението индивидуални произведенияотносно създаването на АС.

2. Организацията-разработчик, която извършва работа по създаването на АС, предоставя на клиента набор от научни и технически услуги на различни етапи и етапи на създаване, а също така разработва и доставя различни софтуерни и хардуерни инструменти за АС .

3. Организация на доставчик, която произвежда и доставя софтуер и хардуер по искане на разработчика или клиента.

4. Организация-генерален проектант на обекта за автоматизация.

5. Организации-проектанти на различни части от проекта на обекта за автоматизация за извършване на строителни, електрически, санитарни и други подготвителни работи, свързани със създаването на атомна електроцентрала.

6. Организации за строителство, монтаж, въвеждане в експлоатация и други.

бележки:

а) в зависимост от условията за създаване на AU са възможни различни комбинации от функции на клиент, разработчик, доставчик и други организации, участващи в създаването на AU;
б) етапите и етапите на тяхната работа по създаването на АС се определят въз основа на този стандарт.

GOST 24.104-85 Автоматизирани системи за управление. Общи изисквания (Раздел 3 се заменя с GOST 34.603-92) Раздел 3 се заменя с GOST 34.603-92С указ на Държавния комитет по стандартите на СССР от 20 декември 1985 г. № 4632 се определя датата на въвеждане

от 01.01 1987г

Този стандарт се прилага за автоматизирани системи за управление (ACS) от всички видове (с изключение на националните) и се установява Общи изискваниякъм автоматизираната система за управление като цяло, функциите на автоматизираната система за управление, подготвеността на персонала и видовете поддръжка на автоматизираната система за управление, безопасността и ергономичността, видовете и процедурата за провеждане на тестове при пускане в експлоатация на автоматизираната контролна система система, пълнотата на автоматизираната система за управление, гаранции.

Стандартът не установява изисквания за ACS, обусловени от спецификата на обектите за управление. Тези изисквания са формулирани в техническото задание за създаване или развитие на всяка ACS или в други регулаторни и технически документи на отдела на клиента на ACS.

Допълнителни изисквания за автоматизирани системи за управление на технологични процеси, автоматизирани системи за управление на предприятия, промишлени и научно-производствени обединения, индустриални автоматизирани системи за управление са установени съответно в задължителни приложения 1-3.

Справочно приложение 4 обяснява някои от термините, използвани в стандарта.

1. ИЗИСКВАНИЯ ЗА ACS

1.1. Изисквания за ACS като цяло

1.1.1. ACS от всякакъв вид трябва да отговаря на изискванията на този стандарт, изискванията на техническите спецификации за неговото създаване или разработване (наричани по-долу TK за ACS), както и изискванията на регулаторните и технически документи, които са в сила в отдела на клиента на ACS.

1.1.2. Пускането в експлоатация на автоматизирана система за управление трябва да доведе до полезни технически, икономически, социални или други резултати, например:

съкращаване управленски персонал;
подобряване на качеството на функциониране на обекта на контрол;
подобряване на качеството на управление и др.

1.1.3. Специфичното съдържание на изискванията за ПП. 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 са инсталирани в техническата спецификация за ACS.

1.1.4. ACS трябва да осигури постигането на целите на неговото създаване (разработване), установени в техническата спецификация за ACS.

1.1.5. ACS трябва да осигури съвместимост между своите части, както и с автоматизирани системи (AS), свързани помежду си с тази ACS.

В случаите, когато ACS или набор от ACS (AS) се създава на базата на компютърна мрежа, за да се осигури съвместимост между елементите на такава мрежа, трябва да се прилагат системи от протоколи за взаимодействие на много нива.

1.1.6. ACS като цяло и всички видове поддръжка трябва да бъдат адаптирани към модернизация, развитие и изграждане в рамките на изискванията, посочени в техническата спецификация за ACS.

1.1.7. Надеждността на АСУ като цяло и на всяка от нейните автоматизирани функции трябва да е достатъчна за постигане на поставените цели на функционирането на системата при дадените условия на използване.

1.1.8. Адаптивността на ACS трябва да е достатъчна за постигане на установените цели на нейната работа в даден диапазон от промени в условията на използване.

1.1.9. ACS трябва да осигурява наблюдение на коректността на изпълнение на автоматизирани функции и диагностика, като се посочват мястото, вида и причината за нарушения на правилното функциониране на ACS.

1.1.10. В автоматизираната система за управление с измервателни канали трябва да е възможно да се контролират метрологичните характеристики на измервателните канали.

1.1.11. ACS трябва да предвижда мерки за защита срещу неправилни действия на персонала, водещи до аварийно състояние на обект или система за управление, от случайни промени и унищожаване на информация и програми, както и от неразрешена намеса.

1.1.12. Всяка информация, постъпваща в ACS, се въвежда еднократно в системата с помощта на един входен канал, ако това не води до неизпълнение на изискванията, установени в техническата спецификация за ACS (по отношение на надеждност, надеждност и др.) .

1.1.13. Изходната информация със същото семантично съдържание трябва да бъде генерирана в ACS веднъж, независимо от броя на адресатите.

1.1.14. Информацията, съдържаща се в базите данни на ACS, трябва да се актуализира в съответствие с честотата на нейното използване при изпълнение на функциите на системата.

1.1.15. ACS трябва да бъде защитена от изтичане на информация, ако това е предвидено в техническата спецификация на ACS.

1.1.16. Името на ACS трябва да включва името на типа на ACS и контролния обект.

Например:

Автоматизирана система за управление на процеса за нагряване на метал в непрекъсната пещ;
организационно-технологична автоматизирана система за управление на цех No5;
Автоматизирана система за управление на завод "Сърп и чук".

1.2. Изисквания за функциите на ACS

1.2.1. ACS в необходими обемитрябва автоматично да изпълнява:

събиране, обработка и анализ на информация (сигнали, съобщения, документи и др.) за състоянието на обекта на управление;
разработване на контролни действия (програми, планове и др.);
предаване на контролни действия (сигнали, инструкции, документи) за изпълнение и неговото управление;
изпълнение и контрол на изпълнението на контролни действия;
обмен на информация (документи, съобщения и др.) с взаимосвързани автоматизирани системи.

1.2.2. Съставът на автоматизирани функции (задачи, комплекси от задачи - наричани по-долу функции) на ACS трябва да осигурява възможност за управление на съответния обект в съответствие с някоя от целите, заложени в техническата спецификация за ACS.

1.2.3. Съставът на автоматизираните функции на ACS и степента на тяхната автоматизация трябва да бъдат технически, икономически и (или) социално оправдани, като се вземе предвид необходимостта от освобождаване на персонала от извършване на повтарящи се действия и създаване на условия за използване на творческите им способности в процеса.

1.3. Изисквания към обучението на персонала на ACS

1.3.1. Квалификацията на персонала на ACS трябва да гарантира ефективното функциониране на системата във всички определени режими.

1.3.2. Персоналът на ACS трябва да бъде подготвен да изпълнява задълженията си в съответствие с инструкциите за организационна подкрепа.

1.3.3. Всяко лице, което е част от персонала на ACS, трябва да прилага съответните информационни модели и да работи с използваните от него технически средства и документацията, която определя реда на неговата дейност.

1.4. Изисквания за техническа поддръжка на ACS

1.4.1. Наборът от технически средства на ACS трябва да е достатъчен за изпълнение на всички автоматизирани функции на ACS.

1.4.2. Комплексът от технически средства на ACS трябва да използва главно технически средства за серийно производство. При необходимост се допуска използването на технически средства от едно производство.

1.4.3. Възпроизвежданите ACS и техните части трябва да се изграждат на базата на унифицирани технически средства.

1.4.4. Техническите средства на автоматизираната система за управление трябва да бъдат поставени в съответствие с изискванията, съдържащи се в техническата, включително експлоатационната, документация за тях и така, че да е удобно да се използват по време на функционирането на автоматизираната система за управление и да се извършва поддръжка.

1.4.5. Поставянето на технически средства, използвани от персонала на автоматизираната система за управление при изпълнение на автоматизирани функции, трябва да отговаря на изискванията на ергономията: за производствено оборудване в съответствие с GOST 12.049-80, за средства за представяне на визуална информация в съответствие с GOST 21829-76 , включително табла за колективно използване от цифрови знаци-синтезиращи електролуминесцентни индикатори съгласно GOST 21837-76.

1.4.6. Техническите средства на ACS, използвани при взаимодействието на ACS с други системи, трябва да бъдат интерфейсно съвместими със съответните технически средства на тези системи и използваните комуникационни системи.

1.4.7. В ACS трябва да се използват технически средства с експлоатационен живот най-малко десет години. Използването на технически средства с по-кратък експлоатационен живот се допуска само в обосновани случаи и по споразумение с клиента на автоматизираната система за управление.

1.4.8. Всяко от техническите средства на автоматизираната система за управление трябва да позволява замяната му със средство с подобно функционално предназначение без каквито и да било конструктивни промени или корекции в останалите технически средства на автоматизираната система за управление (с изключение на случаите, специално предвидени в техническата документация за автоматизираната система за управление). контролна система).

1.4.9. Техническите средства на ACS се допускат да се използват само при условията, посочени в експлоатационната документация за тях. В случаите, когато е необходимо използването им в среда, чиито параметри надвишават допустимите стойности, установени за тези технически средства, трябва да се вземат мерки за защита на отделните технически средства на ACS от влиянието на външни въздействащи фактори.

1.4.10. В ACS трябва да се използват компютърни съоръжения, които отговарят на общите технически изисквания съгласно GOST 22552-84.

1.4.11. В ACS трябва да се използват технически средства, които отговарят на:

за устойчивост на външни въздействащи фактори - GOST 12997-76 за промишлени устройства и оборудване за автоматизация, GSP, GOST 14254-80 за корпуси на електрически продукти, GOST 17516-72 за електрически продукти по отношение на въздействието на механични фактори външна среда, GOST 21552-84 за компютърно оборудване;
по отношение на захранването - GOST 12997-76 за промишлени устройства и оборудване за автоматизация за GSP, GOST 21552-84 за компютърно оборудване;
по категория на изпълнение - GOST 12997-76 за промишлени устройства и оборудване за автоматизация за GSP, GOST 21552-84 за компютърно оборудване.

1.4.12. Защитата на техническите средства на автоматизираната система за управление от въздействието на външни електрически и магнитни полета, както и шум в захранващите вериги, трябва да е достатъчна, за да могат техническите средства ефективно да изпълняват предназначението си по време на функционирането на автоматизираната система за управление .

1.4.13. В ACS, в съответствие с изискванията, предвидени от "Всесъюзните стандарти за разрешени промишлени смущения" 1-72 - 9-72 и GOST 23450-79, трябва да се предвидят мерки за защита на външната среда от излъчвани промишлени радиосмущения от техническите средства на АСУ по време на работа, както и в момента на включване и изключване.

1.4.14. Общи ергономични изисквания за мимически диаграми - в съответствие с GOST 21480-76, за изчисляване на устройства за визуални индикатори - в съответствие с GOST 22902-78, за табла за колективно използване на цифрови знаци-синтезиращи електролуминесцентни индикатори - в съответствие с GOST 21837-76, за електронно-лъчеви тръби за показване на визуална информация - съгласно GOST 23144-78.

1.4.15. Общи ергономични изисквания за превключватели на конзоли: въртящи се - в съответствие с GOST 22613-77, клавиатури и бутони - в съответствие с GOST 22614-77, тип "Toggle" - в съответствие с GOST 22615-77.

1.4.16. Общи ергономични изисквания към устройствата за сигнализиране на първични аудио съобщения - в съответствие с GOST 21786-76.

1.4.17. Общи ергономични изисквания, регулиращи организацията на работното място, взаимното разположение на средствата за показване на информация, средствата за управление и комуникационните съоръжения в рамките на работното място - в съответствие с GOST 22269-76, включително конзолите - в съответствие с GOST 23000-76.

1.4.18. Общи ергономични изисквания към седалките на оператора в съответствие с GOST 21889-76.

1.4.19. Общите ергономични изисквания за залата, кабините на оператора и взаимното разположение на седалките са в съответствие с GOST 21958-76.

1.5. Изисквания към софтуера за ACS

1.5.1. Софтуерът на ACS трябва да е достатъчен за изпълнение на всички функции на ACS, реализирани с помощта на компютърни технологии, както и да разполага със средства за организиране на всички необходими процеси на обработка на данни, позволяващи навременното изпълнение на всички автоматизирани функции във всички регулирани режими на работа на ACS.

1.5.2. ACS софтуерът трябва да има следните свойства:

функционална достатъчност (пълнота);
надеждност (включително възможност за възстановяване, наличие на инструменти за откриване на грешки);
адаптивност;
модифициране;
модулност на конструкцията и
лекота на използване.

1.5.3. Софтуерът на ACS трябва да се изгражда предимно на базата на съществуващи софтуерни пакети и други програми, заети от държавни, индустриални и други фондове на алгоритми и програми, да позволява зареждане и проверка на части и да позволява подмяна на някои програми без коригиране на други.

1.5.4. В ACS следва да се използват основно системи за управление на бази данни (СУБД), регистрирани по предписания начин.

1.5.5. Софтуерът на ACS трябва да бъде проектиран по такъв начин, че липсата на отделни данни да не се отразява на работата на функциите на ACS, при изпълнението на които тези данни не се използват.

1.5.6. Софтуерът на ACS трябва да има диагностични инструменти за хардуера на ACS и да контролира точността на входната информация.

1.5.7. Софтуерът на ACS трябва да прилага мерки за защита срещу грешки при въвеждането и обработката на информация, осигурявайки определеното качество на функциите на ACS.

1.5.8. Общият софтуер на ACS трябва да позволява настройка на компонентите на специалния софтуер и по-нататъшното развитие на софтуера на ACS без прекъсване на процеса на неговото функциониране. Вече генерираният и зареден софтуер трябва да бъде защитен от случайни промени.

1.5.9. Всички програми на специален софтуер на специфичен ACS трябва да са съвместими както помежду си, така и с неговия общ софтуер.

1.5.10. Оперативната софтуерна документация за автоматизираната система за управление трябва да отговаря на стандартите ESPD и да съдържа цялата информация, необходима на персонала на автоматизираната система за управление да използва софтуера, за първоначалното му зареждане и (или) генериране, зареждане на информацията в -машинна информационна база, стартиране на програми на автоматизираната система за управление, проверка на функционирането им чрез подходящи тестове.

1.5.11. Новоразработените софтуерни продукти по време на създаването на специфичен ACS, включени в неговия софтуер, трябва да бъдат регистрирани в държавния, браншовия или друг фонд от алгоритми и програми (в зависимост от случая).

1.6. Изисквания за информационна поддръжка на ACS

1.6.1. Информационната поддръжка на ACS трябва да е достатъчна за изпълнение на всички автоматизирани функции на ACS.

1.6.2. За кодиране на информация, използвана само в този ACS, трябва да се използват класификатори, приети от клиента на ACS.

1.6.3. За кодиране в ACS на изходната информация, използвана на по-високо ниво, трябва да се използват класификатори на по-високи системи за управление, с изключение на специално предвидени случаи.

1.6.4. Общи ергономични изисквания за кодиране на информация - съгласно GOST 21829-76.

1.6.5. В ACS за комуникация между устройства от комплекс от технически средства трябва да се използва следното:

входни и изходни сигнали:
- електрически - ток и напрежение в съответствие с GOST 26.011-80, с дискретна промяна на параметрите в съответствие с GOST 26.013-81, кодирани в съответствие с GOST 26.014-81,
- хидравлични в съответствие с GOST 26.012-80,
- пневматични в съответствие с GOST 26.015-81;
набори от букви и цифри в съответствие с GOST 19767-74;
8-битови кодове съгласно GOST 19768-74.

1.6.6. Информационната поддръжка на ACS трябва да бъде съвместима с информационната поддръжка на системите, взаимодействащи с нея, по отношение на съдържание, система за кодиране, методи за адресиране, формати на данни и формата на представяне на информацията, получена и издадена от ACS.

1.6.7. Формулярите на документи, създадени от ACS, трябва да отговарят на изискванията на стандартите за DCS или регулаторните и технически документи на отдела на клиента на ACS.

1.6.8. Формите на въвеждане, извеждане или коригиране на документи и видеокадри през терминалите на автоматизираната система за управление трябва да бъдат съгласувани със съответния техническа характеристикатерминали.

1.6.9. Наборът от информационни масиви на ACS трябва да бъде организиран под формата на бази данни на компютърни носители.

1.6.10. Формата на представяне на изходната информация на ACS трябва да бъде съгласувана с клиента (потребителя) на системата.

1.6.11. Термините и съкращенията, използвани в изходните документи на ACS, трябва да бъдат общоприети в дадената предметна област и съгласувани с клиента на системата.

1.6.12. ACS трябва да предвиди необходимите мерки за контрол и актуализиране на данните в информационните масиви на ACS, възстановяване на масивите след повреда на всяко техническо средство на ACS, както и да контролира идентичността на информацията със същото име в базите данни.

1.7. Изисквания за организационна поддръжка на ACS

1.7.1. Организационната поддръжка на автоматизираната система за управление трябва да бъде достатъчна за ефективното изпълнение на персонала на автоматизираната система за управление на възложените му задължения при изпълнение на автоматизирани задължения при изпълнение на автоматизирани и свързани неавтоматизирани функции на системата.

1.7.2. Организационната структура на ACS трябва да позволява изпълнението на всички функции на ACS, като се има предвид тяхното разпределение по нива на управление.

1.7.3. Изискванията за разпределение на задълженията между персонала, участващ в работата на автоматизираната система за управление в реално време, се определят, като се вземат предвид изискванията на клауза 11 от задължителното допълнение 1.

1.7.4. Инструкциите за организационна поддръжка на ACS трябва да определят действията на персонала на ACS, необходими за изпълнение на всяка автоматизирана функция, във всички режими на работа на ACS, като се вземат предвид определените изисквания за точността и скоростта на изпълнение от персонала на ACS на техните функционални отговорности, а също така съдържат конкретни инструкции за действия в случай на извънредни ситуации или нарушаване на нормалните условия на работа на ACS. Изисквания за съдържанието на инструкциите - в съответствие с GOST 24.209-80.

1.7.5. За всяка автоматизирана функция, която се изпълнява при взаимодействието на тази автоматизирана система за управление с други системи, инструкциите за персонала на автоматизираната система за управление и тези системи трябва да бъдат свързани помежду си за всички режими на изпълнение на тази функция и да съдържат инструкции за действия на персонала в случай на повреди на техническите средства на автоматизираната система за управление.

1.8. Изисквания за езикова поддръжка на ACS

1.8.1. Езиковата поддръжка на ACS трябва да е достатъчна за комуникация на различни категории потребители в удобна за тях форма с автоматизацията на ACS и за изпълнение на процедури за трансформация и машинно представяне на информацията, обработвана в ACS.

1.8.2. Езиковата поддръжка на ACS трябва да включва:

предвидено езикови средствада опише всяка информация, използвана в ACS;
използваните езикови средства са унифицирани;
описания на еднотипни информационни елементи и записи на синтактични конструкции са стандартизирани;
осигуряват се удобството, уникалността и стабилността на комуникацията между потребителите и средствата за автоматизация на ACS;
Осигурени са средства за коригиране на грешки, които възникват, когато потребителите комуникират с техническите средства на ACS.

1.8.3. Езиковата поддръжка на ACS трябва да бъде отразена в документацията (инструкции, описания) на организационната поддръжка на ACS под формата на правила за комуникация на потребителите с техническите средства на ACS във всички режими на работа на системата.

1.9. Изисквания за правна поддръжка на ACS

Правната поддръжка на ACS трябва да включва набор от правни разпоредби:

определяне на правната сила на информацията за носители на данни и документи, използвани в работата на ACS и създадена от системата;
регулиране на правоотношенията между хората, които са част от персонала на ACS (права, задължения и отговорности), както и между персонала на ACS и персонала на системите, взаимодействащи с ACS.

Забележка.Правилата и разпоредбите, произтичащи от правната сила на информацията за носителите на данни и правните норми, трябва да бъдат включени в инструкциите за организационна поддръжка и правилника за съответните услуги за ACS.

1.10. Изисквания към експлоатационната документация за ACS

1.10.1. Експлоатационната документация за автоматизираната система за управление трябва да е достатъчна за въвеждане в експлоатация на автоматизираната система за управление и нейното ефективно функциониране.

1.10.2. Оперативната документация за ACS трябва:

съдържат информация, необходима за бързо и качествено разработване и правилна работа на автоматизирани системи за управление;
съдържат инструкции за дейността на персонала на ACS в извънредни ситуацииили при нарушаване на нормалните условия на работа на ACS;
не съдържат двусмислени разпоредби.

2. ИЗИСКВАНИЯ ЗА БЕЗОПАСНОСТ

2.1. Неправилните действия на персонала на ACS не трябва да водят до авария.

2.2. Изискванията за безопасност на електрическите продукти, използвани в автоматизирани системи за управление, са в съответствие с GOST 12.2.007.0-75.

2.3. Изискванията за безопасност на компютърното оборудване, използвано в автоматизирани системи за управление, са в съответствие с GOST 25861-83.

2.4. Всички външни елементи на техническите средства на ACS, които са под напрежение, трябва да бъдат защитени от случаен контакт, а самите технически средства трябва да имат заземяване или защитно заземяване в съответствие с GOST 12.1.030-81 и "Правила за захранващото устройство".

2.5. Техническите средства на АСУ, поставени при взриво- и пожароопасни инсталации, трябва да отговарят на изискванията на "Правила за устройство на електрозахранването".

2.6. Техническите средства на ACS трябва да бъдат монтирани така, че да гарантират тяхната безопасна експлоатация и поддръжка.

2.7. Изискванията за безопасност трябва да бъдат установени от специален раздел длъжностни характеристикии (или) инструкции за експлоатация на ACS и имат връзки към инструкции за експлоатация на технически средства.

2.8. Общите ергономични изисквания за работните места на персонала на ACS са в съответствие с GOST 22269-76.

2.9. Комфортните условия на живот за персонала на ACS трябва да отговарят на настоящите санитарни стандарти, максимално допустимите условия на живот са в съответствие с GOST 12.1.005-76, допустимите нива на влияние на опасни и вредни производствени фактори - в съответствие с GOST 12.0. 003-74.

2.10. Общите ергономични изисквания за микроклимата на работните помещения на персонала на ACS са в съответствие с GOST 12.1.005-76.

2.11. Нивата на шум и звукова мощност в местата на персонала на автоматизираната система за управление не трябва да надвишават стойностите, установени от GOST 12.1.003-83 и санитарните стандарти, докато нивата на шум и звукова мощност, генерирани от всички източници, включително акустично предаване на данни, трябва да се вземат предвид.

2.12. Нивата на осветеност на работните места на персонала на ACS трябва да съответстват на естеството и условията на работа. Трябва да се осигури защита срещу отблясъци и отблясъци.

2.13. Общите ергономични изисквания за вибрациите на оборудването на работните места на персонала на ACS са в съответствие с GOST 12.1.012-78.

2.14. Сигнални цветове и знаци за безопасност в съответствие с GOST 12.4.026-76.

3. ВИДОВЕ И ПРОЦЕДУРА НА ИЗПИТВАНЕ ПРИ ВЪЗЛАГАНЕ НА ACS

Този раздел се отнася за всички автоматизирани системи за управление, с изключение на създадените със заповеди на Министерството на отбраната.

3.1. ACS или отделно доставената функция ACS (наричана по-долу ACS), когато е пусната в експлоатация, трябва да премине предварителни и приемо-предавателни изпитания, както и изпитания, предвидени от нормативни и технически документи, които са в сила в отдела на клиента на ACS.

3.2. Изпитванията за приемане на ACS трябва да бъдат предшествани от пробната му експлоатация в контролното съоръжение.

3.3. Тестовете на ACS се извършват в съответствие с документа "Тестова програма", който се изготвя от разработчика на ACS. Изисквания към съдържанието на тестовата програма - в съответствие с GOST 24.208-80.

3.4. Изпитванията за ACS могат да се извършват на един или няколко етапа.

Въз основа на резултатите от изпитването на ACS се съставя "Протокол от изпитване". Изисквания към съдържанието на протокола от изпитването - в съответствие с GOST 24.208-80.

По време на поетапното тестване на ACS в "Протокол за изпитване", въз основа на резултатите от предишния етап, трябва да има заключение за възможността за представяне на ACS за следващия етап на тестване.

3.5. Предварителни тестове на ACS

3.5.1. Извършват се предварителни тестове на ACS за определяне на неговата работоспособност и за решаване на въпроса за възможността за приемане на ACS за пробна експлоатация.

3.5.2. "Тестовата програма" за предварителни изпитания на ACS се одобрява от клиента на ACS.

3.5.3. Предварителните тестове на ACS се организират от клиента и се извършват от разработчика на ACS и клиента заедно.

3.5.4. Комисионната за предварителните изпитвания на АСУ се формира по поръчка на клиента. За председател на комисията се назначава представител на клиента на ACS.

3.5.6. „Протоколът от изпитването“, изготвен въз основа на резултатите от предварителните тестове на ACS, дава заключение относно възможността за приемане на ACS за пробен период, както и списък с необходимите подобрения и препоръчителните условия за тяхното изпълнение .

3.6. Пилотна експлоатация на ACS

3.6.1. Резултатите от приемането на АСУ в опитна експлоатация се оформят със "Сертификат за приемане в опитна експлоатация", съставен на базата на "Протокол за изпитване" от комисията, извършила предварителни изпитания на АСУ. Изисквания за съдържанието на акта - в съответствие с GOST 24.208-80.

3.6.2. Продължителността на пробната работа на ACS се определя от времето, необходимо за проверка на правилното функциониране на ACS при изпълнение на всяка автоматизирана функция и готовността на персонала на ACS да участва в изпълнението на всички автоматизирани функции на ACS.

3.6.3. Минималната продължителност на пробната работа на ACS (с изключение на ACS) преди приемо-предавателните тестове се определя за всяка предавана автоматизирана функция на ACS, тя трябва да съответства на стойностите, посочени в таблицата. Ако общата продължителност на прекъсванията на непрекъснатостта на автоматизираната функция надвишава стойността, посочена в таблицата, пробната работа трябва да продължи до получаване на резултатите, съответстващи на таблицата, или докато се вземе решение за прекратяването й.

Допуска се, по споразумение с клиента, предоставянето на ACS за приемни тестове без пробна експлоатация на тези автоматизирани функции, чиято честота е по-малко от веднъж месечно, при условие че не само тези функции са автоматизирани в ACS.

Честота на изпълнение на автоматизирана функция	Минималната продължителност на пробната експлоатация на ACS преди приемни изпитвания	Допустимата обща продължителност на прекъсванията на непрекъснатостта на автоматизираната функция на ACS
Непрекъснато	1 месец	Не повече от 3 дни
Веднъж на ден или повече	Също	Не повече от 10% от планирания брой решения
По-малко от веднъж на ден до веднъж месечно	3 месеца	Също
По-малко от веднъж месечно до веднъж на всеки шест месеца	Периодът между две последователни решения	Не се допускат нарушения на непрекъснатостта на функцията
Веднъж годишно или по-рядко	Периодът от време, необходим за проверка на възприетата технология за събиране и обработка на информация в процеса на еднократно изпълнение на функцията ACS	Също

бележки:

1. Нарушение на непрекъснатостта на автоматизираната функция на автоматизираната система за управление се счита за неизпълнението й в срока, посочен в техническата документация за автоматизираната система за управление, ако това не е причинено от нарушение на условията за функциониране на автоматизираната система за управление или обекта на управление.

2. Ако действителната продължителност на пробната работа на ACS е била по-голяма от времето, посочено във втората колона на таблицата, тогава общата продължителност на прекъсването на изпълнението за всяка автоматизирана функция се определя за периода от време, посочен в таблицата и незабавно предхождащи приемо-предавателните тестове.

3.6.4. По време на пробната работа на автоматизираната система за управление се води работен дневник, в който се вписва информация: за продължителността на функционирането на автоматизираната система за управление, за резултатите от наблюдението на правилното функциониране на автоматизираната система за управление, за повреди, повреди, аварийни ситуации, при промени в параметрите на обекта на управление и текущите корекции на техническата документация.

3.6.5. Въз основа на резултатите от пробната експлоатация се съставя акт за завършване на работата по проверка на ACS в режим на пробна работа. Изисквания за съдържанието на акта - в съответствие с GOST 24.208-80.

3.7. Тестове за приемане на ACS

3.7.1. Извършват се приемо-предавателни тестове на ACS, за да се определи съответствието му с техническите задания за ACS, изискванията на този стандарт и да се определи възможността за пускане на ACS в експлоатация.

3.7.2. В зависимост от важността на обекта за управление и ACS, приемо-предавателните тестове могат да бъдат:

състояние;
междуведомствена;
ведомствена

и трябва да се извършва от съответните приемни комисии. Приемателната комисия се формира със заповед на министерството (отдела) на клиента на ACS. Нивото на комисията по приемане трябва да бъде определено в техническата спецификация за ACS.

3.7.3. За председател на приемателната комисия се назначава представител на клиента на ACS. Комисията по приемане трябва да включва представители на разработчика на ACS.

3.7.4. Работата на приемателната комисия не включва приемането на сгради, конструкции и спомагателно оборудване, чието създаване е извършено във връзка със създаването на автоматизираната система за управление. Комисията само проверява наличието на актове за приемането им в експлоатация и изпълнението на изискванията, съдържащи се в заданията за проектиране в прилежащите части на проекта на съоръжението, издадени при проектирането на АСУ.

3.7.5. Клиентът и разработчикът представят на комисията по приемане следната документация:

техническо задание за създаване на автоматизирана система за управление;
проект на програма за приемни тестове;
Предварителен протокол за изпитване на ACS;
Сертификат за приемане на ACS за пробна експлоатация;
акт(и) за завършване на работата по проверка на ACS в режим на пробна експлоатация;
техническа документация за ACS (по решение на приемателната комисия).

3.7.6. Преди представяне на АСУ с измервателни канали за приемни изпитвания се извършва метрологичното им освидетелстване в съответствие с приложимите стандарти.

3.7.7. Преди представяне на АСУ за приемни изпитания, системата и техническата й документация трябва да бъдат финализирани съгласно забележките на протокола за предварителни изпитвания и акта за приключване на работата по проверка на АСУ в режим на пробна експлоатация.

Разрешава се по решение на приемателната комисия да се преработи техническата документация на ACS след пускането му в експлоатация. Сроковете за финализиране на техническата документация на ACS са посочени в протокола от приемо-предавателния тест на системата.

3.7.8. Тестовете за приемане на ACS трябва да се извършват във функциониращо контролно съоръжение.

3.7.9. "Програмата за изпитване" за приемните изпитания на ACS трябва да бъде одобрена с решенията на комисията по приемане. Съгласуването на програмата за приемо-изпитание с клиента на ACS е задължително.

3.7.10. Въз основа на резултатите от приемо-предавателните тестове комисията изготвя протокол за изпитване и акт за въвеждане в експлоатация на ACS (или заключение за неприемане на ACS със списък на необходимите подобрения и препоръчителните условия за тяхното изпълнение) . Изисквания за съдържанието на протокола и действие в съответствие с GOST 24.208-80. Изискванията за съдържанието на заключението за неприемане на ACS са подобни на изискванията за съдържанието на акта за въвеждане в експлоатация на ACS.

3.7.11. В случай на поетапно приемане, актът за въвеждане в експлоатация на ACS се съставя въз основа на актовете за въвеждане в експлоатация на отделни части на системата и (или) "Протоколи за изпитване" на всички етапи на приемане на ACS тестове.

3.7.12. За дата на въвеждане в експлоатация на АСУ се счита датата на подписване на акта за въвеждане в експлоатация от приемателната комисия.

3.7.13. Актът за въвеждане в експлоатация на ACS се одобрява от министерството (ведомството) на клиента.

4. ПЪЛЕН КОМПЛЕКТ СЪДЪРЖАВАЩИ СЪЕДИНЕНИЯ, ВЪВЕДЕНИ В РАБОТА

4.1. ACS трябва да включва:

Хардуер на ACS под формата на комплект хардуер на ACS, подготвен за работа;
резервни продукти и устройства (резервни части), устройства и устройства за проверка на работоспособността, настройка на технически средства и наблюдение на метрологичните характеристики на измервателните канали на автоматизираната система за управление в количеството, предвидено в поръчаното проектна документация, съгласувано с клиента на АСУ и метрологичната служба на потребителя по отношение на оборудването за проверка;
оперативна документация в съответствие с GOST 2.601-68 за всеки от продуктите, включени в CTS ACS;
най-малко две копия на програми за носители на данни и оперативна документация за тях в съответствие с GOST 19.101-77, като се вземат предвид ограниченията и допълненията в съответствие с GOST 24.101-80 и GOST 24.207-80;
формуляр за софтуера на ACS като цяло или за софтуера на функцията ACS, пуснат в експлоатация поотделно, и формуляри за софтуерни продукти (съгласно GOST 19.004-80), всеки в един екземпляр. Изисквания към формуляра - в съответствие с GOST 19.501-78;
два екземпляра от оперативната документация за ACS в съответствие с GOST 24.101-80, включително необходимата документация за информационната поддръжка на ACS (формуляр ACS в едно копие).

По споразумение между разработчика на ACS и клиента на ACS, пълнотата на ACS може да бъде разширена.

4.2. Персоналът на ACS трябва да бъде оборудван с персонал, който отговаря на изискванията на точка 1.3.

4.3. За завършване на създадения ACS могат да се използват следните продукти, доставени за производствено и техническо предназначение:

комплекс (комплекси) от хардуер и софтуер с оперативна документация за тях в съответствие с GOST 2.601-68;
софтуерни продукти с оперативна документация за тях в съответствие с GOST 19.101-77;
технически средства с оперативна документация за тях в съответствие с GOST 2.601-68.

4.4. Процедурата за разработване, пускане в производство и тестване на доставените компоненти, използвани в автоматизираната система за управление, трябва да отговаря на държавните стандарти на системата за разработване и пускане на продукти.

Преди да бъдат пуснати в производство, прототипите на компоненти се подлагат на приемни (държавни, междуведомствени, ведомствени) тестове.

5. ГАРАНЦИЯ

5.1. Разработчикът на ACS гарантира съответствието на ACS с изискванията на този стандарт и техническата спецификация за ACS, при условие че потребителят спазва условията и правилата за експлоатация.

5.2. Съответствието на хардуера, софтуера и системите за автоматизация, използвани в ACS и доставяни като производствени и технически продукти с изискванията на стандартите и техническите спецификации за тях, се гарантира от производителите на тези видове продукти, при условие че потребителят спазва условията и правила за експлоатация.

5.3. Гаранционният срок за ACS се изчислява от деня на въвеждане на ACS в експлоатация.

5.4. Гаранционният срок за ACS трябва да бъде зададен в TK за ACS и не може да бъде по-малък от 18 месеца.

ПРИЛОЖЕНИЕ 1
Задължителен

ДОПЪЛНИТЕЛНИ ИЗИСКВАНИЯ ЗА АВТОМАТИЗИРАНИ СИСТЕМИ ЗА УПРАВЛЕНИЕ НА ПРОЦЕСИТЕ (АПК)

1. АСУ ТП в промишлеността и в непромишлената сфера трябва да управляват технологичния обект като цяло и да доставят на свързаните с него системи с надеждна технологична и технико-икономическа информация за работата на технологичния обект на контрол (ТОК).

2. АСУ ТП трябва да разработи и внедри рационални по цели и критерии за управление, контролни действия по ТОУ в реално време на протичането на технологичния процес в обекта на управление.

3. АСУ ТП трябва да изпълнява контролни, информационни и спомагателни функции.

4. APCS трябва да е съвместим с всички взаимосвързани автоматизирани системи (AS), посочени в TK за APCS, включително системите, включени в този APCS като част от гъвкаво автоматизирано производство, например CAD технология, автоматизирани складови и транспортни системи, AS на технологична подготовка на производството.

5. Управляващите действия в АСУ ТП трябва да се генерират автоматично или да се формират от нейния оперативен персонал с помощта на набор от средства за автоматизация, включени в системата.

6. АСУ ТП трябва да осигурява контрол на съоръжението при нормални, преходни и предаварийни условия на неговата експлоатация, както и защита или спиране на съоръжението при заплаха от авария.

7. АСУ ТП трябва да изпълнява функцията за наблюдение на изпълнението на контролни действия по ТО и да сигнализира за излизане на изпълнителните органи на максимално допустимите позиции.

8. При изпълнение на функцията за аварийно автоматично отклонение на оборудването в АСУ ТП трябва да се осигури аларма за това на експлоатационния персонал с помощта на светлина и при необходимост, звукови сигналис автоматично регистриране на времето за изключване.

9. Продуктите трябва да се използват като основно техническо средство на АСУ ТП Държавна системапромишлени устройства и оборудване за автоматизация (GSP), други продукти, които отговарят на изискванията на стандартите ESSP, и компютърно оборудване, отговарящо на GOST 21552-84.

10. Техническите средства на АСУ ТП, поставени на технологичното оборудване, трябва да отговарят на изискванията, наложени им от условията на експлоатация.

11. Отговорностите между операторите трябва да се разпределят, като се вземе предвид:

участие на персонала в изпълнението на неавтоматизирани функции на системата и взаимодействието й с други системи;
допустимото ниво на психофизиологично и емоционално натоварване на операторите, установено от регулаторните и технически документи на индустрията, свързани с изпълнението на задълженията, възложени на всеки от тях, и неговата отговорност за крайните и междинни резултати от работата, както и необходимото ниво на неговия активност в процеса на работа.

12. Всяко лице, което е част от персонала, трябва да притежава:

знания, чийто обем и дълбочина му позволяват да извършва действия (взаимодействия), включени в съответните автоматизирани и взаимосвързани неавтоматизирани функции на АСУ ТП, както и да взема правилни решения при аварийни ситуации или в случай на други нарушения на нормалните операция;
доказани умения, които позволяват извършване на всички действия и взаимодействия с посочената точност и скорост.

13. Софтуерът на АСУ ТП трябва да осигурява, а организационната поддръжка да отразява езиковите средства за комуникация на експлоатационния персонал с КСУ на АСУ ТП, удобни и достъпни за лица, които нямат квалификация на програмист.

14. Кодове и легендаизползваните в АСУ ТП трябва да са близки до термините и понятията, използвани от технологичния персонал на обекта на управление, и да не създават затруднения при тяхното възприемане.

15. Измервателните канали на АСУ ТП трябва да имат метрологични характеристики, осигуряващи изпълнението на информационните му функции с показателите, посочени в техническата спецификация за АСУ ТП.

16. Изисквания за изпитване на ACS TP

16.1. Предварителни изпитания на АСУ ТП се извършват в действащия TOU.

16.2. Предварителни изпитания на функциите на АСУ ТП, необходими за пускане в експлоатация и пускане в експлоатация на технологичното оборудване, могат да се извършват в съоръжението с помощта на симулатори.

16.3. Определянето на действителните стойности на показателите за технико-икономическа ефективност и надеждност на АСУ ТП се извършва след въвеждането му в експлоатация. Продължителността на времето на работа на АСУ ТП, необходима за определяне на действителните стойности на неговите показатели, се изчислява по подходящи методи, одобрени по предписания начин.

ПРИЛОЖЕНИЕ 2
Задължителен

ДОПЪЛНИТЕЛНИ ИЗИСКВАНИЯ ЗА ACS ЗА ПРЕДПРИЯТИЯ, ПРОИЗВОДСТВЕНИ И НАУЧНО-ПРОИЗВОДСТВЕНИ СДРУЖЕНИЯ

1. ACS трябва да повишава ефективността на производствените и стопанските дейности на предприятията, производствените или научно-производствените асоциации (наричани по-долу предприятия).

2. Автоматизираната система за управление (AMCS) на предприятието трябва да осигурява автоматизирано събиране и обработка на информация с широко използване на оптимизационни методи за основните задачи и подсистеми за управление на ниво завод и цех, включително, ако е необходимо, в реално време в телеобработка и режим на диалог.

3. ACS следва да се реализира като набор от съвместно функциониращи подсистеми, взаимодействието между които да се осъществява чрез обща (единична или разпределена) база данни.

4. Организационната поддръжка на автоматизираната система за управление трябва да осигурява подобряване на методите за управление и структурата на системата за управление на предприятието при създаването и развитието на автоматизираната система за управление.

ПРИЛОЖЕНИЕ 3
Задължителен

ДОПЪЛНИТЕЛНИ ИЗИСКВАНИЯ ЗА ИНДУСТРИАЛНИ АВТОМАТИЗИРАНИ СИСТЕМИ ЗА КОНТРОЛ (AMS)

1. OASU трябва да осигури:

подобряване на характеристиките на обекта на управление (повишаване на производителността на труда в индустрията, подобряване на качеството на продуктите, навременна доставка на продукти, намаляване на цената на продуктите);
подобряване на процесите на обработка на информация (намаляване на разходите за обработка на информация, повишаване на надеждността на първоначалните, повишаване на точността и ефективността на изчисленията);
подобряване на организацията на изпълнението на управленските функции (по-специално, рационалното разпределение на работата между отделите на управленския апарат, изчислителните центрове и изследователските организации и предприятия).

2. OASU трябва да има автоматизирани функции за управление на индустрията, например:

прогнозиране и планиране на производствени и индустриални ресурси;
управление на научно-техническото развитие на индустрията и техническата подготовка на индустрията;
контрол трудови ресурсииндустрия;
контрол материални ресурсииндустрия;
управление на капиталното строителство в бранша;
контрол финансови ресурсииндустрия;
управление, включително оперативно управление, на основното производство на ниво индустрия и др.

3. OAMS трябва да се реализира като набор от съвместно функциониращи подсистеми, взаимодействието между които да се осъществява чрез общи бази данни.

4. OASU трябва да включва система за събиране на данни, базирана на изчислителните центрове на OASU, организации и предприятия от индустрията, осигуряваща рационалното разпределение на информацията в бази данни за решаване на взаимодействащи проблеми и предаване на информация между системите по комуникационни канали и на компютърни носители.

5. OASU трябва да осигури интерактивен режим на работа с базите данни на системата.

6. Създаването на OASU трябва да доведе до подобряване на методите и структурата на управление на индустрията.

7. Продължителността на пробната експлоатация на части от OASU трябва да осигури еднократно изпълнение на всички изчисления, необходими за изпълнение на автоматизираните функции на въведената част на OASU, и не трябва да надвишава 3 месеца.

Конкретната продължителност на пробната експлоатация на OASU се определя по споразумение между разработчика и клиента.

ПРИЛОЖЕНИЕ 4
Справка

ОБЯСНЕНИЕ НА ОПРЕДЕЛЕНИ ТЕРМИНИ, ИЗПОЛЗВАНИ В ТОЗИ СТАНДАРТ

Комплекс за автоматизация (KSA)- доставеният набор от взаимно съгласувани комплекси от хардуер и софтуер (продукти), разработени и произведени като продукти за промишлено-технически цели. Съставът на KSA може да включва и други продукти и (или) документи, които са част от информационната, организационна или други видове поддръжка за автоматизирани системи.

Изграждане на ACS- набор от мерки, предприети в ACS при разширяване на неговия обект на управление без промяна на състава на функциите на ACS.

Видеокадър (в ACS)- изображението на екрана на електронно-лъчева тръба на документ на чертеж или текст на съобщение, използвано в автоматизирана система за управление.

Измервателен канал на ACS- функционално комбиниран набор от технически и (ако е необходимо) софтуерни инструменти, предназначени да реализират една проста измервателна функция на ACS.

Предварителни тестове на ACS- проведени контролни изпитания с цел установяване на възможността за приемане на автоматизираната система за управление в опитна експлоатация.

Тестове за приемане на ACS- контролни тестове на автоматизираната система за управление, извършени за определяне на съответствието й с техническото задание за създаване на автоматизираната система за управление, изискванията на стандартите и за определяне на възможността за пускане на автоматизираната система за управление в експлоатация.

Държавни тестове- Приемни тестове на ACS, проведени от държавната комисия.

Междуведомствен тест- Приемателни тестове на ACS, извършени от комисия от представители на няколко заинтересовани министерства и (или) ведомства.

Тестване на отделите- Приемни изпитания на ACS, провеждани от комисия от представители на заинтересованото министерство или ведомство.

Редактор А.И. Ломина
Технически редактор Н.П. Замолодчикова
Коректор Е.И. Евтеева
Дарен на комплекта 16.01.86г. Подписано за печат на 08.04.86г. КОНВ. печат л. 1.5. КОНВ. кр.-От. 1.5 Уч.-изд. л. 1.5.
Тираж 40 000 Цена 10 коп.
Орден "Знак на честта" Стандарти издателство, 123810, Москва, GSP, Новопресненски пер., 3
Тип. „Московска печатница“, Москва, Лялин пер., 6. Заповед 1772г

Дата на въвеждане 01.01.92г

Този стандарт се прилага за автоматизирани системи (АС), използвани в различни дейности (изследователска дейност, проектиране, управление и др.), включително техните комбинации, създадени в организации, сдружения и предприятия (наричани по-долу организации).

1. Общи положения

2. Етапи и етапи на създаване на говорител

Приложение 1 (справка)

Приложение 2 (справка)

1. ОБЩИ РАЗПОРЕДБИ

1.1. е съвкупност от подредени във времето, взаимосвързани, обединени в етапи и етапи на работа, чието изпълнение е необходимо и достатъчно за създаване на АУ, отговарящ на посочените изисквания.

1.3. Работата по разработването на АС се извършва според етапите и етапите, използвани за създаване на АС.

Списъкът на организациите, участващи в работата по създаването на АС, е даден в Приложение 2.

2. ЕТАПИ И ЕТАПИ НА СЪЗДАВАНЕ НА АС

2.1. Етапите и етапите на създаване на AU в общия случай са показани в таблицата.

Етапи	Етапи на работа
1. Формиране на изисквания към АС	1.1. Проучване на обекта и обосновка на необходимостта от създаване на АЕЦ
	1.2. Формиране на потребителски изисквания към високоговорителя
	1.3. Регистрация на отчет за извършената работа и заявление за разработване на AU (тактико-техническо задание)
2. Развитие на концепцията за АС	2.1. Проучване на обекта
	2.2. Извършване на необходимата изследователска работа
	2.3. Разработване на варианти на концепцията на високоговорителя и избор на версия на концепцията на високоговорителя, която удовлетворява изискванията на потребителя
	2.4. Регистрация на отчет за извършената работа
3. Техническо задание	3.1. Разработване и утвърждаване на технически спецификации за създаване на АС
4. Проект на проект	4.1. Разработване на идейни проектни решения за системата и нейните части
4. Проект на проект	4.2. Разработване на документация за АЕЦ и нейните части
5. Технически дизайн	5.1. Разработване на дизайнерски решения за системата и нейните части
	5.2. Разработване на документация за АЕЦ и нейните части
	5.3. Разработване и изпълнение на документация за доставка на продукти за попълване на АС и (или) технически изисквания (технически спецификации) за тяхното разработване
	5.4. Разработване на проектни задания в съседни части на проекта на обекта за автоматизация
6. Работна документация	6.1. Разработване на работна документация за системата и нейните части
6. Работна документация	6.2. Разработване или адаптиране на програми
7. Привеждане в действие	7.1. Подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ
	7.2. Обучение на персонала
	7.3. Пълен комплект високоговорители с доставени продукти (софтуер и хардуер, софтуерни и хардуерни комплекси, информационни продукти)
	7.4. Строително-монтажни работи
	7.5. Пусконаладъчни работи
	7.6. Предварителни тестове
	7.7. Пробна експлоатация
	7.8. Тестове за приемане
8. Акомпанимент на АС	8.1. Изпълнение на работата в съответствие с гаранционните задължения
8. Акомпанимент на АС	8.2. Следгаранционно обслужване

2.2. Етапите и етапите, извършвани от организациите - участници в работата по създаването на АС, са установени в договори и техническо задание, базирани на този стандарт.

Допуска се изключване на етап „Проектиране“ и отделни етапи на работа на всички етапи, комбиниране на етапите „Технически проект“ и „Работна документация“ в един етап „Техническо проектиране“. В зависимост от спецификата на създаваните ядрени системи и условията за тяхното създаване се допуска извършване на отделни етапи на работа преди завършване на предишните етапи, успоредно във времето изпълнение на етапи на работа, включване на нови етапи на работа .

ПРИЛОЖЕНИЕ 1 Справка

1. На етап 1.1 "Проучване на съоръжението и обосновка на необходимостта от създаване на атомна електроцентрала", в общия случай, извършете:

събиране на данни за обекта на автоматизация и извършваните дейности;
оценка на качеството на обекта и извършваните дейности, идентифициране на проблеми, решаването на които е възможно чрез автоматизация;
оценка (техническа, икономическа, социална и др.) на осъществимостта за създаване на АС.

2. На етап 1.2 "формиране на потребителски изисквания за AU" извършете:

подготовка на изходни данни за формиране на изисквания към атомната електроцентрала (характеристики на обекта за автоматизация, описание на изискванията към системата, ограничаване на допустимите разходи за разработване, въвеждане в експлоатация и експлоатация, очакван ефект от системата, условия за създаване и функциониране на системата);
формулиране и изпълнение на потребителските изисквания за АС.

3. На етап 1.3 "Изпълнение на отчет за извършената работа и заявление за разработване на АС (тактико-техническо задание)" се съставя доклад за извършената работа на този етап и заявление за разработване на е съставен АС (тактико-техническо задание) или друг документ, който го замества, с подобно съдържание.

4. На етапи 2.1 "Проучване на обекта" и 2.2 "Извършване на необходимата изследователска работа", организацията-разработчик извършва подробно проучване на обекта за автоматизация и необходимата изследователска работа (R&D), свързана с намиране на начини и оценка на възможността за изпълнение на изискванията на потребителите, изготвяне и одобряване на доклади за научноизследователска и развойна дейност.

5. На етап 2.3 „Разработване на опции за концепцията на AU и избор на версия на концепцията на AU, отговаряща на изискванията на потребителя“, в общия случай, разработете алтернативни варианти за концепцията на създадения AU и планове за тяхното изпълнение ; оценка на необходимите ресурси за тяхното изпълнение и поддържане; оценка на предимствата и недостатъците на всеки вариант; сравнение на потребителските изисквания и характеристики на предложената система и избор най-добрият вариант; определяне на реда за оценка на качеството и условията за приемане на системата; оценка на ефектите, получени от системата.

6. На етап 2.4 "Изпълнение на отчета за извършената работа" изготвят и изготвят доклад, съдържащ описание на извършената работа на етапа, описание и обосновка на предложената версия на концепцията на системата.

7. На етап 3.1 „Разработване и утвърждаване на техническото задание за създаване на АЕЦ“ разработването, изпълнението, съгласуването и утвърждаването на техническото задание за АЕЦ и при необходимост техническото задание за частта на АЕЦ. се извършват.

8. На етап 4.1 "Разработване на идейни проектни решения за системата и нейните части" се определят: функциите на атомната електроцентрала; функции на подсистемите, техните цели и ефекти; състава на комплекси от задачи и индивидуални задачи; концепцията за информационната база, нейната разширена структура; Функции на системата за управление на база данни; състава на изчислителната система; функции и параметри на основния софтуер.

9. На етап 5.1 „Разработване на проектни решения за системата и нейните части“ осигурява разработването на общи решения за системата и нейните части, функционалната и алгоритмичната структура на системата, функциите на персонала и организационната структура, структурата на технически средства, алгоритми за решаване на проблеми и използваните езици, относно организацията и поддържането на информационната база, системата за класификация и кодиране на информацията, върху софтуера.

10. На етапи 4.2 и 5.2 "Разработване на документация за АЕЦ и нейните части" разработването, изпълнението, съгласуването и одобрението на документацията се извършва до степента, необходима за описване на пълния набор от приети проектни решения и достатъчна за по-нататъшна работа. за създаването на АЕЦ. Видове документи - съгласно GOST 34.201.

11. На етап 5.3 "Разработване и изпълнение на документация за доставка на продукти за завършване на АЕЦ и (или) технически изисквания (технически спецификации) за тяхното разработване" изготвя и изпълнява документация за доставка на продукти за доизграждане на АЕЦ; определяне на технически изисквания и изготвяне на технически спецификации за разработване на продукти, които не се произвеждат масово.

12. На етап 5.4 "Разработване на задания за проектиране в съседни части на проекта за автоматизация" извършва разработването, регистрирането, одобряването и одобряването на задания за проектиране в съседни части на обекта за автоматизация за строителни, електро-, санитарни и други подготвителни работи, свързани с създаването AC.

15. На етап 7.1 "Подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ" се извършват работи по организационна подготовка на обекта за автоматизация за въвеждане в експлоатация на АЕЦ, включващи: изпълнение на проектни решения за организационната структура на АЕЦ; осигуряване на подразделения на обекта на управление с инструктивно-методически материали; въвеждане на класификатори на информация.

17. На етап „Попълване на АС с доставените продукти“ осигуряват получаването на компоненти от серийно и единично производство, материали и монтажни продукти. Те извършват входящ контрол на качеството.

18. На етап 7.4 "СМР" се извършва: изпълнение на работи по изграждане на специализирани сгради (помещения) за разполагане на техническо оборудване и персонал на АЕЦ; изграждане на кабелни канали; изпълнение на работи по монтаж на технически средства и комуникационни линии; тестване на монтирано техническо оборудване; доставка на технически средства за въвеждане в експлоатация.

19. На етап 7.5 „Пускане в експлоатация” извършва автономна настройка на хардуера и софтуера, зареждане на информация в базата данни и проверка на системата за нейната поддръжка; комплексна настройка на всички средства на системата.

20. На етап 7.6 "Предварителни изпитвания" се извършват:

изпитване на АЕЦ за работоспособност и съответствие с техническото задание в съответствие с програмата и методиката на предварителните изпитвания;
отстраняване на неизправности и промени в документацията за АЕЦ, включително експлоатационната, съгласно протокола от изпитването;
регистрация на удостоверение за приемане на АЕЦ за опитна експлоатация.

21. На етап 7.7 "Опитна експлоатация" се извършва опитна експлоатация на АЕЦ; анализ на резултатите от експерименталната експлоатация на АЕЦ; ревизия (ако е необходимо) на AC софтуера; допълнителна настройка (при необходимост) на техническите средства на атомната електроцентрала; регистрация на акт за завършване на пробна експлоатация.

22. На етап 7.8 "Приемателни тестове" извършват:

тестове за съответствие с техническото задание в съответствие с програмата и методите за приемни изпитвания;
анализ на резултатите от AU тестовете и отстраняване на констатираните по време на тестовете недостатъци;
регистрация на удостоверение за приемане на АЕЦ за постоянна експлоатация.

23. На етап 8.1 „Извършване на работа в съответствие с гаранционните задължения” се извършва работа по отстраняване на констатираните при експлоатацията на АЕЦ недостатъци през установените гаранционни срокове, за извършване на необходимите промени в документацията за АЕЦ.

24. На етап 8.2 "Следгаранционно обслужване" се извършва работа по:

анализ на функционирането на системата;
идентифициране на отклонения на действителните експлоатационни характеристики на АЕЦ от проектните стойности;
установяване на причините за тези отклонения;
отстраняване на констатираните недостатъци и осигуряване на стабилност на експлоатационните характеристики на АЕЦ;
извършване на необходимите промени в документацията за АС.

ПРИЛОЖЕНИЕ 2. Справка

СПИСЪК НА ОРГАНИЗАЦИИТЕ, УЧАСТВАЩИ В СЪЗДАВАНЕТО НА AU

1. Организация-клиент (ползвател), за която ще бъде създадена АЕЦ и която осигурява финансиране, приемане на работите и експлоатацията на АЕЦ, както и извършването на отделни работи по създаването на АЕЦ.

2. Организацията-разработчик, която извършва работа по създаването на АС, като предоставя на клиента набор от научни и технически услуги на различни етапи и етапи на създаване, както и разработва и доставя различен софтуер и хардуер за АС .

4. Организация-генерален проектант на обекта за автоматизация.

6. Организации за строителство, монтаж, въвеждане в експлоатация и други.

бележки:

1. В зависимост от условията за създаване на АС са възможни различни комбинации от функции на клиент, разработчик, доставчик и други организации, участващи в създаването на АС.

2. Етапите и етапите на тяхната работа по създаването на АС се определят на базата на този стандарт.

ИНФОРМАЦИОННИ ДАННИ

1. РАЗРАБОТЕН И ВЪВЕДЕН от Държавния комитет за управление и стандарти на качеството на продуктите на СССР

РАЗРАБОТЧИЦИ

Ю.Х. Вермишев, д-р. науки; Я.Г. Виленчик; В И. Воропаев, д-р. науки; Л.М. Зайденберг, канд. технология науки; Ю.Б. Ирз, канд. технология науки; В.Д. Костюков, канд. технология науки; М.А. Лабутин, съгл. технология науки; Н.П. Лесковская; I.S. Митяев; V.F. Попов (водител на тема); С.В. Гаршина; A.I. Глухи вярващи; ЮГ. Жуков, к.т.н. науки; З.П. Задубовская; V.G. Иванов; Ю.И. Караванов, к.т.н. науки; А.А. Парчета; В.Ю. Королев; В И. Махнач, канд. технология науки; С. Б. Михалев, д-р. науки; В.Н. Петрикевич; V.A. Рахманов, канд. икономичност. науки; А.А. Раткович; R.S. Седегов, д-р. науки; Н.В. Степанчикова; ГОСПОЖИЦА. Суровец; A.V. Fleents; Л.О. Хвилевски, канд. технология науки; VC Чистов, канд. икономичност. науки

2. ОДОБРЕН И ВЪВЕДЕН в действие с Постановление на Държавния комитет на СССР за управление и стандарти на качеството на продуктите от 29 декември 1990 г. № 3469.

Въведение

V съвременен святвсеки ден се появяват десетки и стотици различни програми, приложения, информационни системи. Те могат да бъдат проектирани както за обществения или търговския сектор, така и за обикновени потребители. 90% от всички потребители не четат документацията, смятат я за скучна, скучна и безинтересна и отварят ръководството за потребителя само когато нещо не се получава или е абсолютно невъзможно да се разбере без инструкции. Вече е общоприето потребителският интерфейс да се изгражда по такъв начин, че да е интуитивен и потребителят да разбира системата, без да се налага да чете дълги ръководства. Въпреки това, когато се работи с големи клиенти, почти винаги е необходимо да се представи определен пакет от документи - ръководства, инструкции, дизайнерски решения, изготвени в съответствие с GOST.
Когато за първи път се сблъскате с писането на документация в съответствие с GOST, изпадате в ступор и пълен шок, тъй като тези GOST са „морски“ и как и какво да се пише за тях става неясно.
Тази статия разглежда GOST за писане на документация и техните основни точки.

Какви са GOST?

Първо трябва да разберете какви са GOST. Всеки просто знае, че GOST е нещо, което е разработено в рамките на Съюза и просто има безкраен брой от тях. Бързам да ви уверя, че няма толкова много стандарти GOST за ИТ сектора и всички те, въпреки времето на тяхното създаване, не са загубили своята актуалност.
На първо място, стандартите за писане на документация са разделени на два вида:

Международни стандарти (ISO, IEEE Std);
Руски или съветски ГОСТ.

Международни стандарти
Международните стандарти се използват за разработване на документация на международно ниво. По правило те не са безплатни, тъй като не са разработени от правителствени организации, но за разлика от нашите, те са разработени съвсем наскоро. Темата за международните стандарти е много широка, така че ще бъде разгледана в друга статия. Веднага се засягат няколко стандарта, които са тясно свързани с писането на документация.
Списък на основните международни стандарти за писане на документация:

IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - стандарт за писане на ръководство за потребителя;
IEEE Std 1016-1998 "Препоръчана практика от IEEE за описания на софтуерен дизайн" - стандарт за писане техническо описаниепрограми;
ISO / IEC FDIS 18019: 2004 „Насоки запроектиране и подготовка на потребителска документация за приложния софтуер ”е друг стандарт за писане на ръководство за потребителя. Този документ има голям бройпримери. Тоест, изглежда по-скоро като ръководство за писане на ръководство за потребителя. Начинаещите ще бъдат особено полезни;
ISO / IEC 26514: 2008, Изисквания за дизайнери и разработчици на потребителска документация, е друг стандарт за дизайнери и разработчици на потребителска документация.

Всъщност има много международни стандарти и те са различни във всяка страна, тъй като един и същ стандарт може да не винаги е подходящ както за европейски, така и за азиатски компании.

руски стандарти
Руските стандарти се разработват на държавно ниво. Всички те са напълно безплатни и всички са лесни за намиране в Интернет. За написване на документация за програмата се използват две серии от GOST 19 и 34. Става въпрос за тях, които ще бъдат обсъдени по-нататък.

Каква е разликата между GOST от серии 19 и 34?

Първият въпрос, който възниква, е как като цяло тези GOST 19 и 34 се различават един от друг.
В GOST 19.781-90 „Единна система за програмна документация. Софтуер за системи за обработка на информация. Термини и определения "дефинициите са посочени:

Програма - данни, предназначени за управление на специфични компоненти на система за обработка на информация с цел изпълнение на конкретен алгоритъм.
Софтуер - набор от програми на системата за обработка на информация и програмни документи, необходими за работата на тези програми.

В GOST 34.003-90 „Информационни технологии. Набор от стандарти за автоматизирани системи. Автоматизирани системи. Термини и определения "дефиницията е посочена:

Автоматизирана система (АС) е система, състояща се от персонал и комплекс от средства за автоматизиране на тяхната дейност, която реализира информационна технология за изпълнение на установени функции.
В зависимост от вида на дейност, например, се разграничават следните видове AU: автоматизирани системи за управление (ACS), системи компютърно подпомагано проектиране(CAD), автоматизирани изследователски системи (ASNI) и др.

В зависимост от вида на контролирания обект (процес) АСУ се разделят например на: АСУ по технологични процеси (АСУ), АСУ по предприятия (АСУ) и др.
Също така, GOST 34 прави разделение на видове поддръжка на АЕЦ:

Организационна;
Методически;
Технически;
Математически;
Софтуер;
Информационни;
лингвистичен;
Правни;
Ергономичен.

В резултат на това автоматизираната система не е програма, а набор от видове поддръжка, включително софтуер. AS, като правило, носи организационно решение за конкретен потребител и клиент, а Програмата може да бъде създадена и репликирана за голям брой потребители, без да е обвързана с което и да е предприятие.
Следователно, ако разработвате документация за програма, която сте създали за конкретно предприятие, тогава вашият GOST 34. Ако пишете документи за масова програма, тогава вашият GOST 19.

ГОСТ 34

Серията GOST 34 (GOST 34.xxx Стандарти за информационни технологии) се състои от:

GOST 34.201-89 Видове, пълнота и обозначения на документи при създаване на автоматизирани системи - този стандарт установява видовете, името, пълнотата и номерата на документите. Това е един от основните документи от серията GOST 34. Всъщност това е основен документ, така че начинаещите трябва първо да се запознаят с него.
GOST 34.320-96 Понятия и терминология за концептуална схема и информационна база - този стандарт установява основните понятия и термини на концептуални схеми и информационни бази, обхващащи разработването, описанието и прилагането на концептуални схеми и информационни бази, манипулирането на информация, както и описанието и изпълнението на информационния процес. Стандартът определя ролята на концептуалната схема. Разпоредбите, изложени в него, имат препоръчителен характер и могат да се използват за оценка на системите за управление на бази данни (СУБД). Този документ не описва специфични методи за използване на инструментите за поддръжка на концептуални схеми. Езиците на концептуалните схеми, описани в стандарта, не трябва да се считат за стандартни.
GOST 34.321-96 Информационни технологии. Система за стандарти за бази данни. Референтен модел за управление – Този документ установява референтен модел за управление на данни.
Референтният модел дефинира обща терминология и понятия, свързани с данните от информационните системи. Такива концепции се използват за дефиниране на услугите, предоставяни от системите за управление на бази данни или системите за речници на данни.
Референтният модел не разглежда протоколи за управление на данни.
Обхватът на референтния модел включва процеси, които се отнасят до управлението на постоянни данни и тяхното взаимодействие с процеси, които се различават от изискванията на конкретен информационна системакакто и общи услуги за управление на данни за дефиниране, съхраняване, търсене, актуализиране, въвеждане, копиране, възстановяване и прехвърляне на данни.
GOST 34.601-90 Автоматизирани системи. Етапи на създаване – стандартът установява етапите и етапите на създаване на АС.
GOST 34.602-89 Техническо задание за създаване на автоматизирана система (вместо GOST 24.201-85) - установява състава, съдържанието, правилата за съставяне на документа „Техническо задание за създаване (разработване или модернизиране) на системата "
Този документ е един от най-често използваните документи от серията GOST 34. При разработването на TK в съответствие с този GOST трябва да се помни за други стандарти, дори ако този документ не съдържа препратки към тези стандарти.
GOST 34.603-92 Информационни технологии. Видове изпитания на автоматизирани системи – стандартът установява видовете изпитания за атомни електроцентрали (автономни, интегрирани, приемни изпитания и опитна експлоатация) и общите изисквания за тяхното провеждане.
РД 50-34.698-90 Автоматизирани системи. Изисквания за съдържанието на документите е един от най-важните документи на 34 GOST, тъй като именно в него е описано съдържанието на почти всички документи, както и описание на всеки параграф от документа.
ГОСТ R ISO / IEC 8824-3-2002 Информационни технологии. Абстрактна синтактична нотация Версия първа — Този международен стандарт е част от Абстрактна синтактична нотация 1 (ASN.1) и предоставя нотация за определяне на дефинирани от потребителя ограничения и ограничения в таблицата.
GOST R ISO / IEC 10746-3-2001 Управление на данни и отворена разпределена обработка.
В този стандарт:
- определя се как се специфицират системите за отворена разпределена обработка (ODP), като се използват концепциите, въведени в GOST R ISO / IEC 10746-2;
- характеристиките, по които системите се класифицират като ODP системи, са идентифицирани.
Стандартът установява рамка за координиране на разработването на стандарти за ODP системи.
GOST R ISO / IEC 15271-02 Процеси на жизнения цикъл на софтуера - този GOST е необходим повече, според мен, за анализатори в проектирането и моделирането на атомни електроцентрали.
Този документ е полезен, от моя гледна точка, за чисто образователни цели.
GOST R ISO / IEC 15910-2002 Процес за създаване на потребителска документация за софтуерен инструмент - дефинира минимално необходимия процес за създаване на потребителска документация от всякакъв вид за софтуерен инструмент, който има потребителски интерфейс. Тези изгледи обхващат отпечатана документация (например ръководства за потребителя и карти за бърза справка), онлайн (оперативна) документация, помощен текст („помощ“) и онлайн системи за документация.

Така че, въз основа на всичко написано по-горе, става ясно, че основните документи в 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 и GOST 34.602-89.
Когато разработвате пакет от документация, първо трябва да отворите GOST 34.201-89 и да изберете етапа на създаване Проектно проектиране, Технически дизайн и Работна документация. След това трябва да изберете документи за разработка, които съответстват на етапа на създаване.

Списък на документи 34 GOST

сцена създаване	Заглавие на документа	код	Част Проектът	Принад легло да се проект но оценка ноа док ченге ции	Принад легло да се експлоатиране тация ноа горе кумол ции	Допълнителни инструкции
EP	График дизайн лист	EP *	ИЛИ	—	—	—
EP	Обяснителна бележка Към проектопроекта	P1	ИЛИ	—	—	—
EP, TP	Организационна схема	CO	ИЛИ	—	—	Допуска се включването в документа P3 или PV
	Структурна схема на комплекса технически средства	C1 *	ТОГАВА	NS	—
	Диаграма на функционалната структура	C2 *	ИЛИ	—	—	При разработване на документи CO, C1, C2, C3 на етап ES е разрешено включването им в документ P1
	специализиран (нов) технически средства	В 9	ТОГАВА	NS	—	При разработване на етап TP разрешено да включва към документ P2
	Схема за автоматизация	C3 *	ТОГАВА	NS	—	—
	Техническо задание за разработка специализиран (нов) технически средства	—	ТОГАВА	—	—	Проектът не включва
TP	Задачи за развитие санитарни и други раздели свързани с проекта със създаването на системата	—	ТОГАВА	NS	—	Проектът не включва
	Технически проект лист	TP *	ИЛИ	—	—	—
	Списък на закупените продукти	VP *	ИЛИ	—	—	—
	Списък на входните сигнали и данни	В 1	И ЗА	—	—	—
	Списък на изходните сигнали (документи)	В 2	И ЗА	—	—	—
	Списък със задачи за развитие строителни, електрически, санитарни и други раздели свързани с проекта със създаването на системата	В 3	ТОГАВА	NS	—	Разрешено е включването в документ P2
	Обяснителна бележка към техническия проект	P2	ИЛИ	—	—	Включва план за действие да подготви обекта за въвеждане в експлоатация системи в експлоатация
	Описание на автоматизираната функции	P3	ИЛИ	—	—	—
	Описание на настройката на задачата (набор от задачи)	P4	ИЛИ	—	—	Разрешено е включването към документи P2 или P3
	Описание на информацията поддръжка на системата	P5	И ЗА	—	—	—
	Описание на организацията информационна база	P6	И ЗА	—	—	—
TP	Описание на системите за класификация и кодиране	P7	И ЗА	—	—	—
	Описание на масива информация	P8	И ЗА	—	—	—
	Описание на комплекса технически средства	P9	ТОГАВА	—	—	За задачата е разрешено да се включи в документ 46 съгласно GOST 19.101
	Описание на софтуера осигуряване	PA	НА	—	—	—
	Описание на алгоритъма (процедура за проектиране)	PB	МО	—	—	Допуска се включването в документи P2, P3 или P4
	Описание на организацията структури	PV	OO	—	—	—
	План за оформление	C8	ТОГАВА	NS	—	Разрешено е включването в документ P9
	Списък на оборудването и материали	—	ТОГАВА	NS	—	—
	Изчисление на местна оценка	B2	ИЛИ	NS	—	—
TP, RD	Оценка на проекта надеждност на системата	B1	ИЛИ	—	—	—
TP, RD	Чертеж на формуляр на документ (видео рамка)	C9	И ЗА	—	NS	На етапа на TP е разрешено включват в документите P4 или P5
RD	Списък на притежателите оригинали	DP *	ИЛИ	—	—	—
	Декларация за оперативна документи	ED *	ИЛИ	—	NS	—
	Хардуерна спецификация	В 4	ТОГАВА	NS	—	—
	Декларация за изискване в материалите	В 5	ТОГАВА	NS	—	—
	Списък на машинните медии информация	VM *	И ЗА	—	NS	—
	Входен масив от данни	В 6	И ЗА	—	NS	—
RD	Директория на базата данни	В 7	И ЗА	—	NS	—
	Състав на изхода (съобщения)	В 8	И ЗА	—	NS	—
	Местни оценки	B3	ИЛИ	NS	—	—
	Метод (технология) автоматизиран проектиране	I1	OO	—	NS	—
	Технологична инструкция	И 2	OO	—	NS	—
	Упътване за употреба	I3	OO	—	NS	—
	Инструкции за оформяне и поддръжка на база данни (набор от данни)	I4	И ЗА	—	NS	—
	Инструкции за експлоатация на KTS	IE	ТОГАВА	—	NS	—
	Схема за свързване на външни кабели	C4 *	ТОГАВА	NS	—	Разрешено е да се изпълнява в под формата на таблици
	Схема на свързване външно окабеляване	C5 *	ТОГАВА	NS	—	Също
	Таблица за свързване и свързване	C6	ТОГАВА	NS	—	—
	Схема за разделяне на системата (структурен)	E1 *	ТОГАВА	—	—	—
	Чертеж на общото устройство	IN*	ТОГАВА	NS	—	—
	Чертеж за монтаж на техническо оборудване	CA	ТОГАВА	NS	—	—
	Схематична диаграма	сб	ТОГАВА	NS	—	—
	Структурна схема на комплекса технически средства	C1 *	ТОГАВА	NS	—	—
	Разположение на оборудването и окабеляването	C7	ТОГАВА	NS	—	—
	Описание на технологичния процес на обработка данни (вкл телеобработка)	PG	OO	—	NS	—
	Общо описание на системата	PD	ИЛИ	—	NS	—
	Тестова програма и методология (компоненти, системи за автоматизация, подсистеми, системи)	PM *	ИЛИ	—	—	—
	Формуляр	FD *	ИЛИ	—	NS	—
	Паспорт	PS *	ИЛИ	—	NS	—
* Документи, чийто код е зададен в съответствие с изискванията на стандартите ESKD

Забележка към таблицата:

Таблицата използва следните обозначения:
- ЕР - проектопроект;
- ТП - технически проект;
- РД - работна документация;
- ИЛИ - общосистемни решения;
- OO - решения за организационна поддръжка;
- TO - решения за техническа поддръжка;
- IO - решения за информационна поддръжка;
- Софтуер - софтуерни решения;
- МО - софтуерни решения.
Знак X - обозначава принадлежността към проектните разчети или оперативната документация.
Номенклатурата на документи с едно име се установява в зависимост от проектните решения, приети при създаването на системата.

Когато списъкът с документи е определен, тогава в RD 50-34.698-90 трябва да намерите избраните документи и да ги разработите стриктно според посочените точки. Всички точки от съдържанието, които са посочени, трябва да бъдат в документа.
Ако се разработва Техническо задание, тогава незабавно трябва да отворите GOST 34.602-89 и да разработите техническа спецификация стриктно съгласно параграфи.

ГОСТ 19

Серията GOST 19 (GOST 19.xxx Единната система за програмна документация (ESPD)) се състои от:

1. GOST 19.001-77 Общи разпоредби - също общ документ, не е от практическа полза. Следователно можете да го пропуснете.
2. GOST 19781-90 Термини и определения - добър списъкдефиниции в областта на софтуера за системи за обработка на информация. Освен като определения не съдържа нищо друго.
3. GOST 19.101-77 Видове програми и програмни документи - един от основните документи на 19 GOST. Именно с него трябва да започнете да работите с 19 GOST, тъй като той съдържа пълен списък и обозначения на GOST документи.

Списък на документи 19 GOST

код	Вид на документа	Етапи на развитие
		Скица проект	Технически проект	Работен вариант
		Скица проект	Технически проект	съставна част	комплекс
—	Спецификация	—	—
05	Списък на оригиналните притежатели	—	—	—
12	Текст на програмата	—	—
13	Описание на програмата	—	—
20	Извлечение от оперативни документи	—	—
30	Формуляр	—	—
31	Описание на приложението	—	—
32	Ръководство за системен програмист	—	—
33	Ръководство на програмиста	—	—
34	Ръководство за оператора	—	—
35	Описание на езика	—	—
46	Техническо ръководство поддръжка	—	—
51	Тестова програма и методика	—	—
81	Обяснителна бележка			—	—
90-99	Други документи

легенда:
- документът е задължителен;
- документът е задължителен за компоненти, които имат самостоятелно използване;
- необходимостта от съставяне на документ се определя на етапа на разработване и одобрение на техническото задание;
- - документът не е съставен.

GOST 19.102-77 Етапи на развитие - съдържа описание на етапите на развитие. Полезно за образователни цели. Според мен няма особена практическа полза.
GOST 19.103-77 Обозначаване на програми и програмни документи - съдържа описание на присвояването на номер (код) на документ. Дори след като прочетете този GOST, остават куп въпроси за това как да присвоите точно този номер на документ.
GOST 19.104-78 Основни надписи - установява формите, размерите, местоположението и процедурата за попълване на основните надписи на листа за одобрение и заглавната страница в програмните документи, предвидени от стандартите ESPD, независимо от методите на тяхното изпълнение. Тъй като документите от 19 GOST са съставени в рамки, този документ е много важен.
GOST 19.105-78 Общи изисквания към програмните документи - установява общи изисквания за проектиране на програмни документи. Изискванията са твърде общи. По правило този GOST почти никога не се използва за разработване на документ, тъй като има достатъчно специален GOST за документ, но за общи познания в този GOST все пак е по-добре да погледнете веднъж.
GOST 19.106-78 Изисквания към изпълнените програмни документи в печат- съдържа изисквания за дизайна на всички документи от 19 GOST.
GOST 19.201-78 Техническо задание, изисквания за съдържание и дизайн - установява процедурата за изграждане и изпълнение на технически спецификации за разработване на програма или софтуерен продукт.
Клаузите на TK 34 от GOST и 19 от GOST се различават.
GOST 19.601-78 Общи правила за дублиране, отчитане и съхранение - Общи правиларазмножаване, тираж, отчитане и съхранение на програмни документи. В GOST в няколко параграфа е описано как да се уверите, че документите не са загубени.
GOST 19.602-78 Правила за дублиране, отчитане и съхранение на програмни документи, завършен печат. В известен смисъл - допълнение към GOST 19.601-78.
GOST 19.603-78 Общи правила за извършване на промени - установява общи правила за извършване на промени в програмните документи. По същество той описва дълъг бюрократичен алгоритъм за извършване на промени в документи.
GOST 19.604-78 Правила за извършване на промени в програмните документи, направени в печатен вид - описва процедурата за работа и попълване на листа за регистрация на промени от списъка.

Списък на специализирани GOST, тоест всеки от тях описва съдържанието и изискванията за конкретен документ:

GOST 19.202-78 Спецификация. Изисквания за съдържание и дизайн;
GOST 19.301-79 Програма и процедура за изпитване. Изисквания за съдържание и дизайн;
GOST 19.401-78 Текст на програмата. Изисквания за съдържание и дизайн;
GOST 19.402-78 Описание на програмата;
GOST 19.403-79 Списък на оригиналните притежатели;
GOST 19.404-79 Обяснителна бележка. Изисквания за съдържание и дизайн;
GOST 19.501-78 Форма. Изисквания за съдържание и дизайн;
GOST 19.502-78 Описание на приложението. Изисквания за съдържание и дизайн;
ГОСТ 19.503-79 Ръководство на системния програмист. Изисквания за съдържание и дизайн;
GOST 19.504-79 Ръководство на програмиста. Изисквания за съдържание и дизайн;
GOST 19.505-79 Ръководство за оператора. Изисквания за съдържание и дизайн;
GOST 19.506-79 Описание на езика. Изисквания за съдържание и дизайн;
GOST 19.507-79 Декларация на оперативните документи;
GOST 19.508-79 Ръководство за поддръжка. Изисквания към съдържанието и дизайна.

Процедурата за работа с 19 GOST:

В GOST 19.101-77 изберете документ и неговия код според етапа на разработка.
Съгласно GOST 19.103-77 присвоете номер на документа.
След това, в съответствие с GOST 19.104-78 и 19.106-78, съставете документ.
От специализиран списък с GOST трябва да изберете този, който съответства на разработвания документ.

Заключение

GOST не е страшен и лесен! Основното нещо е да разберете какво трябва да се напише и какво GOST се използва за това. Основните ни GOST 19 и 34 за писане на документация са много стари, но все още са актуални и до днес. Писането на документация в съответствие със стандарта премахва много въпроси между изпълнителя и клиента. Следователно спестява време и пари.