Приложение G (справочное). Руководство по применению методов прикладного программирования

Приложение G
(справочное)

Руководство
по применению методов прикладного программирования

G.1 Цель данного руководства

В промышленном секторе выбор ПЭ-устройств, как правило, основывается либо на устройствах, соответствующих МЭК 61508 (например, "ПЛК безопасности"), поддерживаемых руководством по безопасности, либо на опыте их предшествующего использования.

Настоящее приложение представляет примеры факторов, называемых "общие свойства прикладного программирования систем безопасности", которые следует рассматривать в зависимости от обстоятельств, либо используя руководство по безопасности, предоставленное производителем, либо с помощью руководства по программированию, предназначенного для конкретного проекта. Эти примеры предназначены поддержать проект ППО в рамках области применения настоящего стандарта и внести свой вклад в достижение ожидаемой систематической полноты безопасности ППО.

Примечание - Это приложение было ранее определено как приложение А.

G.2 Общие свойства прикладного программирования систем безопасности

Настоящее приложение описывает общие, независящие от языка, свойства прикладного программирования системы безопасности. Эти свойства были определены в формате иерархической, трехуровневой структуры. Четыре свойства верхнего уровня представлены ниже.

Безотказность. Безотказность - это предсказуемая и согласованная работа ППО в условиях, указанных в задании на проектирование. Это свойство верхнего уровня является важным для безопасности, так как оно обеспечивает снижение вероятности внесения ошибок в ППО во время его реализации, которые приводят к сбоям в работе ППО.

Устойчивость. Устойчивость - это способность ППО работать допустимым образом в случае нештатных условий или событий в технологическом процессе. Это свойство верхнего уровня является важным для безопасности, так как оно повышает способность ППО справляться с исключительными условиями, восстанавливаться после внутренних отказов и предотвращать распространение ошибок, возникающих из необычных обстоятельств (не все из которых могли быть всецело определены в задании на проектирование).

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

Ремонтопригодность. Это средства, с помощью которых ППО снижает вероятность внесения сбоев во время изменений, выполняемых после ввода в эксплуатацию. Это свойство верхнего уровня является важным для безопасности, так как оно позволяет снизить вероятность некорректной работы в результате внесения ошибок во время адаптивного, корректирующего или полного сопровождения ППО.

G.3 Безотказность

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

В контексте ППО безотказность: 1) либо является вероятностью успешного выполнения в течение заданного промежутка времени и в заданных условиях; 2) либо вероятностью успешной работы по запросу. Факт выполнения ППО до его завершения является результатом его правильного поведения по отношению к системной памяти и логики ППО. То, что ППО своевременно выдает результат, зависит от того, что инженер по автоматизации обладает пониманием языковых конструкций и характеристик рабочей среды во время выполнения. Таким образом, установленные промежуточные свойства безотказности это:

- предсказуемость использования памяти. Существует высокая вероятность того, что ППО не "заставит" логическое решающее устройство обратиться к непредусмотренным или запрещенным ячейкам памяти;

- предсказуемость потока управления. Существует высокая вероятность того, что логическое решающее устройство выполнит инструкции в той последовательности, которая предполагалась программистом;

- предсказуемость во времени. Существует высокая вероятность того, что ППО, работающее в определенной рабочей среде, не будет выходить за рамки его ограничений по времени реакции и ограничений его возможностей. Что касается предсказуемости математического или логического результата, то существует высокая вероятность, что ППО, работающее в определенной рабочей среде, выдаст математический или логический результат, который предполагался инженером по автоматизации.

G.3.2 Предсказуемость использования памяти

G.3.2.1 Минимизация динамического распределения памяти

Динамическое распределение памяти используется в ППО для временного присваивания (распределения) памяти, когда это становится необходимо во время выполнения, и для освобождения памяти (также во время выполнения) других пользователей, когда она им больше не требуется. Проблема безопасности при динамическом распределении памяти в системе реального времени заключается в том, что ППО впоследствии может не освободить всю память или ее часть. Это может произойти либо из-за того, что:

- ППО распределяет память для себя, но в процессе нормального выполнения не освобождает ее, либо

- ППО, которое временно распределило память для своего использования, было прервано до выполнения освобождения памяти.

Каждая из этих двух ситуаций приведет к неизбежной потере всей применимой памяти и потери всех функций безопасности в сети. Поэтому динамическое распределение памяти в цифровых системах безопасности должно быть минимизировано.

Если динамического распределения памяти нельзя избежать, то применим МЭК 61508-3, и ППО должно учитывать положения, обеспечивающие, что:

- вся динамически распределенная во время конкретного цикла выполнения память освобождается в конце этого цикла и

- вероятность прерывания выполнения между точкой, в которой память динамически распределяется, и точкой, в которой она освобождается, минимальна (если не исключена полностью); ППО также должно быть способно обнаруживать любые ситуации, где динамически распределенная память не была освобождена, и освобождать подобную память.

Настоящий стандарт тем самым не рекомендует использовать косвенную адресацию. МЭК 61508-3 применим к ППО, использующему косвенную адресацию.

G.3.2.2 Минимизация страничной организации памяти и свопинга

Страничная организация памяти реализуется для части памяти и применяется для хранения редко используемых областей основной памяти. Если у ППО возникает потребность в этих областях памяти, то логическое решающее устройство считывает содержание одной части памяти и загружает его обратно в другую часть памяти. Свопинг процесса заключается в использовании части памяти для хранения образа памяти всего неактивного процесса (включая такие его области памяти, как пространство стека и динамическую память).

Если приходит время для выполнения процесса, то этот образ загружается из одной части памяти назад в основную память для использования логическим решающим устройством. В случае любого события конкретный объем используемой памяти и часть хранилища, используемого для свопинга, являются неопределяемыми.

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

Если логическое решающее устройство, которое поддерживает страничную организацию памяти или свопинг процесса, используется в ПСБ, то эта функция должна быть отключена на уровне логического решающего устройства. Для всех данных и всех ППО должно быть достаточно основной памяти. Если существуют какие-либо сомнения, что эти функции не были отключены, то применим МЭК 61508-3, и ППО должно быть способно обеспечить нахождение всех критически важных функций и их данных в основной памяти на протяжении всего периода выполнения. Подобные средства в ППО включают вызовы логического решающего устройства ("пиннинг"), директивы инструментальных средств прикладного программирования и скрипты логического решающего устройства.

G.3.3 Предсказуемость потока управления

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

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

Связанные с этим базовые свойства это:

- максимизация структуры;

- минимизация сложности потока управления;

- инициализация переменных перед их использованием;

- по одной точке входа и точке выхода для подпрограмм;

- минимум неоднозначностей, связанных с интерфейсом;

- использование типизации данных;

- учет точности и достоверности;

- порядок очередности арифметических, логических и функциональных операторов;

- отказ от использования функций и процедур с побочными эффектами;

- разделение присваивания и анализа;

- надлежащая работа с программными контрольно-измерительными приборами;

- управление размером библиотек класса;

- минимальное использование динамического связывания;

- контроль перегрузки оператора.

G.3.3.2 Максимизация структуры

Следует избегать в ППО оператора GOTO или подобных операторов управления выполнением, способных привести к неструктурированному переходу выполнения от одной ветви ППО на другую. Проблема безопасности заключается в трудности отслеживания и понимания поведения времени выполнения. Конструкции GOTO могут повлечь за собой нежелательные побочные эффекты, так как они прерывают выполнение определенного сегмента ППО, не гарантируя, что последующее за этим выполнение будет удовлетворять всем условиям, которые привели ко входу в этот сегмент. Стандарты, не рекомендующие или даже запрещающие подобные практики, использовались уже более двадцати лет. Максимизация структуры осуществляется удалением конструкций GOTO и использованием ППО с надлежащей блочной структурой. Конструкции case, if... then... else, do, until и do while позволяют ветвление с определенным возвращаемым значением и не приводят к неопределенности потока управления, которое связано с GOTO или подобными конструкциями.

G.3.3.3 Минимизация сложности потока управления

На сложность потока управления указывает число уровней вложения, предназначенных для выполнения ветвлений или циклов. Чрезмерная сложность затрудняет прогнозирование потока ППО и препятствует проверке и обслуживанию. Более специфичная проблема безопасности заключается в том, что поток управления может быть непредсказуемым в случаях, когда возникают непредвиденные комбинации параметров. Чрезмерного использования вложения можно, как правило, избежать через применение функций или подпрограмм вместо включаемых ветвлений. В качестве меры профилактики безопасности следует установить определенное ограничение на вложения, включив его в проект или руководство по организации программирования.

Таким образом, МЭК 61511 ограничивает слои архитектуры ППО до двух:

- типовые наборы;

- блокировки.

МЭК 61508-3 применим к программам ППО, обладающим числом уровней вложения, превышающим этот установленный предел.

G.3.3.4 Инициализация переменных перед использованием

Если переменные не инициализируются присвоением определенного значения в начале цикла выполнения программы, то это снижает уровень безопасности, так как эти переменные могут содержать "мусор" для своих значений (остаток от предыдущего использования данной области памяти). Предсказуемость выполнения требует установки в ячейки памяти, выделенные под данные процесса, известных значений перед тем, как к ним будет получен доступ (установка и использование). Определенный результат использования неизвестных начальных значений переменной зависит от того, как эта переменная используется в ППО. МЭК 61508-3 применим к ППО, использующим неинициализированные переменные.

G.3.3.5 Одна точка входа и одна точка выхода для подпрограмм

Множественные точки входа и выхода в подпрограммах вносят неопределенность в поток управления также, как это делают конструкции GOTO.

Предсказуемость потока выполнения повышается при использовании одной точки входа и одной точки выхода в каждой программе ППО. Так как предсказуемость потока выполнения является характеристикой, важной для безопасности, то использование нескольких точек входа и выхода в подпрограммах или функциях является нежелательным, даже если это поддерживается в языке. МЭК 61508-3 применим к программам ППО, обладающим несколькими точками входа и выхода.

G.3.3.6 Минимизация неоднозначности интерфейса

Сбои, связанные с интерфейсом, включают несоответствия в списках аргументов при вызове других подпрограмм, в коммуникациях с другими задачами или в передачах сообщений между объектами. Примером такого сбоя может служить инвертирование порядка аргументов при вызове подпрограммы. Предыдущие исследования отказов ППО продемонстрировали, что эта категория сбоев является достаточно значимой. Методы прикладного программирования, позволяющие снизить или устранить вероятность сбоев интерфейса, включают:

- упорядочивание аргументов для чередования разных типов данных (уменьшение шансов того, что два смежных аргумента будут поставлены в неправильном порядке);

- использование именных обозначений вместо обозначений порядка или позиции для языков, поддерживающих подобную систему обозначения;

- тестирование для определения допустимости входных аргументов в начале подпрограммы.

Для стандартных программ должны быть установлены адекватные начальные и конечные условия. Начальное условие является гарантией того, что все локальные переменные инициализированы, а все входные переменные успешно прошли проверку на допустимость. Конечное условие гарантирует, что все выходные переменные успешно прошли проверку на допустимость.

G.3.3.7 Использование типизации данных (структуры данных)

Использование структур данных, которые отличаются от тех, что были предназначены для использования в ППО, может привести к отказам, а подобные отказы, возникающие во время исключительной ситуации, могут оказывать особенно пагубное влияние на безопасность. Эту проблему можно решить объявлением типов данных. Изначально основным преимуществом объявления типов данных являлось то, что это позволяло подготовить правильный объем памяти. Тем не менее типизация данных полезна для улучшенного определения интерфейсов, повышения удобочитаемости (для проверок) и для проверок во время компиляции и функционирования. Эти применения, изначально являвшиеся дополнительными, теперь стали основной мотивацией для типизации данных и привели к использованию строгой типизации данных, для которой требуются дополнительные объявления (типов данных), как минимум те, что входят в допустимый диапазон. Проблемы безопасности, связанные с типизацией данных, включают:

- ограничение использования анонимных типов (например, общий целочисленный тип или тип с плавающей запятой, не ограниченные снизу или сверху) в языках со строгой типизацией;

- предотвращение чрезмерного сдерживания ограничений на типы данных для того, чтобы избежать генерации ложных исключений или сообщений об ошибках (это является проблемой в языках со строгой типизацией);

- уменьшение числа преобразований типов и устранение неявных или автоматических преобразований типов (например, в назначениях или операциях над указателями);

- отказ от использования смешанных операций. Если подобные операции необходимы, то их следует четко идентифицировать и описать при помощи визуально выделенных комментариев в ППО;

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

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

G.3.4 Учет точности и достоверности

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

Реализация ППО должна обеспечивать адекватную точность и адекватную достоверность для предназначенного приложения системы безопасности. Это применимо как к измерениям физических свойств, так и к любым арифметическим значениям с плавающей запятой в рамках ППО. Проблемы с безопасностью возникают, когда заявленная точность переменных с плавающей запятой не поддерживается анализом, в особенности, когда разница между большими значениями незначительна (например, при вычислении интенсивности изменения на основе разницы между текущими и предыдущими значениями, в вычислениях дисперсий или при выполнении операций фильтрации, таких как "скользящее среднее").

G.3.4.2 Порядок очередности арифметических, логических и функциональных операторов

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

G.3.4.3 Отказ от использования функций или процедур с побочными эффектами

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

G.3.4.4 Разделение присваивания и анализа

Операторы присваивания должны быть отделены от выражений анализа. Разделение может нарушаться, когда подпрограммы используются как часть анализа. Например, функция фильтрации может использоваться скорее как часть анализа, чем просто значение датчика. С этим свойством связано минимальное использование глобальных переменных, рассматриваемое ниже.

G.3.4.5 Надлежащее применение вспомогательных функций прикладной программы

Инструментальные средства ППО собирают и выводят определенные значения внутреннего состояния ППО во время выполнения, а также позволяют разработчику проверять корректную реализацию определенных аспектов спецификации. Конкретные проблемы, связанные с безопасностью, в этом случае:

- минимизация нарушений функционирования. Вспомогательные функции, которые нарушают нормальный поток выполнения, являются нежелательными в приложениях безопасности. Например, чрезмерная "запись" или другие выходные операторы могут привести к выполнению значительной части библиотечного ППО, связанного с выходными значениями; менее навязчивым подходом может быть запись этих значений в ячейки внешней памяти, в которых они позже смогут подвергаться обработке. Это также может проявиться при записи данных в двоичном формате для автономной обработки формата (т.е. при преобразовании удобочитаемого для человека текста в цифровой вид). Чтобы минимизировать различия в поведении между нормальным функционированием и тестированием, может быть разумно сохранять определенные вспомогательные функции ППО в фактической окружающей среде;

- обеспечение "видимости" вспомогательных функций в выполняющемся ППО. Некоторые средства ППО изменяют файлы объекта (или выполняемые файлы), сгенерированные логическим решающим устройством, чтобы внести вспомогательные функции. Это, как правило, является недопустимым в системах безопасности, так как влияние подобных изменений в ППО нельзя увидеть, и невозможно оценить это влияние на выполнение;

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

G.3.4.6 Управление размером библиотек классов

Управление размером библиотеки класса является важным для предотвращения трудностей управления системой и снижения производительности по причине слишком большого числа классов или объектов. Если руководящие указания для конкретного проекта ограничивают число классов и объектов, и реализуемое ППО следует этим указаниям, то уровень безопасности повышается.

G.3.4.7 Минимальное использование динамического связывания

Связывание указывает на привязку имени к классу. Динамическое связывание позволяет откладывать связь имени/класса до тех пор, пока во время выполнения не будет создан объект, обозначенный этим именем. Непредсказуемость связывания имени/класса создает проблемы. Она также снижает предсказуемость поведения при выполнении объектно-ориентированной программы и усложняет ее отладку, понимание и отслеживание. Для приложений, имеющих критическое значение для безопасности, желательно устанавливать ограничения на динамическое связывание или устранять их вообще. МЭК 61508-3 применим для ППО, использующего динамическое связывание.

G.3.4.8 Управление перегрузкой операторов

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

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

G.3.5 Предсказуемость во времени

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

Предсказуемость во времени критически важна в используемой системе безопасности, управляемой в реальном масштабе времени. Базовые свойства, связанные с объектно-ориентированным программированием, имеющие отношение к этому промежуточному свойству и уже описанные выше, следующие:

- управление размером библиотек классов;

- минимизация использования динамического связывания;

- управление перегрузкой операторов.

Два дополнительных базовых свойства, связанных с временными характеристиками, рассматриваются в следующих подпунктах:

- минимальное разбиение на задачи;

- минимальное использование обработки, управляемой прерываниями.

G.3.5.2 Минимальное разбиение на задачи

Несмотря на то что разбиение на задачи представляет собой привлекательную модель для одновременной обработки, ее использование является нежелательным в приложениях, имеющих критическое значение для безопасности, по следующим причинам:

- последовательность выполнения является неопределенной, если несколько других вызванных альтернатив ожидает выполнения, так как не всегда ясно, какой из вызовов будет выбран;

- разбиение на задачи допускает критически опасные временные ошибки, такие как появление состояния гонки и взаимоблокировки. Такие ошибки сложно отладить.

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

G.3.5.3 Минимальное использование обработки, управляемой прерываниями

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

В справочных документах и стандартах, связанных с цифровыми системами безопасности, как правило, не рекомендуется или запрещается использование такой обработки (см. МЭК 60880:2006). Отказ от использования обработки, управляемой прерываниями, упрощает анализ синхронизации и поведения при выполнении, а также предотвращает недетерминированный подход ко времени реакции, присущий обработке, управляемой прерываниями.

G.4 Предсказуемость математических или логических результатов

Предсказуемость математических или логических результатов означает, что рассматриваемые результаты, полученные при завершении выполнения нижнего уровня ППО, являются результатами, которые предположил и на которые рассчитывал программист, написавший это ППО. Понятие "логические" предназначено для расширения понятия "результаты" для случая, в котором ППО может манипулировать логическими данными и выдавать логический результат. Поэтому ППО системы безопасности должно быть строго статическим. МЭК 61508-3:2010 применим для ППО, использующего память на триггерах с явным или неявным управлением.

Интенсивное использование блокировок изменяет предсказуемость результатов и повышает сложность демонстрации независимости между структурами ППО. ФБ ПСБ не должны блокировать друг друга.

Применение таймеров должно быть ограничено, а также следует исключать их последовательное включение или взаимоблокировки.

G.5 Устойчивость

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

Устойчивость относится к способности ППО продолжать выполнение в условиях, отличающихся от нормальных, или в случае других непредусмотренных условий. Синонимом устойчивости является живучесть. Устойчивость является важным свойством системы безопасности, так как непредусмотренные события могут произойти во время происшествия или в результате отклонения параметров от их номинальных значений, но способность ППО продолжать контролировать систему и управлять ею в подобных обстоятельствах является жизненно важной.

Промежуточными свойствами для устойчивости являются:

- управление применением разнообразия;

- управление применением обработки исключений;

- проверка ввода и вывода.

G.5.2 Управление применением разнообразия

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

Решение использовать разнообразные реализации ППО принимается на уровне проектирования и тем самым выходит за рамки области применения настоящего руководства. Тем не менее, если в проекте или в требованиях предусмотрено разнообразие, то его применение необходимо контролировать. Принципиальной проблемой использования разнообразия в ППО является вероятность того, что отказы ППО по общей причине могут привести к тому, что резервные системы безопасности откажут таким образом, что работа функция безопасности будет нарушена.

Вероятность возникновения отказов по общей причине между подпрограммами ППО, разработанными независимо друг от друга, достаточно сложно устранить. Любая общая спецификация может повлечь за собой отказы по общей причине. Такая же проблема существует при разработке тестовых данных для проверки ППО - специалисты по тестированию могут опустить те же нештатные или необычные случаи, которые упустили разработчики. Более того, при использовании подхода, при котором выходы нескольких версий ППО можно сравнивать в реальном времени (или иметь возможность сравнивать промежуточные результаты), проекты независимых команд-разработчиков могут быть чрезмерно специфицированы. Такие подробные общие спецификации могут привести к малой степени разнообразия в проекте ППО. Это часто обнаруживается в корпоративных стандартах программирования.

Кроме того, различные версии ППО, написанные независимо по одной и той же спецификации требований, эффективно защищают только от ошибок прикладного программирования (и иногда только от ограниченного набора таких ошибок). С другой стороны, эмпирические данные показывают, что большинство проблем безопасности (и большинство ошибок, встречающихся в ППО) возникают из-за ошибок в требованиях ППО, в особенности связанных с неправильным пониманием того, как должно ППО выполнять свои функции. ППО, предназначенное обеспечить резервирование, может не достигнуть своей цели и просто повторить эти ошибки. При проверке критически важного для безопасности ППО для определения отказов по общей причине основным является анализ разнообразия ППО.

Существует два базовых свойства:

- управление внутренним разнообразием;

- управление внешним разнообразием.

G.5.2.2 Управление внутренним разнообразием

Если применяется только внутреннее разнообразие, то интерфейсы ко всем версиям должны быть идентичны. Другими словами, любые данные датчика или параметры, поступающие от вызывающих процедур, должны идентично передаваться всем версиям, а выходные данные из любых версий должны приниматься и использоваться другими частями системы. Тем не менее внутренние операции и хранилище локальных данных должны использовать разнообразие в многомодульных версиях или реализациях. Применение внутреннего разнообразия упрощает объектно-ориентированный подход, при котором используются одинаковые сообщения и методы, но внутренние алгоритмы и представления данных отличаются. Внутреннее разнообразие должно реализовываться в соответствии с проектом и руководящими принципами, ориентированными на конкретный проект. При этом должны рассматриваться:

- разнообразные алгоритмы. Использование различных алгоритмов, преобразований единиц измерения и параметров процесса (если в этом появляется потребность или это разрешено требованиями или проектом) делает вероятность отказа, связанного с проектированием или реализацией, минимальной;

- разнообразные способы подтверждения соответствия данных. Использование альтернативных схем для подтверждения соответствия данных датчика (или другого входного устройства) и выходных данных делает вероятность отказа, связанного с реализацией инженера-разработчика, минимальной;

- разнообразные стандартные программы обработки исключений. Эта мера снижает вероятность того, что ошибка в обработке исключений или выполнении произойдет одновременно во множестве версий;

- различные типы данных, структуры и распределение памяти. Эта мера снижает вероятность того, что непредвиденное взаимодействие между объектом, сгенерированным ППО с помощью инструментального средства прикладного программирования и логическим решающим устройством приведет к непреднамеренному перезаписыванию данных или ППО одновременно в нескольких версиях;

- разнообразные библиотеки и стандартные подпрограммы. Отказ от использования одинаковых стандартных программ в ППО, библиотечных стандартных программ, предоставляемых компилятором, и интерфейсов прикладного программирования, предоставляемых логическим решающим устройством. Эта мера снижает вероятность одновременного отказа, связанного с дефектом в таких стандартных программах;

- разнообразный порядок арифметических операций. Изменение порядка арифметических операций в преобразованиях, арифметических операторах и операторах присваивания при помощи коммутативных, ассоциативных и дистрибутивных свойств снижает вероятность одновременных отказов, связанных с непредвиденными условиями переполнения, созданными промежуточными результатами или проблемами числовой точности;

- разнообразный порядок операций ввода и вывода. Выполнение операций ввода-вывода в разном порядке снижает вероятность одновременных отказов, связанных с синхронизацией (например, взаимных блокировок), или отказов, управляемых данными (т.е. аварийного завершения программы из-за определенного значения данных).

Разнообразие ограничено тем фактом, что для данной платформы все эти языки действительно являются разнообразным представлением одинаковых алгоритмов. Использование разнообразия языков, таким образом, только ослабляет недостатки каждого языка перед компиляцией. Поэтому ППО может быть написано на двух разных языках для сравнения его поведения.

G.5.2.3 Управление внешним разнообразием

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

G.5.3 Управление обработкой исключений

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

Обработка исключений решает проблемы, связанные с нарушениями нормальных состояний систем и входных данных. Средства обработки исключений в некоторых языках упрощают установление альтернативного пути обработки события, условия которого хотя и являются непредвиденными, но приводят к состояниям, которые заранее можно определить и впоследствии обработать. Проблемы, возникающие при появлении и обработке исключений, часто трудно решить в процедуре самой обработки исключения.

Базовые принципы обработки исключений:

- обработка на нижнем уровне;

- сохранение контроля за исполнением программы;

- единообразная обработка исключений.

G.5.3.2 Локальная обработка исключений

Обработка исключений сразу на нескольких уровнях может привести к неточной интерпретации места возникновения исключения. Этот системный сбой можно предотвратить, устанавливая обработку исключений на нижнем уровне.

G.5.3.3 Сохранение контроля за исполнением программы

Прерывание потока управления, являющегося внешним по отношению к подпрограмме, в которой возникло исключение, создает неопределенность в выполнении, следующем за обработкой исключения. Безопасность повышается за счет поддержания потока управления внешнего по отношению к модулю, ответственному за исключение.

G.5.3.4 Единообразная обработка исключений

Отсутствие единообразной обработки исключений может привести к неодинаковой обработке идентичных исключений в разных частях ППО. В худшем случае это может привести к появлению необработанных исключений. Этих проблем можно избежать с помощью руководства по работе с исключениями, являющегося частью методических процедур прикладного программирования организации или конкретного проекта. Темы, включенные в данное руководство, это:

- общие и зависящие от проекта исключения, которые были определены и предусмотрены;

- определение мест обработки исключений ППО;

- перечисление всех предусмотренных побочных эффектов и верификация отсутствия каких-либо других побочных эффектов;

- обеспечение целостности данных критического состояния во время обработки исключения.

Очень важно заранее определить критерии того, что обрабатывать в исключениях, а что включить в алгоритм обработки самой программы.

G.5.4 Проверка ввода и вывода

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

Искажение данных, вызванное временным отказом или недействительным результатом, может иметь серьезные последствия для последующей обработки, если позволить его распространение. Базовые свойства, связанные с проверкой ввода и вывода, минимизируют подобные последствия посредством ограничения распространения ошибки. Два базовых свойства, рассмотренных в G.5.4.2 и G.5.4.3, это:

- проверка данных ввода и

- проверка данных вывода.

G.5.4.2 Проверка данных ввода

Данные ввода включают данные от другой стандартной программы, данные из внешней среды и данные, хранящиеся в памяти, полученные на предыдущей итерации. Достоверность данных должна проверяться перед обработкой. Подобные проверки снижают вероятность распространения некорректных результатов или искаженных данных. Как минимум, значения входных данных должны проверяться на тип данных и нарушение допустимого диапазона. Если возможно, то следует также выполнять проверки логической непротиворечивости данных. ППО должно иметь средства для обнаружения некорректного ввода и перевода модуля в известное состояние (т.е. заданное по умолчанию или ранее обоснованные значения) в соответствии с проектом более высокого уровня.

G.5.4.3 Проверка данных вывода

Данные вывода - будь это вывод во внешнюю среду, в другую стандартную программу или хранение таких данных для использования в последующей итерации - должны проверяться на достоверность. Как минимум, эта проверка на достоверность должна гарантировать, что значения имеют надлежащий тип данных и не выходят за допустимые диапазоны. Желательно выполнять проверки логической непротиворечивости данных. Однако подобные проверки логической непротиворечивости данных не должны быть настолько ограничивающими, что они ошибочно отбрасывают корректные значения.

Согласно проекту ППО оно должно также содержать средства для обработки отброшенных выходных значений.

G.6 Прослеживаемость

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

Как было ранее определено в настоящем приложении, прослеживаемость связана со свойствами безопасности ППО, которые поддерживают верификацию корректности и полноты на основе сравнения с проектом ППО. Промежуточные свойства прослеживаемости это:

- удобочитаемость;

- управление использованием встроенных функций (см. G.6.2);

- управление использованием скомпилированных библиотек (см. G.6.3).

Так как удобочитаемость также является промежуточным свойством ремонтопригодности, то она рассматривается в G.3.4.8. Последние два свойства и их значимость для безопасности рассматриваются в G.6.2 и G.6.3.

G.6.2 Управление использованием встроенных функций

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

Проблемы использования встроенных функций могут быть решены с помощью организационных или ориентированных на проект руководств. Используя сценарии регрессионного тестирования, можно установить соответствие с ожидаемыми результатами новых версий компиляторов и библиотек программ этапа исполнения. Поэтому следует сохранять тестовые сценарии, процедуры и результаты предыдущего тестирования для возможных встроенных функций. Тестирование также должно оценить поведение для граничащих и выходящих за допустимые границы условий (например, отрицательные аргументы в стандартной программе вычисления квадратного корня, некорректно прерванные строки для функции копирования строки и т.п.) в конкретной среде выполнения.

G.6.3 Управление использованием скомпилированных библиотек

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

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

Подобно встроенным функциям следует сохранять и поддерживать тестовые сценарии, процедуры и результаты тестирования. Тестовые сценарии должны оценивать поведение для нормальных, выходящих за границы и предельных условий в конкретной среде выполнения. Для каждой новой версии скомпилированной библиотеки следует проводить регрессионное тестирование.

G.7 Ремонтопригодность

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

Ремонтопригодность ППО снижает вероятность того, что при осуществлении изменений будут внесены ошибки. Промежуточные свойства, связанные с ремонтопригодностью и влияющие на безопасность, включают:

- удобочитаемость. Те свойства ППО, которые облегчают понимание ППО персоналом проекта;

- абстракцию данных. То, насколько ППО можно разделить на разделы и модули, чтобы минимизировать сопутствующее негативное влияние и вероятность непреднамеренных побочных эффектов, связанных с изменениями ППО;

- функциональную связность. Надлежащее распределение в ППО функций на уровне проектирования устройств, с которыми работает ППО (одна процедур