Страница 13: ДСТУ IEC 61513:2009. Атомні електростанції. Інформаційні та керівні системи, важливі для безпеки. Загальні вимоги до систем (61219)

2. Обсяги планово-попереджувального технічного обслуговування потрібно визначати за до­помогою методу систематичного аналізу, такого як аналіз видів та наслідків відмов або застосу­вання централізованої надійної моделі технічного обслуговування, або розгляду дерев відмов для функцій системи;

3. Методи замінювання компонентів мають гарантувати, що:

• компоненти, які замінюються, є функційно однаковими з тими, що замінюють, і задо­вольняють вимоги якості;

• якщо замінення виконують у робочому режимі, її вплив на функціювання системи оцінюють і документують до замінення;

• зберігають реєстрацію щодо всіх замін, що дає змогу забезпечувати будь-які вимоги до простежуваності;

4. Методи перекалібрування мають гарантувати, що:

• нове калібрування виконують у певних межах (коли такі межі визначено системою, технічний персонал не піддають формальним обмеженням);

• якщо перекалібрування виконують у робочому режимі, її вплив на функціювання системи оцінюють і документують до перекалібрування;

• зберігають реєстрацію щодо всіх перекалібрувань, що дає змогу забезпечувати будь-які вимоги до простежуваності.

Цей підрозділ визначає вихідну документацію етапів життєвого циклу системи: зміст, характе­ристики й основні елементи, які необхідно піддати верифікації.

Вихідну документацію потрібно комплектувати взаємно узгодженими документами, які мають перехресні посилання та які гарантовано відстежують відповідність остаточного проекту вхідним вимогам.

Технічне завдання на систему має бути повним і забезпечувати всю інформацію, необхідну для подальших дій життєвого циклу системи та кваліфікації системи.

Характеристики технічного завдання на систему:

1. вимоги мають припускати можливість перевірення.

Примітка 1. Підрозділ 4.3 IEEE 830 [2]) е настановою з перевірення вимог;

2. вимоги мають бути зрозумілими та чіткими настільки, щоб їх однаково розуміли всі охочі читачі, особливо рецензенти, та відповідальні за специфікацію системи та функційну валідацію.

Примітка 2. Наприклад, документ забезпечує точне та повне визначення вимог на противагу розлогим поясненням й іншій додатковій інформації, а також для обмеження ризику різних тлумачень. Найпридатнішим методом вирішення цих завдань є на­писання технічного завдання на систему за допомогою настанов, таких як IEEE 830 [2] та Меморандум EWICS No. 6 [5];

3. вимоги до прикладних функцій треба формулювати за допомогою функційних термінів, а не термінів комп’ютерної технології для того, щоб верифікацію могли виконувати спеціалісти з функці- ювання КВК й оператори станції, які можуть мати обмежені знання у сфері комп’ютерних технологій;

4. вимоги потрібно встановлювати з використанням документально обґрунтованих системо- технічних методів, інструментальних засобів і настанов.

Примітка 3. Докладні вимоги, що стосуються інструментальних засобів програмного забезпечення для систем класу 1, наведено в 4.2 ІЕС 60880-2,

5. вимоги має бути написано та структуровано так, щоб полегшити оцінення відповідності специфікації системи, а також забезпечити зв’язок із планом кваліфікації системи.

Наведені нижче елементи необхідно піддати верифікації:

1. вимоги мають бути простежуваними та повинні відповідати вимогам до системи, установ­леним у проекті архітектури, та функційній призначеності (див. 5.5);

2. вимоги до інтерфейсу мають відповідати вимогам до систем та устатковання, з якими пов’язано цю систему;

3. вимоги, які необґрунтовано ускладнюють систему, треба ідентифікувати (складність може збільшити ризик помилок у технічному завданні та/або самій системі).

1. Документація специфікації системи має бути повною та містити всю інформацію, необхідну для подальших дій життєвого циклу безпеки системи, особливо для етапів проектування системи та валідації;

2. Документація специфікації системи має визначати, яке наявне устатковання треба ви­користовувати та яке треба розробити. Придатність вибраного устатковання треба обґрунтувати;

3. Документація специфікації системи має описувати структуру системи:

• розкладання системи на підсистеми та/або компоненти технічного та програмного забез­печення;

• внутрішнє поводження системи (див. 6.1.1.2.2), охоплюючи опис основних подій усере­дині системи та її захист від цих подій (див. 6.1.2.2.3);

• межі, умови навколишнього середовища, розрахункова надійність технічного забезпе­чення, поводження, функції, характеристики й інтерфейси кожної підсистеми;

• класифікація кожної підсистеми; необхідне підтвердження, якщо клас підсистеми нижче, ніж клас системи або підсистеми, до складу якої вона належить;

• умови використання та зв’язок певних підсистем у системі.

Примітка. Опис підсистем може бути побудовано за ієрархією, щоб спростити розуміння, від загального опису до елемен­тарних підсистем (тобто підсистем, які не піддаються подальшому розкладанню в проектній документації системи). «Горизон­тальна» інформація також може бути корисною;

4. Документація, що стосується програмного забезпечення, має містити специфікацію про­грамного забезпечення (див. 6.1.2.3);

5. У системах класів 1 або 2 треба визначити призначеність функцій підсистемам, тобто в специфікації системи треба зазначити, яка підсистема сприяє та/або необхідна для виконання цієї функції.

Характеристики документації специфікації системи:

1. документація має бути зрозумілою та чіткою, щоб її розуміли однозначно всі охочі читачі, особливо рецензенти та відповідальні за виконання проекту системи, інтеграцію та валідацію;

2. специфікацію прикладних функцій має бути сформульовано такими термінами, які полег­шують верифікацію та роблять їх зрозумілими для спеціалістів, які займаються функціями КВК, й операторів станції;специфікацію системи потрібно розробляти з використанням відповідних документально обґрунтованих системотехнічних методів, інструментальних засобів і настанов. Ці методи, інстру­ментальні засоби та настанови мають мінімізувати «розбіжність» між методами, інструментальними засобами й настановами, використаними в технічному завданні на систему.

Примітка. Методи й інструментальні засоби розроблення програмного забезпечення можуть поліпшити якість специфікації остаточного проекту системи навіть порівняно зі специфікацією проекту апаратної системи;

3. специфікацію системи має бути написано та структуровано так, щоб полегшити оцінення її відповідності технічному завданню на систему, а також забезпечити ефективний зв’язок із валідаці- єю системи, тобто полегшити повну ідентифікацію специфікації (на противагу просторих пояснень й іншої інформації).

1. Верифікацію специфікації системи стосовно технічного завдання на систему треба вико­нувати до завершення детального проектування. Коригувальні дії потрібно виконати перед завер­шенням монтування й інтеграції системи;

2. Треба встановити ефективні взаємозв’язки між особами, відповідальними за специфікацію системи, й постачальниками для перевірення придатності вибраного устатковання;

3. Верифікація має документально підтвердити та зафіксувати будь-яку невідповідність спе­цифікації системи стосовно технічного завдання на систему;

4. Необхідно перевірити правильність переведення технічного завдання до прикладних функ­цій у специфікацію прикладного програмного забезпечення;

5. У системах класів 1 та 2 будь-яку невідповідність має бути виправлено чи обґрунтовано стосовно безпеки з урахуванням можливих заходів компенсації;

6. Властивості систем класів 1 та 2, що ускладнюють систему і не входять у технічне завдання на систему, має бути ідентифіковано й обґрунтовано стосовно безпеки.

Примітка. Наявність властивостей системи, що не входять у технічне завдання на систему, може значно ускладнити систему та потенційно знизити впевненість у її правильній роботі.

Детальний проект системи може бути виконано за кілька ітерацій. Вимоги цього пункту висува­ють до завершальної документації системи, наявної, коли завершено детальний проект, інтеграцію та валідацію системи, і система готова до відправлення та монтування за місцем експлуатації.

Документацію детального проекту системи можна поділити на чотири групи документів:

Примітка 1. Якщо система реалізується на наявному устаткованні, документація проекту технічного та програмного забез­печення системи є частиною документації наявного устатковання.

Тільки дві перші групи розглянуто, тому що проектування технічного та програмного забез­печення перебуває поза сферою дії цього стандарту (див. 6.1.3).

Примітка 2. У системах класу 1 вимоги до документації програмного забезпечення встановлено в ІЕС 60880 та ІЕС 60880-2, а вимоги до документації технічного забезпечення — в ІЕС 60987.

1. Документи проекту системи мають бути повними та містити всю інформацію, необхідну для наступних дій життєвого циклу системи, охоплюючи інтеграцію, валідацію, монтування, експлуата­цію та технічне обслуговування;

2. Документи проекту системи розширюють обсяг документів на специфікацію та повинні за­безпечувати докладний опис внутрішньої структури та внутрішнього поводження системи. Рівень деталізації опису залежить від класу безпеки системи;

3. Документи на проект системи мають містити опис монтування устатковання станції й умови випробування системи;

4. Документи на проект системи мають містити опис валідації функціювання та характеристик системи, зокрема, очікуваного часу реакції за різних режимів роботи станції, номінальні безпечні значення уставок й алгоритмів управління, та допуски уставок безпеки.

Характеристики документації проекту системи:

1. Документація має бути зрозумілою та чіткою, щоб вона могла бути однаково зрозумілою всім охочим читачам, зокрема авторам і рецензентам плану інтеграції системи, плану кваліфікації системи, плану монтування й уведення в експлуатацію, та плану технічного обслуговування сис­теми, технічному персоналу, авторам і рецензентам модифікацій проекту;

2. Документацію детального проекту потрібно зберігати під час розробляння системи для га­рантії того, що остаточна версія документів відповідає реалізованому проекту.

1. Верифікацію детального проекту системи та його документацію треба виконувати до за­стосування нового технічного та програмного забезпечення; треба також залишати досить часу для виконання будь-яких коригувальних дій, обумовлених результатами верифікації;

2. Виконання встановлених вимог до надійності прикладних функцій системи (див. 6.1.3.1.1) треба піддавати верифікації, наскільки це можливо, на ранньому етапі детального проектування.

Примітка. Аналіз надійності системи може потребувати коригування детального проекту, архітектури системи, наприклад ступеня резервування та навіть вибір загальних архітектурних рішень KBK;

3. Потенційну здатність сервісних функцій системи піддавати ризику виконання прикладних функ­цій потрібно піддавати суворому аналізу відповідно до важливості прикладних функцій для безпеки;

4. Допущення, зроблені під час верифікації детального проекту, має бути чітко сформульовано та задокументовано.

Документація з інтеграції системи має містити план інтеграції, звіти про випробування щодо інтеграції й усю інформацію, необхідну для наступного етапу валідації.

1. Звіти про випробування з інтеграції мають містити наведену нижче інформацію:

• версії технічних і програмних модулів, специфікацію випробувань, інструментальні засоби й устатковання разом із будь-якими відповідними даними калібрування;

• результати кожного випробування із зазначенням розбіжностей між очікуваними та дійсними результатами й для кожної розбіжності дані щодо виконаного аналізу та прийнятих рішень із про­довження випробування або реалізації змін.

2. У системах класу 1 застосовують вимоги 7.7 ІЕС 60880.

1. Верифікацію звітів з інтеграції системи відповідно до плану інтеграції системи потрібно ви­конувати до проведення валідації;

2. Для системи класу 1 простежуваність від детальної проектної документації до відповідного компонента й інтеграційних тестів і аналізів має бути забезпечено так, щоб мати можливість оці­нювати тести й аналізи щодо тестового покриття;

3. Для систем класу 2 простежуваність від детальної проектної документації до відповідного компонента й інтеграційних тестів і аналізів має бути забезпечено так, щоб мати можливість оці­нювати тести й аналізи щодо тестового покриття.