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

Архітектура системи має зменшити ризик і наслідки поширення відмов та сторонніх дій відмов. Можна розглянути наведені нижче методи:

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

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

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

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

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

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

Специфікація програмного забезпечення містить:

• специфікацію прикладних функцій (специфікації прикладного програмного забезпечення);

• специфікацію архітектури програмного забезпечення.

Примітка 1. Архітектура програмного забезпечення визначає основні компоненти та підсистеми програмного забезпечення, як їх взаємопов’язано та як буде досягнуто необхідних якостей. Цей стандарт не містить вимог до архітектури програмного за­безпечення (для систем класу 1 див. ІЕС 60880 та ІЕС 60880-2);

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

Примітка 2. У разі використання наявного сімейства устатковання специфікації системного програмного забезпечення є частиною документації устатковання.

1. Для полегшення складання специфікації, верифікації та валідації прикладних функцій архі­тектура програмного забезпечення має чітко розподілятися між прикладним програмним забезпе­ченням та системним програмним забезпеченням (див. В.2.а ІЕС 60880). У такому разі верифікація та валідація прикладного програмного забезпечення може виконуватися незалежно;

2. Специфікацію прикладного програмного забезпечення можна отримати з технічного завдан­ня до прикладних функцій (див. 6.1.1.1). За потреби специфікацію можна розширити за допомогою введення взаємозв’язку із функціями управління та моніторингу системи;

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

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

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

Це охоплює призначення:

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

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

• вихідних ліній управління діями виконавчих механізмів.

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

2. Призначення має передбачати стримування відмов;

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

4. Функції різних категорій, призначені до одної й тої самої системи або підсистеми, мають стосуватися найвищої категорії безпеки, за винятком випадків, коли можливо продемонструва­ти, що дані або функції нижчої категорії не піддають ризику функції вищих категорій, наприклад, спричинюючи зупинку чи помилкове спрацьовування функцій вищої категорії. Це може призвести до рознесення функцій у різні підсистеми або рішення виконувати функції нижчої категорії в інших системах (ітерація процесу загального призначення — див. 5.3);

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

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

6.1.3 Детальне проектування та реалізація системи

Завданнями цього етапу є:

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

• розроблення (проектування та кодування)/придбання комп'ютерних програм, що становлять операційне та сервісне програмне забезпечення системи.

Примітка 1. Нормальною ситуацією (див. 6.1.2.2) є обмежена кількість нових розроблень, наприклад, інтерфейсів з іншими системами;

• розроблення (проектування та кодування)/генерація прикладного програмного забезпечення системи.

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

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

Вихідними даними цього етапу є:

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

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

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

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

Метою функційної валідації є виявлення помилок і неточностей у специфікації прикладних функцій, які неможливо виявити під час валідації системи (див. 6.1.5). До складу функційної валі­дації входить моделювання роботи виконавчого устатковання й АЕС.

1. Правильність специфікації прикладної функції на відміну від вимог до функційності та ха­рактеристик функцій станції (див. 5.1.1) має пройти валідацію щодо функцій категорії А;

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

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

• демонстрація має ґрунтуватися на балансі детерміністичних критеріїв та кількісного аналізу надійності;

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

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

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

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

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

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

Метою цього етапу є з’єднання модулів технічного та програмного забезпечення і перевірення сумісності програмного забезпечення, завантаженого в технічні засоби (див. розділ 7 ІЕС 60880).

Основними вхідними даними на етапі інтеграції системи є підсистеми та компоненти системи, документація детального проекту та план інтеграції системи.

Вихідними даними цього етапу є інтегрована система.

1. Інтеграцію треба виконувати згідно з планом інтеграції, визначеним у 6.2.3;

2. Після того як усе прикладне програмне забезпечення (раніше розроблене для сімейства устатковання або спеціально розроблене) інтегровано в систему, треба верифікувати експлуата­ційні вимоги;

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

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

Метою даного етапу є тестування інтегрованої системи для демонстрації її відповідності функ- ційній, експлуатаційній специфікаціям й інтерфейсу (див. розділ 8 ІЕС 60880).

Інтегрована система, документація специфікації системи та план валідації системи є осно­вними вхідними даними етапу валідації системи.

1. Валідацію системи необхідно виконувати відповідно до плану валідації, визначеного в 6.2.4;

2. Вимоги розділу 8 ІЕС 60880 потрібно застосовувати до валідації функцій категорії А;

3. Вимоги розділу 8 ІЕС 60880 потрібно застосовувати до валідації функцій категорій В та С з наведеними нижче поправками:

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

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

Метою даного етапу є монтування, з'єднання та випробування системи за місцем експлуатації.

Подальші дії, пов’язані із загальною інтеграцією системи з іншими системами та загальним уведенням до експлуатації, є частиною загального життєвого циклу КВК-системи (див. розділ 7).

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

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

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

1. Унесення модифікацій до системи потрібно виконувати відповідно до встановлених про­цедур (див. 6.3.6);

2. Необхідно виконати випробування правильності роботи системи після модифікації;

3. Не дозволено вносити зміни до іншого технічного/програмного забезпечення, окрім зазна­ченого процедурами технічного обслуговування;

4. Після замінення устатковання необхідно продемонструвати/обґрунтувати, що воно відпо­відає всім специфікаціям первісного устатковання;

5. Для систем класу 1 процес модифікації програмного забезпечення має проходити відповідно до розділу 9 ІЕС 60880, а процес модифікації технічного забезпечення — до розділу 11 ІЕС 60987.

6.2 Системне планування

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

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

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

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