УДК 629.4.067:004.422.8(083.74X476)    МКС 45.060    КП    06    ЮТ

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

Предисловие

Цели, основные принципы, положения по государственному регулированию и управлению в области технического нормирования и стандартизации установлены Законом Республики Беларусь «О техническом нормировании и стандартизации».

1    ПОДГОТОВЛЕН научно-производственным республиканским унитарным предприятием «Белорусский государственный институт стандартизации и сертификации» (БелГИСС)

ВНЕСЕН Госстандартом Республики Беларусь

2    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ постановлением Госстандарта Республики Беларусь от 27 апреля 2011 г. № 19

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

Международный стандарт разработан техническим комитетом по стандартизации IE С/ТС 9 «Электрическое оборудование и системы для железных дорог» Международной электротехнической комиссии (IEC).

Перевод с английского языка (еп).

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

В разделе «Нормативные ссылки» и тексте стандарта ссылки на международные и европейский стандарты актуализированы.

Сведения о соответствии государственных стандартов ссылочным международным стандартам приведены в дополнительном приложении Д.А.

Степень соответствия - идентичная (ЮТ)

4    ВВЕДЕН ВПЕРВЫЕ

© Госстандарт. 2011

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

Издан на русском языке

СТБ IEC 62279-2011

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

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

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

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

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

7.2.10    Связь между различными документами, описанными в настоящем разделе, может быть также определена через таблицу документальной перекрестной ссылки. Для каждого из документов, перечисленных в графе «Документы», стадия и раздел, связанные с его созданием, указаны по горизонтали и вертикали относительно ячейки, содержащей символ «|». Стадии, на которых он используется. указаны по вертикали относительно ячеек, отмеченных символом «♦». Номер раздела или другая ссылка на определение документа указаны в графе «Где определено». Если указан номер раздела, следующие разделы также необходимо проверить, так как они могут содержать более подробную информацию. Следует отметить, что ссылка на план управления конфигурацией ПО приведена в скобках, так как в данном разделе просто дана ссылка на ISO 9001.

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

Раздел 8 9 10 11 12 13 14 15 16 Документы Где определено Заголовок SRS SA SDD SVer S/HI SVal Ass Q Ma Стадии (•) = параллельно с другими стадиями Входы системы (вход из разра-ботки) ♦ ♦ ♦ Спецификация требований к системе EN 50129 (В.2.3) ♦ ♦ ♦ ♦ ♦ ♦ Спецификация требований безопасности системы EN 50129 (В.2.4) ♦ ♦ Описание архитектуры системы EN 50129 (В-2.1) План обеспечения безопасности системы EN 50129 IEC 62278 Планирование поп ♦ ♦ ♦ ♦ ♦ ♦ 1 План обеспечения качества ПО 15.4.3 ♦ ♦ 1 План управления конфигурацией ПО 15.4.2 1 ♦ ♦ План верификации ПО 11.4.1 1 ♦ ♦ План интеграции ПО 11.4.5 1 ♦ ♦ План интеграции ПО и аппаратных средств 12.4.1 1 ♦ План валидации ПО 13.4.3

7

Раздел	8	9	10	11	12	13	14	15	16	Документы	Где определено
Заголовок	SRS	SA	SDD	SVer	S/HI	SVal	Ass	Q	Ma
Стадии (*) = параллельно с другими стадиями
							♦		1	План сопровождения ПО	16.4.3
										План подготовки данных	17.4.2.1
										План проверки данных	17.4.2.4
Требования к поп	■	♦	♦	♦	♦	♦	♦			Спецификация требований к ПО	8.4.1
										Спецификация прикладных требований	17.4.1.1
	1			♦	♦	♦	♦			Спецификация требований к тестированию ПО	8.4.13
				1						Отчет о верификации требований к ПО	11.4.1
Разработка ПО		1	♦	♦	♦	♦	♦			Спецификация архитектуры ПО	9.4.1
			1	♦	♦	♦	♦			Спецификация проекта ПО	10.4.3
				1						Отчет о верификации архитектуры и проекта ПО	11.4.12
Разработка модуля ПО			1	♦	♦	♦	♦			Спецификация проекта модуля ПО	10.4.3
			1	♦	♦	♦	♦			Спецификация испытаний модуля ПО	10.4.14
				1						Отчет о верификации модуля ПО	11.4.13
Кодирование			1	♦	♦	♦	♦			Исходный код ПО
				1		♦	♦			Отчет о верификации исходного кода ПО	11.4.14
Тестирование модуля			1	♦						Отчет об испытаниях модуля ПО	10.4.14
Интеграция ПО				1						Отчет об испытаниях интеграции ПО	11.4.15
										Отчет об испытаниях данных	17.4.2.4
Интеграция ПО и аппаратных средств					1					Отчет об испытаниях интеграции ПО и аппаратных средств	12.4.8
Валидация (*)						1				Отчет о валидации ПО	13.4.10

СТБ IEC 62279-2011

Раздел 8 9 10 11 12 13 14 15 16 Документы Где определено Заголовок SRS SA SDD SVer S/H 1 SVal Ass Q Ma Стадии (*) = параллельно с другими стадиями Оценка (*) 1 Отчет об оценке ПО 14.4.9 Со про вожде-ние 1 Записи об изменениях 16.4.9 1 Записи об обслуживании ПО 16.4.8

8 Спецификация требований к ПО

8.1    Цель

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

8.1.2    Описание спецификации требований к тестированию ПО.

8.2    Входные документы

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

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

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

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

8.3    Выходные документы

1)    Спецификация требований к ПО.

2)    Спецификация требований к тестированию ПО.

8.4    Требования

8.4.1    В спецификации требований к ПО должны быть установлены требования к свойствам разрабатываемого ПО, а не к порядку его разработки. Эти свойства определены в ISO/IEC 9126 (за исключением безопасности) и включают:

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

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

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

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

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

-    компактность.

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

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

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

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

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

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

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

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

9

СТБ1ЕС 62279-2011

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

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

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

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

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

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

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

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

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

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

Ш) критерии приемки, в том числе рабочие характеристики и аспекты качества.

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

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

9 Архитектура ПО

9.1    Цели

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

9.1.2    Анализ требований, установленных для ПО архитектурой системы.

9.1.3    Определение и оценка важности взаимодействия между аппаратным оборудованием и ПО в части безопасности.

9.1.4    Выбор метода разработки, если он не был определен ранее.

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

1)    Спецификация требований к ПО.

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

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

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

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

Спецификация архитектуры ПО.

9.4    Требования

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

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

9.4.3    В спецификации архитектуры ПО должна быть установлена, оценена и детально описана значимость взаимодействия аппаратных средств и ПО. Согласно требованиям IEC 62278 и EN 50129, результаты предварительных исследований взаимодействия между аппаратными средствами и ПО должны содержаться в спецификации требований безопасности системы.

СТБ IEC 62279-2011

9.4.4    В спецификации архитектуры ПО должны быть установлены все элементы ПО и для этих элементов определено:

i) являются ли эти элементы новыми, существующими или лицензионными;

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

iii) уровень полноты безопасности элемента ПО.

9.4.5    На использование готового коммерческого ПО накладываются следующие ограничения:

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

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

iii)    при уровне полноты безопасности ПО 3 или 4 должны быть приняты следующие меры предосторожности:

a)    готовое коммерческое ПО должно быть подвергнуто тестированию при валидации;

b)    должен быть проведен анализ возможных отказов готового коммерческого ПО;

c)    должна быть разработана стратегия выявления отказов готового коммерческого ПО и защиты системы от этих отказов;

d)    стратегия защиты должна быть подвергнута тестированию при валидации;

e)    должны быть созданы и оценены журналы регистрации ошибок;

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

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

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

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

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

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

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

ii)    прослеживаемой по отношению к спецификации требований к ПО.

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

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

10 Разработка и внедрение ПО

10.1    Цели

10.1.1    Разработка и внедрение ПО с заданным уровнем полноты безопасности согласно спецификации требований к ПО и спецификации архитектуры ПО.

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

11

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    Спецификация проекта ПО должна включать описание:

i) элементов ПО, установленных в архитектуре ПО и требованиях к их уровню полноты безопасности;

и) внешних интерфейсов элементов ПО;

iii)    интерфейсов между элементами ПО;

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

v)    деления требований на элементы;

vi)    основных алгоритмов и упорядочивания;

vii)    диаграмм.

10.4.5    В спецификации проекта модуля ПО должны быть описаны (одна спецификация проекта модуля ПО на каждый модуль):

i)    идентификация всех низших элементов ПО (в настоящем стандарте называемых модулями), прослеживаемых к верхнему уровню;

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

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

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

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

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

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

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

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

О сертификат соответствия признанному государственному/международному стандарту;

ii)    отчет об оценке с подробным описанием его пригодности к применению по назначению;

iii)    механизм избыточного контроля, который обеспечивает выявление ошибок трансляции.

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

i)    иметь характеристики, позволяющие определять ошибки программирования;

ii)    иметь характеристики, подходящие для метода разработки.

СТБ IEC 62279-2011

Содержание

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

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

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

4    Цели и соответствие.............................................................................................................................4

5    Уровни полноты безопасности ПО.......................................................................................................4

5.1    Цель..................................................................................................................................................4

5.2    Требования......................................................................................................................................4

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

6.1    Цель..................................................................................................................................................5

6.2    Требования......................................................................................................................................5

7    Жизненный цикл и документация.........................................................................................................6

7.1    Цели..................................................................................................................................................6

7.2    Требования......................................................................................................................................6

8    Спецификация требований к ПО..........................................................................................................9

8.1    Цель..................................................................................................................................................9

8.2    Входные документы........................................................................................................................9

8.3    Выходные документы......................................................................................................................9

8.4    Требования......................................................................................................................................9

9    Архитектура ПО...................................................................................................................................10

9.1    Цели................................................................................................................................................10

9.2    Входные документы......................................................................................................................10

9.3    Выходные документы....................................................................................................................10

9.4    Требования....................................................................................................................................10

10    Разработка и внедрение ПО.............................................................................................................11

10.1    Цели..............................................................................................................................................11

10.2    Входные документы....................................................................................................................12

10.3    Выходные документы..................................................................................................................12

10.4    Требования..................................................................................................................................12

11 Верификация и тестирование ПО....................................................................................................14

11.1    Цель..............................................................................................................................................14

11.2    Входные документы....................................................................................................................14

11.3    Выходные документы..................................................................................................................14

11.4    Требования..................................................................................................................................14

12    Интеграция ПО и аппаратных средств............................................................................................16

12.1    Цели..............................................................................................................................................16

12.2    Входные документы....................................................................................................................16

12.3    Выходные документы..................................................................................................................16

12.4    Требования..................................................................................................................................16

СТБ1ЕС 62279-2011

13    Валидация ПО....................................................................................................................................17

13.1    Цель..............................................................................................................................................17

13.2    Входные документы....................................................................................................................17

13.3    Выходные документы..................................................................................................................17

13.4    Требования..................................................................................................................................17

14    Оценка ПО..........................................................................................................................................18

14.1    Цель..............................................................................................................................................18

14.2    Входные документы....................................................................................................................18

14.3    Выходные документы..................................................................................................................18

14.4    Требования..................................................................................................................................18

15    Обеспечение качества ПО................................................................................................................19

15.1    Цели..............................................................................................................................................19

15.2    Входные документы....................................................................................................................19

15.3    Выходные документы..................................................................................................................19

15.4    Требования..................................................................................................................................19

16    Обслуживание ПО.............................................................................................................................21

16.1    Цель..............................................................................................................................................21

16.2    Входные документы....................................................................................................................21

16.3    Выходные документы..................................................................................................................21

16.4    Требования..................................................................................................................................21

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

17.1    Цели..............................................................................................................................................22

17.2    Входные документы....................................................................................................................22

17.3    Выходные документы..................................................................................................................22

17.4    Требования..................................................................................................................................22

17.4.1    Жизненный цикл подготовки    данных...................................................................................22

17.4.2    Средства и методы подготовки    данных..............................................................................23

17.4.3    Разработка ПО.......................................................................................................................23

Приложение А (обязательное) Критерии выбора методов и мероприятий......................................30

Приложение В (справочное) Библиография методов.........................................................................38

Приложение Д А (справочное) Сведения о соответствии государственных стандартов

ссылочным международным    стандартам......................................................................76

IV

СТБ IEC 62279-2011

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

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

Чыгунка

С1СТЭМЫ СУВЯ31, С1ГНАЛ13АЦЫ1 I АПРАЦОУК1 ДАНЫХ Праграмнае забеспячэнне для с!стэм юравання i засцяроп на чыгунцы

Railway applications Communications, signalling and processing systems Software for railway control and protection systems

Дата введения 2011-08-01

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

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

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

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

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

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

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

-    средства поддержки;

-    встроенное ПО.

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

1.5    В настоящем стандарте также описано использование стандартного готового коммерческого ПО.

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

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

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

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

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

IEC 62278:2002 Железные дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопригодности и удобства обслуживания

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

I EC 62280-1:2002 Железные дороги. Системы связи, сигнализации и обработки данных. Часть 1. Экстренная связь в закрытых системах передачи

IEC 62280-2:2002 Железные дороги. Системы связи, сигнализации и обработки данных. Часть 2. Экстренная связь в открытых системах передачи

ISO 9000:2000 Системы менеджмента качества. Основные положения и словарь ISO 9000-3:1997 Стандарты в области управления качеством и обеспечения качества. Часть 3. Руководящие указания по применению стандарта ИСО 9001:1994 для разработки, поставки, установки и обслуживанию программного обеспечения

ISO 9001:1994 Система качества. Модель для обеспечения качества при проектировании, разработке. производстве, монтаже и обслуживании

EN 50129:2003 * Железные дороги. Системы связи, сигнализации и обработки данных. Безопасность электронных систем сигнализации

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

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

IEC 9000:2000 Системы менеджмента качества. Основные положения и словарь IEC 60050-191:1990 Международный электротехнический словарь. Глава 191. Надежность и качество услуг

IEEE STD 610.12 Глоссарий терминов технологий программирования

ISO/IEC 2382 (все части) Информационные технологии. Словарь

ISO/IEC 9126 (все части) Разработка программного обеспечения. Качество продукции

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

3.2    эксперт (assessor): Лицо или представитель, назначенный для проведения оценки.

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

3.4    готовое коммерческое ПО (COTS, commercial off-the-shelf software): Программное обеспечение, разработанное в соответствии с потребностями рынка, доступное на платной основе, пригодность которого к использованию по назначению подтверждается широким кругом покупателей.

3.5    отдел разработок (design authority): Организация, орган или подразделение, ответственные за разработку проектного решения для выполнения установленных требований, контроль за дальнейшей разработкой системы и вводом ее в эксплуатацию в конкретной среде.

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

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

3.8    ошибка (error): Отклонение от заданного проектного решения, которое может привести к непредсказуемому поведению или отказу системы.

3.9    отказ (failure): Отклонение от заданных рабочих характеристик системы, представляющее собой последствие ошибки или сбоя в системе.

3.10    сбой (fault): Ненормальный режим, который может привести к ошибке или отказу системы. Сбой может быть случайным или систематическим.

3.11    предотвращение сбоев (fault avoidance): Применение методов разработки, целью которых является предотвращение появления сбоев в ходе разработки и построения системы.

3.12    устойчивость к сбоям (fault tolerance): Предусмотренная способность системы к обеспечению постоянного корректного предоставления услуги согласно установленным требованиям при ограниченном количестве сбоев программного обеспечения и аппаратных средств.

Действует взамен ENV 50129:1998.

СТБ IEC 62279-2011

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

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

3.15    исполнитель (implementer): Одно или несколько лиц, назначенных отделом разработок для физической реализации конкретных решений.

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

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

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

3.19    прослеживаемость требований (requirements traceability): Обеспечение того, чтобы требования могли быть представлены как выполненные должным образом.

3.20    риск (risk): Комбинация частоты, или вероятности, и последствий определенного опасного события.

3.21    безопасность (safety): Отсутствие неприемлемых уровней риска.

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

3.23    ПО, связанное с безопасностью (safety-related software):Программное обеспечение, выполняющее функции обеспечения безопасности.

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

Примечание - ПО не зависит от используемых носителей информации.

3.25    жизненный цикл ПО (software life cycle): Деятельность, выполняемая в течение периода времени, который начинается от формирования требований к созданию программного обеспечения и заканчивается тогда, когда программное обеспечение больше непригодно к эксплуатации. Жизненный цикл программного обеспечения, как правило, включает стадии установления требований, разработки. тестирования, интеграции, установки и обслуживания.

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

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

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

3.29    уровень полноты безопасности системы (system safety integrity level): Число, которое указывает степень достоверности соответствия системы установленным требованиям безопасности.

3.30    прослеживаемость (traceability): Степень связи между двумя или более изделиями в процессе разработки, особенно между теми, которые состоят в отношениях предыдущего с последующим или главного со второстепенным.

3.31    валидация (validation): Подтверждение посредством проведения анализа и тестирования того, что изделие во всех отношениях соответствует установленным требованиям.

3.32    лицо, ответственное за валидацию (validator): Лицо или представитель, назначенные для проведения валидации.

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

3.34    лицо, ответственное за верификацию (verifier): Лицо или представитель, назначенные для проведения верификации.

3

4    Цели и соответствие

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

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

4.3    Если требование сопровождается словами «в степени, требуемой уровнем полноты безопасности ПО», это означает, что для выполнения этого требования может быть применен ряд методов и мер.

4.4    Если применимы требования 4.3, должны быть использованы приведенные в настоящем стандарте таблицы для выбора методов и мер, соответствующих уровню полноты безопасности ПО.

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

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

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

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

5    Уровни полноты безопасности ПО

5.1    Цель

Описание присвоения уровней полноты безопасности ПО.

5.2    Требования

5.2.1    Согласно требованиям IEC 62278 и EN 50129 необходимо разработать:

-    спецификацию требований к системе;

-    спецификацию требований безопасности системы;

-    описание архитектуры системы;

-    план обеспечения безопасности системы, что включает:

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

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

-    требования надежности аппаратных средств;

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

Уровень полноты безопасности ПО должен быть установлен в ходе общего процесса определения уровня полноты безопасности согласно IEC 62278.

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

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

5.2.4    Должны быть учтены риски, влекущие:

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

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

-    экологическое загрязнение;

-    утрату или ущерб имуществу.

4

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

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

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

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

6.1    Цель

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

6.2    Требования

6.2.1    Поставщик и/или разработчик и потребитель как минимум должны соблюдать требования соответствующих частей ISO 9001 согласно руководящим указаниям, приведенным в ISO 9000-3.

6.2.2    Реализация процесса обеспечения безопасности должна осуществляться под контролем соответствующей организации по безопасности, которая отвечает требованиям подраздела «Организация по безопасности» раздела «Обеспечение управления безопасностью» EN 50129. Данное требование не применяется, если ПО имеет уровень полноты безопасности 0.

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

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

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

i) технические знания, соответствующие сфере деятельности;

И) разработка ПО;

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

iv)    технические знания в области средств обеспечения безопасности;

v)    правовая и нормативная база.

6.2.6    Должен быть назначен независимый эксперт ПО (см. также 6.2.10 и 14.4.1).

6.2.7    Эксперт должен быть уполномочен проводить оценку ПО.

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

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

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

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

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

5

На уровнях полноты безопасности ПО 3 и 4 существует два варианта:

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

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

6.2.9    За выполнение требований разделов настоящего стандарта ответственны:

-    спецификация требований к ПО (раздел 8) - разработчик;

-    спецификация требований к тестированию ПО (раздел 8) - лицо, ответственное за валидацию;

-    архитектура ПО (раздел 9) - разработчик;

-    проектирование и разработка ПО (раздел 10) - разработчик;

-    верификация и тестирование ПО (раздел 11)- лицо, ответственное за верификацию;

-    интеграция ПО и аппаратных средств (раздел 12) - разработчик;

-    валидация ПО (раздел 13) - лицо, ответственное за валидацию;

-    оценка ПО (раздел 14) - эксперт.

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

-    быть уполномочен отделом обеспечения безопасности;

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

-    напрямую подчиняться отделу обеспечения безопасности.

7 Жизненный цикл и документация

7.1    Цели

7.1.1    Структурирование разработки ПО на определенные фазы и виды деятельности.

7.1.2    Документальное оформление всей информации, относящейся к ПО, на протяжении жизненного цикла ПО.

7.2    Требования

7.2.1    Должна быть выбрана модель жизненного цикла для разработки ПО. Она должна быть подробно описана в плане обеспечения качества ПО согласно разделу 15. В качестве примера две возможные модели жизненного цикла приведены на рисунках 3 и 4.

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

7.2.3    Все виды деятельности на конкретной стадии жизненного цикла ПО должны быть определены до ее начала. Каждая стадия жизненного цикла ПО должна делиться на простые задачи с четко определенными входными и выходными данными и видом деятельности для каждой из задач.

7.2.4    В плане обеспечения качества ПО должны быть описаны все необходимые действия по верификации и отчеты.

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

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

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

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

b)    он не должен противоречить предшествующему документу;

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