AOP-52 безпека проєктування і оцінка програмного забезпечення для боєприпасів

Що це таке

AOP-52 - Allied Publication НАТО, що веде безпеку проєктування і оцінку програмного забезпечення обчислювальних систем, пов'язаних з боєприпасами: програмного забезпечення, що виконує функцію, пов'язану з безпекою, в системі боєприпасів чи зброї. Він веде процес Software Systems Safety від планування програми до Safety Assessment Report, що підтримує введення системи на службу, і первинна відповідальність за його ведення «lies with the system safety manager/ engineer in both the supplier and acquirer's organizations», причому від Program Manager очікують «support the integrated safety process between systems engineering, software engineering, and safety engineering in the design, development, test, and operation of the system software.» AOP-52 прямий щодо власного статусу: він «is a guideline and is not intended to supersede any National Government or Agency policy, standard, or guidance pertaining to system safety (e.g., US MIL-STD-882 series, UK Def-Stan 00-56).» Це Edition B, Version 1, датоване листопадом 2016 року, що замінює AOP-52 Edition 1.

Планування і залучені люди

Документ припускає, що можливість планування безпеки вже є або її ставлять: Software Safety Program Plan, що фіксує інтерфейси програми, постачання за контрактом і відповідальності до початку аналізів небезпек, розглянутий під контролем конфігурації, щойно задано базу. Software Configuration Control Board, що затверджує пізніші зміни, має включати члена інженерії системної безпеки, і постачальники, чиє програмне забезпечення несе функції, пов'язані з безпекою, мають вести програму Software Quality Assurance за затвердженим планом. Власні Generic Software Safety Requirements AOP-52 пристосовують до конкретної системи як спільну діяльність замовника і постачальника, документують і підписують керівництво обох сторін і перевіряють Inspection, Analysis, Demonstration or Test. Документ працює поруч із власним процесом System Safety AOP-15, а не замінює його: «it is not the intent of these charts to supplant the content of AOP-15: the system-level process both provides the basis for the Software Systems Safety Process and shows the inherent cohesiveness of the Software Systems Safety Process with the System Safety Process.»

Аналізи небезпек, що будують докази

Preliminary Hazard List виявляє кандидатів небезпек, перш ніж можна закріпити причинні фактори, специфічні для програмного забезпечення. Далі йде Preliminary Hazard Analysis, що живить ранні дослідження компромісів проєктування, а попередній і детальний Software Design/Subsystem Hazard Analysis відстежують конструкцію, як вона дозріває від концепції до коду. System Hazard Analysis починається, щойно Preliminary Hazard Analysis затверджено і вимоги розподілено на функції програмного забезпечення, і оновлюється на «each software milestone review (Software Requirements Review, Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review, Initial Operating Commencement (IOC), Low Rate of Production Decision, and Initial Operating Capability)», лишаючись відкритим, доки не поставлено остаточну версію програмного забезпечення. Документ конкретний щодо одного строку, що найбільше має значення для роботи проєктування: «the safety design requirements (hardware, software, and human interfaces) must be complete prior to the milestone at which Software Engineering freezes the requirements (e.g., Critical Design Review).»

Масштабування зусилля до ризику

Software Control Category описує, скільки автономного контролю програмне забезпечення має над небезпекою. На найтяжчому кінці «software exercises autonomous control over potentially hazardous hardware systems, subsystems, or components without the possibility of intervention to preclude the occurrence of a hazard.» Та категорія, перехрещена з тяжкістю події, яку програмне забезпечення могло б спричинити, задає Software Safety Criticality Index, який своєю чергою веде матрицю Level of Rigor для роботи проєктування, коду, випробувань і інтеграції: найвищий рівень кличе перевірку безпеки через аналіз вимог, аналіз конструкції, аналіз коду і окремі випробування безпеки, з дедалі легшими рівнями нижче аж до лише високорівневих випробувань безпеки. Той самий індекс задає, скільки незалежної перевірки і валідації потребує дана система.

Загальні вимоги безпеки проєктування програмного забезпечення

Розділ 4 - найдовший розділ документа: постатейні правила «shall», адресовані конструктору системи і програмного забезпечення, що охоплюють проєктування системи, обчислювальне середовище, проєктування самоперевірки, події і функції, пов'язані з безпекою, проєктування інтерфейсу і людського інтерфейсу, критичне часування і переривання, вибір мови, стандарти кодування, супроводження програмного забезпечення і аналіз і випробування програмного забезпечення. Два правила повторюються як найясніші приклади документа: «at least two people shall be thoroughly familiar with the design, code, testing, and operation of each software module in the system», і «the use of patches to 'fix' a problem may be acceptable in general software development, but must not be tolerated in the development of safety related software.» Додаток D проходить ту саму землю пункт за пунктом: стандарт кодування «should define rules that lead to clear, unambiguous source code that is easy to review, test and maintain, amenable to static analysis», і «to be effective, a coding standard must be enforced», ідеально інструментом. Очікують високорівневі мови, окрім дуже малих одиниць логіки, і «for higher integrity systems (e.g. safety critical software), specific object code verification will be necessary» поруч з методами запевнення компілятора, як-от валідація, «an internationally agreed black box method of testing compilers, designed to demonstrate that a compiler conforms to the appropriate international language standard» - хоча документ ясний, що сам сертифікат валідації не гарантує, що компілятор завжди дасть правильний результат. Вибір будь-якого інструмента, використаного для підтримки цієї роботи, - власна відповідальність розробника, у заявленому порядку переваги: спочатку інструмент потрібного рівня запевнення, далі поєднання інструментів, потім інструмент у поєднанні з ручною діяльністю, і лише коли підхожого інструмента немає, процес виконують повністю вручну.

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

Випробування і Safety Assessment Report

Випробування фази розробки йдуть на рівні одиниці, підсистеми/CSCI і системи, кожне виконане кимось іншим, ніж автор того коду, і завершуються Functional Qualification Testing і Independent Verification and Validation, «a requirements-based test program run by a group independent of the organization that developed the software», разом з формальним Test Coverage Analysis і вимог, і структури коду.

Safety Assessment Report, або Safety Case, - центральний доказовий артефакт документа: «a structured argument, supported by a body of evidence, that provides a compelling, comprehensive and validated assessment that a system is safe for a given application in a given environment.» Від його змісту очікують продемонструвати відповідність застосовному законодавству, регулюванню, стандартам і політиці; дієву систему управління безпекою; компетентний персонал; чинні і простежувані вимоги безпеки; задоволені чи належно пом'якшені вимоги; стерпні залишкові відмови; і що «safety claims, safety arguments and evidence have been subjected to independent scrutiny.» Requirements Traceability Matrix простежує кожну вимогу безпеки програмного забезпечення від специфікації через конструкцію до її результату випробування, і весь процес викладено в додатку F як іменовану послідовність фаз, від System Definition and Safety Planning через Certification і в Sustained Engineering, щойно систему виведено в поле.

Як вас оцінюють

AOP-52 не створює сертифікації, яку організація може тримати, і каже так про очевидні альтернативи безпосередньо: «having third party certification (e.g. CMM, CMMI, DO-178B, ISO 9001) alone does not guarantee that safety concerns will be properly addressed.» Що він описує замість цього ближче до урядового нагляду за конкретною програмою, ніж до акредитації компанії: Safety Review Authority і органи сертифікації зважують докази в Safety Assessment Report, погоджуються з конструкцією програмного забезпечення на Critical Design Review і пізніше погоджуються, або призначають пункти дій, щодо рекомендації, перш ніж програмне забезпечення системи введуть на службу. Це рішення про виріб програмного забезпечення перед ними, а не схема, щодо якої організацію постачальника оцінюють один раз і несуть далі, і проходження розгляду AOP-52 не робить постачальника «сертифікованим за AOP-52».

Стандарти, на які він посилається

• STANAG 4452 - Standardization Agreement, що фіксує угоду держав НАТО користуватися AOP-52; обкладинка, що дає йому силу.
• AOP-15 - супутня Allied Publication щодо оцінки безпеки і придатності до служби неядерних боєприпасів, чий крок Software Hazards Analysis AOP-52 існує задовольнити.
• ISO 9001 - названий як приклад сторонньої сертифікації процесу, яка сама по собі не гарантує, що питання безпеки адресовані.
• IEC 61508 - Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, перелічений у власній бібліографії документа, а не викликаний як зобов'язальна вимога.

NATO Standardization Document Database - авторитетне джерело AOP-52. Документи НАТО безоплатні; ми віддаємо належне НАТО за каталог і самі ні продаємо, ні розміщуємо копію.

Стандарти, на які він посилається

• AOP-15Довідково
• ISO 9001Довідково
• IEC 61508Довідково

Інші стандарти в темі «Безпека боєприпасів і вибухових речовин»

• AOP-15AOP-15 оцінювання безпеки і придатності боєприпасів
• AOP-20AOP-20 посібник випробувань систем безпеки, взведення і функціонування
• AOP-21AOP-21 випробування безпеки компонентів систем ініціювання
• AOP-46AOP-46 оцінка повного життя боєприпасів
• AOP-62AOP-62 настанови з нагляду боєприпасів на службі
• AOP-63AOP-63 планування відбору і випробувань для нагляду боєприпасів