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

Кінець таблиці З

Примітка. Для порівняння цього визначення етапів з ІЕС 61508-2 див. додаток D.

Примітка 1. Для систем класу 1 вимоги до програмного забезпечення цього виду діяльності визначено ІЕС 60880.

Примітка 2. Для систем класу 1 вимоги до технічного забезпечення цього виду діяльності визначено ІЕС 60987.

Примітка 3. Для систем класу 1 вимоги до розробленого раніше програмного забезпечення цього виду діяльності визначено

ІЕС 60880-2. ,

Рисунок 5 — Життєвий цикл безпеки системи

Цей підрозділ визначає вимоги до життєвого циклу безпеки системи.

Ці вимоги охоплюють властивості, які стосуються:

• певних функцій, призначених системі у процесі функційного призначення;

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

Примітка. Розділ 8 ІЕС 61226 містить основні вимоги до КВК ФСБ та спеціальні вимоги до різних категорій КВК ФСБ. Такі вимоги беруть до уваги в цьому стандарті за розроблення вимог до систем або функцій відповідно

• .1.1 Технічне завдання на систему

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

Вихідна документація, що описує архітектуру КВК та функційне призначення (див. 5.5), є вхідними даними для технічного завдання на системи.

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

Технічне завдання на систему має встановлювати:

• функції системи;

• проектні обмеження;

• межі та взаємозв'язки з іншими системами;

• інтерфейс із персоналом;

• умови навколишнього середовища;

• необхідну кваліфікацію.

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

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

1. Технічне завдання до кожної прикладної функції має встановлювати:

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

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

Примітка. ІЕС 61069-2 [6] може бути корисним під час ідентифікації та визначання критеріїв щодо робочих характеристик;

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

Процес функційного призначення визначає для кожної категорії функцій мінімальний клас КВК- системи. Разом із вимогами незалежності між функціями в одній групі безпеки (критерій одиничної відмови, захисний проект проти ВЗП) такі чинники дають змогу якісно оцінити надійність функції або групи функцій у групі безпеки.

Кількісна оцінка надійності прикладних функцій може знадобитися для верифікації проекту системи та базового проекту станції (див. А.2.2 ІЕС 60880). Це оцінення зазвичай виконують щодо проекту технічного забезпечення системи, де наявні добре перевірені методи, однак немає загаль­новизнаного методу щодо кількісної оцінки надійності програмного забезпечення (див. 6.1.3.1.2).

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

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

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

Примітка. Наприклад, контроль за зміненням параметрів має відповідати умовам, передбаченим планом захисту системи (див. 6.2.2), планом експлуатації системи (див. 6.2.6) і планом технічного обслуговування системи (див. 6.2.7).

Зазвичай технічне завдання на систему не розглядає функції системного програмного за­безпечення в явному вигляді. Ці функції, пов'язані з експлуатацією та самоконтролем системи, визначають для наявного устатковання (див. 6.1.2.1) і їх може бути краще визначено на стадії специфікації системи. Проте вимоги до системного програмного забезпечення в неявному вигля­ді визначаються вимогами до прикладних функцій та вимогами до проектних обмежень системи (див. 6.1.1.2.1).

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

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

• задовольняти вимоги, пов’язані з категоріями прикладних функцій;

• забезпечувати передбачене функціювання системи;

• забезпечувати або сприяти демонстрації правильної роботи системи.

Архітектуру системи обумовлено категоріями функцій, що виконуються цією системою (див. 5.3.2) і концепцією глибокоешелонованого захисту (див. 5.2 та 7.8.1 IAEA-50-SG-D3).

1. Система може виконувати функції найвищої категорії, які дозволено для її класу (див. 5.3.2), і функції нижчих категорій. Система може охоплювати підсистеми нижчих класів за умови виконання таких вимог:

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

2. проект системи має забезпечувати виконання вимог до підсистем або устатковання вищих класів у разі відмови устатковання нижчих класів;

2. Проект системи повинен мати у своєму складі резервування або інші заходи для забезпе­чення стійкості до відмов (див. 6.1.2.2.3) та для забезпечення призначення прикладних функцій, важливих для безпеки (див. 6.1.2.4).

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

3. Проект системи має задовольняти вимоги незалежності (див. 6.1.2.2.2) щодо:

• запобігання поширенню відмов від систем, менш важливих для безпеки;

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

4. Проект систем класу 1 має забезпечувати резервування, що дає змогу задовольняти крите­рій одиничної відмови для функцій категорії А під час експлуатування та технічного обслуговування (див. 6.1.2.4 е)).

Примітка. Відмови програмного забезпечення є систематичними та невипадковими. Тому критерій одиничної відмови не можна застосовувати до проекту програмного забезпечення системи так, як його застосовують до проекту технічного забезпе­чення. Можливі наслідки ВЗП, спричинених програмним забезпеченням усередині кожного рівня захисту та між резервованими рівнями, треба враховувати на рівні кожної системи та архітектури КВК (див. 4.1.1 з ІЕС 60880-2).

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

Примітка 1. Зауважимо, що комп'ютерна система мас детерміністичну поведінку, якщо затримання часу між збудженням і відповіддю має гарантований максимум і мінімум за всіх необхідних умов (визначення, отримане з [4]);

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

3. Для забезпечення високого ступеня надійності детерміністичної поведінки системи класу 1 потрібно розробляти за методикою, зазначеною в додатку В ІЕС 60880 (а саме B.2.d — щодо часу виконання та В.2.е — щодо переривання). Методи, які використовують статичну послідовність дій (див. примітку 2), є такими, яким надають перевагу, порівняно з використанням переривань.

Примітка 2. Статичність визначають як те, що стосується події або процесу, який відбувається поза участю комп'ютерної програми (IEEE 610). Тому за статичної послідовності дій порядок виконання інструкцій не залежить від роботи комп’ютера — хоча може бути кінцеве число різних послідовностей дій залежно від шляху виконання.

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

4. Системи класу 2 може бути розроблено за технологіями, відмінними від передбачених у в). У таких випадках проект системи має забезпечувати відповідну роботу системи щодо всіх перед­бачених умов станції;

5. Для збільшення спроможності систем класів 1 та 2 витримувати непередбачувані стани:

• треба обґрунтувати відповідний набір проектних обмежень для використання ресурсів (таких як: потужність центрального процесора, пам’ять, пропускна здатність обміну даними, ресурси операційної системи) і внутрішню синхронізацію системи;

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

1. Системи має бути спроектовано так, щоб помилки та відмови виявлялися в достатньо ранній період для збереження потрібної готовності системи до роботи. Виявлення відмов за допо­могою елементів самоконтролю устатковання має бути збалансовано з упровадженою складністю системи. По можливості треба дотримуватися вимог 4.8 та А.2.8 ІЕС 60880 щодо самоконтролю для систем кожного класу;

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

3. Проект системи має передбачати можливість безпечного переходу до відповідного резерв­ного режиму роботи в разі виявлення відмов (поступову деградацію);

4. Для систем класу 1 елементи самоконтролю мають відповідати ІЕС 60880 та ІЕС 60987.