Changes

==Real-timeness, frame dropping, and alarm detection latency==One of the major concerns that were faced during the conception of the PoC was related to its real-timeness. In principle, regarding two real-time requirements have to be met to achieve the desired functionalities:# [R1] Regarding the acquisition of the frames from the image sensor, such a PoC should be based on a real-time system because it should guarantee that all frames are captured (i.e. no frame loss), no matter what processing the PP is performed performing simultaneously (encoding the live stream, serving a web page, etc.). HoweverTaking into account the frame rate and the fact that the sensor has no buffering capabilities, this requirement holds when implies that the system is waiting for an alarm processing platform has about 3ms to happencomplete the acquisition of each frame. Once an # [R2] Maximum alarm buffer is filled, a fame loss can detection latency has to be tolerated. When an much smaller than the alarm is detected, say A1, the system, in fact, ignores new possible alarms until the buffer associated with A1 is stored on the SSDsize.

A new frame The first requirement is sent by obvious, but it can be relaxed a little bit in the image sensor sense that it has to be satisfied while when the processing platform every 3ms approximatelysystem is waiting for an alarm to happen and until the alarm buffer is filled. Taking into account After that the sensor has no buffering capabilitiesmoment, a fame loss can be tolerated because it does not compromise system functionalities. In other words, this implies that the processing platform has to complete following the acquisition detection of a frame in less than 3ms although new alarm say A1, it is acceptable that the arrival of a system ignores new frame possible alarms until the buffer associated with A1 is an asynchronous eventstored on the SSD.

R2 is a little more subtle and it will be explained with the help of Fig. 3.  [[File:TBD.png|thumb|center|600px|Alarm detection latency]]  TBD  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 system platform not specifically designed with real-time capabilities was used to limit the implementation effort and the costsdevelopment time. Rather, it was decided to use a platform providing enough headroom in terms of processing power and to verify experimentally the fulfillment of requirements. Basically, two methods different approaches were utilized for this verification.# At the application software levelRegarding frame loss, a mechanism able to detect any it was implemented at the application software level. Should a frame loss was implementedoccur, this event is logged and reported. Incidentally, this mechanism exploits frame timestamp timestamps describedin [[#Alarm recordings|this section]].# A tailor-made testbed  ===Alarm detection latency===