4.2.2.4 Recoverability

return to Non-Functional Requirements

About

Return to the Top

recoverability is the ability of a system to be rebuilt in the event of a system failure do to human or natural disasters or catastrophic failures in hardware or software. After the system is recovered it is able to resume with full functionality with minimum interruption. For example in DataBase Management System's (DBMS), a Checkpoint is a place in time where the database transactions, operations, and logging are paused long enough to be completed and recorded into the database files. These files are then archived (i.e., copied, backed up) away from the current database files. After the Checkpoints operation is complete, the DBMS can resume with new transactions, operations and logging. Although the concepts of a Checkpoints are usually thought of in conjunction with DBMSs, it is also possible to have Checkpoints applied to Operating Systems (OSs) as well. Virtual Machines (VMs) and containers (i.e., docker) can be thought of as a checkpoint made against the OS files, logs, etc. at a particular point in time. Every time the VM or Container are reloaded, they start from a set known point (a Checkpoint).

DDS Specifics

Return to the Top

data_distribution_service_dds can log all the messages sent over a topic. The logs can then be replayed back in order to restore or recreate a particular scenario in the future This is invaluable for testing and training not just for the DDS infrastructure but also the components that use the DDS, and the people that use the system such as c2 consoles, medical devices scenarios, etc.

Note: There are several excellent examples provided in section 03_user.