DO-330 Software Tool Qualification Considerations

Giriş

Açıklaması şöyle. Yani bir DO-178C hedefi için bir araç kullanıyorsak bu aracın qualify edilmesi gerekiyor.

Many verification activities can be performed either manually or by using automated tools to help run the analysis. When automated tools are used to achieve a DO-178C objective without their output being verified, those tools must be qualified for use following the DO-330 Guidelines.

Açıklaması şöyle. Toplam 5 Tool Qualification Level (TQL) seviyesi var. Bunlar da 3 gruba ayrılmışlar.

If you use any commercial verification tools to automate DO-178C verification processes and don’t plan on manually reviewing output from the tools, they will need to be qualified at the appropriate tool qualification level.

Ancak aracın nasıl qualify edilmesi gerektiği D0-178C belgesinde yok. Açıklaması şöyle

DO-178C itself describes when a tool must be qualified, but does not go into detail on how this should be done.

The ED-215/DO-330: Software Tool Qualification Considerations supplement to DO-178C expands on this guidance by defining corresponding objectives for the specification, development and verification of qualified tools.

DO-330 guidance can be applied to any tools, not just those used for software development or verification, for example systems design or hardware development tools, and acts more like a stand-alone guidance document.

Bunu açıklayan belge DO-330. Açıklaması şöyle

The ED-215/DO-330: Software Tool Qualification Considerations supplement to DO-178C expands on this guidance by defining corresponding objectives for the specification, development and verification of qualified tools.

DO-330 guidance can be applied to any tools, not just those used for software development or verification, for example systems design or hardware development tools, and acts more like a stand-alone guidance document.

Qualification Seviyeler Nasıldır?

Açıklaması şöyle. Toplam 5 Tool Qualification Level (TQL) seviyesi var. Bunlar da 3 gruba ayrılmışlar.

DO-178C defines 3 sets of tool assessment criteria which, when combined with the DAL level of your software, are used to classify tool at one of 5 different Tool Qualification Levels (TQLs) as shown in table image attached to the post.

Şeklen şöyle

TQL seviyelerinin açıklaması şöyle.  Yani TLQ1 araçlar çok daha sıkı test edilmeli.

Tools with a lower numbered TQL (e.g. 1) must be tested more rigorously than those with a higher numbered TQL (e.g. 5), and the rigor of testing needed for tools with lower numbered TQLs approaches the rigor needed for testing DAL A software.

Bazı örneklerin açıklaması şöyle. Code Generator araçlar Criteria 1, doğrulama araçları da Criteria 3 olabiliyor.

For example, a code generator tool that converts an architectural description of the software into package or class structures fulfils criteria 1.

Verification tools typically fall into Criteria 3 (and are thus classified at TQL-5) as they neither create airborne software nor eliminate or reduce any processes other than the ones for which they are intended.

Criteria 2 typically applies in cases such as model-based testing with a qualified code generator. In this case, the task of verifying the generated code is eliminated or reduced in favor of testing the model, and so the model-based testing tool meets criteria 2.

DO178B Software Verification Process

6.1 Software Verification Process Objectives
6.2 Software Verification Process Activities
6.3 Software Reviews and Analysis
6.3.1 Reviews and Analysis of the High-Level Requirements
6.3.2 Reviews and Analysis of the Low-Level Requirements
6.3.4 Reviews and Analysis of the Source Code
  a. Compliance with the low-level requirements
  b.Compliance with the software architecture
  c. Verifiability
  d. Conformance to standards
  Bu alan için "Static Code Analysis" aracı kullanılabilir.
  e. Traceability
  f. Accuracy and consistency
6.3.5 Reviews and Analysis of the Outputs of the Integration Process
6.3.6 Reviews and Analysis of the Test Cases,Procedures and Results 

Final Run For Score Nedir?

Açıklaması şöyle. Yani gerçek uçuş sisteminde koşarak, doğrulama sonuçları ve delilleri üretmek.

How to prepare for the final “run for score” in your DO-178C project…

As you approach the end of the Verification stage of your project, you’ll need to prepare for your final run for score, which will produce comprehensive verification results and compliance evidence for your final software baseline in the context of your final product.

This means that the test environment should be the same as the final flight system, including all hardware and with all software components integrated. The final run for score is typically performed after the Verification milestone (SOI#3), but is necessary to produce the compliance artifacts you’ll need for certification.

The most efficient strategy when preparing for the final run for score is to ensure that when you go ahead with it, you’ll collect all of the results you need to.

This includes results for all of your requirements-based tests and the evidence you need to show that you have achieved 100% data coupling and control coupling coverage and structural coverage of your final code (through either tests or manual analysis and justification) at the required coverage granularities for your DAL.
Your requirements-based test results should be collected from the final code as it will be written in your product. This means that, if you have instrumented your code to support coverage analysis, you will need to run your requirements-based tests on code that has not been instrumented and collect your coverage results separately.

For large projects, running a final “run for score” may take weeks or even months.

DO-178C

Giriş
DO-178C halefi olduğu DO-178B'ye halen çok benziyor. Dolayısıyla bence önce DO-178B'yi okumak gerekir.

DO-178C
Do-178C 2011 yılında yayınlandı. Yeni başlayan tüm yazılımların artık DO-178C ile geliştirilmesi gerekiyor. Bu standarttan önce başlayan projeler halen DO-178B'yi kullanabilir.

Farklı Neler Var?
Öncelikle Do-178B'deki karışıklığa sebep olan (ambiguity) şeyler düzeltilmiş. DO-178B geliştirme dili (language agnostic), araçlar ve teknolojiden bağımsız yazılmış. Değişen şartlara uygun olarak, bu konulara değinen destekleyici belgeler (supplement) gelmiş.

Destekleyici belgeler için açıklama şöyle

If we speak about airborne software, the main document is the RTCA/EUROCAE DO-178/ED-12 currently at the "C" version: Software Considerations in Airborne Systems and Equipment Certification
If you want to certify (and thus commercialize) your software for flight, this is the main document to read.

Depending on the scope of the software and the design/development process there might be different supplements (see here):

- DO-330 Software Tool Qualification Considerations

- DO-331 Model-Based Development and Verification Supplement to DO-178C and DO-278

- DO-332 Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A

- DO-333 Formal Methods Supplement to DO-178C and DO-278A

It has been prepared by the RTCA/EUROCAE joint committee and approved by both FAA and EASA under different names, but the content is the same.

... these documents are not freely available

Belgeler ile ana doküman arasındaki ilişkiyi gösteren bir şekil burada

7.3. Data Control Categories

Bir açıklama burada. Yazılım yaşam döngüsündeki çıktıları CC1 ve CC2 olarak sınıflandırıyor. CC1 çıktılar versiyonlanmalı ve değişiklik isteği ile güncellenmeli. CC2 çıktılar ise zaten doğası gereği kayıt olduğu için versiyonlamaya gerek yok. Örnek olarak "Problem Report" gibi şeyler verilebilir.

DO-330 Software Tool Qualification Considerations

DO-330 Software Tool Qualification Considerations yazısına taşıdım.

DO-332 Object Oriented Technology and Related Techniques Supplement
DO-332 Object Oriented Technology and Related Techniques Supplement yazısına taşıdım.

DO-333 Formal Methods Supplement to DO-178C and DO-278A
Formal method, formal system ve formal language sanırım farklı şeyler.