Р 330 руководство по квалификации программных инструментов - Arganabio.ru - инструкции по эксплуатации и многое другое

Квалификация инструментов для разработки встраиваемого ПО

Время на прочтение
4 мин

Количество просмотров 2.7K

Привет, Хабр! В этой статье я хочу максимально просто и доступно рассказать про то, как доказывается, что ваши средства разработки и верификации подходят для создания систем повышенной надежности. Это очень важный и далеко не самый простой вопрос, и моя цель — ответить на него как можно более понятным языком. В самой статье я обобщил указания из отраслевых стандартов, таких как КТ-178 или Р-331 (встраиваемое ПО в авиации), ГОСТ Р ИСО 26262-8 (встраиваемое ПО в автомобилестроении). Так что добро пожаловать под кат.

Квалификация – зачем она?

Отраслевые стандарты, такие как КТ-178 или ИСО 26262, описывают процессы создания ПО повышенной надежности. Если следовать этим описаниям, то создание такого ПО превратится в бюрократический ад, который будет длиться вечно. Но существует программное обеспечение, которое позволяет автоматизировать значительную часть этих процессов. Такое ПО называется инструментом. И если вы применяете инструмент, то он должен быть надежным (ИСО 26262 даже вводит термин «уверенность в инструменте»). Для подтверждения надежности инструмента проводится его квалификация.

Квалификация — теория

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

А еще уровень квалификации напрямую влияет на трудозатраты: так, для авиации, для квалификации инструмента по наивысшему уровню КТ-178С, требуется выполнение 76 контрольных мероприятий, а по низшему – только 14.

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

Квалификация – заметки по практике

Как было сказано в теоретической части, квалификация инструментов – это затратный процесс, однако он упрощается несколькими способами:

Поддержка процесса квалификации производителями инструментов (вендоров)
Указания по квалификации инструментов из стандартов

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

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

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

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

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

Инструменты MathWorks и их квалификация

Такие инструменты, как Simulink, DSP Toolbox, Control System Toolbox – это стандарт индустрии для разработки систем управления, цифровой обработки сигналов. Неудивительно, что их применяют в авиации, автомобилестроении и прочих отраслях. Из разработанных моделей генерируется C/C++ код, который ездит и летает. Естественно, что перед разработчиками встает вопрос квалификации инструментов. И квалификация инструментов MathWorks для КТ-178С осуществляется для инструментов верификации моделей и кода:

Simulink Check
Simulink Coverage
Simulink Requirements
Simulink Design Verifier
Simulink Test
Simulink Report Generator
Polyspace Bug Finder
Polyspace Code Prover
Simulink Code Inspector

А для ISO 26262 поставляются сертификаты для:

Simulink Check
Simulink Coverage
Simulink Requirements
Simulink Design Verifier
Simulink Test
Simulink Report Generator
Polyspace Bug Finder
Polyspace Code Prover
Embedded Coder
HDL Coder
PLC Coder

В зависимости от отрасли предоставляются пакеты поддержки квалификации инструментов DO Qualification Kit для авиации или IEC Certification Kit для автомобильной, железнодорожной и других отраслей.

Вместо выводов

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

Р-330, «Руководство по квалификации программных инструментов», в частности:

п. 2.0 Назначение квалификации инструмента
п. 3.1. Уровни квалификации
Справочные материалы D, вопрос D7

ГОСТ Р ИСО 26262-8, Глава 11, «Уверенность в использовании инструментального программного обеспечения»

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

Источник

Квалификация инструментов

DO Qualification Kit реализует подход к квалификации инструмента, указанный в DO-178C. Чтобы использовать DO Qualification Kit, выполняются следующие действия:

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

DO Qualification Kit предоставляет руководство и информацию для вышеуказанных шагов и включает шаблоны документов, наборы тестов и процедур тестирования, необходимые для квалификации поддерживаемых продуктов Simulink и Polyspace.

Для поддерживаемых продуктов DO Qualification Kit включает в себя следующие артефакты:

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

Тесты и процедуры из DO Qualification Kit запускаются в пользовательской среде установки MATLAB или Polyspace. Полученные результаты тестов сравниваются с ожидаемыми результатами из DO Qualification Kit и, по необходимости выполняется устранение любых различий. Simulink Report Generator необходим для квалификации Simulink Check, Simulink Coverage, Simulink Code Inspector и Simulink Test.

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

DO Qualification Kit предоставляет подробное руководство по рабочему процессу, необходимое для разработки и проверки систем с использованием модельно-ориентированного проектирования. Руководство по рабочему процессу описывает процесс, методы и инструменты, используемые для каждого этапа разработки и верификации программного обеспечения, начиная от валидации требований высокого уровня до верификации. Новые концепции для модельно-ориентированного проектирования, представленные в DO-331, объяснены и проиллюстрированы, в том числе роль тестирования на основе симуляций и структурное покрытие модели.

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

Источник

Привет, хабр! В этой статье я хочу максимально просто и доступно рассказать про то, как доказывается, что ваши средства разработки и верификации подходят для создания систем повышенной надежности. Это очень важный и далеко не самый простой вопрос, и моя цель — ответить на него как можно более понятным языком. В самой статье я обобщил указания из отраслевых стандартов, таких как КТ-178 или Р-331 (встраиваемое ПО в авиации), ГОСТ Р ИСО 26262-8 (встраиваемое ПО в автомобилестроении). Так что добро пожаловать под кат

Квалификация – зачем она?

Квалификация — теория

В отраслевых стандартах есть понятие уровня безопасности. В разных стандартах они называются по-разному: Уровень ПО в КТ-178, Уровни Полноты Безопасности автомобиля в ИСО 26262. А для средств разработки применяются уровни квалификации инструментов (КТ-178) или уровни классификации инструментов (ИСО 26262). Эти уровни назначаются по критичности инструментов – чем больше влияния оказывает инструмент на разработку, тем более высокий уровень квалификации будет ему назначен. При этом одним из главных критериев по определению влияния инструмента является мера его влияния на результирующее ПО.
В качестве примера можно рассмотреть генератор исходного кода и статический анализатор кода. Сгенерированный код попадает в прошивку устройства, которое будет установлено на борт самолета или автомобиля. Таким образом, генератор кода оказывает непосредственное влияние на результирующее ПО. Так как генератор кода – сложная штука, и может генерировать код с ошибками, то к качеству этого генератора кода предъявляются строгие требования и уровень его квалификации будет максимальным. Другое дело – статический анализатор, результат работы которого не попадает в бортовое ПО и степень его влияния минимальна. Поэтому для статического анализатора уровень квалификации будет ниже, чем для генератора кода.
А еще уровень квалификации напрямую влияет на трудозатраты: так, для авиации, для квалификации инструмента по наивысшему уровню КТ-178С, требуется выполнение 76 контрольных мероприятий, а по низшему – только 14.
Еще один важный момент – квалификация инструментов проводится не разработчиком инструмента, а непосредственно разработчиком ПО, причем квалификация должна проводиться для каждого проекта!

Квалификация – заметки по практике

Поддержка процесса квалификации производителями инструментов (вендоров)
Указания по квалификации инструментов из стандартов

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

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

Инструменты MathWorks и их квалификация

Такие инструменты как Simulink, DSP Toolbox, Control System Toolbox – это стандарт индустрии для разработки систем управления, цифровой обработки сигналов. Неудивительно, что их применяют в авиации, автомобилестроении и прочих отраслях. Из разработанных моделей генерируется C/C++ код, который ездит и летает. Естественно, что перед разработчиками встает вопрос квалификации инструментов. И квалификация инструментов MathWorks для КТ-178С осуществляется для инструментов верификации моделей и кода:

Simulink Check
Simulink Coverage
Simulink Requirements
Simulink Design Verifier
Simulink Test
Simulink Report Generator
Polyspace Bug Finder
Polyspace Code Prover
Simulink Code Inspector

А для ISO 26262 поставляются сертификаты для:

Simulink Check
Simulink Coverage
Simulink Requirements
Simulink Design Verifier
Simulink Test
Simulink Report Generator
Polyspace Bug Finder
Polyspace Code Prover
Embedded Coder
HDL Coder
PLC Coder

Вместо выводов

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

Р-330, «Руководство по квалификации программных инструментов», в частности:

п. 2.0 Назначение квалификации инструмента
п. 3.1. Уровни квалификации
Справочные материалы D, вопрос D7

ГОСТ Р ИСО 26262-8, Глава 11, «Уверенность в использовании инструментального программного обеспечения»

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

Источник

МЕЖГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ КОМИТЕТ АВИАЦИОННЫЙ РЕГИСТР

ДИРЕКТИВНОЕ ПИСЬМО

№ 03-2016

22 ноября 2016г.

О СЕРТИФИКАЦИИ (КВАЛИФИКАЦИИ) АВИАЦИОННОЙ ТЕХНИКИ, СОДЕРЖАЩЕЙ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

1. Настоящим Директивным письмом вводятся в действие:

1.1. Квалификационные требования КТ-178С «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники»;

1.2. Руководство Р-248С «Пояснительные материалы к документам КТ-178С и КТ-278А»;

1.3. Руководство Р-330 «Руководство по квалификации программных инструментов»;

1.4. Руководство Р-331 «Разработка и верификация на основе модели»;

1.5. Руководство Р-332 «Объектно — ориентированные технологии и связанные методы»;

1.6. Руководство Р-333 «Дополнение по формальным методам к документам КТ-178С и КТ-278;

1.7. Рекомендательный материал РМ-178С «Оценка соответствия программного обеспечения бортовой аппаратуры и систем требованиям КТ-

178С».

Требования настоящего Директивного письма распространяются на Разработчиков образцов авиационной техники (Разработчики ОАТ) и Разработчиков комплектующих изделий (Разработчики КИ).

2. Процедура взаимодействия Разработчиков ОАТ/КИ с Авиарегистром МАК и его рабочими органами в процессе сертификации (квалификации) авиационной техники, содержащей программное обеспечение (ПО), отражена в соответствующем РМ.

3. Создание ПО авиационной техники по альтернативной КТ-178С процедуре допускается, если Заявитель докажет Авиарегистру МАК её приемлемость.

4. Издание данных документов поручено АНО ЦС «Статус».

Контакты:

— Телефоны: 8 499 755 00 46; +7 915 432 57 17.

-Факс:8 499 759 01 81;

— Адрес: 127083, г. Москва, ул. Масловка Верхняя, д. 28, кор.2, пом. II, коми. 12

Председатель Авиарегистра МАК

Источник

Verification and validation of flight control system airborne software

Yakui Gao, … Chaoyou Zhi, in Test Techniques for Flight Control Systems of Large Transport Aircraft, 2021

3.1.2.3 Software testing

Software testing is the process of verifying if a system meets specified requirements or identifying the differences between actual and expected results. As defined in Software Engineering Terminology 1983, software testing is a process of running or testing a system by manual or automatic means to verify if it meets specified requirements or to identify the differences between expected and actual results.

The airborne software of the flight control system of large aircraft is a kind of embedded real-time multiredundancy control airborne software. Combined with the hardware of flight control computer, it realizes all functions and performance of the flight control system, such as the operating system, control law calculation, redundancy management, and built-in test. To sum up, the airborne software of the flight control system has the following characteristics:

1.: The flight control system is a real-time multitask scheduling management software. Many tasks such as control law calculation and redundancy management work in parallel.
2.: The flight control system has complex external interfaces and has many interfaces to connect with external sensors, computers, and actuating equipment (such as ARINC429 bus interface, GJB2894 bus interface, AFDX interface, RS422 bus interface, RS232 interface, A/D conversion interface, D/A conversion interface, and discrete quantity interface).
3.: Strong real-time performance of the software: the airborne software of the flight control system has many algorithms related to time. The main task cycle of the software shall be strictly controlled within specified time and all tasks such as data acquisition, redundancy management, and control law calculation are required to be completed within a certain time.
4.: Simultaneous development and verification, various test environments: software development and testing follow the V&V model and it is required to conduct different levels of testing in different development stages so as to find problems early. Therefore different test environments should be established. Some tests need professional test tools. Besides, special simulation test target machines should be configured as the processors are different.
5.: High reliability and safety: the core airborne software of the flight control system is a key software ensuring high safety and its unreliable performance will bring disastrous consequences. Therefore some advanced technologies to improve reliability and safety such as fault-tolerant technology, N-version technology, safety monitoring, and safety isolation technology shall be adopted in the design of airborne software. The requirement of high safety and reliability greatly increases the workload of testing. To improve the safety and reliability of software, the logic of software products becomes more complex and testing becomes more difficult after multiple technologies are adopted.

Software testing is mainly based on software requirements. From the life cycle of software, the software testing can be divided into unit test, integration test, and system test (including the Component testing based on software integration and the configuration item test based on software and hardware integration). From the tested program, the software testing can be divided into static testing and dynamic testing. From the internal structure of the tested program, the software testing can be divided into black box testing and white box testing. These testing methods divide software testing from different perspectives. In actual testing, these testing methods are used together.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128229903000036

Formal Model Based Safety Analysis Methods and the Application

Peng Wang, in Civil Aircraft Electrical Power System Safety Assessment, 2017

10.3.3 The Application of Formal Model Based Safety Analysis in Software Design and Verification

With the increasing use of software in the aircraft systems and equipment, failure of airborne software will affect the safety of the system equipment and the overall aircraft. The application of formal methods in the verification process of airborne software will improve the performability, correctness, and safety dependency of the software, and will further ensure the safety of systems and equipment. Differing from the formal methods of systems, the formal methods are mainly used to check whether the software design meets its requirements.

The common software formal methods include B, Z, VDM, RAISE, etc. B is a formal method based on the mathematical theory and supports the overall development processes of software, from protocol description to producing the executable code. Z is a very popular formal specification language of software currently with the style of “state-operation.” The method takes the first-order predicate logic and set theory as the basis of formal semantics and uses the function, mapping, correlation, and other mathematical methods for the specification. VDM is the abbreviation of Vienna Development Method, including a series of software formal specifications and software developing techniques. Derived from the research work of IBM Vienna laboratory, the VDM has a mathematical notation system and a proof rules based on the predicate logic and set theory. RAISE can also be called as the Rigorous Approach to Industrial Software Engineering. RAISE language is a formal language, and it can be used to write the extremely abstract and preliminary specification as well as the specific specification which can easily or even automatically convert into the programming language.

There are a series of comparatively mature tools for software formal verification methods, include SMV, Spin, UPPAL, CBMC, BLAST, SLAM, etc. SMV is a program used to verify the CTL formula by using the symbolic model algorithm. It adopts the finite state automata as the modeling language and describes the model and protocol in the input files. The model description language is a simple parallel assignment while using SMV. Spin is a system supporting the design and verification of asynchronous process, and it focuses on proving the correctness of process interaction. The process interaction can be realized through the synchronization primitive, asynchronous communication of pipelines, and shared variable. The UPPAL is a comprehensive tool platform to model, validate, and verify the real-time system. It models the real-time system as the timed automaton and extends its data types (including bound integer, array etc.). CBMC is a model checker which can verify the ANSI-C and C++ language, and it is used to verify the array bound, buffer overflow, pointer safety, exception, user defined assertion, and so on. BLAST is another model checker to verify the C language. It uses the predicate abstraction to abstract the C code and provide the automatic verification for program. SLAM is a formal verification tool based on the model checking and is used to check whether the software interfaces meet the prescribed key behavior properties. It will help the developers design the software system with high reliability and functions satisfying the requirements.

At present, the formal methods in the aviation industries have been mainly applied in the process of software verification, and the schematic of software formal verification method is shown in Fig. 10.2. Honeywell Inc. have adopted the formal methods to verify 60% airborne software in the flight control system, thus improving 5 times of the software development efficiency and reducing the coding error to 1%. Besides, the system has also passed the certification of FAA.

Figure 10.2. Software formal verification method.

At present, the formal method has been widely used in the airborne development process of aviation industries. Aimed at the utilization of this method in the aviation airborne software, the RTCA (Radio Technical Commission for Aeronautics) has proposed in DO-178B to use the formal method as an alternative compliance method of the software in airborne systems and equipment. And in the latest published DO-178C document, the RTCA further pubished DO-333 (Formal Methods Supplement to DO-178C and DO-278A) as the guideline of the formal method in the software life cycle.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081007211000108

Airworthiness Regulations and Safety Requirements

Peng Wang, in Civil Aircraft Electrical Power System Safety Assessment, 2017

1.5.2.3 RTCA DO-178C

In the early 1970s, with the large-scale use of software in the airborne system and equipment, the airborne software has a great influence on the safety of the equipment, system, and aircraft. To resolve the problem, it is urgent to build a set of standards to ensure that the airborne software meets the airworthiness requirement of the safety level.

In May 1980, RTCA, Inc. established the “Digital Avionics Software” Committee, which is dedicated to developing and documenting software practices to support the development of software-based airborne systems and equipment. In January 1982, RTCA and EUROCAE completed the work and formally published DO-178, “Software Considerations in Airborne Systems and Equipment Certification.”

In 1983, RTCA Executive Committee determined that DO-178 should be revised to reflect the experience gained in the certification of the aircraft and engines containing software-based systems and equipment. Thus, RTCA and EUROCAE completed the work and published DO-178A, “Software Considerations in Airborne Systems and Equipment Certification,” in 1985.

With the rapid development of software technology and different understanding of some critical issues, it is necessary to revise DO-178A. In 1989, the FAA formally requested that RTCA establish a special committee to revise DO-178A. Thus, in December 1992, RTCA and EUROCAE formally completed DO-178B, “Software Considerations in Airborne Systems and Equipment Certification.”

In 2004, FAA and representatives of the aviation industry initiated a discussion with RTCA concerning the advances in software technology since 1992, when DO-178B/ED-12B was published. RTCA then requested a Software Ad Hoc committee to evaluate the issues and determine the necessity for improved guidance in light of these advancements in technology. Thus, RTCA and EUROCAE carried out the revision activities and published DO-178C series documents in December 2011.

AC 20-115C issued by FAA accepted DO-178C series documents as an acceptable compliance means of airborne software in July 2013. DO-178C series documents consist of DO-178C, Software Considerations in Airborne Systems and Equipment Certification; DO-330, Software Tool Qualification Considerations; DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A; DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A; and DO-333, Formal Methods Supplement to DO-178C and DO-278A [13].

Now FAA, EASA, and other certification authorities accept DO-178C series documents as airborne software design and verification standard in civil aviation. The documents are used to guide the software development process of airborne equipment and systems and ensure that the software completes its intended function and conforms to the airworthiness requirements. The civil aviation industry uses the documents as the compliance means of airborne software. The civil aviation industry develops software life cycle processes in accordance with documents, satisfies objectives for software life cycle processes, accomplishes the activities that provide a means for satisfying those objectives, and provides software life cycle data that indicates that the objectives have been satisfied.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081007211000017

Basic Concepts

He Ren, … Yong Chen, in Reliability Based Aircraft Maintenance Optimization and Applications, 2017

2.23 Software maintenance

The term software maintenance is something of a misnomer because software maintenance is essentially a continuation of the developmental design process. Failures in airborne software are normally found in unusual operational modes—“bugs” that need to be redesigned out of the system, having been undetected in initial development testing. There remains a significant continuing airworthiness and thus safety concerns, however, that airborne software management processes sustain the same level of integrity as all other critical aircraft systems. It is unusual for civil operators to have authority to modify their own software while some military systems have been established on the basis of experience dating back to the 1960s.

One software characteristic is that a small change introduced in one part of the program, perhaps late in development or aimed at resolving a problem, may have serious implications in other, apparently unrelated areas of code. Operational improvements may be sought by way of similar, apparently minor changes.

Detailed consideration of this topic is beyond the scope of this course. It is important, however, to appreciate the need for careful risk management in tackling airborne software problems and also the need for observing the same critical standards for making and recording changes to the software as applied in the original design, development, and testing.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128126684000022

Preliminary System Safety Assessment

Peng Wang, in Civil Aircraft Electrical Power System Safety Assessment, 2017

5.9.9.2 Item Development Assurance Level Assignment

In the EPS, the main highly integrated and complex components include the GCU, RATGCU, BPCU, battery controller, ADCU, etc. The GCU and BPCU contain the airborne software. It is necessary to assign IDAL for the airborne complex avionic hardware and software.

•

The IDAL assignment of the GCU and RAT GCU

The FFS is determined through Fig. 5.28. In the normal AC power supply system, neither the left nor the right AC power supply function have functional independence, and the LGCU and RGCU do not have item independence either. Therefore, when assigning DAL for them, they can be considered together and assigned the same FDAL and IDAL. However, normal and emergency power supply channels meet the requirements of functional independence, and the RAT GCU and L/R GCU satisfy the requirement of item independence, so the functional failure logic diagram can be formed as follows:

Figure 5.28. Part of the functional failure logic diagram of “Total Loss of AC Network.”

According to Fig. 5.28, the FC1 failure condition has the following minimum FFS:

•: F1 error and F2 error, or
•: F1 error and I2 error, or
•: I1 error and F2 error, or
•: I1 error and I2 error.

•

DAL assignment (Table 5.7).

Table 5.7. Examples for the DAL assignment of catastrophic failure conditions

FDAL Assignment	IDAL Assignment	Annotation
F1	F2	I1	I2
B	B	B	B	Acceptable(final decision in our case)
A	C	Unacceptable: F1 level B & I2 level C are not allowed, and I2 does not support the assignment of F2 level B
C	A	Unacceptable: F2 level B & I1 level C are not allowed, and I1 does not support the assignment of F1 level B
A	C	A	C	Acceptable
C	A	Unacceptable: F2 level C & I1 level C are not allowed, and I1 does not support the assignment of F1 level A
B	B	Unacceptable: F2 level C & I1 level B are not allowed, and I1 level B does not support the assignment of F1
C	A	A	C	Unacceptable: F1 level C & I2 level C are not allowed, and I2 does not support the assignment of F2 level A
C	A	Acceptable
B	B	Unacceptable: F1 level C & I2 level B are not allowed, and I2 level B does not support the assignment of F2

To summarize, we can assign DALs as follows:

•: F1 level B & F2 level B & I1 level B & I2 level B;
•: F1 level A & F2 level C & I1 level A & I2 level C;
•: F1 level C & F2 level A & I1 level C & I2 level A;

However, market research tells us that the first choice costs the least, and a decision can be made at last:

“the FDALs of the normal power supply and emergency power supply are level B, and as for GCU and RAT GCU, the IDAL assigned are level B.”

Comprehensively considering all the failure conditions and their classifications in SFHA, it is clear that there is not only a GCU or RAT GCU failure that can cause a catastrophic failure condition. Therefore, it can be concluded that assigning the GCU and RAT GCU as IDAL B level can meet the requirements of each failure condition.

•

DAL assignment for BPCU

Because the failure of the BPCU will cause the Minor failure condition of “losing the AC ground service power supply,” the level of software and hardware in the BPCU can be assigned as level C.

•

DAL assignment for the battery controller

The batteries supply power for the deployment of the RAT. If the battery controller fails at the time of conversion between the normal and emergency power channels which results from the normal power channels fail, the RAT cannot be deployed and will have catastrophic effects. But taking into account that the battery system is just used temporarily during the emergency situation, and the normal and emergency channels are independent, the IDAL is determined to be level B at least.

•

DAL assignment for ADCU

ADCU controls the deployment of the RAT. If the ADCU fails at the time of conversion between the normal power channels and emergency power channels which results from the normal power channels fail, the RAT cannot be deployed and will have catastrophic effects. But taking into account that the ADCU is just used during the emergency situation, and the normal and emergency channels are independent, the IDAL is determined to be level B at least.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780081007211000054

Airworthiness verification test of the flight control system

Yakui Gao, … Chaoyou Zhi, in Test Techniques for Flight Control Systems of Large Transport Aircraft, 2021

9.1 Overview

According to the requirements of Regulations for Conformity Certification of Civil Products and Spare Airborne Equipment (CCAR21), the applicant shall demonstrate and prove that the design of products conforms to applicable airworthiness requirements through conformity certification test and demonstrate such conformity to the airworthiness department during the type conformity certification period.¹ Chapters 2 and 4–8Chapter 2Chapter 4Chapter 5Chapter 6Chapter 7Chapter 8 of this book, respectively, introduce the airborne equipment test of the flight control system, control law and flying quality evaluation of the flight control system, combined test of the flight control subsystem, “iron bird” integration test of the flight control system, onboard ground test of the flight control system, and flight test of the flight control system. Chapter 3 introduces the verification and validation of the flight control system airborne software. The test content and test methods introduced are basically based on the development requirements of domestic military aircraft and are rarely involved with airworthiness verification. Although the development of domestic military aircraft requires most of the same test content and requirements as the airworthiness verification test, some special requirements of the airworthiness verification test are not involved, such as the management requirements of the airworthiness authority and the description of relevant test items showing the conformity of airworthiness clauses.

This chapter mainly describes the management requirements for the airworthiness verification test of the flight control system and the test items and test methods related to the airworthiness clauses as the supplement to other chapters. Please refer to other chapters of this book for detailed test content and methods.

The airworthiness verification test of the flight control system is one of the main conformity certification methods to judge whether the design of the system satisfies the requirements and is also an important means to guarantee the safety of aircraft. It takes up a large part in the whole development work and goes throughout the whole development process of the flight control system. To ensure the test can accurately reflect the inherent characteristics of the tested system, obtain exact test parameters and results, and provide a reliable basis for conformity certification, the verification test shall be managed according to the procedures stipulated by the airworthiness authority. The test piece shall accurately reflect the requirements of the test and it shall be generally the airborne equipment of the aircraft. Before the aircraft obtains the type certificate or before the type is determined, all products of the flight control system are called test pieces, including the products participating in the test bed test, installed products of aircraft, and products for the verification test.

The airworthiness verification test is generally divided into the engineering verification test and flight test (MC6). The engineering verification test includes the laboratory test (MC4), onboard ground test (MC5), simulator test (MC8), and equipment qualification test (MC9). The classification of the airworthiness verification test of the flight control system is same as the classification of the general airworthiness verification test, as shown in Table 9.1 in detail. The test items of the flight control system included into the airworthiness verification test shall be negotiated with the airworthiness examination group according to the specific conditions of the aircraft systems and conformity verification requirements of airworthiness clauses. Section 9.2 covers the certification requirements for verification test of flight control system and introduces the general process, procedures, and requirements of the examination conducted by the airworthiness authority to the verification test. They are the same as the general requirements for the airworthiness verification test and are described mainly from the perspective of airworthiness management. Generally, the certification requirements cover the formulation of the Certification Compliance Plan of flight control system, determination of the conformity certification methods of applicable clauses, determination of corresponding test items, preparation of test plan, preparation of test procedure and submission of it for review, manufacturing of test pieces and test facilities, implementation of conformity inspection and witnessing test, preparation of the test report, and its submission for review. From the perspective of the examination conducted by airworthiness authority, the airworthiness verification test of the flight control system is the same as the airworthiness verification test of other systems and it mainly has the following features:

Table 9.1. Classification of airworthiness verification test of flight control system.

Classification	Code	Name	Description	Test items in the book
Engineering verification test	MC4	Laboratory test	Generally the integrated test bed test of subsystems and “iron bird” integration test of flight control system	Test items introduced in chapters 5 and 6chapter 5chapter 6 of this book
MC5	Onboard ground test	Generally the flight control system test conducted for aircraft on the ground	Test items introduced in chapter 7 of this book
MC8	Simulator test	Generally the flight control system test conducted on engineering simulator	Test items introduced in chapter 4 of this book
MC9	Qualification test	Generally the airborne equipment test	Test items introduced in chapter 2 of this book
Test flight	MC6	Flight test	Generally the flight control system that must pass the aircraft flight test	Test items introduced in chapter 8 of this book

1.: The test is conducted to verify whether the airborne equipment and system design meet the airworthiness requirements. The airworthiness requirements are the applicable requirements regulated by airworthiness clauses, special conditions or other airworthiness documents.
2.: The examination representative monitors the whole process of the test.
3.: The test procedure, design drawing, and documents of test pieces as well as the test report shall be reviewed and approved by the examination representative.
4.: The examination representative will conduct conformity inspection for the test pieces, installation of test pieces, test devices, and environment.
5.: The examination representative may witness the test at the scene and have the right to discontinue the test if a major problem is found or occurs.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128229903000097

Introduction

Yakui Gao, … Chaoyou Zhi, in Test Techniques for Flight Control Systems of Large Transport Aircraft, 2021

1.3.1 Basic features of a verification test

The verification test of a flight control system is a complicated process both in terms of technology and management and its features are described as follows.

1.: Failure verification test is the core of the flight control system test. The flight control system is the most critical system to ensure the successful completion of an aircraft’s mission and its safe operations. Regulations for Civilian Aircrafts stipulates that the probability of catastrophic failure of aircraft caused by function failure of the flight control system shall be lower than 1×10⁻⁹ and the flight control system realizing this security index shall have a complex system architecture of redundancy, an airborne unit of high reliability, and Class A or Class B airborne software. Therefore the verification of this system must be sufficient and the failure mode verification test becomes one of the most important contents of the flight control system test.
2.: Verification and validation is a series of technical activities. The flight control system verification test is completed through a series of technical activities. The airborne unit qualification test shall be jointly organized by the airborne unit supplier and the customer representatives (airworthiness representatives of civil aircraft) stationed in the airborne unit development unit and attended by a chief engineer unit. The subsystem integrated test shall be jointly organized by the subsystem supplier and the customer representative of the subsystem development unit (airworthiness representatives of civil aircraft) and attended by a chief engineer unit. The system integration test shall be organized by a chief engineer unit and a customer representative stationed in the chief engineer unit and carried out on a special flight control system “iron bird” integrated test bench. A great deal of the tests requires the attendance of the test flight crew. The onboard ground test shall be conducted on an aircraft, wherein the chief engineer unit takes charge, the chief manufacturing unit coordinates to complete the test, and customer representatives stationed in the chief engineer unit and of the manufacturing unit attend the test. With regard to the flight test, the test flight unit shall take charge, the chief engineer unit and machine manufacturing unit shall coordinate to complete the test, and customer representatives shall attend the whole test process. In the test process, there are dozens to hundreds of times of the test task book review and validation, test outline review and validation, quality and safety inspection before test, test result analysis and report compilation, and review meetings at different levels related to the flight control system verification test, involving a high degree of complexity.
3.: The verification test is a technical work that demands high input. The high cost can be seen from the technical activities above for the flight control system verification test. The airborne unit development unit should set up a special test bench for hundreds of airborne units; the subsystem development unit should set up a special test bench for the subsystem; the chief engineer unit should set up a combined test bench for the engineering simulator, flight control system “iron bird” integrated test, and devices for the onboard ground test, and the flight test unit should set up a comprehensive test flight system covering ground monitoring, telemetry and telecontrol, and onboard testing. Meanwhile, the environment required for the testing in different stages of the flight control system software, the control, testing, and analysis software required for the test, and the test pieces required in tests in different stages all require a great input of funds. It is roughly estimated that the input for the software and hardware related to large aircraft development and flight control system verification testing will be in the billions of RMB. According to statistics, the verification cost of a certain type of flight control system software accounts for 15.3% of its total life cycle cost, which is 84% higher than its programming cost. The human resources, energy, and material resources required are also a considerable expense.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128229903000012

Fault and timing analysis in critical multi-core systems: A survey with an avionics perspective

Andreas Löfwenmark, Simin Nadjm-Tehrani, in Journal of Systems Architecture, 2018

2.3 Safety-critical systems

Regardless of which domain a critical system belongs to, it is subjected to international safety standards containing guidance for validation and certification. Table 1 shows the safety levels of a few major domains.

Table 1. Comparison of safety levels [13].

Domain	Safety levels (high to low)
Avionics DO-178C DAL^a	A	B	C	D	E
Automotive ISO 26262 ASIL^b	–	D	C/B	A	QM
General IEC-61508 SIL^c	4	3	2	1	–
Railway EN 50128 SIL^c	4	3	2	1	–

a: Design assurance level
b: Automotive safety integrity level
c: Safety integrity level

As an example, development of safety-critical airborne software is guided by the standard RTCA/DO-178C [14] containing a number of objectives to be fulfilled. The software is assigned a design assurance level (DAL), ranging from level A (most critical) to E (non-critical), depending on the criticality as determined in the safety assessment process.

In addition to RTCA/DO-178C, the certification authorities have issued the Certification Authorities Software Team position paper (CAST 32A) [15] that identifies topics impacting safety, performance, and integrity of an airborne software system executing on multi-core processors. It is required that probabilistic safety guarantees are provided to functionalities of different criticality as shown in Table 2. Clearly, higher criticality levels require more stringent analyses of both hardware and software to ensure the assurance levels needed. Worst-case execution time (WCET) estimates need to be determined more thoroughly and tend to be higher (more pessimistic) in higher criticality levels.

Table 2. Failure rate per RTCA/DO-178C criticality level.

Level	Failure condition	Failure rate
A	Catastrophic	10−9/h
B	Hazardous	10−7/h
C	Major	10−5/h
D	Minor	10−3/h
E	No Effect	N/A

Read full article

URL:

https://www.sciencedirect.com/science/article/pii/S1383762117304903

Источник

Обратная связь

Если не удалось найти инструкцию, то Вы можете заказать её на нашем сайте. Мы постараемся найти нужную Вам инструкцию в электронном виде и отправим ее по электронной почте.

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

Email: Onlinemanuals@ya.ru

Мы в социальных сетях

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

ВКонтакте >

Что такое Onlinemanuals.ru?

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

Для правообладателей >

Источник