As you know, total redundancy is more or less impossible to achieve. The redundancy we incorporate in our solutions are redundant power supplies, fans and storage (RAID-configured) on each recording server. Redundant recording solutions has of course dual recording servers. Single-point-of-failure items are mainly interface units for audio and screens. These units distribute the data to the recorders over Ethernet.
All sources recorded by the guardREC® recording solution is presented as redundant IP packages. Our source interface units distributes the data over dual LANs, and the original IP-sources (ED-137 and IP radar feeds) are distributed to the recorders over dual LANS.
In projects where we deliver the hardware, we normally uses HP ProLiant servers due to their flexibility and reliability. For small solutions, we use the HP ProLiant DL20 which is 38,22 cm deep.
Our recording software license is based on channels. We do not differentiate on type of audio
channels, which means that if the customer upgrades their VCCS audio-distribution from
analogue to ED-137 and keep the same number of channels, the only impact will be to configure a new transformer receiving ED-137 instead of analogue audio.
By default, the Quarantine location is c:/guardrec/quarantines, but this can of course be defined by the user.
If the purpose of storing the quarantine on a removable media or as a file to transfer is to be able to replay the Quarantine on a PC not connected to the recorder, I would suggest to export the Quarantine either as a standard export file or as an Impound file. If the export is meant used during an investigation, Impound is preferred.
The Impounded (or exported) data-set is found in the download-folder on the PC performing the Impound, and can easily be pasted in a mail or on a USB stick. The password required to replay the Impounded data-set should be sent in a separate mail. The password is also found in the Audit Trail if the user forgot to write it down during the Impound process.
Yes, it is supported.
The channel mapping for the ED-137 is done automatically. The channel mapping is a little different depending on if we’re recording ED-137b or ED-137c. If we’re recording ED-137b, we/user define the Channel Mapping differentiators. By default, this is the IP address in combination with the Frequency. These can be altered, if the customer wants to differentiate the channels based on other criteria. ED-137c have specified that these shall be the differentiators. One of our customers always records ED-137b, and wants in addition to record each operator on a separate channel. This is solved by adding another Transformer which have the IP as a separator. This channel will then contain all communication from a certain IP address independent of frequency.
This is also supported. All resolutions up to 4k x 2k, Either lossless or H.264 encoded. The replay of screens can be made in full sync with TTW replay, voice and other recorded data.
I’m assuming that with “Radar video” you mean the screen images of the radar screen, and not the actual radar feeds. Screen images are stored in exactly the same resolution as they presented on the operator’s monitor. 4K images are stored as 4K images. The storage location is determined by the user, based on configured storage locations. Since the recorded screendata are significant larger than audio or radar feeds, some customers choses to have a dedicated folder for the screen data with a shorter retention period in order to increase storage capacity. The replay service in the guardREC® application keeps track on where the data are stored, so the user will not notice that some data are stored in a different location than other data.
Yes, it is possible to easily upgrade a current GuardREC version with support for Radar Replay and Investigation. A license upgrade linked to radar channels and the radar replay feature is required.
If the radar data is sent on LAN then there is no need for any special interface. Radar feeds distributed over serial lines requires a serial interface unit. The guardREC systems is compatible with most Asterix protocols.
The (blue) line between the targets are only for visualization. The Horizontal separation is the horizontal vector (in Nautical miles) and Vertical separation is the vertical vector (in feet).
Any sensor type as presented in, or by, the Asterix protocol can be selected, but not a combination of types for the same radar feed. The system supports presentation of multiple radar feeds where target types can be presented individually for each radar feed and as such one can say that a combination of types are also possible.
Playback can be selected for dedicated flights both in real time and scenario mode. This is achieved by selecting the track in question and use the Opacity function to hide those track not of interest. The track can also be easily identified by the “Search for track” function.
Keyboard and mouse recording is something which we have on our roadmap. We have designed the solution and it’s fairly straight forward to implement it. The request for this type of recording has reduced over the last years, and we have therefore not prioritized it. If requested; we’ll implement it in our solution.
Multiple site topology is supported. Operators can sit in a central location performing investigation, monitoring and configuration. Central operation requires a LAN or WAN connection(s) to the sites.
Remote replay follow the same principle as Multiple site topology.
Yes, you are correct. Chrome is the preferred browser (V8 engine).
The only requirement for the replay- and configuration station is that it has Chrome installed and that it’s connected to the recorders over LAN or WAN. A KVM or laptop is sufficient. Please remember that you also need speakers, if the unit doesn’t have this in-built. You can also use an existing PC and add the recorder IP sub-net to the NIC, and connect it to the recorder.
One cannot interact with ATG recording (this is simply screen grabbing/bitmap). The presentation I made was with TTW input. We support recording of both ATG and TTW (at the same time), but I wanted to focus on TTW replay in this webinar.
Interactive investigation is often done by the local ATCO based on recording of the existing radar system. This can be done in multiple ways when audio communication is a requirement. Either two systems in parallel (ATC recording system and Voice recorder) or as a hybrid solution. With GuardREC Radar recording and replay the local investigators can more easily prepare the case to the regulator. The Radar replay can also be used as a training facility.
Yes, it does. And a few more filtering options too.
License-wise the smallest solution we have is 4 channels. It’s the same application which is used in all solutions, which means that all installed solutions have the same flexibility independent of the original configuration.
The guardREC® has no real practical limitation on how many audio and radar channels we can record. The system can scale both in terms of performance and storage by adding servers and necessary hardware. The software has no limit.
That is a large system, but yes we support it. Our system is very scalable in both performance and storage. In reality, no limitation as one has to add hardware to support the size. Screens and other types of data (radar, ed-137, IP cams…) may be added to the system at any time without the need to reconfiguration of the whole system and it does not even have to restart. Just add, configure the module, and start. Then the sources will be available for replay together with existing sources immediately.
There is no accurate answer to this question. Export of a longer time period will take more time than export of a shorter time period. I tried to export one minute of a video channel, and it took approx. 5,5 seconds. 3 minutes of video took approx. 13,5 seconds. In other words; not too long time.
Our API is a RestFUL API and is included / open in the recording application. We did the implementation towards the Thales TopSky solution last year, and it worked perfectly during the tests at Thales together with their TopSky C, X and He. We can automatically create an API manual depending on the application version of the guardREC® Recording solution. Attached you’ll find the manual for version 4.16, which is the version I used during the presentation.
Yes, the GuardREC system can be integrated to any ATC system and we already have integration with several ATC vendors.
In principle yes. So far Thales is the only ATM system vendor which has certified our solution. Indra will be implemented this year. Having said that, we have a very rich API which allows for easy integration.
Yes. Depends on which ATM vendor/system.