ISTQB CT-AuT key terms

A process assessment model derived from ISO/IEC 33000 used by the automotive industry to rate supplier development processes from level 0 to level 5, with separate process groups for system, software and hardware engineering plus supporting processes.

A rating on the six-point scale (0 to 5) describing how well a process performs and how consistently it is institutionalized, determined by the extent to which its process attributes are achieved.

A measurable characteristic of process capability, such as performance management or process definition, whose achievement rating (N, P, L, F) determines whether a capability level is reached.

The ability to follow a requirement forward to its design, implementation and test cases and backward from any test or code element to the originating requirement, enabling impact analysis and completeness checks during assessments.

The functional safety standard for road vehicles covering the lifecycle from concept through decommissioning, defining hazard analysis, safety goals, ASILs, safety mechanisms and confirmation measures for electrical/electronic systems.

A risk classification from A (lowest) to D (highest) assigned to safety goals based on severity, probability of exposure and controllability, determining the rigour of required development and verification activities.

A top-level safety requirement derived from hazard analysis and risk assessment that states what must be achieved to avoid an unreasonable level of risk, without prescribing a technical solution.

The ISO 26262 activity that identifies hazardous events at the vehicle level and assigns severity, exposure and controllability ratings in order to determine safety goals and their ASILs.

A technical measure implemented in hardware or software, such as a plausibility check, watchdog or redundant channel, that prevents a fault from leading to a violation of a safety goal or brings the system to a safe state.

An operating mode of the system in which risk is acceptably low, for example degraded torque or a controlled shutdown, that the system reaches or maintains when a fault is detected.

The property that a lower-ASIL or non-safety function cannot corrupt the output of a higher-ASIL function, demonstrated through criteria such as memory partitioning, timing and communication protection.

The process by which a system or test observes deviations from specified behaviour, such as out-of-range sensor values or checksum mismatches, and reports them so that fault reactions can be triggered.

A standardized layered software architecture for deeply embedded, hard real-time ECUs comprising basic software, runtime environment and application software components with statically configured communication.

An encapsulated AUTOSAR application unit that provides and requires ports and communicates only through the runtime environment, allowing it to be tested and deployed independently of the ECU it later resides on.

The AUTOSAR middleware layer that implements the virtual function bus on a concrete ECU, routing inter-component communication and runnables to basic software services.

An abstract communication concept in AUTOSAR through which software components exchange data and operations without knowing whether the partner resides on the same ECU or another one.

The standardized AUTOSAR layer providing operating system, communication, memory, diagnostic and I/O services to application software, configured through modules such as the ECU abstraction and services layers.

A test environment in which production or generated application code runs as compiled software on a host PC, with the plant and bus environment simulated, enabling early automated and scalable testing without ECU hardware.

A test environment in which controller and plant are both executable models, typically in a modelling tool, used to validate control algorithms and requirements before code generation.

A test environment in which a real ECU or network of ECUs is connected to a real-time simulated plant and vehicle environment, allowing electrical faults, sensor signals and bus traffic to be injected safely.

An umbrella term for the family of in-the-loop test configurations (MiL, SiL, PiL, HiL) that differ in which parts are real and which are simulated, chosen according to test objective and maturity.

The simulation of all communication partners on a vehicle network so that the device under test receives realistic periodic frames and can transmit without real ECUs being present.

Execution of plant models with guaranteed timing so that simulated signals are produced within fixed cycle times, matching the physical dynamics the ECU expects from the real vehicle.

The generation and monitoring of vehicle network traffic (CAN, LIN, FlexRay, Automotive Ethernet) in a test environment, including frame scheduling, signal manipulation and fault injection on the bus.

Comparing outputs of two versions of a system, such as a model and its generated code, with identical inputs to detect behavioural differences introduced by transformation or optimization.

Examination of source code or models without executing them, using tools or reviews to find violations of coding rules, suspicious constructs, complexity hotspots and potential runtime faults.

A widely applied set of coding guidelines for the C language that restricts error-prone constructs to improve safety, portability and analysability of embedded automotive software.

A documented set of rules and recommendations for writing source code, such as naming, complexity limits and forbidden language features, checked automatically and enforced through reviews.

A formally justified and approved exception to a coding rule, recorded with rationale and risk assessment, so that an intentional violation does not invalidate the static analysis result.

A systematic examination of source code by people, guided by checklists or the coding guideline, to find defects that tools miss, such as wrong algorithms, missing checks or unclear intent.

A static technique that builds the graph of possible execution paths through a program to detect unreachable code, missing returns, endless loops and to support structural coverage planning.

A static technique tracking where variables are defined and where those definitions are used, revealing anomalies such as use before definition or definitions never used.

A count of the linearly independent paths through a piece of code, derived from the control flow graph, used to judge testability and to set a minimum number of structural test cases.

A dynamic test design approach in which test cases are derived from specified requirements and their acceptance criteria, aiming to show that each requirement is met and traceably verified.

A black-box technique that divides input and output ranges into classes expected to be processed the same way, so that one representative value per class is tested.

A black-box technique that selects test values at and around the edges of equivalence partitions, where defects in comparisons and limits most often occur.

A structural coverage measure reporting the percentage of executable statements exercised by a test suite, used as an entry criterion for code-level testing in safety-related projects.

A structural coverage measure reporting the percentage of decision outcomes (true and false of each branch) exercised, stronger than statement coverage and commonly required for higher ASILs.

A structural coverage criterion requiring that each elementary condition in a decision is shown to independently affect the decision outcome, while every entry and exit point and every condition is exercised.

The deliberate introduction of errors such as corrupted signals, stuck bits, lost frames or short circuits during a test to verify that detection and safety mechanisms react as specified.