Приложение 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 Общие положения

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

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

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

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

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

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

G.7.2 Удобочитаемость

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

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

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

- соблюдение правил использования отступов;

- использование описательных имен идентификаторов;

- комментирование и внутренняя документация;

- ограничение размера подпрограмм;

- минимизация многоязыкового программирования;

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

- уменьшение разброса взаимосвязанных устройств;

- уменьшение использования литералов.

G.7.2.2 Соблюдение правил использования отступов

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

- блоков программирования (последовательностей операторов, ограниченных операторами begin и end);

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

- разветвляющихся конструкций (например, if... then... else, case-операторов, циклов и т.п.);

- множественных уровней вложения (например, цикл do в цикле do);

- объявления переменных и подпрограмм;

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

- использования и управления исключениями.

G.7.2.3 Использование описательных имен идентификаторов

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

Примеры рассматриваемых проблем включают:

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

- как должны именоваться переменные цикла (например, "i.j.k" или более длинные названия);

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

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

- списки связанных с проектом терминов и зарезервированных слов (например, ограничения на использование понятий "аварийный сигнал", "предельное значение" и т.д.).

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

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

G.7.2.4 Комментирование и внутренняя документация

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

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

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

- другие вызываемые подпрограммы или модули и их взаимозависимости;

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

- ответственное подразделение или группу по программированию;

- дату создания модуля;

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

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

- комментарии о цели, области применения и ограничениях для каждого аргумента (для подпрограмм с аргументами).

Аналогичные примеры для документации в рамках ППО включают:

- ссылку на проектную документацию более высокого уровня в комментариях, связанных с объявлениями типов данных, переменных и констант;

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

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

G.7.2.5 Ограничение размера подпрограммы

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

G.7.2.6 Минимизация многоязыкового программирования

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

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

G.7.2.7 Уменьшение неясных или труднонаходимых конструкций программирования

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

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

G.7.2.8 Уменьшение разброса взаимосвязанных устройств

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

G.7.2.9 Уменьшение использования литералов

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

G.7.3 Абстракция данных

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

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

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

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

G.7.3.2 Минимизация использования глобальных переменных

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

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

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

G.7.3.3 Минимизация сложности интерфейсов

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

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

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

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

G.7.4 Функциональная связность

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

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

G.7.4.2 Одноцелевое назначение функций и процедур

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

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

"глагол + цель (цели)".

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

G.7.4.3 Одноцелевые переменные

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

G.7.5 Гибкость

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

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

G.7.5.2 Изоляция изменяемых функций

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

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

G.7.5.3 Переносимость

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

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

- минимизацию использования встроенных функций;

- минимизацию использования скомпилированных библиотек;

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

- минимизацию разбиения на задачи;

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

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

G.7.5.5 Разграничение нестандартных конструкций

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