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

ГОСТ 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. ИЗИСКВАНИЯ КЪМ СКУД

1.1. Изисквания към автоматизираната система за управление като цяло

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

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 са монтирани в техническите спецификации на автоматизираната система за управление.

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

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

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

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

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

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

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

1.1.10. АСУ, които имат измервателни канали, трябва да имат възможност за контрол на метрологичните характеристики на измервателните канали.

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

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

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

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

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

1.1.16. Името на СКУД трябва да включва името на типа СКУД и обекта на управление.

Например:

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

1.2. Изисквания към функциите на СКУД

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

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

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

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

1.3. Изисквания за готовността на персонала на автоматизираната система за управление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• за устойчивост на външни въздействащи фактори - 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, тип "превключвател" - в съответствие с 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. Автоматизираната система за управление трябва да използва предимно системи за управление на бази данни (СУБД), регистрирани по предписания начин.

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

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

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

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

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

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

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

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

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

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

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

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

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

• входни и изходни сигнали:
  • електрически - ток и напрежение съгласно 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. Информационната поддръжка на автоматизираната система за управление трябва да бъде съвместима с информационната поддръжка на взаимодействащите с нея системи по отношение на съдържанието, системата за кодиране, методите на адресиране, форматите на данните и формата на представяне на информацията, получена и издадена от автоматизираната система за управление.

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

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

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

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

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

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

1.7. Изисквания за организационно осигуряване на автоматизирани системи за управление

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

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

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

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

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

1.8. Изисквания за езикова поддръжка на автоматизирани системи за управление

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

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

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

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

1.9. Изисквания за правна поддръжка на автоматизирани системи за управление

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

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

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

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

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

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

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

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

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

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

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

2.4. Всички външни елементи на техническите средства на системата за автоматично управление, които са под напрежение, трябва да бъдат защитени от случайно докосване, а самите технически средства трябва да бъдат заземени или защитно заземени в съответствие с ГОСТ 12.1.030-81 и „Правила за захранващи устройства“ .

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

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

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

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

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

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

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

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

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

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

3. ВИДОВЕ И ПРОЦЕДУРА НА ИЗПИТВАНИЯ ПРИ ПУСКАНЕ НА ACS В ЕКСПЛОАТАЦИЯ

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

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

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

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

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

Въз основа на резултатите от теста ОКС изготвя „Протокол от теста“. Изискванията за съдържанието на протокола от изпитването са в съответствие с GOST 24.208-80.

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

3.5. Предварителни тестове на автоматизираната система за управление

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

3.5.2. „Тестовата програма” за предварително изпитване на СКУД се одобрява от клиента на СКУД.

3.5.3. Предварителните тестове на СКУД се организират от клиента и се извършват съвместно от разработчика на СКУД и клиента.

3.5.4. Комисията за провеждане на предварителни изпитания на автоматизираната система за управление се формира по нареждане на клиента. За председател на комисията се назначава представител на клиента на автоматизираната система за управление.

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

3.6. Пробна експлоатация на автоматизирани системи за управление

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

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

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

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

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

Бележки:

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

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

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

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

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

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

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

• правителство;
• междуведомствени;
• ведомствени

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

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

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

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

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

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

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

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

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

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

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

3.7.11. В случай на поетапни изпитвания за приемане, актът за пускане в експлоатация на автоматизираната система за управление се съставя въз основа на актовете за пускане в експлоатация на отделни части на системата и (или) „Доклади за изпитване“ на всички етапи на приемателното изпитване на автоматизираната система за управление.

3.7.12. Датата на въвеждане в експлоатация на автоматизираната система за управление се счита за дата на подписване на акта за въвеждане в експлоатация от приемателната комисия.

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

4. ПЪЛНОТА НА ВЪВЕДЕНАТА В ЕКСПЛОАТАЦИЯ СКУД

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

• Технически средства за АСУ под формата на комплекс от технически средства за АСУ, подготвени за работа;
• резервни части и устройства (SPTA), инструменти и устройства за проверка на работоспособността, настройка на техническото оборудване и наблюдение на метрологичните характеристики на измервателните канали на автоматизираната система за управление до степента, предвидена от проектната документация по поръчка, съгласувана с клиента на автоматичната система за управление и метрологично обслужване на потребителя по отношение на оборудването за изпитване;
• оперативна документация в съответствие с 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;
• два екземпляра на оперативна документация за автоматизираната система за управление в съответствие с GOST 24.101-80, включително необходимата документация за информационна поддръжка на автоматизираната система за управление (формата на автоматизираната система за управление в едно копие).

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

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

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

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

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

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

5. ГАРАНЦИЯ

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

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

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

5.4. Гаранционният срок на СКУД трябва да бъде определен в техническите спецификации на СКУД и не може да бъде по-малък от 18 месеца.

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

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

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

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

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

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

5. Контролните действия в автоматизираната система за управление на процесите трябва да се генерират автоматично или да се генерират от нейния оперативен персонал с помощта на набор от средства за автоматизация, включени в системата.

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

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

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

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

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

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

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

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

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

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

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

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

16. Изисквания за изпитване на автоматизирани системи за управление на процесите

16.1. Извършват се предварителни изпитания на АСУТП на съществуващо техническо оборудване.

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

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

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

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

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

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

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

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

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

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

1. OASU трябва да гарантира:

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

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

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

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

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

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

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

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

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

ПРИЛОЖЕНИЕ 4
Информация

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

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

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

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

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

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

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

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

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

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

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

Днес ще говорим за вътрешните стандарти за проектна документация. Как тези стандарти работят на практика, защо са лоши и защо са добри. Когато разработваме документация за държавни и сериозни частни клиенти, обикновено нямаме избор - съответствието със стандартите е включено в изискванията за документиране на технически спецификации. В практиката съм срещал различни примери за неразбиране на структурата на стандартите, какво трябва да има в документите и защо са необходими тези документи. В резултат на това перата на технически писатели, анализатори и специалисти понякога произвеждат такива скъпоценни камъни, че не е ясно в какво състояние на съзнанието са били написани. Но всъщност всичко е съвсем просто. Търсенето в Habr не върна никакви връзки към повече или по-малко пълен материал по тази тема, така че предлагам да попълним тази досадна празнина.

Какви са стандартите за документация?

Във въпросните 34 серии има само 3 основни стандарта за документация:

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

Това е основен документ, който предоставя пълен списък на документацията по GOST 34, препоръки за кодиране на документи, към кои етапи на проекта принадлежат документите (етапите са описани в GOST 34.601-90), както и как могат да се комбинират с взаимно.

Всъщност този стандарт е голяма таблица с коментари. Може да се постави в Excel за по-лесно използване.

Обемист стандарт, който описва съдържанието на проектните документи с различна степен на детайлност. Като индекс се използва горепосоченият GOST 34.201-89.

Има много въпроси и тълкувания на неговите разпоредби по отношение на стандарта RD 50-34.698-90, които поради тяхната неяснота често се разбират по различен начин от клиента и изпълнителя или дори членовете на екипа на проекта. Но, за съжаление, нямаме нищо по-конкретно.

Нека сега разгледаме плюсовете и минусите на стандартите, като традиционно започваме с минусите.

Недостатъци на стандартите

Основният недостатък е очевиден за всички - стандартите са стари. Те съдържат остаряла идея за архитектурата на автоматизирана система. Например:

• двуслойни приложения, състоящи се от клиентска програма и DBMS сървър (без три или повече „ниво“ приложения, без Weblogic или JBoss)
• описаната структура на таблиците на базата данни ще даде представа за логическия модел на данни (фактът, че може да има някакъв вид хибернация между приложението и базата данни, изглеждаше като лош излишък тогава)
• потребителският интерфейс е с един прозорец (има ли нещо друго? Какво е „браузър“?)
• В системата има малко отчети, всички са на хартиен носител и са отпечатани на матричен принтер.
• Разработваната програма е фокусирана върху решаването на „проблема с обработката на информацията“, който има ясен вход и изход и е тясно специализиран. Обработката на информация се основава на „алгоритъм“. Понякога има няколко „алгоритъма“. (Обектно-ориентираното програмиране тогава едва правеше първите си стъпки и не се разглеждаше сериозно).
• администраторът на базата данни разбира каква информация има в таблиците и активно участва в редактирането на системните директории (наистина ли има един СУБД сървър за 50 различни приложения?)

Съответно стандартът има артефакти като следните:

5.8. Чертеж на формата на документа (видеокадър)
Документът трябва да съдържа изображение на формата на документа или видеокадър в съответствие с изискванията на държавните стандарти на единната система за документация R 50-77 и необходимите обяснения.

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

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

Сега думите „машинограма“, „видео рамка“, „ADC“ вече не ни казват нищо. Аз също не ги намерих в употреба, въпреки че съм завършил специализиран институт през 90-те години. Това беше времето на появата на Windows 3.1, VGA дисплеи, три-инчови флопи дискове и първите местни интернет сайтове. Но тези думи са в стандарта и клиентът понякога капризно изисква да му предоставим пълен набор от документация в съответствие с GOST 34.201-89. Освен това подобни формулировки в ТЗ мигрират от едно министерство в друго и вече са се превърнали в някакъв негласен шаблон, в който се набива съдържанието.

Така че документът с глупавото име „Чертеж на формуляра на документа (видео рамка)“ в проекта трябва и не трябва да е празен.

Какво е добро в стандарта

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

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

Когато трябва компетентно да зададете задача на западни изпълнители, които никога не са чували за нашите стандарти GOST, можете също да разчитате на тези стандарти или по-скоро на тяхното съдържание и семантичен компонент. Защото, повтарям, гаранцията за пълнота на информацията струва много. Колкото и да се ласкаем с високото ниво на нашия професионализъм, може да забравим да включим елементарни неща в нашите изисквания, докато същият ГОСТ 34.602-89 „помни“ всичко. Ако не ви е ясно как трябва да изглежда резултатът от работата на западните изпълнители, вижте изискванията за документация и препоръчаните раздели. Уверявам ви, по-добре е да не мислите за това! Най-вероятно има западни аналози на нашите стандарти, в които всичко може да бъде по-пълно, по-модерно и по-добро. За съжаление не съм запознат с тях, тъй като все още не е имало нито един случай, когато нашите стандарти GOST не са достатъчни.

Можете да се смеете на факта, че създателите на стандартите не знаеха нищо за java или .NET, за HD мониторите и интернет, но не бих посъветвал да подценяваме мащаба на работата, която са свършили, и нейната стойност за нашата професионална общност.

Как да четем и разбираме стандартите за документация съгласно GOST серия 34

Стандартът разделя всички документи по две оси – време и предметна област. Ако погледнете таблица 2 в GOST 34.201-89, можете ясно да видите това разделение (колони „Етап на създаване“ и „Част от проекта“

Етапи на създаване на автоматизирана система за управление

Етапите на създаване са определени в GOST 34.601-90. Три от тях са свързани с документацията:

• Проект на проект (ED)
• Технически проект (ТП)
• Разработване на работна документация (DD)

Идеен проектследва след етап Технически спецификации и служи за разработване на предварителни проектни решения.

Технически проектописва бъдещата система от всички ъгли. Документите на етап TP трябва след прочитане да оставят пълна яснота в предлаганите подходи, методи, архитектурни и технически решения. На следващата фаза ще бъде твърде късно да се опишат подходи и да се обосноват технически решения, така че фаза P е ключът към успешното завършване на работата, тъй като цялото разнообразие от изисквания на техническите спецификации трябва да бъде отразено в документите на фаза P Във фаза P системата може изобщо да не съществува.

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

Части (раздели) от проектна документация за създаване на автоматизирана система за управление

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

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

За да се опише напълно тази „машина“, са направени следните раздели (както на чертежа):

Софтуер (MS), отговаряйки на въпросите: каква логика е заложена вътре в „черната кутия“? Защо бяха избрани тези конкретни алгоритми, тези конкретни формули и тези конкретни коефициенти?

Математическият софтуер не знае нищо за процесори или бази данни. Това е отделна абстрактна област, обиталището на „сферичните коне във вакуум“. Но математическият софтуер може да бъде много тясно свързан с предметната област, известна още като реалния живот. Например алгоритмите за управление на системите за контрол на трафика трябва да бъдат одобрени от Държавната инспекция по безопасност на движението, преди да бъдат одобрени от клиента. И тогава разбирате защо са включени в отделна книга. Защото никой в ​​КАТ не се интересува на каква ОС ще работи сървъра за приложения, но какъв знак и ограничение на скоростта ще изскочи на таблото при дъжд или сняг е много интересно. Те носят отговорност за своята част и няма да подписват нищо друго. От друга страна, когато подпишат, няма да има въпроси относно техническата страна на въпроса - защо са избрали тези табла или светофари, а не други. Мъдростта на "предците" се проявява точно в такива практически случаи.

Информационна поддръжка (ИС). Друга част от системата. Този път черната кутия на нашата система е прозрачна и ние гледаме информацията, която циркулира в нея. Представете си модел на човешката кръвоносна система, когато всички други органи са невидими. Нещо подобно е Информационна поддръжка. Той описва състава и маршрутите на информационния поток отвътре и отвън, логическата организация на информацията в системата, описание на справочници и системи за кодиране (тези, които са правили програми за производство, знаят колко са важни). Основната описателна част попада на етапа на TP, но някои „рудименти“ се вливат в етапа на RD, като документа „Каталог на базата данни“. Ясно е, че преди това съдържаше точно това, което пише в заглавието. Но днес се опитайте да създадете такъв документ за сложна комплексна система, когато много често системата използва закупени подсистеми със собствени мистериозни хранилища за информация. Дори не казвам, че сега този документ не е особено необходим.

Или ето „Изявление за компютърни носители за съхранение“. Ясно е, че преди това е съдържал няколко магнитни барабана или ролки с филм. Сега какво трябва да сложа там?

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

Софтуер. Любимата на всички част от проектната документация. Да, дори само защото това е само един документ! И тогава всеки разбира какво трябва да се напише там. Но все пак ще го повторя.

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

Техническа поддръжка (TO). Не по-малко обичана част от проектната документация. Розовата картина се помрачава само от изобилието от документи, които трябва да бъдат разработени. Общо стандартът изисква разработването на 22 документа, от които 9 са на етап ТС.

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

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

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

На етап TP разделът съдържа само един документ “ Описание на организационната структура“, в който трябва да кажем на клиента за какво трябва да се подготви по отношение на промяна на организационната структура. Изведнъж трябва да организирате нов отдел, който да управлява вашата система, да въведете нови позиции и т.н.

На етап RD се появяват други, по-интересни документи, които бих искал да разгледам отделно.

Упътване за употреба. Коментарите са излишни според мен.

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

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

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

Технологичната инструкция е слой между инструкцията за експлоатация и ръководството за потребителя. RP описва подробно кактрябва да извършите определени действия в системата. Това се казва в технологичната инструкция койтотрябва да се извършват действия в определени случаи, свързани с работата на системата. Грубо казано, технологичната инструкция е кратък дайджест на RP за конкретна позиция или роля. Ако клиентът няма оформени роли или иска вие сами да създадете роли и изисквания за работа, включете най-основните роли в документа, например: оператор, старши оператор, администратор. Коментарите на клиента по темата „но при нас не е така“ или „не ни харесва“ трябва да бъдат придружени от списък с роли и описание на длъжностните задължения. Тъй като бизнес процесите ние не го слагаме. Ние сме тези бизнес процеси автоматизирам.

За описаните рейкове ще пиша отделно, с колоритни примери, тъй като това не е първият път, когато това се повтаря в различни сектори на „националната икономика“.

Описание на технологичния процес на обработка на данни (включително телеобработка). Жалка реликва от пещерната епоха, когато имаше специално определени „компютърни оператори“, които подадоха перфокарти в машината и опаковаха разпечатка на резултата в плик. Тази инструкция е за тях. Не мога да ви кажа какво точно да напишете в него в 21 век. Излезте сами. Най-доброто нещо е просто да забравите за този документ.

Решения за цялата система (WSO). Стандартът предвижда 17 документа в раздел ОП. Първо, това са почти всички документи от предварителния етап на схемата. Второ, това са всички видове оценки, изчисления и кратки описания на автоматизирани функции. Тоест информация за хора не от основното ИТ производство, а за помощен персонал - мениджъри, оценители, специалисти по закупуване, икономисти и т.н.

И трето, ОП включва мегадокумент, наречен „Обяснителна бележка към техническия проект“, който е предназначен да бъде един вид резюме, но всъщност много дизайнери набутват цялото полезно съдържание на етапа на ТР в него. Такъв радикален подход може да бъде оправдан и дори взаимноизгоден както за клиента, така и за изпълнителя, но в определени случаи.

Опции за използване на GOST 34

1. Пълно и точно спазване на стандарта. Естествено, никой няма да напише доброволно такъв облак от документи. Следователно, пълен набор от документи се изготвя само при спешно искане на клиента, което той е осигурил в техническите спецификации и също така е фиксиран със споразумение отгоре. В този случай трябва да приемете всичко буквално и да дадете на клиента физически „книги“, върху които ще бъдат имената на документите от таблица 2 на GOST 34.201-89, с изключение на напълно ненужните, списъкът на които вие трябва да се обсъди и осигури писмено. Съдържанието на документите също трябва, без никакво въображение, да отговаря на RD 50-34.698-90, чак до имената на разделите. За да се взриви мозъкът на клиента, понякога голяма система се разделя на подсистеми и за всяка подсистема се издава отделна проектна документация. Изглежда ужасяващо и не подлежи на нормален контрол с помощта на земния разум. Особено по отношение на интеграцията на подсистемите. Което значително опростява приемането. Основното нещо е вие ​​самите да не се обърквате и системата ви да работи както трябва.
2. Ние просто обичаме стандартите GOST. Сериозните големи компании обичат стандартите. Защото помагат на хората да се разбират по-добре. Ако вашият клиент е известен с любовта си към реда и стандартизацията, опитайте се да се придържате към стандартната идеология на GOST при разработването на документи, дори ако това не се изисква от техническите спецификации. Ще бъдете по-добре разбрани и одобрени от одобряващите специалисти, а вие самите няма да забравите да включите важна информация в документацията, ще видите по-добре целевата структура на документите, ще планирате по-точно работата по писането им и ще си спестите и вашите колеги много нерви и пари.
3. Не ни интересува документацията, стига всичко да работи. Изчезващият вид на безотговорния клиент. Подобен поглед върху документацията все още може да се намери сред малките и бедни клиенти, както и в авторитарните „идиотокрации“, останали от времето на перестройката, където шефът е заобиколен от верни приятели - директори и всички въпроси се решават в лични разговори . В такива условия можете напълно да пренебрегнете документацията, но е по-добре в крайна сметка да не събаряте гледката и поне схематично да попълвате документацията със съдържание. Ако не на този клиент, тогава го предайте (продайте го) на следващия.

Заключение

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

Надявам се представеният материал да ви е бил полезен или поне интересен. Въпреки привидната досада, документирането е важна и отговорна работа, в която точността е толкова важна, колкото и писането на добър код. Пишете добри документи, колеги! И следващата седмица заминавам на две поредни командировки, така че не мога да гарантирам публикуването на нови материали (нямам кеш, пиша от главата си).

Въведение

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

Какви са стандартите GOST?

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

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

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

1. IEEE Std 1063-2001 “IEEE Standard for Software User Documentation” - стандарт за писане на ръководства за потребителя;
2. IEEE Std 1016-1998 “IEEE Recommended Practice for Software Design Descriptions” - стандарт за писане на техническо описание на програма;
3. ISO/IEC FDIS 18019:2004 „Указания за проектиране и подготовка на потребителска документация за приложен софтуер“ е друг стандарт за писане на ръководства за потребителя. В този документ има голям брой примери. Така да се каже, това е по-скоро ръководство за писане на ръководство за потребителя. Ще бъде особено полезно за начинаещи специалисти;
4. ISO/IEC 26514:2008 „Изисквания за дизайнери и разработчици на потребителска документация“ е друг стандарт за дизайнери и разработчици на потребителска документация.

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

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

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

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

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

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

1. Автоматизирана система (АС) - система, състояща се от персонал и набор от средства за автоматизация на тяхната дейност, прилагаща информационни технологии за изпълнение на установени функции.
   В зависимост от вида на дейността се разграничават например следните видове АС: автоматизирани системи за управление (АСУ), системи за автоматизирано проектиране (САПР), автоматизирани системи за научни изследвания (АСНИ) и др.

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

1. Организационни;
2. Методически;
3. Технически;
4. математически;
5. софтуер;
6. Информационни;
7. езикови;
8. правни;
9. Ергономичен.

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

ГОСТ 34

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

1. GOST 34.201-89 Видове, пълнота и обозначения на документи при създаване на автоматизирани системи - този стандарт установява видовете, името, пълнотата и номерата на документите. Това е един от основните документи от серията GOST 34. Всъщност това е основен документ, така че начинаещите трябва първо да се запознаят с него.
2. ГОСТ 34.320-96 Понятия и терминология за концептуални схеми и информационни бази - този стандарт установява основните понятия и термини на концептуални схеми и информационни бази, обхващащи разработването, описанието и прилагането на концептуални схеми и информационни бази, манипулиране на информация, както и описание и изпълнение на информационния процес. Стандартът определя ролята на концептуалната диаграма. Разпоредбите, посочени в него, имат препоръчителен характер и могат да се използват за оценка на системи за управление на бази данни (СУБД). Този документ не описва конкретни методи за използване на инструменти за поддръжка на концептуална диаграма. Езиците на концептуалната схема, описани в стандарта, не трябва да се считат за стандартни езици.
3. ГОСТ 34.321-96 Информационни технологии. Система от стандарти за база данни. Референтен модел за управление - Този документ установява референтен модел за управление на данни.
   Референтният модел дефинира обща терминология и концепции, свързани с данните на информационните системи. Такива концепции се използват за дефиниране на услугите, предоставяни от системи за управление на бази данни или системи с речник на данни.
   Референтният модел не взема предвид протоколи за управление на данни.
   Обхватът на референтния модел включва процеси, които се занимават с управлението на постоянни данни и тяхното взаимодействие с процеси, различни от изискванията на конкретна информационна система, както и общи услуги за управление на данни за дефиниране, съхраняване, извличане, актуализиране, въвеждане, копиране , възстановяване и предаване на данни.
4. ГОСТ 34.601-90 Автоматизирани системи. Етапи на създаване - стандартът установява етапите и етапите на създаване на АС.
5. GOST 34.602-89 Технически спецификации за създаване на автоматизирана система (Вместо GOST 24.201-85) - установява състава, съдържанието, правилата за изготвяне на документа „Технически условия за създаване (разработване или модернизация) на системата. ”
   Този документ е един от често използваните документи от серията GOST 34. Когато разработвате технически спецификации за този GOST, трябва да помните за други стандарти, дори ако този документ не съдържа препратки към тези стандарти.
6. ГОСТ 34.603-92 Информационни технологии. Видове изпитвания на автоматизирани системи - стандартът установява видове изпитвания на АС (автономни, комплексни, приемни изпитвания и пробна експлоатация) и общи изисквания за тяхното изпълнение.
7. RD 50-34.698-90 Автоматизирани системи. Изискванията за съдържанието на документите са един от най-важните документи на GOST 34, тъй като той описва съдържанието на почти всички документи, както и описание на всеки параграф от документа.
8. GOST R ISO/IEC 8824-3-2002 Информационни технологии. Abstract Syntax Notation Version One – Този стандарт е част от Abstract Syntax Notation Version 1 (ASN.1) и установява нотация за спецификацията на потребителски дефинирани ограничения и ограничения на таблици.
9. GOST R ISO/IEC 10746-3-2001 Управление на данни и отворена разпределена обработка.
   В този стандарт:
   • определя се как се специфицират системите с отворена разпределена обработка (ODP) с помощта на концепциите, въведени в GOST R ISO/IEC 10746-2;
   • Идентифицирани са характеристиките, според които системите принадлежат към OPO системите.

   Стандартът установява рамка за координиране на разработването на стандарти за ODP системи.

10. GOST R ISO/IEC 15271-02 Процеси на жизнения цикъл на софтуера - този GOST е необходим повече, според мен, за анализатори при проектиране и моделиране на AS.
    Този документ е полезен, от моя гледна точка, за чисто образователни цели.
11. GOST R ISO/IEC 15910-2002 Процес за създаване на потребителска документация за софтуерен инструмент - определя минимално необходимия процес за създаване на потребителска документация от всички видове за софтуерен инструмент, който има потребителски интерфейс. Тези видове включват печатна документация (например ръководства за потребителя и карти за бърза справка), онлайн документация, помощен текст и системи за онлайн документация.

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

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

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

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

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

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

ГОСТ 19

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

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

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

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

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

1. GOST 19.102-77 Етапи на развитие - съдържа описание на етапите на развитие. Полезно за образователни цели. Според мен няма голяма практическа полза.
2. GOST 19.103-77 Обозначения на програми и програмни документи - съдържа описание на присвояване на номер (код) на документ. Дори след като прочетете този GOST, остават много въпроси за това как да присвоите същия номер на документ.
3. GOST 19.104-78 Основни надписи - установява формите, размерите, местоположението и процедурата за попълване на основните надписи на листа за одобрение и заглавната страница в програмните документи, предвидени от стандартите ESPD, независимо от методите на тяхното изпълнение. Тъй като документите 19 GOST са съставени в рамки, този документ е много важен.
4. GOST 19.105-78 Общи изисквания за програмни документи - установява общи изисквания за подготовка на програмни документи. Изискванията са твърде общи. По правило този GOST почти не се използва за разработване на документ, тъй като е достатъчен специален GOST за документ, но за общи познания все пак е по-добре да разгледате този GOST веднъж.
5. GOST 19.106-78 Изисквания за програмни документи, изпълнени в печатна форма - съдържа изисквания за изпълнение на всички документи 19 GOST.
6. GOST 19.201-78 Технически спецификации, изисквания за съдържание и дизайн - установява процедурата за конструиране и изготвяне на технически спецификации за разработване на програма или софтуерен продукт.

   Клаузите на техническите спецификации на 34 GOST и 19 GOST са различни.

7. ГОСТ 19.601-78 Общи правила за копиране, отчитане и съхранение - общи правила за тиражиране, обращение, отчитане и съхранение на програмни документи. GOST описва в няколко точки как да се гарантира, че документите не се губят.
8. GOST 19.602-78 Правила за копиране, отчитане и съхранение на програмни документи, изпълнение на печат. Метод - допълнение към GOST 19.601-78.
9. GOST 19.603-78 Общи правила за извършване на промени - установява общи правила за извършване на промени в програмни документи. По същество той описва дълъг бюрократичен алгоритъм за извършване на промени в документи.
10. GOST 19.604-78 Правила за извършване на промени в програмни документи, направени в печат - описва процедурата за работа и попълване на Регистрационен лист за промяна.

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

1. GOST 19.202-78 Спецификация. Изисквания за съдържание и дизайн;
2. ГОСТ 19.301-79 Програма и методика на изпитване. Изисквания за съдържание и дизайн;
3. GOST 19.401-78 Текст на програмата. Изисквания за съдържание и дизайн;
4. GOST 19.402-78 Описание на програмата;
5. GOST 19.403-79 Списък на оригиналните държачи;
6. GOST 19.404-79 Обяснителна бележка. Изисквания за съдържание и дизайн;
7. GOST 19.501-78 Форма. Изисквания за съдържание и дизайн;
8. ГОСТ 19.502-78 Описание на приложението. Изисквания за съдържание и дизайн;
9. GOST 19.503-79 Ръководство на системния програмист. Изисквания за съдържание и дизайн;
10. GOST 19.504-79 Ръководство за програмист. Изисквания за съдържание и дизайн;
11. GOST 19.505-79 Ръководство за оператора. Изисквания за съдържание и дизайн;
12. GOST 19.506-79 Описание на езика. Изисквания за съдържание и дизайн;
13. GOST 19.507-79 Декларация на експлоатационните документи;
14. GOST 19.508-79 Ръководство за поддръжка. Изисквания за съдържание и дизайн.

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

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

Заключение

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

Дата на въвеждане 01/01/92

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

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

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

2. Етапи и етапи на създаване на АС

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

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

1. ОБЩИ ПОЛОЖЕНИЯ

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

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

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

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

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

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

2.1. Етапите и етапите на създаване на AS са показани най-общо в таблицата.

Етапи	Етапи на работа
1. Формиране на изисквания към ораторите	1.1. Обследване на съоръжението и обосновка на необходимостта от създаване на атомна електроцентрала
	1.2. Формиране на потребителски изисквания към високоговорителите
	1.3. Изготвяне на отчет за извършената работа и заявка за разработване на АС (тактико-технически задания)
2. Развитие на концепцията за АС	2.1. Проучване на обекта
	2.2. Извършване на необходимата изследователска работа
	2.3. Разработване на варианти за концепция за климатик и избор на вариант за концепция за климатик, който отговаря на изискванията на потребителите
	2.4. Съставяне на протокол за извършената работа
3. Техническо задание	3.1. Разработване и одобряване на технически спецификации за създаване на атомни електроцентрали
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. AC поддръжка	8.1. Извършване на работа в съответствие с гаранционните задължения
	8.2. Следгаранционен сервиз

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

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

ПРИЛОЖЕНИЕ 1. За справка

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

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

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

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

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

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

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

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 „Разработване на проектни задачи в съседни части на проекта за автоматизация“ те разработват, формализират, координират и одобряват проектни задачи в съседни части на проекта на обекта за автоматизация за извършване на строителни, електрически, санитарни и други подготвителни работи, свързани до създаването на АС.

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

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

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

16. На етап 7.2 „Обучение на персонала” се обучава персонал и се проверява способността му да осигурява функционирането на централата.

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

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

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

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

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

21. На етап 7.7 „Провеждане на опитна експлоатация” се извършва опитна експлоатация на АЕЦ; анализ на резултатите от пробната експлоатация на АЕЦ; модификация (при необходимост) на софтуера на АС; допълнителна настройка (при необходимост) на техническото оборудване на АЕЦ; издаване на удостоверение за завършена пробна експлоатация.

22. На етап 7.8 „Провеждане на приемни изпитвания“ се извършва следното:

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

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

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

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

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

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

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

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

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

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

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

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

Бележки:

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

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

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

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

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

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

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

М. Острогорски, 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). Много автоматизирани системи изискват сложна математическа и лингвистична поддръжка. Но е трудно да си представим автоматизирана система, която би била напълно лишена от един от трите вида поддръжка, изброени по-горе (упражнение: опитайте).