Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Alarm detection latency verification
In light of these requirements, it is clear that the processing platform should be engineered as a real-time system. Despite these considerations, however, a platform not specifically designed with real-time capabilities was utilized. Rather, it was decided to use a platform providing considerable headroom in terms of processing power and to verify experimentally the fulfillment of requirements. This approach allowed to meet the budget available for the PoC by limiting implementation effort and development time. Basically, two different approaches were utilized for experimental verification.
* With regard to frame loss, a mechanism able to detect this anomaly was implemented at the application software level. Should a frame loss occur, this event is logged and reported as shown by the example log below (see "Abnormal frame rate" messages) (*). Incidentally [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 [2020-08-10 10:49:22,570][DEBUG][main_logger.main] Alarm signal asserted [2020-08-10 10:49:22,571][INFO][main_logger.main] WAITING_FOR_ALARM -> FILLING_ALARM_BUFFER [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 [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:49:25, this mechanism exploits 778][ERROR][main_logger.main] Abnormal frame rate (59.6 fps) [2020-08-10 10:49:25,839][ERROR][main_logger.main] Abnormal frame timestamps described in rate (74.5 fps) [2020-08-10 10:49:25,938][INFO][main_logger.alarmbuffersaverthread] Saving to /mnt/alarms/2020-08-10_10.49.22_CEST [2020-08-10 10:50:45,750][ERROR][main_logger.main] Stopping to stream frames ... [2020-08-10 10:50:45,784][ERROR][main_logger.main] It is enough data for buffer ... [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 ... [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 recordings|this sectionsignal deasserted [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 [2020-08-10 10:51:59,844][INFO][main_logger.main]STREAM_ONLY -> WAITING_FOR_ALARM* Concerning alarm detection latency, a tailor-made testbed was built as illustrated in the next section.
===Alarm detection latency verification===
The following diagram shows how the specific testbed used for this verification looks like.
In essence, the idea consists of shooting a 5-digit 7-segment-display timer with 1ms resolution. The timer cycles repeatedly from 00.000s to 99.999s and also provides a digital signal that is used to emulate the alarm signal. Whenever the timer reaches 50.000s, this signal is raised for 1 second. In other words, the timer triggers an emulated alarm that is synchronized with the visualization of the 50th second on the displays. Referring to the Fig.X TBD2, istants t<sub>B</sub>, t<sub>0</sub>, and t<sub>A</sub> can be easily associated with the time visualized by the timer as follows:
*t<sub>B</sub> = 50.000-8.000 = 42.000s
*t<sub>0</sub> = 50.000s
*The timer displaying 50.000.
Let's analyze one of the recording buffers that were captured this way. It refers to the alarm recorded on Agust 8, 2020 at 12.09.51 CEST. The following images show the frame associated with t<sub>B'</sub>, t<sub>A'</sub>, and t<sub>0'</sub> respectively.
*t<sub>B'</sub> frame
**This frame is named <code>000000_-8.133780480.png</code>
**The timer displays 41.86x(expected 42.000)
*t<sub>A'</sub> frame
**This frame is named <code>003332_+3.046812160.png</code>
**The timer displays 53.04x(expected 53.000)
What about t<sub>0'</sub> frame? It is named correctly (<code>002424_+0.000000000.png</code>), but the timer displays 98.88x, which is not what we expected at all. Why? To find the answer, let's have a look at the subsequent frame:
Timer displays 50.00x. This means that, in the middle of the exposure window associated with the alarm frame, the timer refreshed all the 7-segment displays from something like 49.xyz to 50.abc. Thus, all the digits were affected by a change during the acquisition and this is the reason why they do not appear consistently.
In conclusion, the number of stored frame is correct (3333) and the assessment of these frames—which the aforementioned specific frames was repeated over several recordings—was completed successfully because the discrepancies are in the order of hundreds of milliseconds, therefore much smaller than the size of the recording window. These checks were repeated over several recordings. Nevertheless, it is also worth mentioning that this analysis does not allow us to say that the processing platform behaves like a true real-time system when it comes wit regard to acquiring capturing the high-frame-rate flow of frames coming from the image sensorand processing the alarm signal. InsteadAs such, we can draw not determine the conclusion upper bound of alarm detection latency. Rather we can say that it the system '''typically''' performs like as in the example detailed here. And this is enough to satisfy this PoC's requirements.
ML
Appendix A
[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
[2020-08-10 10:49:22,570][DEBUG][main_logger.main] Alarm signal asserted
[2020-08-10 10:49:22,571][INFO][main_logger.main] WAITING_FOR_ALARM -> FILLING_ALARM_BUFFER
[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
[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:49:25,778][ERROR][main_logger.main] Abnormal frame rate (59.6 fps)
[2020-08-10 10:49:25,839][ERROR][main_logger.main] Abnormal frame rate (74.5 fps)
[2020-08-10 10:49:25,938][INFO][main_logger.alarmbuffersaverthread] Saving to /mnt/alarms/2020-08-10_10.49.22_CEST
[2020-08-10 10:50:45,750][ERROR][main_logger.main] Stopping to stream frames ...
[2020-08-10 10:50:45,784][ERROR][main_logger.main] It is enough data for buffer ...
[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 ...
[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
[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
[2020-08-10 10:51:59,844][INFO][main_logger.main] STREAM_ONLY -> WAITING_FOR_ALARM
==Credits==
*Image sources:
**[https://www.freepik.com/vectors/technology Technology vector created by macrovector - www.freepik.com]
