QP/C  8.0.2
Real-Time Embedded Framework
Loading...
Searching...
No Matches
Context Viewpoint

Technology ViewpointResource Viewpoint

The Context Viewpoint provides a "black box" perspective on the architecture subject (QP Framework in this case) in the surrounding context (QP Application and underlying Operating System). The views within this viewpoint identify the stratification of services (layers) and the interfaces between the layers. The Context Viewpoint frames the following concerns:

  • context of the architecture subject
  • functional decomposition of the system into layers
  • interfaces between the layers

The model kind used to illustrate the Context Viewpoint is the UML package diagram Figure SAS-CTXT (static view). It shows the QP Framework in the context of other software elements. The architecture is layered with clearly defined interfaces. As required in a truly layered architecture, the dependencies between layers point in one direction only (from higher-level to lower-level layers).

Figure SAS-CTXT: Context of use with layers and QP Framework interfaces.
Remarks
In compliance with the UML conventions, the diagrams shown in this section intentionally omit many elements of QP Framework or QP Applications. The presented views contain only selected elements necessary to explain the high-level structure, but without cluttering the diagrams with irrelevant details.
Note
QP Framework classes, their responsibilities, and relationships are described in the Structural View in Software Design Specification.

Layer View

The Layers View explains the QP Framework context in terms of distinct layers and their relationships. The objectives of the Layer View are:

  • simplification of the interactions inside the system because a software layer can only interact with the layer immediately below.
  • promote modularity by encapsulating functionalities within layers. This makes it easier to manage, test, and update individual parts of the system without affecting others.
  • enhance scalability by allowing layers to be scaled independently.
  • encourage reusability of components within and across projects. For example well-defined QP Application layer can be reused in different contexts (e.g., with different operating system or different target hardware), saving development time and effort.
  • improve maintainability by isolating changes to specific layers. This reduces the risk of unintended side effects when modifying the system.
  • facilitate interoperability by allowing layers to interact only through the well defined interfaces (see Interface View).
  • provide flexibility to allow layers to be modified or replaced without impacting the entire system.
  • enhance security by isolating sensitive operations within specific layers. This limits the exposure of critical functionalities and data.

SAS_QP_APP

SAS_QP_APP: QP Application layer

Description

QP Application layer (Figure SAS-CTXT [0]) consists of specific Active Object classes and Event classes. The QP Application classes inherit and specialize the base classes from QP Framework. QP Application also uses services provided by the QP Framework API.

Note
The specific classes inside the QP Application layer, such as ActiveObjA or EventA, are derived from the QP Framework base classes, which are described in the Structural View in Software Design Specification.

SAS_QP_FRM

SAS_QP_FRM: QP Framework layer

Description

QP Framework layer (Figure SAS-CTXT [1]) provides the base classes to be specialized by the QP Application. QP Framework also provides the runtime environment to execute QP Application. Finally QP Framework provides the QP Framework API, which are services that the specific Active Objects can call directly without subclassing and specializing the base classes.

Note
The QP Framework base classes, such as QActive and QEvt are described in the Structural View in Software Design Specification.

Backward Traceability

Forward Traceability (truncated to 1 level(s))

SAS_QP_OSAL

SAS_QP_OSAL: OS abstraction layer (OSAL)

Description

Operating System Abstraction layer (Figure SAS-CTXT [2]) insulates the QP Framework from the specifics of the underlying Operating System (OS). The OS Abstraction Layer provides an abstracted OSAL API that QP Framework uses internally. The OS Abstraction Layer also implements the OSAL API for the underlying OS layer, which is called a specific QP port.

Backward Traceability

Forward Traceability (truncated to 1 level(s))

SAS_QP_OS

SAS_QP_OS: OS layer

Description

Operating System layer (Figure SAS-CTXT [3]) provides the execution context for Active Objects as well as other services used by the OS abstraction layer (OSAL). The OS Layer might consist of one of the real-time kernels provided in the QP Framework (e.g., QV, QK, or QXK) or might be a 3rd-party RTOS/OS.

Backward Traceability

Forward Traceability (truncated to 1 level(s))

Interface View

The Interface View defines how different layers of a system interact with each other. The objectives are:

  • define clear layer boundaries, ensuring each layer's responsibilities and interactions are well-defined.
  • ensure compatibility to allow seamless communication and data exchange between layers.
  • promote modularity to allow components to be developed, tested, and maintained independently, which enhances flexibility and scalability.
  • facilitate integration to provide a blueprint for integrating different components, making it easier to assemble the system and ensure that all parts work together harmoniously.
  • enhance reusability by designing interfaces that can be reused across different projects or components, reducing development time and effort.
  • support interoperability to ensure that the system can interact with other systems or external components, which is especially important in real-time embedded systems where integration with hardware and other software is common.
  • maintain consistency in how components interact, which helps in maintaining the integrity and reliability of the system.

SAS_QP_CLS

SAS_QP_CLS: QP Framework base classes

Description

Base classes in QP Framework (Figure SAS-CTXT [1A]) provide an interface for QP Application to inherit and specialize.

Backward Traceability

  • SRS_QP_EVT_00: QP Framework shall provide Event abstraction to QP Application
  • SRS_QP_SM_00: QP Framework shall provide support for hierarchical state machines both for Active Objects and for passive event-driven objects in the Application
  • SRS_QP_AO_00: QP Framework shall provide the Active Object abstraction to QP Application

Forward Traceability (truncated to 1 level(s))

SAS_QP_API

SAS_QP_API: QP Framework API

Description

QP Framework API (Figure SAS-CTXT [1B]) provides an interface to various QP Framework services without the need to subclass and specialize the QP Framework base classes. Examples of such services include: direct event posting, subscribing and publishing events, or arming and disarming time events.

Backward Traceability

  • SRS_QP_EDM_00: QP Framework shall provide direct event posting to Active Object instances based on the FIFO policy
  • SRS_QP_EDM_01: QP Framework shall provide direct event self-posting to Active Object instances based on the LIFO policy
  • SRS_QP_EDM_50: QP Framework shall provide publish-subscribe event delivery mechanism
  • SRS_QP_EDM_52: QP Framework shall allow Active Object instances to subscribe to a given event signal at run-time.
  • SRS_QP_EDM_53: QP Framework shall allow Active Object instances to unsubscribe from a subscribed event signal at run-time.
  • SRS_QP_EDM_54: QP Framework shall allow Active Object instances to unsubscribe from all subscribed event signals at run-time.
  • SRS_QP_EMM_40: QP Framework shall provide a method of explicitly recycling mutable events.
  • SRS_QP_TM_00: QP Framework shall support Time Events.
  • SRS_QP_TM_11: For every clock rate QP Framework shall provide a clock-tick processing operation that QP Application must call periodically to service the armed Time Events.
  • SRS_QP_TM_20: QP Framework shall provide Time Event initialization.
  • SRS_QP_TM_21: QP Framework shall allow a Time Event to be armed both for one-shot and periodic expiry.
  • SRS_QP_TM_22: QP Framework shall allow a Time Event to be explicitly disarmed.
  • SRS_QP_TM_23: QP Framework shall allow a Time Event to be rearmed.
  • SRS_QP_TM_30: QP Framework shall provide operation to check whether any Time Events are armed for a given tick rate.

Forward Traceability (truncated to 1 level(s))

SAS_OSAL_API

SAS_OSAL_API: OSAL API

Description

OSAL API (Figure SAS-CTXT [2A]) is an abstract interface between QP Framework and the underlying OS to insulate the framework from the OS.

Backward Traceability

  • SRS_QP_NF_40: QP Framework shall be portable to 16-/32-/64-bit CPUs.
  • SRS_QP_NF_41: QP Framework shall be portable to a wide range of real-time kernels.

Forward Traceability (truncated to 1 level(s))

SAS_OS_API

SAS_OS_API: OS API

Description

OS API (Figure SAS-CTXT [2B]) is the specific Operating System API. This interface is not part of QP Framework, but is used in every specific OS Abstraction layer (OSAL).

Forward Traceability (truncated to 1 level(s))

Technology ViewpointResource Viewpoint