Гост р 51904 2002 кратко

Обновлено: 04.07.2024

Мы всегда ЕСПД обходились (и то с большими оговорками)
А от ГОСТА можно отмазаться, заявив, что у вас не система реального времени, следовательно он к вам не применим.

У нас к ним другой подход.
У нас устройство с микроконтроллером внутри вычислительной машиной не является.
Это просто законченное функциональное устройство, выполняющее некий набор функций, заданный в ТЗ. И вся КД на него выполняется по ЕСКД, как если бы этот же функционал был реализован внутри чисто аппаратно.
Например, сигнальный маяк для самолёта. Его дело коротко помаргивать раз в 3-4 секунды. Функционал его может быть реализован как чисто аппаратно, так и програмно-аппаратно - на микроконтроллере или ПЛИС. Но наличие внутри микроконтроллера не делает его вычислительной машиной. Зачем такому устройству документация по ЕСПД? Что писать в руководстве системного программиста, программиста или руководстве оператора?
Другой пример - сигнализация для автомобиля. И в центральном блоке и в брелках стоят микроконтроллеры. Это делает их вычислительными машинами? Или это все-таки устройства выполняющие некий конечный набор простых функций? Какие эксплуатационные документы на сигнализацию выпускать? По ЕСКД или по ЕСПД? И таких примеров куча: микроволновка, стиральная машина, кофемашина, телевизор, домофон, электронный звонок, электросчётчик, детская игрушка с кнопками, издающая разные звуки при нажатии и пр.

В итоге мы с нашими заказчиками, ВП и нормоконтролем решили этими глупостями не заниматься. Работаем по ЕСКД. Считаем все наши приборы просто устройствами, а не вычислительными машинами.
ЕСПД у нас появляется лишь при наличии универсальной ЭВМ (сервера, десктопа, ноутбука и т.п.), где можно запускать разные программы. Там это действительно к месту.

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

А ещё ведь к прошивке могут прикладываться ещё различные служебные файлы, которые например загружаются в РПЗУ отдельно. Неужели Вы всё это прописываете в конструкторской СПКД ?

Мы например файлы прошивки вместе с номером версии и CRC прописываем именно в спецификации программного обеспечения (СППО), выполненной по ЕСПД, а уже саму СППО включаем в СПКД.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

Укажите номер ГОСТа (или иного регламентирующего документа) по которому вы выполняете СППО? Что-то ничего такого по названию я не нашёл.

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

Хэш бинарника прошивки прописывается в удостоверяющем листе (ТБ-УЛ) на таблицу кодов (ТБ). ТБ - это бинарный файл на носителе данных (диске), т.е. в терминах ЕСКД - электронный документ (по ГОСТ 2.051-2013). ТБ-УД - удостоверяющий лист - бумажка формата А5 с живыми подписями, именем файла и его хэшем (см. п. 4.15 ГОСТ 2.051-2013).
У наших заказчиков позиция простая: после присвоения КД на прибор литеры О1 и приёмки (закрытия) ОКР никаких изменений КД не допускается. Ни по железу, ни по ПО/прошивкам. Всё ПО/прошивки заливаются в приборы на заводе-изготовителе и не подлежат модификации/перезаливке в процессе эксплуатации.
Вобщем, подход, как к чисто "железному" прибору на основе жесткой логики.
Доступ к прошивке (чтению, изменению, программированию) возможен лишь в условиях завода-изготовителя при вскрытии корпуса прибора. Это этапы изготовления, ремонта и утилизации. Это требование РД заказчика на наш тип аппаратуры (ВТ 1-й группы стратегической значимости).

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

Зачем такому устройству документация по ЕСПД? Что писать в руководстве системного программиста, программиста или руководстве оператора?

Согласно ГОСТ 19.101-77 обязательным является только текст программы (или спецификация на комплекс программ).
Все остальное определяется на этапе разработки КД (в ГОСТе на этапе разработки ТЗ, по факту никогда не требуется).
Поэтому данный вариант проще нежели ГОСТ Р 51904-2002.

Есть, конечно. Это ведь "бумажный" документ. Хранится в бумажном виде в архиве КД, плюс скан на сервере с прочей несекретной электронной КД. Если ТБ с грифом, то она хранится в архиве секретной КД в отделе безопасности на диске (CD-R, DVD-R), а ТБ-УЛ там же в сейфе с бумажной секретной КД. Электронного архива для секретной КД в виде сервера и сети у нас нет. Начальнику ОБ этого не надо. Поэтому вся секретная электронная КД только на дисках.

Уточню свой вопрос:
1. У вас есть вид документа ТБ-УЛ? Или это опечатка в ТБ-УД (удостоверяющий лист) или ТБ-ЛУ (лист утверждения).
2. На мой взгляд необходимо и достаточно одного единственного бумажного документа на один электронный, будь то УД, ЛУ или, есть у нас ещё такое, МНЗ - ведомость документов на (магнитном, со старых ещё времён) носителе.
На ТБ для МК ЛУ мы не делаем, делаем УД. УД - стандартный лист А4 с рамкой и штампом по ГОСТ, с двумя комплектами подписей: первый в штампе, второй в табличке с файлами, и хешами удостоверяемых электронных документов (там подпись разраба, зам.ГК и ПЗ). Ещё есть МНЗ на носитель информации - просто листик с именами файлов, хешами, типами документов, и подписью того, кто изготовил носитель и МНЗ.
Отсюда я и не понял зачем нужен ТБ-УЛ.

1. Да, у нас есть бумажный конструкторский документ с кодом ТБ-УЛ. Что такое код документа ХХ-УЛ подробно расписано в ГОСТ 2.051-2013. См. п. 4.15 и приложение В. После прочтения этого документа вопросов остаться не должно. Это замена электронной подписи. Типа, полуэлектронный документооборот: сама КД электронная, но подписи к ней на бумаге.
ТБ-ЛУ у нас нет. Листы утверждения (ЛУ) мы делаем только на эксплуатационные документы: ПС, ФО, РЭ. А ТБ к ним не относится.
Вобщем, все, как вы и хотите: на каждый электронный конструкторский документ с кодом ХХ у нас имеется бумажный удостоверяющий лист с кодом ХХ-УЛ. Один УЛ на несколько документов у нас делать не принято.

Всё тот же ГОСТ 19.101-77. Вот смотрите, в этом документе в таблице 2 "Спецификация - состав программы и документация на неё".
Сама СППО выполняется по ГОСТ 2.106-96, т.е как и спецификация по ЕСКД.
Ведь ГОСТ 2.106-96 прямо говорит "Наличие тех или иных разделов определяется составом специфицируемого изделия." поэтому да, в спецификации прописывается состав программы и при необходимости документация на неё.
Сама программа состоит из файлов, и прописывая в спецификации состав программы, т.е её файлы Вы не можете обойтись без CRC, версии и т.д, иначе каким образом идентифицировать эти файлы?
Причём любая программа, будь то hex или exe выпускаются на диске, который хранится отдельно. То есть в спецификации Вы прописываете фактически состав диска, который используется при изготовлении платы, блока и т.д.
Соответственно на диск с текстом программы отдельно своя СП.
И диск это уже материальная вещь для производства.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

. Что такое код документа ХХ-УЛ подробно расписано в ГОСТ 2.051-2013. См. п. 4.15 и приложение В. После прочтения этого документа вопросов остаться не должно. Это замена электронной подписи. Типа, полуэлектронный документооборот: сама КД электронная, но подписи к ней на бумаге.

"полуэлектронный документооборот" - замечательное определение!
Ни в коем случае не оспаривая Вами описанный порядок, ЛУ в нашей системе получается лишним, дублирующим УД. Причём более правильным, на мой взгляд, является вариант с УЛ, если с УД здесь Вы опечатались:

ТБ-УД - удостоверяющий лист - бумажка формата А5 с живыми подписями, именем файла и его хэшем (см. п. 4.15 ГОСТ 2.051-2013).

Скажите, пожалуйста, ещё одну вещь: а что в системе "полуэлектронного документооборота" написано в СП на изделие, в которое входит ДЭ с ЛУ? Перечисляются ли имена файлов?
Для примера у нас в СП указывается сам "электронный документ" с именем файла и УД на него.

где Д99 - это оговоренный в СТП тип документа для исходных кодов прошивок, а исходники до 5 файлов перечисляются поимённо (main.c, lib.h, lib.c, fw.proj).

Последний раз редактировалось prostoRoman 2019-ноя-20 11:19, всего редактировалось 2 раза.

Государственный стандарт РФ ГОСТ Р 51904-2002
"Программное обеспечение встроенных систем. Общие требования к разработке и документированию"
(утв. постановлением Госстандарта России от 25 июня 2002 г. N 247-ст)

Дата введения 2003-07-01

1 РАЗРАБОТАН Государственным научно-исследовательским институтом авиационных систем с участием Научно-исследовательского института стандартизации и унификации

ВНЕСЕН Научно-исследовательским институтом стандартизации и унификации

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 июня 2002 г. N 247-ст

3 Стандарт подготовлен в развитие ГОСТ Р ИСО/МЭК 12207-99 "Информационная технология. Процессы жизненного цикла программных средств" с целью учета специфики разработки и документирования программного обеспечения встроенных систем реального времени

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

Откройте актуальную версию документа прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!

Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.

Государственный стандарт РФ ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" (утв. и введен в действие постановлением Госстандарта РФ от 25 июня 2002 г. N 247-ст)

Текст ГОСТа приводится по официальному изданию Госстандарта России, Москва, 2002 г.

Созданный специально для встроенных систем, ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем. Общие требования к разработке и документированию" регламентирует общие требования к разработке и документированию программного обеспечения. Во многом этот ГОСТ повторяет общеизвестные международные стандарты типа DO-178B, принятые при сертификации авиационного встроенного программного обеспечения.

Одним из принципиальных моментов является использование не водопадной модели жизненного цикла проекта, выделяющей его отдельные стадии (этапы), а процессной модели. Таким образом, в рамках ГОСТ Р 51904-2002 и DO-178B программный проект и производство программного продукта рассматриваются как совокупность параллельно текущих и взаимодействующих процессов.

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

Трассируемость должна обеспечивать прослеживаемость того:

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

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

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

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

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

Категория A - катастрофическая: отказная ситуация, препятствующая безопасному функционированию объекта управления.

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

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

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

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

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

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

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

Задачи процесса планирования включают в себя:

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

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

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

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

Процедуры процесса разработки включают в себя:

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

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

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

При этом можно упрощенно рассматривать процесс разработки как процесс последовательной трансляции:

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

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

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

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

ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию

Статус документа: действует , введён в действие 01.07.2003 Название на английском языке: Embedded system software. General requirements to development and documentation Дата актуализации информации по стандарту: 17.02.2014, в 20:06 (более года назад) Вид стандарта: Стандарты на процессы Дата начала действия ГОСТа: 2003-07-01 Дата последнего издания документа: 2005-10-01

Назначение ГОСТ Р 51904-2002: Настоящий стандарт распространяется на процессы разработки и документирования программного обеспечения (ПО) встроенных систем реального времени. Стандарт распространяется на все действия, имеющие отношение к разработке программного обеспечения. Настоящий стандарт применяют полностью ко всему поставляемому программному обеспечению, включая среду разработки, если контрактом не предусмотрено использование специальных стандартов для определенных заказчиком типов ПО. Стандарт не применим для аппаратных элементов программно-аппаратного обеспечения

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

Читайте также: