ПОДВИЖНОЙ СОСТАВ ЖЕЛЕЗНЫХ ДОРОГ Системы связи, сигнализация и обработки данных Программное обеспечение для систем управления и защиты на железной дороге

СТ РК МЭК 62279 - 2007

(IEC 62279:2002 Railway applications communications, signaling and processing systems -Software for railway control and protection systems, IDT)

Издание официальное

Комитет по техническому регулированию и метрологии Министерства индустрии и торговли Республики Казахстан (Г осстандарт)

Астана

Предисловие

1    РАЗРАБОТАН ТОО «Национальный центр аккредитации»

ВНЕСЕН Комитетом путей сообщения Министерства транспорта и коммуникации республики Казахстан

2    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Комитета по техническому регулированию и метрологии Министерства индустрии и торговли Республики Казахстан от 27 сентября 2007 года № 546

3    Настоящий стандарт идентичен международному стандарту МЭК 62279-2002 «Подвижной состав железных дорог. Системы связи, сигнализация и обработки данных. Программное обеспечение для систем управления и защиты на железной дороге» (IEC 62279:2002 Railway applications communications, signaling and processing systems -Software for railway control and protection systems), IDT

4 СРОК ПЕРВОЙ проверки ПЕРИОДИЧНОСТЬ ПРОВЕРКИ

5 ВВЕДЕН ВПЕРВЫЕ

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

7 Вопросы жизненного цикла и документация

7.1    Задачи

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

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

7.2    Требования

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

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

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

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

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

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

Кроме того, каждый документ, за исключением документов программного обеспечения COTS (см. пункт 9.4.5) или ранее разработанное программное обеспечение (см. пункт 9.4.6) разрабатывается согласно следующим правилам:

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

Он не должен противоречить предыдущему документу;

Каждый термин, акроним или аббревиатура должны иметь одно значение в каждом документе;

Ссылка на каждый предмет или концепцию делается одним названием или описанием в каждом документе.

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

Контекст всех документов регистрируется в форме соответствующей для манипуляции, обработки и хранения.

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

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

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

7.2.1 Связь между различными документами, определенная в пункте 7, может также быть определена используя таблицу документальной перекрестной ссылки. По каждому документу, перечисленному в колонке «Документы», фаза и пункт, связанные с его созданием могут быть найдены читая таблицу горизонтально и вертикально от ячейки, содержащей символ «(». Фазы, в которых он используется можно найти, читая таблицы вертикально от ячеек, отмеченных символом «♦». Пункт или другая ссылка на определение документа могут быть найдены в колонке «Где определены». Там где пункт предоставлен, следующие пункты также требуют проверки, так как они могут содержать дальнейшую информацию. Следует отметить, что ссылка на план управления конфигурацией программного обеспечения дается в скобках, так как данный пункт просто дает ссылку на СТ РК ИСО 9001.

9

СТ РК МЭК 62279 - 2007

Таблица документальной перекрестной ссылки

Пункт 8 9 10 11 12 13 14 15 16 Кркат атауы Где определено Атауы SRS SA SDD SVe S/H SVal Ass Q Ма ФАЗЫ(*) = параллельное Документы ЖУЙЕГЕ ЕНГ13У ♦ ♦ ♦ Спецификация требований систем ENB 50129 В.2.3 annex ♦ ♦ ♦ ♦ ♦ ♦ Спецификация требований систем по безопасности ENB 50129 В.2.4 annex ♦ ♦ Описание архитектуры системы ENB 50129 В.2Л annex План безопасности системы ENB 50129 IEC 62278 SW ПЛАНИРОВАНИЕ (*) ♦ ♦ ♦ ♦ ♦ ♦ i Sw План гарантии качества 15.4.3 ♦ ♦ i Sw План управления кофигурацией (15.4.2) 1 ♦ ♦ Sw План проверки подлинности 11.4.1 1 ♦ ♦ Sw План проверки интеграции 11.4.5 1 ♦ ♦ Sw/Hw План проверки интеграции 12.4.1 1 ♦ Sw План подтверждения 13.4.3 ♦ 1 Sw План обслуживания 16.4.3 План подготовки данных 17.4.2.1 План проверки данных 17.4.2.4 SW ТРЕБОВАНИЯ (*) 1 ♦ ♦ ♦ ♦ ♦ ♦ Sw Спецификация требований 8.4.1 Спецификация требований программы 17.4.1.1 1 ♦ ♦ ♦ ♦ Sw Спецификации требований к испытаниям 8.4.13 1 Sw Отчет проверки подлинности 11.4.11 SW ПРОЕКТ 1 ♦ ♦ ♦ ♦ ♦ Sw Спецификации архитектуры 9.4.1 1 ♦ ♦ ♦ ♦ Sw Спецификация проекта 10.4.3 1 Sw Отчет проверки подлиности архитектуры 11.4.12 SW ПРОЕКТ МОДУЛЯ 1 ♦ ♦ ♦ ♦ Sw Спецификация проекта модуля 10.4.3 1 ♦ ♦ ♦ ♦ Sw Спецификация испытания модуля 10.4.14 1 Sw Отчет проверки подлинности модуля 11.4.13 КОД 1 ♦ ♦ ♦ ♦ Sw код источника 1 ♦ ♦ Sw Отчет проверки подлинности кода источника 11.4.14 ИСПЫТАНИЕ МОДУЛЯ 1 ♦ Sw Отчет испытания модуля 10.4.14 SW ИНТЕГРАЦИЯ 1 Sw Отчет испытания интеграции 11.4.15 Отчет испытания данных 17.4.2.4 SW/HW ИНТЕГРАЦИЯ 1 Sw/Hw Отчет испытания интеграции 12.4.8 ПОДТВОЕ подлиности 1 SwOthct подтверждения 13.4.10 1 Sw Отчет оценки 14.4.9 ОЦЕНКА (*) I Sw Записи изменений 16.4.9 ОБСЛУЖИВАНИЕ 1 Sw Записи обслуживания 16.4.8

СТ РК МЭК 62279 - 2007

8 Спецификация требований программного обеспечения

8.1    Задачи

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

Описать Спецификации требования к испытанию программного обеспечения.

8.2    Входящие документы Спецификации требований системы Спецификации требований безопасности системы Описание архитектуры системы

План гарантии качества программного обеспечения

8.3    Выходящие документы Спецификации требований системы Спецификации требований к испытанию системы

8.4    Требования

8.4.1    Спецификации требований программного обеспечения выражают требуемые свойства разрабатываемого программного обеспечения, а не процедуры по их разработке. Все эти свойства, которые (за исключением безопасности) определены в [4], включают:

-функциональность (включая возможности и время реагирования);

-надежность и ремонтопригодность;

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

-эффективность;

-используемость;

-мобильность.

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

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

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

b)    прослеживаемые по отношению ко всем документам, упомянутым в пункте 8.2.

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

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

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

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

11

8.4.7    Любые препятствия между аппаратным оборудованием и программным обеспечением определяются и документально регистрируются в спецификациях требований программного обеспечения.

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

8.4.9 Спецификации    требований    программного    обеспечения    включают

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

8.4.10 Спецификации требований программного    обеспечения    включают

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

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

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

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

8.4.14    Спецификации требовании к испытаниям программного обеспечения определяют пункты испытания для каждой требуемой функции, наборы тестовых данных, включая:

a)    требуемый входной сигнал с их последовательностью и значениями;

b)    ожидаемый выходной сигнал с их последовательностью и значениями;

c)    критерии приемлемости , включая рабочие и качественные аспекты.

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

8.4.16    Любой непрослеживаемый материал должен быть продемонстрирован как не несущий функций безопасности или интеграции системы.

9 Архитектура программного обеспечения

9Л Задачи

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

9Л.2 Рассмотреть требования, предъявленные к программному обеспечению архитектурой программного обеспечения.

9.1.3 Определить и оценить важность взаимодействия аппаратного

СТ РК МЭК 62279 - 2007

оборудования/программного обеспечения в вопросах безопасности.

9.1.4 Выбрать метод проектирования, если таковой еще не был ранее определен.

9.2    Входящие документы

1)    Спецификации требований программного обебспечения;

2)    Спецификации требований безопасности системы;

3)    Описание архитектуры системы;

4)    План гарантии качества программного обеспечения.

9.3    Выходящие документы

Спецификации архитектуры программного обеспечения.

9.4    Требования

9.4.1    Предложенная архитектура программного обеспечения устанавливается поставщиком программного обеспечения и /или разработчиком и подробно приводится в спецификациях архитектуры программного обеспечения.

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

9.4.3    Спецификации архитектуры программного обеспечения определяют,

оценивают и детально приводят важность взаимодействия аппаратного оборудования /программного обеспечения. Согласно требованиям [5],    [6],    предварительные

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

9.4.4    Спецификации архитектуры программного обеспечения определяют все компоненты программного обеспечения и для этих компонентов определяют следующее:

a)    являются ли эти компоненты новыми, существующими или запатентованными;

b)    проводилось ли подтверждение подлинности этих компонентов ранее, если да, то каковы были условия подтверждения подлинности;

c)    уровень полноты безопасности программного обеспечения компонента.

9.4.5    Программное обеспечение COTS подлежит следующим ограничениям:

a)    использование программного обеспечения COTS при 0 уровне полноты безопасности программного обеспечения принимается без дальнейших мер предосторожности;

b)    если программное обеспечение COTS должно быть использовано при 1 и 2 уровне полноты безопасности программного обеспечении, оно включается в процесс подтверждения подлинности программного обеспечения;

c)    если программное обеспечение COTS должно быть использовано при 3 или 4 уровне полноты безопасности программного обеспечения, то будут предприняты следующие меры предосторожности:

d)    Программное обеспечение COTS включается в испытание подтверждения подлинности;

e)    Должен проводится анализ возможных сбоев программного обеспечения COTS;

f)    Должна быть определена стратегия для определения сбоев программного обеспечения COTS и защиты системы от этих сбоев;

g)    Стратегия защиты подлежит испытанию подтверждения подлинности;

h)    Журналы регистрации ошибок существуют и оцениваются;

i)    насколько возможно используются только простейшие функции программного обеспечения COTS.

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

13

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

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

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

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

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

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

b)    прослеживаемыми по отношению к спецификациям требований программного обеспечения.

9.4.11    Спецификации архитектуры    программного    обеспечения    обосновывают

баланс между стратегиями предотвращения неисправностей и устранением неисправностей.

9.4.12    Спецификации архитектуры    программного    обеспечения    обосновывают

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

10 Проектирование и внедрение программного обеспечения

10.1    Задачи

10.1.1    Произвести проектирование    и внедрение    программного обеспечения

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

10.1.2    Получить программное обеспечение, которое можно анализировать,

испытывать, проверять и обслуживать. Испытание модуля также включено в эту фазу. Так как проверка подлинности и испытания будут    критическим    элементом в

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

СТ РК МЭК 62279 - 2007

этапа.

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

10.1.4    Произвести интеграцию программного обеспечения,

10.2    Входящие документы

1)    Спецификации требовании программного обеспечения;

2)    Спецификации архитектуры программного обеспечения;

3)    План гарантии качества программного обеспечения.

10.3    Выходящие документы

1)    Спецификации проектирования программного обеспечения;

2)    Спецификации проекта модуля программного обеспечения;

3)    Спецификации модуля испытаний программного обеспечения;

4)    Код источника программного обеспечения и подтверждающая документация;

5)    Отчет модуля испытания программного обеспечения.

10.4    Требования

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

10.4.2    Размер и сложность разработанного программного обеспечения удерживается на минимальном уровне.

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

10.4.4    Спецификация проектирования программного обеспечения включает:

a)    компоненты программного обеспечения, которые отслеживаются к архитектуре программного обеспечения и их уровню полноты безопасности;

b)    интерфейсы компонентов программного обеспечения со средой;

c)    интерфейсы между компонентами программного обеспечения;

d)    структуру данных;

e)    декомпозицию требований на компоненты;

f)    основные алгоритмы и последовательность;

g)    диаграммы.

10.4.5    Спецификации проекта модуля программного обеспечения рассматривают (одну спецификацию проекта модуля программного обеспечения на модуль):

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

b)    их детальные интерфейсы со средой и другие модули с детальными вводами и выводами;

c)    их уровень полноты безопасности;

d)    детальные алгоритмы и структуры.

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

10.4.6    Каждый модуль программного обеспечения должен быть считываемым, понятным и контроле пригодным.

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

15

обеспечения в течение всего жизненного цикла программного обеспечения.

10.4.8    Где применимо используются инструменты автоматического контроля и инструменты комплексного развития. Это приминает во внимание нужды лица, проверяющего подлинность и лица, подтверждающего подлинность.

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

a)    «Сертификат подтверждения подлинности» по отношению к признанному национальному/международному стандарту;

b)    отчет об оценке, который подробно приводит доводы относительно его целевого использования;

c)    процесс, основанный на контроле резервной подписи, который обеспечивает выявление ошибок трансляции.

10.4.10    Выбранный язык должен соответствовать соответствующим требованиям:

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

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

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

10.4.12    Стандарты кодирования разрабатываются и используются для разработки всего программного обеспечения. На них дается ссылка в плане гарантии качества программного обеспечения (см. пункт 15.4.5).

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

автор;

история конфигурации;

краткое описание.

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

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

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

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

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

c)    он должен быть в проверяемой форме;

d)    набор данных испытаний и их результаты регистрируются в машиночитаемой

СТ РК МЭК 62279 - 2007

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

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

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

a)    абстракция, модульность и другие свойства, которые контролируют сложность;

b)    четкое и точное выражение следующего:

- функциональность;

информационный поток между компонентами;

определение последовательности информации, связанной со временем;

согласованность;

структура и свойства данных;

c)    человеческое восприятие;

d)    проверка и подтверждение подлинности.

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

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

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

a)    прослеживаемость требований к проекту или другим объектам, выполняющим

его;

b)    прослеживаемость объектов проектирования к объектам реализации, которые подтверждают их примерами.

11 Проверка подлинности и испытание программного обеспечения

11.1    Задача

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

11.2    Входящие документы

1)    Спецификации требований системы;

2)    Спецификации требований безопасности программного обеспечения;

3)    Спецификации требований программного обеспечения;

4)    Спецификации требований к испытаниям программного обеспечения;

5)    Спецификации архитектуры программного обеспечения;

6)    Спецификации проектирования программного обеспечения;

7)    Спецификации проекта модуля программного обеспечения;

8)    Спецификации модуля испытаний программного обеспечения;

9)    Код источника программного обеспечения и подтверждающая документация;

17

СТ РК МЭК 62279 - 2007

Содержание

1.    Область применения.............................................................................................. 1

2.    Нормативные ссылки.............................................................................................. 2

3.    Термины и определения....................................................................... 2

4.    Задачи и согласованность................................................................... 4

5.    Уровни полноты безопасности программного обеспечения.......................... 5

6.    Персонал и ответственность............................................................... 6

7.    Вопросы жизненного цикла и документация.......................................... 8

8.    Спецификация требований программного обеспечения............................. 11

9.    Архитектура программного обеспечения............................................... 12

10    Проектирование и внедрение программного обеспечения.......................... 14

11.    Проверка подлинности и испытание программного обеспечения................ 17

12.    Интеграция программного обеспечения/аппаратного оборудования............... 20

13.    Подтверждение подлинности программного обеспечения.......................... 22

14.    Оценка программного обеспечения....................................................... 24

15.    Гарантия качества программного обеспечения.................................. 25

16.    Обслуживание программного обеспечения............................................ 27

17.    Системы сконфигурированные данными прикладной программы.................... 29

Приложение А. Критерии выбора методов и мер............................................. 38

Приложение Б. Библиография методов.......................................................... 49

Приложение. Библиография....................................................................... 86

III

10)    План гарантии качества программного обеспечения;

11)    Отчет испытания модуля программного обеспечения.

11.3    Выходящие документы

1)    План проверки подлинности программного обеспечения;

2)    Отчет о требованиях проверки подлинности программного обеспечения;

3)    Отчет проверки подлинности архитектуры и проекта программного обеспечения;

4)    Отчет по модулю проверки подлинности программного обеспечения;

5)    Отчет по проверке подлинности кода источника программного обеспечения;

6)    План испытания интеграции программного обеспечения;

7)    Отчет испытания интеграции программного обеспечения.

11.4    Требования

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

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

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

11.4.4    План проверки подлинности программного обеспечения рассматривает следующее:

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

b)    выбор и использование контрольной аппаратуры программного обеспечения;

c)    выбор и документация деятельности по проверке подлинности;

d)    оценка полученных результатов проверки подлинности;

e)    оценка требований надежности;

1) роли и ответственность вовлеченных в процесс испытания;

g) степень тестового покрытия, требуемая к достижению.

11.4.5    План испытания интеграции программного обеспечения документирует следующее:

a)    набор тестовых данных и данные испытаний;

b)    типы испытаний, подлежащих выполнению;

c)    режимы испытаний, инструменты, конфигурация и программы;

d)    критерии испытаний, на основе которых будет обосновываться завершение испытания.

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

11.4.7    Проверка подлинности проводится независимой стороной до степени требуемой уровнем полноты безопасности программного обеспечения, как определено на Рисунке 5.

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН

ПОДВИЖНОЙ СОСТАВ ЖЕЛЕЗНЫХ ДОРОГ Системы связи, сигнализация и обработки данных Программное обеспечение для систем управления и защиты на железной дороге

Дата введения 2008.07.01.

1 Область применения

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

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

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

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

-    Прикладное программирование;

-    Операционные системы;

-    Вспомогательные инструменты;

-    Встроенное программное обеспечение.

Прикладное программирование состоит из программирования высокого уровня, программирования низкого уровня и целевого программирования (например, многозвенная логическая схема Логических программируемых контроллеров).

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

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

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

Издание официальное

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

2    Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие стандарты:

СТ РК 2.4-2000 ГСИ РК. Поверка средств измерений. Организация и порядок проведения.

СТ РК 2.12-2000 ГСИ РК. Система калибровки Республики Казахстан. Калибровка средств измерений. Организация и порядок проведения.

СТ РК ИСО 9000-2000 Системы менеджмента качества. Основные положения и словарь.

СТ РК ИСО 9001-2001 Системы менеджмента качества. Требования.

СТ РК ИСО/МЭК 17025-2001 Общие требования к компетентности испытательных и калибровочных лабораторий.

СТ РК ИСО МЭК 62280-1-2007 Подвижной состав железных дорог. Системы связи, сигнализации и обработки данных. Часть 1. Обеспечение безопасности связи в закрытых системах передачи.

СТ РК ИСО МЭК 62280-2-2007 Подвижной состав железных дорог. Системы связи, сигнализации и обработки данных. Часть 2. Обеспечение безопасности связи в открытых системах передачи.

3    Термины и определения

В настоящем стандарте применены термины по [1], [2], [3], [4], а также следующие термины с соответствующими определениями:

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

3.2    Оценщик: Лицо или агент, назначенный для проведения оценки.

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

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

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

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

3.7    Элемент: Часть продукта которая была определена как основная единица или структурный элемент. Элемент может быть простым или сложным.

3.8    Ошибка:    Отклонение от заданного проекта, что может привести к

непредусмотренному поведению системы или сбою.

СТ РК МЭК 62279 - 2007

3.9    Сбой; Отклонение от заданных рабочих показателей системы. Сбой представляет собой последствие неисправности или ошибки в системе.

3.10    Неисправность; Ненормальный режим, который может привести к ошибке или сбою системы. Неисправность может быть случайной или системной.

3.11    Предотвращение неисправностей; Использование проектных методов, которые подразумевают предотвращение неисправностей во время проектирования и разработки системы.

3.12    Устойчивость к ошибкам; Встроенные возможности системы по обеспечению постоянного правильного предоставления услуги как задано при ограниченном количестве неисправностей аппаратного оборудования или программного обеспечения.

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

3.14    Комплексное программное обеспечение:    Комплексное    программное

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

3.15    Внедренец; Один или более лиц, назначенных Управлением по проектированию для трансформации определенных проектов в их физическую форму.

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

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

3.18    Надежность: Способность единицы выполнять заданную функцию при определенных условиях за определенный период времени.

3.19    Прослеживаемость требований: Задачей прослеживаемости требований является обеспечение того, чтобы требования могли быть показаны как соответственно выполненные.

3.20    Риск:    Комбинация    частоты или вероятности и последовательность

определенных опасных случаев.

3.21    Безопасность: Свобода от неприемлемых уровней риска.

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

3.23    Программное обеспечение, связанное с безопасностью: Программное обеспечение, ответственное за безопасность.

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

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

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

обслуживания.

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

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

3.28    Уровень    полноты    безопасности программного    обеспечения:

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

3.29    Уровень полноты безопасности системы: Номер, который указывает требуемую степень достоверности для того, чтобы система соответствовала указанным требованиям безопасности.

3.30    Прослеживаемость: Уровень создания связи между двумя или более

продуктами    процесса    развития,    особенно теми, у которых    есть связь

предшественника/преемника или главного/второстепенного по отношению друг к другу.

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

3.32    Лицо, подтверяедающее подлинность: Лицо или агент, назначенный для подтверждения подлинности.

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

3.34    Лицо, проверяющее подлинность: Лицо или агент, назначенный для проверки подлинности.

4 Задачи и согласованность

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

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

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

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

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

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

СТ РК МЭК 62279 - 2007

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

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

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

5 Уровни полноты безопасности программного обеспечения

5.1    Задачи

Описать задачу уровней полноты безопасности программного обеспечения для программного обеспечения.

5.2    Требования

5.2.1 Согласно [5], [6] следующее подлежит разработке:

Спецификации требований системы,

Спецификации требовании системы в отношении безопасности,

Описание архитектуры системы,

План безопасности системы,

Что включает:

Функции безопасности;

Конфигурацию или архитектуру системы;

Требования в отношении надежности аппаратного обеспечения;

Требования полноты безопасности.

Уровень полноты безопасности программного обеспечения будет приведен в ходе прохождения общего процесса получения уровня полноты безопасности, заданного в [5].

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

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

Риски, которые могут быть приняты во внимание - это те, которые связанны со следующими последствиями риска:

Гибель человека или людей;

Травмы или заболеванию людей;

Экологическое загрязнение; и Потеря или повреждение собственности.

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

5

Уровень полноты безопасности программного обеспечения	Описание полноты безопасности программного обеспечения
4	Очень высокий
3	Высокий
2	Средний
1	Низкий
0	Не связанный с безопасностью

5.2.6 Уровень полноты безопасности программного обеспечения должен быт задан в спецификациях требований программного обеспечения (пункт 8). Если разные компоненты программного обеспечения имеют разные уровни полноты безопасности программного обеспечения, то он должны быть заданы в спецификациях архитектуры программного обеспечения (пункт 9).

6 Персонал и ответственность

6.1    Задачи

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

6.2    Требования

Поставщик и/или разработчик и потребитель должны реализовать соответствующие части СТ РК ИСО 9001 согласно руководств.

За исключением случаев, когда уровень полноты безопасности программного обеспечения, процесс безопасности должен реализовываться под контролем соответствующей организации по безопасности, которая соответствует подпункту «Организации по безопасности» пункта «Свидетельства безопасного управления» [7].

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

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

Обоснование, содержащееся в пункте 6.2.4 регистрируется в Плане гарантии качества программного обеспечения и, соответственно, включает свидетельства компетентности в следующих областях:

a)    проектирование соответствующее области применения;

b)    программное проектирование;

c)    проектирование компьютерных систем;

d)    проектирование безопасности;

e)    правовая и нормативная структура.

Назначается независимый оценщик программного обеспечения.

См. Также 6.2.10 и 14.4.1.

Оценщик получает полномочия на проведение оценки программного обеспечения.

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

СТ РК МЭК 62279 - 2007

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

Постановщик/внедренец,    лицо,    проверяющее    подлинность    и    лицо,

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

При 0 уровне полноты безопасности программного обеспечения:

Ограничений не существует;

Постановщик/внедренец,    лицо,    проверяющее    подлинность    и    лицо,

подтверждающее подлинность все могут быть одним лицом.

При 1 и 2 уровне полноты безопасности программного обеспечения:

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

При 3 и 4 уровне полноты безопасности программного обеспечения существует 2 разрешенные схемы.

Лицо, проверяющее подлинность и лицо, подтверждающее подлинность могут быть одним лицом, но они не могут быть постановщиком/внедренцем. Кроме того, лицо, проверяющее подлинность и лицо, подтверждающее подлинность не все отчитываются через менеджера проекта, так как делают постановщик/внедренец, они имеют полномочия предотвращать выпуск продукции.

Постановщик/внедренец, лицо, проверяющее подлинность и лицо, подтверждающее подлинность    все должны быть отдельными    лицами.

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

6.2.9    Стороны, ответственные за разные пункты приведены ниже:

Спецификации требований программного обеспечения (пункт 8)- постановщик.

Спецификации к требованиям испытаний программного обеспечения (пункт 8)-

лицо, подтверждающее подлинность.

Архитектура программного обеспечения (пункт 9) - постановщик.

Проектирование и разработка программного обеспечения (пункт 10)    -

постановщик.

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

Интеграция программного обеспечения/Аппаратного оборудования (пункт 12) -постановщик.

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

Оценка программного обеспечения (пункт 14) - оценщик,

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

Быть уполномочен управлением по безопасности;

Быть полностью независимым от группы проекта;

Напрямую отчитываться управлению по безопасности.

7