Component Documentation

Addresses: ISO 26262-8 12.5.1, from 12.4.2.1

The slint-sc runtime ships inside the customer’s binary, so it’s qualified as a software component rather than as a tool. This document is its specification. The Component Qualification Plan says how it’s qualified. The Component Qualification chapter of the Qualification Report records the outcome.

Safety Analysis: what can go wrong in the runtime, and the measure or constraint that covers each error.

Specification

12.4.2.1 asks the specification of the component to include the following.

Item	Where
a) Unique identification	The `slint-sc` crate from `api/slint-sc`, of the release under qualification
b) Maximum target ASIL	ASIL B; see Integrity Level
c) Qualification activities	Component Qualification Plan
d) Requirements of the component	The rendering model and the generated code contract, one identified paragraph per requirement
e) Requirements of the intended use	User Manual, and the runtime constraints
f) Configuration	The crate has no features and no dependencies, so it has one configuration
g) Interfaces and shared resources	The slint-sc Runtime API, and the frame buffer the application owns; see Architecture Design
h) Application manual	User Manual
i) Integration instructions	Integration below
j) Reactions under anomalous operating conditions	Safety Analysis; a frame buffer of the wrong size is rejected per `sls.gen.render-error`
k) Known anomalies and workarounds	Known Problems

Integration

When Slint SC is available, it will be a crate on crates.io ↗. To add it to a project, add Slint SC as a dependency in Cargo.toml. The generated code of the application’s .slint files depends on it; see Compiling a .slint File Into Rust.