QP/C Real-Time Event Framework 8.1.5
QP/C Real-Time Event Framework 8.1.5
Fault is an abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function ([IEC 61508-4:2010] 3.6.1, [ISO 26262-1:2018] 3.54).
Error is a discrepancy between a computed, observed, or measured value or condition and the actual, specified, or theoretically correct value of condition ([IEC 61508-4:2010] 3.6.11, [ISO 26262-1:2018] 3.46).
Failure is termination of the ability of a functional unit to provide a required function or operation of a functional unit in any way other than required ([IEC 61508-4:2010] 3.6.4). Failure is also termination of an intended behavior of an element or an item due to a fault manifestation ([ISO 26262-1:2018] 3.50).
Safe State is a state of the Equipment Under Control (EUC) when safety is achieved ([IEC 61508-4:2010] 3.1.13). NOTE: In transitioning from a potentially hazardous condition to the final safe state, the EUC may have to go through several intermediate safe states. For some situations, a safe state exists only so long as the EUC is continuously controlled. Such control may be for a short or an indefinite period of time.
Fault detection is the activity of monitoring a system for erroneous states caused by a fault within the subsystem to be checked ([IEC 61508-7:2010] C.3.1). The primary goal of fault detection is to inhibit the effect of wrong results. A system that checks its own erroneous states is called self-checking. Fault detection in software is based on the principles of redundancy and diversity. It may be achieved by checks in the value domain or in the time domain on different levels, such as physical (temperature, voltage, etc.), logical (error-detecting codes), functional (assertions), or external (plausibility checks).
Fault management is proactively detecting faults and, once a fault is detected, reacting to the fault by placing the system in a safe state.
Operational situation is a scenario that can occur during a system's life ([ISO 26262-1:2018] 3.104). Examples: Driving a vehicle at high speed; parking on slope; system maintenance.
Crash-Only Model for handling errors makes no attempts at recovery and instead transitions to the safe state as quickly as possible. The Crash-Only model is commonly applied in the situation where a system-level component (like QP/C software component) does not know about how the particular QP/C Application will be operating in the Equipment Under Control (EUC), and therefore cannot anticipate any elaborate error-recovery policy. The Crash-Only model has the following advantages [Crash:2003]:
The Crash-Only Model is particularly beneficial in safety-critical systems where quick recovery and minimal downtime are crucial.
Failure Assertion Programming (FAP) is a runtime fault-detection technique in which the software evaluates Boolean conditions that must always hold true during correct operation. These conditions express the assumptions under which the software is intended to function safely. If any such condition evaluates to false at runtime, control is immediately relinquished and the fault-management subsystem is invoked to record diagnostic information and transition the system into a safe state ([IEC 61508-7:2010] C.3.3).
Failure assertion programming incorporates the principles of Design by Contract ([DBC:2000]) by applying specialized assertions to check:
Failure assertion programming is a runtime technique used in deployed safety-related systems to detect faults and trigger the system's safe-state reaction (see Crash-Only Model).
Failure assertion programming) should be used only for errors that are believed to never occur in the correctly functioning software. Assertions should never be used for handling operational situations, which require the exact opposite strategy than errors.Software self-monitoring is the activity that the software system performs to check itself for erroneous states caused by various faults. Software self-monitoring includes fault detection, fault management, and various self-tests. On fault detection, the software must perform fault management by taking appropriate actions ([IEC 61508-3:2010] 7.4.2.7).
Data Flow Self-Monitoring is a set of techniques to inhibit the effects of erroneous data exchanged between software components. In the QP/C software component, data flow self-monitoring is used as the primary safety mechanism to protect the interfaces between software layers. QP/C software component achieves this through the use of precondition assertions.
Precondition is a Boolean condition that must be true before a function begins execution. Preconditions express the assumptions that a function makes about its inputs, its calling context, and the state of the component. Violating a precondition indicates a systematic design fault or an unexpected misuse of the API. In QP/C, preconditions are used to verify:
These checks ensure that data flowing into a function is consistent with the component's design assumptions.
Duplicate inverse storage (DIS), a.k.a., "duplicated variable" [Pont:2017] is an effective and widely used method for data integrity self-monitoring. In this method, each monitored data item is accompanied by a redundant duplicate storage data_dis, which contains the bit-inverted version of the original data (bit inversion is recommended in [IEC 61508-7:2010] A.5.7 Double RAM with hardware or software comparison and read/write test). Every time the original data is legitimately modified, the duplicate inverse storage is updated. This establishes an invariant (data == ~data_dis), which can be used to detect erroneous data modifications.
Duplicate storage (DS) is an effective and widely used method for data integrity self-monitoring. In this method, each monitored data item is accompanied by a redundant duplicate storage data_ds, which contains a copy (without bit inversion) of the original data. Every time the original data is legitimately modified, the duplicate storage is updated. This establishes an invariant (data == data_ds), which can be used to detect erroneous data modifications. Duplicate Storage (DS) shall be used in cases where bit-inversion might lead to overly complex code (e.g., for certain types of pointers on CPUs with memory models, where pointer size does not coincide with the size of unitptr_t).
Duplicate Inverse Storage and Duplicate Storage are only applied in the SafeQP/C and SafeQP/C++ editions. A pointer with the value NULL has in C or C++ programming languages a special meaning and denotes a pointer that points to an invalid object. NULL or nullptr is commonly used to initialize pointer variables and also to indicate an invalid value of a pointer variable. Attempt to dereference a NULL pointer is considered undefined behavior in C or C++, and should never happen in a correctly operating program. For this reason, software should apply an effective detection of NULL pointer dereferencing as soon as it occurs. Such detection typically requires assistance from the hardware, which might involve mapping memory area around address 0x0 to invalid memory, or setting a no-access MPU (Memory Protection Unit) region around address 0x0.
The call stack is the fundamental data structure that the CPU uses to manage the function calls and returns, and how they pass parameters to each other. A multi-threaded program can have multiple call stacks. Stack overflow occurs when the stack grows beyond the predetermined bounds. This might have an extensive range of consequences, from unnoticeable to catastrophic. However, after any instance of stack overflow, the software is no longer trustworthy and must be considered unsafe. For that reason, safety-critical software should detect stack overflow (any stack, if multiple stacks are used).
Stack painting is an effective way to monitor the worst-case stack utilization. It consists of pre-filling the entire stack memory with a dedicated fill value, for example 0xDEADBEEF, before the application starts executing. Whenever the execution stops, the stack memory can be searched from the end against the normal growth of the stack until the memory content is different from the dedicated value 0xDEADBEEF, which is assumed to be how much stack memory has been unused. If the dedicated value cannot be found at all, the stack has consumed all stack space and most likely has overflowed.
Low watermark is a software fault-detection and resource-monitoring measure that tracks the minimum value ever reached by a monitored resource during system operation. The "low watermark" represents the lowest historical availability of a resource. In safety-related systems, the technique is typically applied to resources that decrease as they are consumed, such as:
The goal fo Control-Flow Self-Monitoring is to inhibit the effects of erroneous software execution paths, such as endless loops or unbounded iteration. The methods for control flow self-monitoring apply runtime checking for algorithms that cannot be bounded by static analysis, such as link-list traversal.
Control flow self-monitoring Software Safety Functions (SSFs) specified in this section are part of the defensive programming set of highly recommended techniques ([IEC 61508-3:2010] Table A.4 and [ISO 26262-6:2018] 5.4.3 Table 1);Specific algorithms, such as linked-list traversal, lead to implementations with explicit or implicit loops that are potentially unbounded. The fixed upper loop bound technique is based on providing an explicit integer upper loop bound on the number of iterations ([NASA-10:06] Rule 2). It must be trivially possible for a static analysis tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. When the loop exceeds the upper bound, it must trigger an assertion failure.
The invalid control flow technique consists of placing error assertions in invalid paths through the code. The method can utilize existing paths or add paths that otherwise wouldn't be checked. For example, if the cases in a given switch statement exhaust all expected options, the invalid control flow technique would add the default case with the error-assertion. A similar situation arises in the chain of if-else if... statements that are supposed to exhaust all conditions. In that case, the invalid control flow technique would add the final else branch with an error-assertion.
Freedom from Interference (FFI) (a.k.a., non-interference) is the demonstrated absence of unintended interactions between elements that share resources, such that no element can cause cascading failures or degrade the ability of another element to meet its allocated safety requirements or safety goals ([ISO 26262-1:2018] 3.65, [IEC 61508-3:2010] Annex F).
Spatial isolation is the property that prevents one element from corrupting or accessing the memory, registers, I/O regions, or other storage resources allocated to another element, except through controlled and specified interfaces ([ISO 26262-6:2018] Table 3:1h, [IEC 61508-3:2010] Annex F.4).
Temporal isolation is the property that ensures each element receives sufficient processing time and access to time-critical resources so that its time-dependent safety requirements (deadlines, response times, execution budgets) are always met, regardless of the behavior or load generated by other elements sharing those resources ([IEC 61508-3:2010] Annex F.5).
Time-Triggered Architecture (TTA) is a real-time embedded system architecture in which all activities — task execution, communication, sensing, and actuation — are driven by a globally synchronized periodic time-base and prescribed schedule rather than by external arbitrary events. Practical implementations of microcontroller software for TTA (see [Pont:2017]) typically involve a single periodic interrupt, which drives a scheduler, which in turn releases tasks at predetermined points in time (prescribed schedule). A TTA architecture can be viewed as a subset of a more general event-triggered architecture (ETA).
The explicit Safety Management concepts and safety-related documents, such as Software Safety Manual (SSM) and Software Safety Requirements Specification (SSRS), are only applied in the SafeQP/C and SafeQP/C++ editions. Safety Element out of Context (SEooC) is a component that is developed independently of its final system application, using assumed safety requirements, operating conditions, and external risk controls defined by the supplier. The component is developed and verified to a defined safety integrity level so that it can be reused in multiple systems, provided that the system integrator confirms that the component's assumptions, constraints, and required safety measures are satisfied in the target system.
Systematic Capability (SC) is the measure of confidence that software-related systematic faults have been adequately avoided and controlled for a given safety level (SIL/ASIL/software safety class). It is achieved by applying a rigorously defined set of development, verification, and validation techniques and measures — such as formal methods, static analysis, dynamic testing, reviews, and architectural/design measures — appropriate to the targeted safety integrity.
An Assumed Safety Requirement (ASR) is a system-level safety requirement that QP/C depends on but cannot satisfy by itself as a Safety Element out of Context (SEooC). ASRs define the external safety conditions, constraints, and guarantees that must be provided by the application and system integrator for the QP/C safety mechanisms to achieve their intended safety integrity level.
ASRs represent the assumed allocation of system safety requirements to the environment in which QP/C operates. They are mandatory: failure to satisfy an ASR invalidates the corresponding part of the QP/C Safety Case.
The mandatory Assumed Safety Requirements (ASRs) are used in the Software Safety Manual, where they are visually distinguished by the exclamation point icon. Also, ASRs use the words "shall" or "must" to indicate their normative, binding, and non-negotiable character.Purpose
ASRs define the safety-critical conditions that QP/C relies on. They:
ASRs ensure that QP/C is deployed only in systems that provide the external safety guarantees it depends on.
Integrator Obligations
Failure to satisfy an ASR invalidates the corresponding part of the QP/C Safety Case and may compromise the systems safety argument.
An Assumption of Use (AoU) is a documented recommendation, design expectation, or system-level practice that reflects how the QP/C SEooC is intended to be used within a safety-related system. AoUs describe recommended practices, design patterns, expectations, hardware characteristics, and supporting safety mechanisms that are not implemented within QP/C itself, but which materially contribute to achieving the intended Safety Functions and safety integrity level. In the QP/C documentation, AoUs employ the word "should" to indicate their advisory, non-mandatory nature.
AoUs are derived in accordance with the ISO 26262 concept of a Safety Element out of Context (SEooC) and represent the supplier's expectations about the environment into which QP/C will be integrated.
Some existing Safety Manuals — such as those from major MCU vendors — use the term Condition of Use (CoU) for integrator-facing usage expectations. For the purposes of the QP/C documentation, CoUs used in such documents are essentially equivalent to Assumptions of Use (AOUs). The term "assumption" is preferred here because it is more widely used in functional safety standards (especially [ISO 26262]) and in many established SEooC Safety Manuals, and therefore provides clearer alignment with industry-standard terminology.Purpose
The purpose of documenting AoUs is to:
Integrator Obligations
The integrator of the QP/C SEooC into a safety-related system shall/should:
A Prerequisite (PRQ) is a defined setup condition, environmental requirement, or preparatory step that must be satisfied before a verification activity (VER) can be executed or before an Assumed Safety Requirement (ASR) can be validated.
Purpose
PRQs establish the baseline environment in which Assumed Safety Requirements (ASRs) and Assumptions of Use (AoUs) can be meaningfully tested.
Integrator Obligations
A Procedure (PROC) is a documented, repeatable sequence of actions or steps that must be performed to correctly install, configure, operate, or maintain the QP/C Framework within its defined safety envelope. Unlike Verification (VER), which demonstrates compliance with assumptions and constraints, PROCs define how tasks are executed safely and consistently in practice.
Purpose
PROCs provide the operational instructions that ensure those assumptions and constraints are respected during integration and lifecycle activities.
Integrator Obligations
A Verification (VER) step represents a defined check, test, or analysis activity that demonstrates whether a Assumed Safety Requirement (ASR) has been correctly implemented and satisfied. VERs form the operational link between documented assumptions and the evidence required for compliance with functional safety standards such as IEC 61508, IEC 62304, and ISO 26262.
Purpose
VERs are the verification steps that confirm that those assumptions and constraints are met in practice.
Integrator Obligations
An Artifact (ART) is a documented reference item or structural material that supports safe integration and lifecycle activities of the QP/C Framework component. ARTs are not assumptions, constraints, or verification steps themselves, but serve as static, traceable resources such as annotated directory trees, configuration templates, architectural diagrams, or schema definitions.
Purpose
ARTs provide the reference context (e.g., file structures, diagrams) that ensures procedures and verification activities are reproducible and auditable.
Integrator Obligations
An Evidence (EVD) is the documented objective proof that a verification activity (VER) has been executed and that the associated Assumed Safety Requirement (ASR) has been satisfied. EVD provides the tangible artifacts required to demonstrate compliance with functional safety standards such as IEC 61508, IEC 62304, and ISO 26262.
Purpose
EVD is the resulting artifact (e.g., test logs, analysis reports, inspection records) that confirms the VER outcome and closes the traceability loop.
Integrator Obligations
A Reference Design (RD) is an illustrative scenario demonstrating a correct and compliant application of the QP/C Framework within a representative safety-related context. An RD does not define requirements, assumptions, or obligations; instead, it provides a concrete, recommended, working instance of how QP/C can be applied in practice when the integrator follows the relevant ASRs and AoUs.
RDs serve as didactic artifacts: they show how QP/C behaves under realistic conditions, how its safety mechanisms interact, and how its architectural patterns are instantiated. They are intentionally simplified to highlight essential concepts without introducing system-specific complexity.
Purpose
Integrator Obligations
RDs do not constitute normative design guidance and must not be interpreted as prescribing the only valid implementation approach. Rather, they illustrate one correct instantiation of the QP/C safety argument.
A Use Case (USE) is a documented description of a specific, supported way in which the QP/C Framework is expected to be applied within a safety-related system. A USE defines the valid operational context for QP/C by specifying the type of application, architectural pattern, execution model, and safety-relevant behaviors for which the frameworks safety argument has been developed and verified.
USEs do not prescribe how to perform tasks (as PROCs do), nor do they define assumptions or requirements (as AoUs and ASRs do). Instead, they describe the intended scenarios in which QP/C can be safely and effectively integrated, providing the boundary conditions for correct and compliant use.
Purpose
Integrator Obligations
Failure to adhere to the constraints of an Intended Use Case may invalidate the applicability of the QP/C safety argument unless the integrator provides equivalent or superior justification.