Remarks: This Software Design Specification is part of the SafeQP Certification Kit↑, but applies to the whole QP/C Framework family↑. This document is the best source of information about the design, and internal implementation of QP/C Framework component.

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-10-18	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_SDS_QP

Software Design Specification (SDS)

Description
This Software Design Specification, with Unique Identifier: DOC_SDS_QP, describes the software design for the QP/C Framework that realizes the architecture specified in the QP Software Architecture Specification (DOC_SAS_QP), requirements specified in the QP Software Requirements Specification (DOC_SRS_QP), and QP Software Safety Requirements Specification (DOC_SSRS_QP).

Scope
This design specification addresses the following concerns (understood here as areas of interest concerning a software design [IEEE-1016:2009]):

logical structure of QP/C Framework component
interaction using events
state dynamics using hierarchical state machines
time management using Time Events
algorithms used to implement various functions
interface between QP/C Framework and the Operating System underlying the framework;
safe programming techniques

Regulatory background

Across the functional safety standards, the Software Design Specification serves the same regulatory purpose: To provide documented, reviewable evidence that the detailed software design correctly implements the software architecture and the safety requirements derived from hazard and risk analysis, at the required integrity level, and in a form suitable for verification and validation.

Safety Standard	Software Design Specification Role
[IEC 61508-3:2010] Functional Safety of E/E/PE Systems	The SDS is required because IEC 61508 mandates a documented, traceable, and verifiable software design that satisfies SIL-allocated software safety requirements. Regulators and assessors treat the SDS as evidence that systematic faults are controlled, design measures are applied, and the architecture is decomposed into verifiable units. It is a core artifact demonstrating that the software design can achieve the required Safety Integrity Level.
[IEC 62304:2006 + Amd1:2015] Medical Device Software	The SDS is mandated through the standards requirement for detailed software design supporting risk controls defined under ISO 14971. Its regulatory basis comes from medical device law: manufacturers must show that risk-control measures are implemented in the design and can be verified. The SDS therefore provides regulatory evidence that the software design implements device-level safety controls in a structured, testable way.
[ISO 26262-6:2018] Road Vehicles Functional Safety	The SDS is required to demonstrate that ASIL-derived software safety requirements are implemented through a structured, deterministic design. It provides evidence for freedom from interference, fault containment, and ASIL-appropriate design measures. Assessors rely on the SDS to confirm that the software design can enforce safety goals and support ASIL-graded verification.

Design Viewpoints
The Software Design Specification is organized according to the international standard [IEEE-1016:2009] Software Design Descriptions using the following design viewpoints, each consisting of various design views. The described viewpoints are followed by the traceable Software-Design-Specifications, which define and specify the relevant views.

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

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

Backward Traceability

FSM_QP_SDLC_03: Step-3 of the QP/C component SDLC shall review and update Software Design Specification (SDS).
FSM_QP_SDLC_04: Step-4 of the QP/C component SDLC shall perform Unit Design.

Document Conventions

Software-Design-Specification UIDs

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

 +--------------- [1] Work artifact class (e.g., 'SDS' for Software Design Specification)
 |  +------------ [2] Project identifier ('QP' for QP/SafeQP Framework,
 |  |                 'QA' for QP/SafeQP Application)
 |  |   +-------- [3] Design view (e.g., 'OSAL' for OS Abstraction Layer)
 |  |   |
SDS_QP_view

Examples: SDS_QP_QHsm, SDS_QP_START

References

[IEEE-1016:2009]	IEEE Computer Society, "IEEE Standard for Information Technology - Systems Design - Software Design Descriptions", 2009
[ISO-42010:2011]	ISO/IEC/IEEE, "International Standard ISO/IEC/IEEE 4210, Systems and software engineering - Architecture description", 2011
[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-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_SAS_QP]	Software Architecture Specification
[PSiCC:02]	Miro Samek, Practical Statecharts in C/C++, CMP Books 2002. https://www.state-machine.com/psicc
[PSiCC2:08]	Miro Samek, Practical UML Statecharts in C/C++, 2nd Edition, Newnes 2008. https://www.state-machine.com/psicc2
[OO-in-C:23]	Object-Oriented Programming in C↑, Quantum Leaps, GitHub, 2023
[GoF:94]	Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1994.
[UML2.5:17]	"OMG Unified Modeling Language (OMG UML) Version 2.5.1", document formal/2017-12-05, OMG 2017
[UML-Dist:04]	Martin Fowler, "UML Distilled, 3rd Edition", Addison-Wesley, 2004

Safety Viewpoint