dave_user, Administrators
5,138
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
|}
In essence, the system consists of a high-frame-rate image sensor (*) interfaced to a Linux-based embedded platform also denoted as PP in the rest of the document. The sensor frames a specific area of the production line and sends a constant-rate flow of frames to the PP for further processing, as detailed in the following sections.
The first part is a progressive counter, starting from 000000. In other words, the image whose file name is something like 000000_x.bmp refers to the frame captured at the beginning of the recording window (t<sub>B</sub>). At the other end, the image whose file name starts with the highest counter refers to the frame captured at the end of the recording window (t<sub>A</sub>). This scheme is convenient for automatically processing the frames because it allows to order them very easily.
The second part of the file names is the relative time offset (expressed in seconds) with respect to the "alarm frame." The alarm frame, in turn, is the first frame captured after the detection of an alarm signal. Consequently, the alarm frame is always named as <code>n_+0.000000000.bmp</code>. In other words, this frame is associate associated with t<sub>0</sub>. In the example shown above, the alarm frame's name is <code>002424_+0.000000000.bmp</code>. This rule allows to determine straightforwardly how close a frame is to the alarm event. For instance, see the following image that refers to a screenshot captured on the processing platform itself.
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]].
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 frames is correct (3333) and the assessment of the aforementioned specific frames 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 and similar results were found. Nevertheless, it is worth mentioning that this analysis does not allow to say that the processing platform behaves like a true real-time system with regard to capturing the high-frame-rate flow of frames and processing the alarm signal. As such, we can not determine the upper bound of alarm detection latency, for example. Rather we can say that the system '''typically''' performs as in the example detailed here. And this This result is enough to satisfy this the PoC's requirements.
== Appendix B ==
This section provides some further details regarding the testbed utilized for the alarm detection latency verification. The following screenshot shows the emulated alarm signal, which is generated by the custom timer. It consists of a 1-second positive pulse. [[File:MISC-TN-015-timer-alarm-signal.png|thumb|center|600px|Fig. B1: Emulated alarm signal generated by the custom timer]] Each display is statically driven by a [https://www.onsemi.com/pub/Collateral/MC74HC595-D.PDF 74HC595] shift register in order to avoid multiplexing that would be detrimental for our purpose. [[File:MISC-TN-015-timer-refresh-alarm.png|thumb|center|600px|Fig. B2: Emulated alarm signal and latch clock when displaying 50.000]]
==Credits==
*Industrial automation image source: [https://www.freepik.com/vectors/technology Technology vector created by macrovector - www.freepik.com]
