Bureaucrats, dave_user, Administrators
4,650
edits
Changes
no edit summary
== Appendix A ==
In this appendix, the log indicated in section [[#Real-timeness, frame loss, and alarm detection latency|''Real-timeness, frame loss, and alarm detection latency'']] will be further analyzed to provide more details about the application software. During normal operation, if the alarm detection functionality is enabled, the application waits indefenitely for an alarm to be raised:
<pre class="board-terminal">
[2020-08-10 10:48:53,674][INFO][main_logger.main] SAVING_ALARM_BUFFER -> STREAM_ONLY
[2020-08-10 10:48:53,675][INFO][main_logger.main] STREAM_ONLY -> WAITING_FOR_ALARM
</pre>
When this event occurs
<pre class="board-terminal">
[2020-08-10 10:49:22,570][DEBUG][main_logger.main] Alarm signal asserted
</pre>
, the application changes state and completes filling the alarm buffer
<pre class="board-terminal">
[2020-08-10 10:49:22,571][INFO][main_logger.main] WAITING_FOR_ALARM -> FILLING_ALARM_BUFFER
</pre>.
As per system requirements, it takes 3 seconds to fill the buffer after the alarm occurrence (from 10:49:22,570 to 10:49:25,631 in this example). Right after filling process is completed, a specific thread is resumed to store the buffer on the disk:
<pre class="board-terminal">
[2020-08-10 10:49:23,571][DEBUG][main_logger.main] Alarm signal deasserted
[2020-08-10 10:49:25,631][INFO][main_logger.alarmbuffersaverthread] Starting AlarmBufferSaverThread ...
[2020-08-10 10:49:25,631][INFO][main_logger.main] FILLING_ALARM_BUFFER -> SAVING_ALARM_BUFFER
</pre>.
Interestingly, while the PP is saving the recording buffer on the disk, some frames from the image sensor are lost due the non real-time nature of the system. As explained previously, this is tolerable.
<pre class="board-terminal">
[2020-08-10 10:49:25,678][ERROR][main_logger.main] Abnormal frame rate (42.6 fps)
[2020-08-10 10:49:25,716][INFO][main_logger.alarmbuffersaverthread] Deleting oldest alarm ...
[2020-08-10 10:50:48,822][ERROR][main_logger.main] Stopping to stream frames ...
[2020-08-10 10:50:48,855][ERROR][main_logger.main] It is enough data for buffer ...
</pre>
The following messages refer to a new alarm signal that happened during the writing on to the disk. This alarm is ignored because the system is not designed to process more the one alarm at a time.
<pre class="board-terminal">
[2020-08-10 10:51:02,582][DEBUG][main_logger.main] Alarm signal asserted
[2020-08-10 10:51:03,581][DEBUG][main_logger.main] Alarm signal deasserted
</pre>
Finally, after the completion of storing persistently the buffer, the system is ready to detect and process a new alarm again:
<pre class="board-terminal">
[2020-08-10 10:51:59,825][INFO][main_logger.alarmbuffersaverthread] Ending AlarmBufferSaverThread ...
[2020-08-10 10:51:59,844][INFO][main_logger.main] SAVING_ALARM_BUFFER -> STREAM_ONLY
