mirror of
https://github.com/QuantumLeaps/qpc.git
synced 2025-02-04 07:13:16 +08:00
199 lines
6.7 KiB
Plaintext
199 lines
6.7 KiB
Plaintext
/*! @page srs_toc Requirements (SRS)
|
|
|
|
<h1>Software Requirements Specification (SRS)</h1>
|
|
<p>This document specifies the requirements for the **QP/C** @termref{rtef, real-time embedded framework (RTEF)} (later referenced simply as _QP/C_). This document describes the intended features of _QP/C_, as well as the interfaces to other software, such as application-level software as well as the lower-level software providing services to QP/C. The quick links to the main sections of this SRS are given below:
|
|
</p>
|
|
|
|
- @subpage srs_intro
|
|
+ @ref srs_purpose
|
|
+ @ref srs_audience
|
|
+ @ref srs_conv
|
|
+ @ref srs_refs
|
|
+ @ref srs_assume
|
|
- @subpage srs_fun
|
|
+ @ref srs_qep
|
|
+ @ref srs_qf
|
|
+ @ref srs_qv
|
|
+ @ref srs_qk
|
|
+ @ref srs_qxk
|
|
- @subpage srs_nf
|
|
+ @ref srs_constr
|
|
- @subpage reqdef
|
|
|
|
|
|
@next{srs_intro}
|
|
*/
|
|
/*##########################################################################*/
|
|
/*! @page srs_intro Introduction
|
|
|
|
@tableofcontents
|
|
|
|
<p>Embedded software developers face many challenges, but some of the most difficult problems fall into two main categories:
|
|
</p>
|
|
|
|
- problems related to concurrency, such as execution of interrupts and tasks of a Real-Time Operating System (@termref{RTOS})
|
|
|
|
- problems related to execution logic, such as correctly choosing the right code to execute in response to a given event.
|
|
|
|
|
|
<p>The embedded software industry is in the midst of a major revolution. Tremendous amount of new development lays ahead. This new software needs an actual @termref{architecture} that is _safer_, more extensible, and easier to understand than the usual "free-threading" approach of a traditional Real-Time Operating System (@termref{RTOS}).
|
|
</p>
|
|
This document describes the requirements of the QP/C software framework, which provides such a reusable software architecture for real-time embedded (RTE) systems. This architecture is based on event-driven, asynchronous, non-blocking, encapsulated @ref srs_ao "active objects".
|
|
|
|
|
|
|
|
@section srs_purpose Purpose
|
|
The purpose of the QP/C @termref{ao} @termref{framework} is to provide a reusable software @termref{architecture} and efficient implementation of the @termref{ao} model of computation for deeply embedded applications, such as single-chip microcontrollers.
|
|
|
|
|
|
|
|
@section srs_audience Intended Audience
|
|
|
|
This SRS document is primarily intended for **embedded software engineers**, who develop applications based on the QP/C framework.
|
|
|
|
This SRS can be also of interest to test engineers, software architects, system engineers, quality-assurance engineers, hardware engineers, as well as managers overseeing the software development.
|
|
|
|
|
|
|
|
@section srs_conv Document Conventions
|
|
|
|
|
|
@subsection srs_conv_num Numbering of Requirements
|
|
|
|
|
|
|
|
@subsection srs_conv_shall Use of "Shall" and "Should"
|
|
Requirement definitions use consistent terminology to indicate whether something is mandatory or desirable. _Shall_ is used to denote **mandatory** behavior. _Should_ is used to denote a **desirable** behavior that should typically take place, but might not happen all the time or might be optional in uncommon cases.
|
|
|
|
|
|
|
|
@section srs_refs References
|
|
- @reqref{RQPC101}
|
|
- @reqref{RQPC102}
|
|
|
|
- @reqref{RQPC201}
|
|
- @reqref{RQPC202}
|
|
|
|
|
|
@section srs_assume Assumptions and Dependencies
|
|
|
|
@next{srs_fun}
|
|
*/
|
|
/*##########################################################################*/
|
|
/*! @page srs_fun Functional Requirements
|
|
|
|
|
|
@section srs_qep State Machine Event Processor (QEP)
|
|
The QP/C Event Processor (QEP) is a sub-component of the QP/C framework that implements processing of events according to state machine machine semantics. Specifically, according to that semantics each event is processed to completion (Run-to-Completion) before the processing of the next event can begin.
|
|
|
|
|
|
@reqdef{RQPC101} QEP shall process events according to the Run-To-Completion (RTC) semantics.
|
|
|
|
@description
|
|
RTC event processing means that a given event must be handled entirely (to completion) before processing of the next event can begin. QEP shall implement this requirement via a generic "dispatch" operation, which will process one event at at time and needs to complete (return) before it can be called again.
|
|
|
|
@rationale
|
|
RTC is the universally assumed semantics of processing events in virtually all event-driven systems. The main advantage of RTC is that it eliminates by design any concurrency hazards within a given software component.
|
|
|
|
|
|
@reqdef{RQPC102} QEP shall support multiple and interchangeable event processing strategies, including various state machine implementations.
|
|
|
|
|
|
@reqdef{RQPC103} QEP shall support hierarchical state machines with the following features:
|
|
- leaf states
|
|
- composite states
|
|
- entry actions to states
|
|
- exit actions from states
|
|
- nested initial transitions in composite states
|
|
- regular transitions between states at any level of nesting
|
|
- internal transitions in states
|
|
- guard conditions on all types of transitions
|
|
- transitions to history (shallow)
|
|
- transitions to history (deep)
|
|
|
|
|
|
@reqdef{RQPC104} The state machine implementation must be __human readable__.
|
|
|
|
@reqdef{RQPC105} The state machine implementation must be __traceable__.
|
|
|
|
@reqdef{RQPC106} The state machine implementation must be amenable to automatic code generation.
|
|
|
|
@reqdef{RQPC107} The QMsm-state machine implementation strategy shall additionally support the following features:
|
|
- submachines
|
|
- entry points
|
|
- exit points
|
|
- submachine states
|
|
|
|
@reqdef{RQPC108} The generic "dispatch" operation must not use dynamic memory.
|
|
|
|
@reqdef{RQPC109} The generic "dispatch" operation must be deterministic.
|
|
|
|
@reqdef{RQPC110} The generic "dispatch" operation must use limited and known amount of call stack.
|
|
|
|
@reqdef{RQPC111} The application-level code shall have an easy access to the instance variables via just one pointer.
|
|
|
|
@reqdef{RQPC112} The application-level code shall have an easy access to the current event via just one pointer.
|
|
|
|
|
|
@section srs_qf Active Object Framework
|
|
|
|
|
|
|
|
@section srs_qv Cooperative Run-to-Completion Kernel
|
|
|
|
|
|
|
|
@section srs_qk Preemptive Run-to-Completion Kernel
|
|
|
|
|
|
|
|
@section srs_qxk Preemptive Blocking Kernel
|
|
|
|
|
|
@next{srs_nf}
|
|
*/
|
|
/*##########################################################################*/
|
|
/*! @page srs_nf Non-Functional Requirements
|
|
|
|
|
|
@section srs_quality Software Quality Attributes
|
|
|
|
|
|
|
|
@section srs_perform Performance Requirements
|
|
|
|
@reqdef{RQPC201} The software shall support hierarchical state nesting
|
|
|
|
@amplification
|
|
State hierarchy is the primary mechanism of behavioral reuse in state machines.
|
|
|
|
@rationale
|
|
This is a useful thing to have
|
|
|
|
@section srs_port Portability Requirements
|
|
|
|
@reqdef{RQPC202}
|
|
The software shall support hierarchical state nesting
|
|
|
|
@par Amplification
|
|
The implementation must be traceable.
|
|
|
|
|
|
|
|
@section srs_safe Safety Requirements
|
|
|
|
|
|
|
|
@section srs_secure Security Requirements
|
|
|
|
|
|
|
|
@section srs_constr Constraints
|
|
|
|
|
|
@section srs_standards Compliance with Standards
|
|
|
|
|
|
@next{sas_toc}
|
|
*/
|