Requirements of performance measurements for DDS¶
This page contains the requirements for the performance measurements in DDS. It is separated into 2 chapters. One of them contains the requirements of the client. The other chapter contains the specifications. The specifications describe the requirements in a SMART way. These specifications are therefore testable to see if the requirement is met. The specifications are, in this project, created by the developer and discussed with the client.
The table below shows all the requirements and specifications. Additionally, it shows the specifications that belong to a requirement. This way, the specifications linked to a requirement can easily be found.
ID | Type | Title | Incoming | Outgoing |
---|---|---|---|---|
Doc_1 | req | readable documentation | DOC_DEV; DOC_INSTRUCTIONS; DOC_SPH; DOC_QoS | |
Doc_2 | req | formal documentation | DOC_UML; DOC_DDS | |
Doc_3 | req | team pages documentation | ||
Perf_1 | req | performance of DDS | PERF_LIB; PERF_CPU; PERF_MEM; PERF_CONNECT; PERF_DISCONNECT; PERF_QoS; PERF_SCALABLE | |
Learn_1 | req | learning | LEARN_WRAPPER | |
Commer_1 | req | commercial availability | COMMERCIAL_LICENSE | |
API_1 | req | API's | API_TEST; PERF_API | |
DOC_DEV | spec | further development documentation | Doc_1 | |
DOC_INSTRUCTIONS | spec | documentation instructions | Doc_1 | |
DOC_SPH | spec | documentation style | Doc_1 | |
DOC_QoS | spec | documentation of Quality of Service policies | PERF_QoS | Doc_1; PERF_CPU; PERF_MEM; PERF_CONNECT; PERF_DISCONNECT |
DOC_UML | spec | PlantUML usage | Doc_2 | |
DOC_DDS | spec | software documentation of DDS | Doc_2 | |
PERF_LIB | spec | software DDS library | Perf_1 | |
PERF_CPU | spec | performance CPU | DOC_QoS; PERF_QoS; PERF_SCALABLE | Perf_1 |
PERF_MEM | spec | performance memory | DOC_QoS; PERF_QoS; PERF_SCALABLE | Perf_1 |
PERF_CONNECT | spec | performance of connecting | DOC_QoS; PERF_QoS; PERF_SCALABLE | Perf_1 |
PERF_DISCONNECT | spec | performance of disconnecting | DOC_QoS; PERF_QoS; PERF_SCALABLE | Perf_1 |
PERF_QoS | spec | performance difference Quality of Service policies | Perf_1; PERF_CPU; PERF_MEM; PERF_CONNECT; PERF_DISCONNECT; DOC_QoS | |
PERF_SCALABLE | spec | documentation of Quality of Service policies | Perf_1; PERF_CPU; PERF_MEM; PERF_CONNECT; PERF_DISCONNECT | |
LEARN_WRAPPER | spec | software wrapper | Learn_1 | |
COMMERCIAL_LICENSE | spec | commercial license | Commer_1 | |
API_TEST | spec | different API's | PERF_API | API_1 |
PERF_API | spec | performance different API's | API_1; API_TEST |
Requirements¶
The requirements are given by the client and are not SMART defined.
Documentation¶
The graph below shows the linkage between the requirements and the corresponding specifications. These requirements are all related to the documentation.
The requirement of the team pages does not contain any SMART defined specifications. The team pages can be used for documenting things quickly and less precise. There are no additional specifications bound to this requirement.
The documentation must be readable for developers who want to learn more about DDS. |
The formal documentation is the documentation for the delivered artefacts and should be clear and concise. |
The team pages may have less concise language, there are no additional requirements for the team page documentation other than the General requirements. |
Software¶
The graph below shows the link between the requirements and the corresponding specifications. These requirements are all related to the software that shall be developed during the project.
The performance of DDS shall be measured with various configurations. |
The delivered artefacts are made for learning/explaining DDS. |
The delivered software can be used in commercial products. |
The effect of different API’s for DDS must be compared with each other, if possible. |
Specifications¶
The specifications are defined with the client. These are derived from the main requirements.
Documentation¶
The specifications for the documentation are listed below.
Every artefact shall be documented in such extent that a developer knows how DDS is used within the artefact. Note This specification can be checked by giving 2 developers the project including the documentation. They should be able to explain how DDS is used within the project. |
Every artefact contains execution instructions that can be followed by developers. Note This requirement can be checked by giving 2 developers the project including the documentation. They should be able to successfully execute the instructions. |
The documentation shall be written in ReStructured Text for Sphinx. |
The performance differences between Quality of Service policies are documented. Note There must be results of performance measurements that show what Quality of Service policies are faster or slower based on the performance measurements (performance CPU (PERF_CPU), performance memory (PERF_MEM), performance of connecting (PERF_CONNECT), performance of disconnecting (PERF_DISCONNECT)). At least 2 different Quality of Service policies must be compared with each other. |
All diagrams within the Sphinx documentation shall be written using PlantUML, if they are supported by the PlantUML language. Note This also includes the extended functionalities of PlantUML like Ditaa and DOT. |
The use of DDS within the software shall be documented. Note The documentation of the software shall contain a technical explanation of how DDS is used within the application. |
Software¶
The specifications for the software are listed below.
The Cyclone DDS library shall be used as the DDS implementation. Note Only if something is not implemented in the CycloneDDS library, a different DDS implementation may be used for the tests. |
The CPU usage of different Quality of Service policies shall be measured. |
The memory usage of different Quality of Service policies shall be measured. |
The time between the DDS registration of a device and the notification of other devices shall be measured. |
The time between the DDS disconnection of a device and the notification of other devices shall be measured. |
The performance of Quality of Service policies within DDS shall be compared to each other. |
The difference in performance, CPU/memory footprint, registration time, disconnection time, shall be recorded with 2 devices in the network compared to at least 4 devices in the network. Note This requirement tests the scalability of DDS. |
The functions of Cyclone DDS shall not be used within a wrapper. |
The delivered software shall be in accordance with the MIT, BSD or Apache licenses, with an exception for the DDS library. |
The communication between 2 different APIs shall be tested (The C/C++ API and the Python API). |
The difference in performance, speed of the implementation, shall be measured between different APIs (if this is possible, see requirement different API's (API_TEST)). |