Remarks: This Software Architecture Specification is part of the SafeQP Certification Kit↑, but applies to the whole QP/C Framework component family↑. This document is the best source of information about the master plan for the overall organization of QP/C Framework component, which also directly impacts the QP/C Applications derived from the framework. The detailed QP/C Framework component design is described in a separate document: QP Software Design Specification [DOC_SDS_QP].

Document Revisions

QP/C version	Document revision	Date (YYYY-MM-DD)	By	Description
7.3.4	A	2024-05-05	MMS	Initial release for IEC-61508 SIL-3 and IEC-62304 Class-C.
7.4.0	B	2024-07-30	MMS	Updated for QP 7.4.0.
8.0.0	C	2024-11-17	MMS	Updated for QP 8.0.0.
8.1.2	D	2025-12-09	MMS	Updated for QP 8.1.2.
8.1.3	D	2026-03-21	MMS	Updated for QP 8.1.3.

About this Document

DOC_SAS_QP

Software Architecture Specification (SAS)

Description
This Software Architecture Specification (SAS), with Unique Identifier: DOC_SAS_QP, describes the software architecture of QP/C Framework component that satisfies the QP Software Requirements Specification (DOC_SRS_QP) and the QP Software Safety Requirements Specification (DOC_SSRS_QP).

Note: The architecture specified in this document can be ultimately implemented in various programming languages, so this document applies to a whole family of QP/C Real-Time Event Frameworks (RTEFs), currently consisting of QP/C, QP/C++_, __SafeQP/C, and SafeQP/C++ frameworks implemented in C and C++, respectively. Other possible implementations (e.g., QP/Rust) of these requirements and features might be added in the future.

Scope
This Software Architecture Specification addresses the following general concerns (understood here as topics of interest [ISO-42010:2022]):

the applied programming paradigms and software technologies;
the context, layering, and assignment of functionality to the QP/C Framework component and the external application that integrates it (application responsibilities are defined in the Safety Manual DOC_SSM_QP);
the interface between the QP/C Framework component and the QP/C Application based on the framework, as well as between the QP/C Framework component and the Operating System underlying the framework;
main policies concerning resource management and ownership.

Regulatory background

Across the functional safety standards, the Software Architecture Specification serves the same regulatory purpose: To provide documented, reviewable evidence that the software architecture can support and enforce the safety requirements derived from hazard and risk analysis, at the required integrity level.

Safety Standard	Software Architecture Specification Role
[IEC 61508-3:2010] Functional Safety of E/E/PE Systems	The SAS exists because IEC 61508 requires a structured, hierarchical software design that can be shown to meet the allocated SIL-rated software safety requirements. Regulators and assessors expect the architecture to demonstrate control of systematic faults, enforce modularity and independence, and support verification and traceability. The SAS is therefore a compliance artifact that proves the software design is robust enough to achieve the required SIL.
[IEC 62304:2006 + Amd1:2015] Medical Device Software	The SAS is mandated through the standards requirement for a documented software architecture that supports risk control, traceability, and safe partitioning. Its regulatory basis comes from medical device law: manufacturers must show that software risk controls (per ISO 14971) are implemented and verifiable. The architecture specification is thus a regulatory evidence document linking risk controls to concrete design structures.
[ISO 26262-6:2018] Road Vehicles Functional Safety	Requirements must support ASIL decomposition, traceability, and verification planning. Emphasizes interface definitions, failure modes, and non-functional constraints.

Architectural Viewpoints
The QP/C Framework component architecture is presented according to the international standard [ISO-42010:2022] Architecture Description by means of the following architectural viewpoints (each consisting of various architectural views):

Audience
This Software Architecture Specification is primarily intended for the following stakeholders:

Application Developers who develop QP/C Applications based on the QP/C Framework component,
Software Architects,
Quality-Assurance Engineers,
System Engineers,
Test Engineers, as well as
Managers who oversee the software development.

Backward Traceability

FSM_QP_SDLC_02: Step-2 of the QP/C component SDLC shall review and update Software Architecture Specification (SAS).

Document Conventions

Architecture Specification UIDs

For traceability, this Software Architecture Specification uses the Unique Identifiers (UIDs) with the following structure:

 +--------------- [1] Work artifact class (e.g., 'SAS' for Software Architecture Specification)
 |  +------------ [2] Project identifier ('QP' for @QPX Framework component)
 |  |   +-------- [3] Architecture view (e.g., 'OSAL' for OS Abstraction Layer)
 |  |   |
SAS_QP_view

Examples: SAS_QP_OSAL, SAS_QP_OOA

UML Semantics

Most diagrams presented in this Software Architecture Specification conform to the established and precisely defined semantics of the Unified Modeling Language [UML2.5:17]. In case a diagram uses any non-normative" elements, the semantics of those are explained in the diagram description.

References

[ISO-42010:2022]	ISO/IEC/IEEE, "International Standard ISO/IEC/IEEE 4210, Software, systems and enterprise engineering - Architecture description", 2022
[IEC 61508-1:2010]	IEC 61508-1:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 1: General requirements
[IEC 61508-2:2010]	IEC 61508-2:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 2: Requirements for E/E/PE safety-related systems
[IEC 61508-3:2010]	IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 3: Software requirements
[IEC 61508-4:2010]	IEC 61508-4:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 4: Definitions and abbreviations
[IEC 61508-7:2010]	IEC 61508-7:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 7: Overview of techniques and measures
[ISO 26262-1:2018]	ISO 26262-1:2018(en) Road vehicles — Functional safety — Part 1: Vocabulary. International Standardization Organization.
[ISO 26262-2:2018]	ISO 26262-2:2018(en) Road vehicles - Functional safety - Part 2: Management of functional safety. International Standardization Organization.
[ISO 26262-3:2018]	ISO 26262-3:2018(en) Road vehicles - Functional safety - Part 3: Concept phase. International Standardization Organization.
[ISO 26262-4:2018]	ISO 26262-3:2018(en) Road vehicles - Functional safety - Part 4: Definitions and abbreviations. International Standardization Organization.
[ISO 26262-6:2018]	ISO 26262-6:2018(en) Road vehicles - Functional safety - Part 6: Product development at the software level. International Standardization Organization.
[ISO 26262-8:2018]	ISO 26262-8:2018(en) Road vehicles - Functional safety - Part 8: Supporting processes. International Standardization Organization.
[DOC_SRS_QP]	Software Requirements Specification
[DOC_SSRS_QP]	Software Safety Requirements Specification
[DOC_SDS_QP]	Software Design Specification
[QM-Tool:2024]	Quantum Leaps, QM Model-Based Design Tool↑
[OO-in-C:2023]	Object-Oriented Programming in C↑, Quantum Leaps, GitHub, 2023
[UML2.5:17]	"OMG Unified Modeling Language (OMG UML) Version 2.5.1", document formal/2017-12-05, OMG 2017

Safety Viewpoint