dave_user, Administrators
5,144
edits
Changes
no edit summary
{{InfoBoxTop}}
{{AppliesToMachineLearning}}
{{AppliesTo Machine Learning TN}}
[[Category:MISC-AN-TN]]
[[Category:MISC-TN]]
|August 2020
|First public release
|-
|1.0.1
|August 2020
|Minor fixes
|}
As stated previously, a an H.264 video file is also generatedby combining all the saved frames. This can be convenient for users when they wish to analyze the evolution of the framed scene from a dynamic perspective.
==Real-timeness, frame loss, and alarm detection latency==
The top part shows the ideal recording buffer. As described in section [[#Sizing the alarm buffer|''Sizing the alarm buffer'']], the recording is supposed to start 8 seconds (t<sub>B</sub>) before the occurrence of the alarm event (t<sub>0</sub>) and end 3 seconds afterwards (t<sub>A</sub>). As a matter of fact, the recording system takes some time to recognize that the alarm signal is asserted—we refer to this time as ''alarm detection latency''. The fact that this latency is greater than 0 leads to the actual situation illustrated in the bottom part of the picture. Let t<sub>0'</sub> be the actual instant when the PP detects the assertion of the alarm signal. Consequently, the beginning and the end of the recording buffer (t<sub>B'</sub> and t<sub>A'</sub> respectively) are delayed as well. Of course, alarm detection latency should be minimized in order to get the actual recording buffer as close as possible to the ideal one. If the latency is too large, in fact, the recording could miss essential events. For instance, let's assume that the alarm was triggered by a failure occurring at time t<sub>F</sub> as shown in the picture. Because of the alarm detection latency, this instant is before the start of the actual recording buffer (t<sub>F</sub> precedes t<sub>B'</sub>) and thus it is not available for the post-mortem analysis.
In light of these requirements, it is clear that the processing platform should be engineered as a real-time systemto avoid exceeding a maximum latency. 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) (*).
<pre class="board-terminal">
</pre>
* Concerning alarm detection latency, a tailor-made testbed was built as illustrated in the next section.
(*) Incidentally, this mechanism exploits frame timestamps described in [[#Alarm recordings|this section]].
Fig. B1 shows the emulated alarm signal (magenta) and the signal used to update the 7-segment displays when the timer reaches 50.000 (light blue). This signal is connected to the "latch clock" inputs of the shift registers so that all the displays are updated simultaneously.
Turning on/off LED's is a very fast process, comparable with the propagation time of the shift register itself. Thus, it can be assumed that the displays show 50.000 within a few tens of nanoseconds after the rising edge of the latch clock. This , that is long microseconds before the assertion of the emulated alarm signal, proving . This proves the correctness of the timer implementation.
==Credits==
*Industrial automation image source: [https://www.freepik.com/vectors/technology Technology vector created by macrovector - www.freepik.com]
