Qualification Method

Addresses: ISO 26262-8 11.4.4.1 f, 11.4.9

This chapter states how each tool reaches the confidence level its classification asks for. The runtime isn’t a tool; its qualification is in the Component Qualification Plan.

TODO

At ASIL B, Tables 4 and 5 of ISO 26262-8 highly recommend increased confidence from use (11.4.7) and evaluation of the tool development process (11.4.8). They only recommend validation (11.4.9), the method chosen here. Decide whether 11.4.8 is also claimed. If it is, 11.4.8.3 wants the evaluation based on a recognized standard, such as Automotive SPICE, the ISO/IEC 33000 series, or CMMI, so say which.

Slint Compiler

The slint-compiler is qualified by validating the tool, per ISO 26262-8 11.4.9.

Validation means writing test cases that cover each language feature of Slint SC, and verifying that the generated Rust code is correct for each. Every paragraph of the Language Specification carries an identifier, and every identifier is traced to at least one test, so the coverage of the feature set is measured rather than asserted.

11.4.9.2 asks for	How
a) Evidence that the tool complies with its specified requirements	The Traceability Matrix
b) Analysis of malfunctions found during validation	Known Problems
c) Reaction to anomalous operating conditions	The compiler syntax tests assert that everything outside the qualified subset is rejected with a diagnostic

slint-sc-coverage

slint-sc-coverage is qualified by validation too. Runtime test cases state their expected coverage in the source, and fail on any difference from the measurement. See Coverage Tool Verification.

Test Suites

The suites that produce this evidence are described in Test Suites, and their outcomes in Test Results.

TODO

Give each suite an identifier, so the potential errors can be traced to the suites that cover them.