QP/C  7.4.0-rc.2
Real-Time Embedded Framework
No Matches
Software Architecture Specification
This document is part of the QP Certification Kit , which has been specifically designed to help companies in safety certification of their software based on the QP Framework treated as commercial off-the-shelf (COTS) software.

Static View: Layers & Interfaces

Revision History

Revision QP/C
By Description
0.0 7.3.0 2023-06-30 MMS Initial Release

Purpose and Scope

This Software Architecture Specification (SAS) with Unique Identifier: DOC-SAS-QP, describes the software architecture of QP Framework and QP Applications. The main objectives of this Software Architecture Specification are to present the software architectural elements and their interactions in a hierarchical structure according to [ISO-42010:2011].

The Software Architecture Specification provides means to implement both the QP Software Requirements Specification (DOC-SRS-QP) and QP Software Safety Requirements Specification (DOC-SSR-QP) to achieve the required safety integrity levels:

  • IEC 61508 SIL 3
  • IEC 62304 Class C
  • ISO 26262 ASIL D
This document is also the best source of information about the master plan for the overall organization and operation of QP Framework as well as QP Applications derived from the framework. The detailed QP Framework design is described in a separate document: QP Software Design Specification [DOC-SDS-QP].

Stakeholders and Concerns

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

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

This architecture specification addresses the following concerns (understood here as topics of interest [ISO-42010:2011]):

  • the suitability of the architecture for achieving the QP Framework's purposes, as specified in the Software Requirements Specification [DOC-SRS-QP] and Software Safety Requirements [DOC-SSR-QP];
  • the interface between QP Framework and the QP Application based on the framework;
  • the interface between QP Framework and the Operating System underlying the framework;
  • maintainability and evolvability of the QP Framework and the QP Application based on the framework.

Architecture Viewpoints

This document describes the following architectural viewpoints:

Static viewpoints:

Dynamic viewpoints:

Safety viewpoint:

Architecture Model

This Software Architecture Specification assumes an object-oriented architecture model, utilizing the concepts of class, inheritance and polymorphism.

The object-oriented point of view does not impose the choice of object-oriented programming language. In traditionally procedural languages, such as C, object-oriented concepts can be applied as design patterns. A set of such patterns for the C programming language is described in the reference Object-Oriented Programming in C [OO-in-C:23].

Architecture Framework

This Software Architecture Specification describes an object-oriented software framework, which significantly differs from software organized as a "toolkit", such as a traditional Real-Time Operating System (RTOS).

A software framework (e.g., QP Framework) provides a reusable architecture for a specific problem domain (embedded, real-time systems in case of QP Framework). A framework has key distinguishing characteristics that differentiate it from a "toolkit" (see also Framework vs. Toolkit in DOC-SRS-QP):

  • inversion of control: In a framework, unlike in a toolkit or in a standard end-application, the overall program's flow of control is not dictated by the application, but by the framework (the framework calls the application, not the other way around).
  • extensibility: application developers can extend the framework by deriving and specializing base classes provided inside the framework.
  • non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting application-implemented extensions. In other words, developers can extend the framework, but cannot modify its code.

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 QP Framework or 'QA' for QP Application)
 |  |  +---------- [3] Work artifact ID (e.g., 'QActive' for class QActive)
 |  |  |

Examples: SAS-QP-QActive, SAS-QP-MEM

UML Semantics

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


[ISO-42010:2011] ISO/IEC/IEEE, "International Standard ISO/IEC/IEEE 4210, Systems and software engineering - Architecture description", 2011
[DOC-SRS-QP] Software Requirements Specification
[DOC-SSR-QP] Software Safety Requirements
[DOC-SDS-QP] Software Design Specification
[QM-Tool:2024] Quantum Leaps, <a href="https://github.com/QuantumLeaps/qm>QM Model-Based Design Tool</a> <tr><td>[OO-in-C:2023] <td><a href="https://github.com/QuantumLeaps/OOP-in-C">Object-Oriented Programming in C</a>, Quantum Leaps, GitHub, 2023 <tr><td>[UML2.5:17] <td><em>"OMG Unified Modeling Language (OMG UML) Version 2.5.1"</em>, document formal/2017-12-05, OMG 2017 <tr><td>[UML-Dist:04] <td>Martin Fowler, <em>"UML Distilled, 3rd Edition", Addison-Wesley, 2004

Static View: Layers & Interfaces