КАСТ-15
 Публикация ФАУ | |
| Аббревиатура | КАСТ-15 |
|---|---|
| Год начался | 2003 |
| Организация | Команда программного обеспечения центров сертификации |
| Домен | Авионика , сертификация типа |
CAST-15 « Объединение требований высокого и низкого уровня» — это позиционный документ группы программного обеспечения центров сертификации (CAST). Это публикация ФАУ , которая «не представляет собой официальную политику или руководство какого-либо органа власти», но предоставляется заявителям на сертификацию программного и аппаратного обеспечения только в образовательных и информационных целях.
Как установлено рекомендательным циркуляром AC 20-115 RTCA ФАУ, публикация DO-178B/C определяет приемлемые средства сертификации программного обеспечения , годного к полетам . Уникальный среди стандартов разработки, DO-178B ввел различие между требованиями высокого уровня и требованиями низкого уровня как формальными продуктами анализа и проектирования требований к программному обеспечению при разработке программного обеспечения, годного к полетам. [1] [2] [3]
DO-17B/C определил разные наборы целей для этих двух уровней требований. Для достижения соответствия заявителю необходимо выполнить оба набора задач со своими требованиями. Однако в узких условиях руководство этого стандарта допускает объединение этих двух уровней в один уровень требований, но предостерегает от такой практики в целом. [4]
Этот позиционный документ касается наблюдаемого неправильного использования данного руководства; некоторые кандидаты объединяли требования высокого и низкого уровня для «простых» продуктов, но не достигали всех связанных целей для обоих уровней требований. [5]
Этот документ с изложением позиции также является примером того, как центры сертификации используют различие между «что» и «как». [6] между требованиями высокого и низкого уровня [7] [8] [9] DO-178B/C не дает четкого объяснения.
Фон
[ редактировать ]Различные заинтересованные стороны в определении и верификации программного обеспечения имеют разные цели и уровни абстракции. Заинтересованные стороны, ответственные за определение или проверку функциональности программного продукта высокого уровня, обычно озабочены структурами и поведением внешних интерфейсов продукта, а детали внутренних структур программного обеспечения не обязательно поддерживают эту направленность. С другой стороны, тем, кто отвечает за определение и проверку покрытия требований всего внутреннего кода, нужны гораздо более подробные сведения о внутренних структурах программного обеспечения. Это является обоснованием для DO-178B/C, устанавливающего отдельные цели для требований высокого и низкого уровня, с учетом того, что заявители разрабатывают дополнительные уровни требований в крупных проектах. [10]
Однако DO-178B допускал возможность разработки только одного уровня требований для особо простых систем. То есть органы по сертификации (например, назначенные ФАУ технические представители ) не будут ожидать большего или меньшего количества уровней требований, чем необходимо. Однако опыт органов по сертификации показал, что некоторые заявители неправильно использовали или злоупотребляли этим намерением, и в результате такие заявители на позднем этапе реализации своих проектов обнаруживали, что они не могут продемонстрировать соответствие и были вынуждены повторять некоторые действия.
Это также проблема при любом использовании инструментов разработки, которые потенциально уменьшают разрешение требований в проекте, особенно тех, которые используют нотации более высокой абстракции (например, UML или моделирование блочного потока). Кандидаты, использующие такие инструменты, обычно должны заявить, используют ли в своих процессах разработки нотации таких инструментов роль описания либо требований высокого уровня, либо требований низкого уровня, но обычно не того и другого. [11]
Статус
[ редактировать ]В целом, позиционные документы CAST были выпущены для гармонизации проверки проектов программного обеспечения, проводимых в соответствии с DO-178B или DO-254. Но они также были предназначены для информирования о разработке и возможном выпуске DO-178C и сопутствующих публикаций. Поскольку большая часть обсуждений и обоснований, записанных в CAST, не включена в новые публикации, CAST остаются источником понимания обновленных стандартов.
Этот документ с изложением позиции CAST-15 больше не представлен на сайте публикаций FAA, поскольку опасения группы были рассмотрены в FAQ № 81 в DO-248C , Вспомогательная информация для DO-178C и DO-278A. [12] а также изменениями и разъяснениями в выпуске DO-178 Revision C :
- Часто задаваемые вопросы были созданы европейскими органами по сертификации, которые были обеспокоены риском возникновения у заявителей неотслеживаемых и непроверяемых пробелов в своих требованиях, и он не рекомендует объединять высокие и низкие уровни требований в один уровень. [13]
- Примечание «От заявителя может потребоваться обоснование процессов разработки программного обеспечения, предъявляющих единый уровень требований». был добавлен в DO-178C, раздел 5.0, стр. 31. [5] [14]
Однако ни DO-248C, ни DO-178C полностью не включают в себя «полное обсуждение этой темы». [5] [7] это записано CAST-15.
Большая часть содержания исходного документа CAST-15 опубликована в EASA Сертификационной записке EASA CM-SWCEH-002 от 2012 года (Раздел 23 «Объединение требований высокого и низкого уровня»). [15]
Содержание
[ редактировать ]DO-178C/ DO-178B содержит рекомендации по объединению требований к программному обеспечению высокого и низкого уровня. Номинально в контексте DO-178C/DO-178B Требования высокого уровня к сертифицированному программному продукту отличаются от Требований к программному обеспечению низкого уровня, причем первые являются результатами процесса разработки требований к программному обеспечению, а вторые — результатами процесса разработки программного обеспечения. Процесс проектирования. [16]
- Требования высокого уровня — это, по существу, системные требования, которые относятся к Программному продукту ( внешний взгляд на то, чем должен быть полный Программный продукт и что он должен делать).
- Низкоуровневые требования являются результатом декомпозиции и разработки требований таким образом, что исходный код может быть создан, проверен и протестирован непосредственно на основе низкоуровневых требований ( взгляд изнутри на то, как программный продукт должен быть реализован для этого). [17]
В некоторых приложениях системные/высокоуровневые требования достаточно просты и подробны, поэтому исходный код может быть создан и проверен напрямую. В этой ситуации системные/высокоуровневые требования также считаются требованиями низкого уровня, что означает, что в дополнение к достижению целей требований высокого уровня те же требования должны также достигать целей требований низкого уровня. . [17]
Обеспокоенность, вызвавшая принятие CAST 15, заключается в том, что некоторые претенденты на сертификацию программного обеспечения интерпретировали приведенное выше руководство как позволяющее объединить как требования к программному обеспечению высокого уровня, так и требования низкого уровня к программному обеспечению в одном документе с требованиями к программному обеспечению или другом артефакте без каких-либо указаний на то, какие требования являются Высокоуровневые и низкоуровневые, но при этом не учитывается прослеживаемость между требованиями низкого и высокого уровня и не учитывается определение производных требований для обратной связи с системными процессами, включая безопасность системы.
В этом позиционном документе обсуждаются некоторые проблемы и опасности, которые, по мнению органов сертификации, возникают в результате объединения требований низкого уровня в набор требований высокого уровня, и рекомендуется не делать этого. [18] Заменяющий контент, опубликованный в FAQ № 81 в DO-248C. Вспомогательная информация для DO-178C и DO-278A, представляет собой более короткий список проблем сертификации для объединения (или слияния) этих двух уровней «что» и «как» в единый набор требования без разграничения соответствующих целей сертификации двух уровней. Часто задаваемые вопросы № 81 также не рекомендуют объединять уровни высокого и низкого уровня даже в тех случаях, когда код может быть написан и проверен за «один шаг» требований, как это позволяет исходное руководство DO-178B/C, но предлагает предложения о том, как для решения проблем. [19] [20]
Разработка на основе моделей
[ редактировать ]Различие или сочетание требований высокого и низкого уровня является особой проблемой при разработке на основе моделей . Поскольку поставщики и заявители используют инструменты разработки на основе моделей при разработке бортового программного обеспечения, возникает обеспокоенность по поводу автоматизации и устранения уровней сертификационных доказательств. Приводятся аргументы в пользу тщательного определения того, какие артефакты на основе модели представляют требования высокого уровня, а какие — требования низкого уровня. Наконец, стандарт DO-331 (Разработка и проверка на основе моделей), дополнение к DO-178C, разъяснил эти аспекты, заявив, что требования высокого уровня — это требования, расположенные до модели, на основе которой была разработана модель, а требования низкого уровня те, которые расположены в самой модели. DO-331 прояснил проблему разработки на основе моделей, поэтому проблемы слияния уровней CAST-15 не применимы к разработке на основе моделей. [21]
Ссылки
[ редактировать ]- ^ Дэвид Л. Лемпия и Стивен П. Миллер (2009). DOT/FAA/AR-08/32 Справочник по управлению инженерными требованиями (PDF) . Федеральное управление гражданской авиации . Проверено 9 июля 2022 г.
DO-178B [27] определяет, что требования к программному обеспечению должны быть организованы в требования к программному обеспечению высокого и низкого уровня. Также требования к программному обеспечению высокого уровня должны соответствовать системным требованиям (цель 1 таблицы А-3 в приложении А), а требования к программному обеспечению низкого уровня должны соответствовать требованиям к программному обеспечению высокого уровня (цель 1 таблицы А-). 4 в приложении А). Они определены в DO-178B как
Требования высокого уровня: требования к программному обеспечению, разработанные на основе анализа системных требований, требований безопасности и системной архитектуры.
Требования низкого уровня: Требования к программному обеспечению, вытекающие из требований высокого уровня, производных требований и ограничений проектирования, на основе которых исходный код может быть напрямую реализован без дополнительной информации. - ^
Джонни Кардозу Маркес, Сарасуати Мегуме Хаяши Елисетти, Луис Альберто Виейра Диас, Адилсон Маркес да Кунья (2012). «Использование разработки на основе моделей в качестве низкоуровневых требований к программному обеспечению для получения сертификации бортового программного обеспечения» . Конференция: Информационные технологии: новые поколения (ИТНГ) . Проверено 9 июля 2022 г.
DO-178B определяет два уровня требований к программному обеспечению. SW-HLR обычно представляет «что» должно быть спроектировано, а SW-LLR представляет «как» выполнить проектирование. .... Этот формализованный проект должен содержать достаточную информацию о таких аспектах, как структуры кода и поток данных/управления, чтобы исходный код мог быть создан непосредственно из него, вручную или с использованием инструмента, без какой-либо дополнительной информации.
{{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Вэнс Хилдерман и Тони Багхай (2007). Сертификация авионики, полное руководство по DO-178 (программное обеспечение) DO-254 (аппаратное обеспечение) . Avionics Communications, Inc. Лисбург, Вирджиния: ISBN 978-1-885544-25-4 .
DO-178B уникален среди «стандартов» программного обеспечения тем, что требует двух или более уровней требований.
- ^ Леанна Риерсон (19 декабря 2017 г.) [7 января 2013 г.]. Разработка программного обеспечения, критически важного для безопасности: Практическое руководство по авиационному программному обеспечению и обеспечению соответствия DO-178C . ЦРК Пресс . п. 114. ИСБН 9781351834056 . Проверено 14 февраля 2022 г.
... Документ группы по программному обеспечению органов сертификации (CAST)* CAST-15 ... предостерегает от объединения требований к программному обеспечению на одном уровне. Есть несколько проектов, где необходим один уровень требований к программному обеспечению (...), но их меньшинство.
- ^ Перейти обратно: а б с Дэниелс, Дьюи (1 января 2001 г.). «Мы уже там? Взгляд практикующего на DO-178C/ED-12C». Крис Дейл, Том Андерсон (ред.). Достижения в области системной безопасности: материалы девятнадцатого симпозиума по системам, критичным для безопасности, Саутгемптон, Великобритания, 8-10 февраля 2011 г. Издательство Спрингер . п. 299. ИСБН 978-0-85729-132-5 .
Другая связанная с этим проблема заключается в том, что DO-178B допускает возможность единого уровня требований, и в этом случае требования высокого уровня также считаются требованиями низкого уровня. Намерение состояло в том, чтобы избежать принудительного создания двух уровней требований даже для тривиально простых программных приложений. Заявители иногда неправильно используют этот параграф, чтобы оправдать создание единого уровня требований для сложных программных приложений. Это может привести к тому, что процесс разработки не будет соответствовать DO-178B. Это была тема документа о позиции группы по программному обеспечению центров сертификации (CAST) CAST-15…. В раздел 5 было добавлено примечание о том, что от заявителя может потребоваться обоснование процессов разработки программного обеспечения, которые предъявляют единый уровень требований. Полное обсуждение этой темы можно найти в CAST-15. [курсив добавлен]
- ^ Риерсон, с. 113, «Чтобы избежать этой скользкой дорожки, предлагаю инженерам... Четко определить разделение между требованиями ( что ) и проектированием ( как )....»
- ^ Перейти обратно: а б Вольпони, Аллан Дж.; Раджамани, Рави (2012). «12. Гибридные модели управления состоянием двигателя». В Ашоке Н. Шривастава, Цзявэй Хан (ред.). Машинное обучение и обнаружение знаний для управления работоспособностью инженерных систем . Серия интеллектуального анализа данных и открытия знаний. Чепмен и Холл / CRC Press . п. 299. ИСБН 978-1-4398-4179-2 .
... По большей части системные требования к программному обеспечению можно связать с... системными требованиями. Требования к программному обеспечению могут быть далее разбиты на требования высокого уровня и подробные (низкоуровневые) требования. Требования высокого уровня описывают функциональные аспекты системы; т. е. они описывают, «что» проектируется. Требования низкого уровня описывают фактическую конструкцию программного обеспечения; т.е. «как» разработано программное обеспечение. Прослеживаемость гарантирует, что все требования были реализованы как функции программного обеспечения (прямая прослеживаемость) и, наоборот, что все реализованные функции связаны с требованием (обратная прослеживаемость). Для интересного обсуждения этой темы читатель может просмотреть краткий документ с изложением позиции, выпущенный Федеральным управлением гражданской авиации [8] ... [8] Группа по программному обеспечению органов сертификации FAA (CAST), «Объединение требований высокого и низкого уровня», Документ с изложением позиции, CAST-15, февраль 2003 г. [выделено автором]
- ^ Джейми П. Уайт, Хасан Реза (2012). «Вывод требований DO-178C на соответствующем уровне иерархии». ICSEA 2012: Седьмая международная конференция по достижениям в области программной инженерии . п. 432. ИСБН 978-1-61208-230-1 . Проверено 8 февраля 2022 г.
Кроме того, документ с изложением позиции CAST-15 содержит указания о том, что для требований к программному обеспечению документ с требованиями высокого уровня должен описывать «что», а документ с требованиями низкого уровня должен описывать «как». [курсив добавлен]
- ^ Раймонд Дж. Эстрада, Эрик Диллабер, Ген Сасаки (2013). «Лучшие практики разработки программного обеспечения, соответствующего DO-178, с использованием модельно-ориентированного проектирования». Конференция AIAA по наведению, навигации и управлению (GNC) (PDF) . Проверено 8 февраля 2022 г.
Согласно документу с изложением позиции CAST-15 (группа программного обеспечения центров сертификации) [15], HLR обычно представляет «что» должно быть спроектировано, а LLR представляет «как» выполнять проектирование. [курсив добавлен]
{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Джейми П. Уайт, Хасан Реза, с. 432. «Конечная цель состоит в том, чтобы поместить требования в документ с требованиями, который обеспечивает наибольшую наглядность для заинтересованных сторон, сохраняя при этом объем документа. Следовательно, существует тонкая грань между размещением слишком большого количества информации в документе с требованиями высокого уровня и обеспечение соответствующего уровня прозрачности для заинтересованных сторон».
- ^ Раймонд Г. Эстрада, Эрик Диллабер, Ген Сасаки, «... [15]. Это связано с разными целями каждого уровня требований; HLR указывает, что должно делать системное программное обеспечение, а LLR указывает, как оно работает. и какие компоненты для этого используются. Проверка должна выполняться отдельно для данных как для HLR, так и для LLR, и объединение этих двух может сделать это невозможным. Обратите внимание, что, хотя раздел 5 DO-178C допускает единый уровень требований, это не так. обычно не делается, поскольку требует, чтобы требования системного уровня содержали дополнительную информацию, позволяющую отслеживать объединенный элемент данных HLR/LLR».
- ^ Риерсон, с. 113, «Часто задаваемые вопросы по DO-248C № 81… и… CAST-15 ».
- ^ Фредерик Потон, ACG Solutions, «DO-178C/ED-12C по сравнению с DO-178B/ED-12B – изменения и улучшения», 2012 г. «Основная проблема заключается в возможных пробелах в уточнении требований, которые препятствуют достаточному анализу прослеживаемости и таким образом, соблюдение целей проверки».
- ^ «Инструмент различий DO-178B/C», редакция: 008, стр. 12 и т. д., 2013 г. «Если разработчик предлагает объединить требования высокого и низкого уровня, ASE найдет обоснование и определит, поддерживает ли это обоснование плавный переход между уровнями абстракции системы и единым уровнем требований. Некоторыми признаками того, что это может быть нецелесообразно, могут быть единые системные требования, ведущие к чрезмерно большому количеству объединенных требований высокого/низкого уровня».
- ^ «Аспекты сертификации программного обеспечения» (PDF) . Меморандум о сертификации (CM-SWCEH-002, выпуск 1). EASA : 12.9 марта 2012 г. Проверено 19 апреля 2023 г.
Следующие разделы руководства настоящего Сертификационного меморандума не соответствуют содержанию Приказа ФАУ 8110.49 , но они соответствуют содержанию существующих документов CAST ... Раздел 21, Объединение требований высокого и низкого уровня (CAST 15). )
- ^ RTCA/ DO-248C «Вспомогательная информация для DO-178C и DO-278A», FAQ № 81, страницы 43-44. «Когда бортовые программные компоненты большие или сложные, процесс разработки требований к программному обеспечению создает HLR, а процесс проектирования программного обеспечения создает LLR и архитектуру. Таким образом, HLR и LLR не являются результатами одних и тех же процессов разработки».
- ^ Перейти обратно: а б RTCA/ DO-178C «Аспекты программного обеспечения при сертификации бортовых систем и оборудования», стр. 31. «Требования низкого уровня — это требования к программному обеспечению, из которых исходный код может быть напрямую реализован без дополнительной информации». ... «Однако, если исходный код генерируется непосредственно из требований высокого уровня, то требования высокого уровня также считаются требованиями низкого уровня, и также применяются рекомендации для требований низкого уровня».
- ^ Раймонд Г. Эстрада, Эрик Диллабер, Ген Сасаки, «Объединение HLR и LLR в одну модель или элемент данных не рекомендуется [15]».
- ^ RTCA/ DO-248C «Вспомогательная информация для DO-178C и DO-278A», FAQ № 81, страницы 43-44. «Могут существовать некоторые системы, в которых требования системного уровня уточняются до требований к программному обеспечению, подходящих для кодирования за один этап уточнения. В этом случае может быть возможен единый уровень требований к программному обеспечению; однако...».
- ^ Алек Бэнкс и Роб Эшмор (2019). «Обеспечение требований в машинном обучении» (PDF) . Материалы семинара CEUR . 2301 (документ 8). Семинар CEUR (CEUR-WS.org) . Проверено 9 июля 2022 г.
[ цитата по CAST-15 ] В приложениях, связанных с безопасностью, эти принципы обычно приводят к декомпозиции требований к программному обеспечению на два различных уровня. Требования высокого уровня (HLR) подробно описывают, «что требуется» в проекте. Затем они систематически разлагаются на требования низкого уровня (LLR), которые предоставляют программистам информацию о том, «как реализовать» этот проект. Чтобы минимизировать двусмысленность, LLR часто включает псевдокод или математические формулы. ... Группа программного обеспечения центров сертификации (CAST). 2003. Объединение требований высокого и низкого уровня. Документ с изложением позиции CAST-15 , завершен в феврале 2003 г.
- ^ Маркус Тобиас Хохштрассер (2020). Разработка на основе модульных моделей критически важного для безопасности программного обеспечения для управления полетом (PDF) . Universitätsbibliothek der TU München . Проверено 9 июля 2022 г.
Пример 4 обусловлен более высокой абстракцией моделей проектирования по сравнению с LLR. Например, традиционные HLR часто содержат диаграммы состояний или таблицы истинности. Эти диаграммы очень близки к реализации в SF . В таких случаях отдельные HLR — это всего лишь искусственно введенный уровень, ведущий к «разработке методом копирования и вставки». Важно отметить, что этот рабочий процесс не объединяет HLR и LLR, поскольку системные требования берут на себя роль HLR, включая все необходимые действия и цели (см. DO-331 MB.5.0). Проблемы, изложенные в позиционном документе CAST-15 «Объединение требований высокого и низкого уровня» [87], неприменимы.
Внешние ссылки
[ редактировать ]- CAST-15 в Wayback Machine (архивировано 29 августа 2017 г.). Проверено 3 декабря 2021 г.