Final Report Summary - ASPIS (ASPIS - Autonomous Surveillance in Public transport Infrastructure Systems)
Executive Summary:
Introduction
The prompt availability of relevant information to the right people is the critical factor for the management of any emergency situation, in particular during the critical, early post-incident stages.
In case of a catastrophic event such as a bombing in a subway or the wreck of a ship, a quick assessment of the situation and the awareness of the number of potential victims could improve drastically the rescue operations and help to save lives.
The ASPIS project has the ambition to fill this gap by developing a video “black-box” able to send video sequences recorded just before the event to the rescue teams to help them in their tasks.
The project aims to develop and test a scalable, unattended surveillance/alarm system for public spaces, in particular for public transportation systems. Having a highly modular architecture, this innovative system is meant for the unattended surveillance of public transport, maritime transport and other public spaces. It serves primarily for the prompt and reliable situation awareness during the early, most critical emergency phase, thus greatly facilitating the overall crisis response. It is an innovative application enabling civil protection authorities to take advantage of the most recent developments in the fields of ad-hoc networking, multi-modal communications, embedded systems and microprocessor integration.
Project Context and Objectives:
The objectives and work performed can be divided into four main parts: operational and functional requirements analysis, technical analysis on the state of the art and available solutions, system design and development, demonstration
• Operational and Functional Analysis
The objectives of the operational and functional analysis were to identify the operational requirements and the functional specifications of the ASPIS system with the End-users, in the scope of improving crisis management in case of a bombing blast in a subway or the wreck of a ferryboat.
The results of this phase are input to the continued work with the systems and sub-systems design and development. They are also used for the definition of the acceptance criteria necessary for the testing and validation procedures. During this phase, the ASPIS end-users involved all the actors who interface directly with the ASPIS system in case of an emergency, like transport police, fire brigades, the ship’s captain or any other entities involved directly in metro or ferry vessel SAR operations.
• Technical analysis
In the technical analysis phase, state-of-the-art studies and feasibility testing of particular components for the ASPIS devices were performed. Three areas were mainly analysed: networking and communications, modularity and system integration and finally mechanical packaging and cost of the future solution. Technologies available and able to fulfil the functional requirements were identified and compared to the subway of ferry environment constrains allowing finally to give the inputs to design and development of the ASPIS component.
• System design and development
The systems design and development started in June 2009. The outcomes from the operational and functional analysis and from the technical analysis phases have been developed into specifications for the ASPIS sub-systems and full system. Availability and maturity of the technologies as well as environmental constrains proved to be strong factor for the selected solutions.
The architecture of the AMD (ASPIS Mobile Device) has been designed in order to be able to interface either with analogue cameras (legacy cameras) or IP cameras. The mechanical design of the AMD was achieved taking mainly into account the RATP requirements which were the most severe concerning available space (volume) and thermal requirements (heat draining without using a fan). The PC 104 form factor was selected for the processor board and frame grabber. An Ethernet switch available of the shelf has been selected for its environmental specifications and PoE capabilities meeting RATP requirements. It has been integrated in the AMD so as to provide connections for IP cameras directly powered by Ethernet (PoE). IP cameras with H.264 compression have been developed as well as a 4 channel video encoder able to compress in H.264 the videos streams provided by 4 analogue cameras and convert them into an IP stream.
The AMD communication, management and recording software has been developed in order to interface with its various peripherals (IP cameras, compression board, power management module, Wimax unit, Wifi modules) as well as with other AMDs (for redundancy and alarm spreading) and with the ASC (ASPIS Central Station). AMD power supply needed some particular attention for the selection of the battery and development of the power supply management system in order to meet the operational requirement.
Different communication paths have been developed to allow the AMDs to communicate inside the train as well as with the ACS located in the central control room. They can communicate using either a wired Ethernet link, a Wifi connection or even an ad-hoc Wifi connection. The AMD communicate with the ACS through Wimax and the Wimax unit. The Wimax unit communicates with the AMDs using either a wired Ethernet link or a Wifi connection.
This allows redundant communication paths and the ability to send data even if one communication mean is destroyed during the catastrophic event (probably the wired connection).
The ACS software has been developed in order to work either on a fixed platform (a laptop) for control room operation, or on a mobile platform (a tablet PC) for rescuers.
• Subway Demonstration
For the subway application, three AMDs were installed in a subway train and each recorded the video streams of six cameras. The triggering device composed of a microphone sensor and a pressure sensor was activated to send an alarm which froze the video buffers. The alarm as well as snapshots grabbed at the time of the alarm were transmitted to the ACS located in the Control room via the Wimax link and FO network. After alarm validation by the ACS, the AMDs transferred their video buffers, giving to the operators a clear view of the situation as it was just before the event and just after the event. The demonstration also showed the capacity to transfer a live video and audio stream from the train to the control room from anywhere in the tunnel between two stations.
• Maritime Demonstration
Two maritime scenarios were created to respond to IMO (International Maritime Organisation) requirements. The first scenario demonstrated the ability of the ASPIS system to detect an intrusion in a restricted zone using video analytics. The intrusion alarm was detected by the AMD and transferred to the ACS on the bridge with a video sequence showing the intrusion. The second scenario consisted in detecting people re-entering a zone that had been evacuated following an “Abandon Ship” order. In this scenario, cameras were installed in the passageways of the ship. The AMD and cameras are disabled in normal conditions for privacy preserving reasons. However, in case of fire or wreckage, the passengers are evacuated zone by zone by the crewmembers and when a zone had been fully evacuated, the AMD covering the zone is activated in order to detect by video analysis people trying to re-enter the zone and sent an alarm to the Captain.
Both demonstrations worked very satisfactory and demonstrated the ASPIS concept as fulfilling the requirements.
Project Results:
1. WP2 – Requirements & specifications
This work package has been launched during the kick-off meeting in Patras, Greece, involving JRC as leader of the work package, Thales providing its industrial and market knowledge on the mass transport security domain, RATP, the Paris Metro operator and ANEK Lines, a major Greek Ferry operator.
Intensive work has been done with the two end-users, RATP and ANEK, in order to define operational requirements and functional specifications for the three use-cases of ASPIS system.
The first Application Scenario (AS 1) concerns the protection of subway trains. In case of an accident or a bombing in a train running in a tunnel, the communication means between the train and the Central Station have a high probability to fall out of order, leaving the rescue team in a crisis situation where they are not able to assess the situation. RATP experienced unfortunately several bomb attacks on their network (RER B at Saint Michel station in July 1995, RER B at Port Royal Station in December 1996) and they also had very close relations with the London Underground during and after the July 2005 bombing. So their experience and analysis of such dramatic situations is really essential. In case of the London bombing, this blackout period following the blast lasted more than one hour, making the rescue operation planning and management quite difficult. Was it an accident, a fire, a derailment, a bombing? Was it a chemical attack or did a dirty bomb explode? ASPIS system as described in the DoW could prove very helpful in offering a fast assessment of the situation and providing a rescue communication channel with the train.
Several meetings were organized at RATP premises in order to work on this use-case:
• 24/07/2008 – RATP Headquarters in Paris and Thales Premises in Vélizy.
Participants: Thales, JRC, HAI, RATP
The bombing scenario was discussed and the operational requirements were specified, in terms of pre-event recording duration, frame rate and image resolution. One important requirement concerns the fact that the face of a person entering rapidly the train has to be clearly recognisable on a recorded sequence. The field of view of the cameras was also discussed in order to provide a full coverage of the space inside the cars. A state of the art of the existing technologies as well as a presentation of the systems already in use in the metro stations or on-board busses was made by Thales. Some societal issues were discussed, about covered surveillance versus deterrence effect of visible equipment. Some more capabilities were discussed, such as night vision (thermal camera), but RATP confirmed that they do not have such requirement. They tested thermal cameras for monitoring the platforms and the tracks in order to detect people falling on the tracks, but they stopped their investigations in this field, as the results were poor in comparison to the cost of the solution.
• 08/12/2008 – RATP Headquarters and Thales premises in Vélizy.
Participants: all partners.
RATP organized a visit of their Security Centre (PC 2000) where they explained the architecture of their security system and the operational procedures, focussing more deeply on the usage of live video surveillance and recorded sequences. A simulation of an alarm was done in order to illustrate the way the system is used. RATP explained the distribution of responsibility between them, the Police and the Fire brigades, and how they collaborate or exchange information. The presentation continued with a visit to the investigation room where the recorded video are analysed and where sequences relevant for legal investigations are extracted.
This presentation gave the partners a better understanding of the operational use of the video surveillance in a subway network and gave valuable inputs for the architecture of the ASPIS system.
The maritime scenarios were discussed during the kick-off meeting in Patras and during face-to-face meetings between JRC and ANEK. The outcome of these meetings was to propose two maritime application scenarios:
The second Application Scenario (AS 2) concerns a ferry use-case and more particularly the surveillance of doors and accesses to sensitive rooms or spaces of the ship. The new security regime and the ISPS code introduced a number of additional access restrictions on board of a vessel (i.e. bridge). Most doors, however, even if they have to be closed, cannot be locked (at least from both sides) as they serve for evacuation in case of emergencies. While most of the ships functions as well as the commands given from the bridge and the engine rooms are monitored at the bridge and recorded for documentation purposes, most restricted access doors are not monitored. In this use-case, the ASPIS system will be activated upon the opening of a restricted access door, signal the opening and document by a sequence of pictures showing who entered, exited or just opened a restricted access door. This information could be used by the ship’s captain for taking eventual corrective action and for documenting passages through the vessel’s restricted access doors.
The third Application Scenario (AS 3) concerns also a ferry use-case, but this time in a crisis situation when a vessel evacuation order has been given. The aim of the system, as described initially, is to provide a mean to the captain and the crew to be sure that all passengers of the ferry left the boat after an evacuation order has been given. This requirement is the consequence of several dramatic ship accidents in which passengers stayed trapped in their cabin and sunk with the ship after wreckage. The original idea, as described in the Description of Work, was to install small cameras part of the ASPIS system in all the cabins and, using video analysis, to detect if there are people in the cabin. In case of danger and need for evacuation of the ship, the ASPIS systems could detect people who did not evacuate the ship, alert the bridge and provide the crew with the location of the trapped passengers. If the usefulness of such a system in emergency conditions is undisputable, this scenario looks highly questionable for its possible effects on privacy issues, “big brother” syndrome etc.
As most of the work concerning the first deliverable had to be done over a short period across summer vacations, deliverable D2.1 on User Requirements and Operational Scenarios was finalized in Month 5, on schedule.
Deliverable 2.2 concerning Functional Specifications was more impacted by the hesitations concerning ISI and was finally issued at Month 9 instead of Month 6.
The concern about privacy issues in the third scenario described in delivery D2.1 was again discussed during the third plenary ASPIS meeting in Chania, Greece, in May 2009. As the meeting was held in ANEK headquarters, we could get the participation of people in charge of commercial issues and security issues. After extensive discussions with them, the installation of cameras in the cabins was finally rejected for privacy protection reasons, even if it could have been technically possible to de-activate the cameras in normal conditions. As a consequence, the originally foreseen scenario was modified as follows: the ASPIS cameras are no more installed in the cabins, but they are placed at all ends of the corridors giving access to the cabins. Upon an “abandon ship” signal, crew members are passing through the corridors checking that all cabins have been evacuated (this is part of the standard existing procedure). On the completion of such process they trigger the respective ASPIS device (i.e. the device controlling the access corridors of the particular set of cabins) so that ASPIS can effectively monitor that nobody accesses the cabins after these have been checked as empty. This change of scenario has minor consequences on the technical architecture of the system and it also decreases the risks concerning the complexity of image analysis in the cabins. The number of cameras will be reduced as they will no more be installed in each cabin but only in the gangways of the ship. The detection of people should be more reliable in this new configuration as the environment will be less complex in the gangways compared to the cabins were hidden zones could exist and lighting problems could occur. This change was presented to the Project Officer and approved.
This meeting gave also the partners the opportunity to visit the ANEK ferryboat ELYROS on which the ASPIS demonstration system will be installed. During this visit, the partners could discuss intensively with the captain and the officers of the ship and visit the bridge, the various decks as well as the machinery room. The partners could also exchange with Captain CHATZIDAKIS, Safety Manager of ANEK.
2. WP3 – System design
WP3 started in parallel with WP2, from the beginning of the project. This work package involved all academic and industrial partners. The end users RATP and ANEK Lines were not mentioned in the description of work; however they were regularly informed and even involved in the different choices and conclusions of this work package.
A first meeting specific to this WP took place at HAI premises in Tanagra, Greece on July 3rd 2008. It involved JRC, HAI and ISI in order to clarify the distribution of responsibilities between HAI and ISI concerning this work package. The following distribution was agreed:
• HAI
o Supervisory module
o Image acquisition module
o Embedded platform
o
• ISI
o Communication module
o Power module
o Location module
o Packaging
Deliverable 3.1 presents an analysis of the state-of-the-art of technologies that may be of use to the ASPIS project as well as of systems that are currently present on the market and that are relevant to the ASPIS functionalities. This analysis goes through technological aspects concerning embedded platforms, communication technologies, image acquisition technologies, sensor technologies for the ASPIS triggering, power module, ASPIS device mechanical aspects and finally enabling technologies for the ASPIS central station. In a second stage, D3.1 presents CCTV systems and their main components making a system state-of-the-art followed by an initial market study associated with the ASPIS expected outcome.
This report was achieved in Month 11, 5 months behind original schedule.
Deliverable 3.2 presents the Feasibility Report of the system proposed in the ASPIS project. It first presents in a tabular form the functional specifications coming from D2.2. Then, it analyses the feasibility per functional specification category referring respectively to system readiness, incident phase, uploading and processing of information and finally sustainability of the ASPIS system. It was delivered in Month 12, 3 months behind schedule.
Deliverable 3.3 is about System Architecture and Sub-Systems Specifications. A first version was issued in Month 12, almost on schedule. This first version covers almost all the system and sub-systems. However some parts such as location module, power supply or interfaces were still in discussion at this stage. As the main choices were already approved, it was decided to deliver a first version of document and not to delay furthermore the project. An updated version of this deliverable will be released later.
The interface protocols between the ASPIS sub-systems and components have been finalised in parallel with the development of the subsystems, as per work package 4. The specifications of these interfaces and communication protocols have been added to chapter 5 of deliverable 3.3 shortly after the beginning of the second period, following the Ispra plenary meeting in December 2009. The following protocol and interface definition of each software module have been described:
• Supervisory module (SUM) [Protocols 2.X)
• Triggering module (TM) [Protocols 1.X]
• Analogue camera module (frame grabber) (ACM)
• Digital camera module (DCM) [Protocols 5.X]
• Communication module (COM) [Protocols 3.X]
• ASPIS Central Station (ACS) [Protocols 4.X]
All the above modules are viewed from the AMD point of view with the exception of the ACS.
3. WP4 – Sub-systems design
WP4 started on Month 12. It was initiated during the Chania meeting in May 2009.
As the overall project suffers a delay of about 4 months, actions were discussed in order to accelerate the development of WP4 and get a chance to meet the RATP test in 2010. Therefore it was decided to avoid any technological risk and to select technologies that are already mastered by some of the partners. HAI made a presentation of the different cards that may be utilized in the framework of the ASPIS device design and implementation: PC104+ CPU boards, industrial motherboards, video grabbers, compression and analytics boards. The consortium reaffirmed its selection of the PC104 technology which was preferred compared to industrial PC board because this solution is better suited for the embedded device world.
A second discussion took place about selecting the operating system (Windows Embedded or Linux) to be used for the ASPIS Monitoring Device. Windows Embedded was finally selected as the partners in charge of the development of the AMD had lower skill with Linux. There was also a serious risk of unavailability of the Linux version of the drivers for some components to be integrated in the AMD (frame grabber for instance). In such case it would have been necessary to develop the Linux driver, with the risk of additional delay.
These structuring choices were presented to the Project officer during the 1st year meeting in Brussels on July 2nd, 2009 and the decision to make the choice of a more mature and less risky platform solution was approved.
A technical meeting on WP4 was held on 3 and 4 September at ITTI premises in Poznan, Poland. All partners but ANEK participated to this meeting. The architecture of the ASPIS Central Station (ACS) and the ASPIS Central Unit (ACU) were presented and discussed. The component diagram and state diagram were presented by RACTI and ISI and were discussed. Some priority problems were raised and discussed as well as back-up strategies in case of loss of connection between devices or lack of bandwidth.
THALES confirmed their reluctance to develop under Windows Embedded as all on-board security products they develop are under Linux. In order to overcome this difficulty, THALES proposed to completely undertake the part of imaging and audio through a dedicated PC104 sized card which can accommodate 4 IP cameras and 1 (or 4) bi-directional input links and which is connected to the PC104 processor board though a standard Ethernet port. RATP and THALES reported that the exercise for national research project SIC will be held next April in Paris and that ASPIS tests would be de-coupled for feasibility reasons. This will gives more time to the consortium to finalize the demonstrator.
An initial list of material to be purchased by the partners involved in the development of the AMD was issued at Month 14 and orders were placed following. On the ACS/ACU side, ITTI will have to buy a computer for the purpose of demonstrating the ACU. It will probably be a ruggedized laptop with a touch-screen or some function buttons. These specifications will be submitted to SAR specialists to be sure suitable equipment is used.
Following the Poznan meeting, a visit of RATP maintenance site for Metro Line 14 took place on Sept. 8th 2009 with the participation of RATP, JRC and Thales. Line 14 is an automatic driverless subway that has been selected by RATP for the demonstration. The different locations where the ASPIS components could be installed on the cars were checked. It was decided that the equipment installation for the demonstration should be light (double sided tape will be accepted for light components). RATP asked for the frequencies that will be used for the wireless transmissions in order to get approval. Site access constraints were also discussed: preparation of the demonstration will be done during the night, when the trains are out of service. Access rights for people have to be asked for well in advance. People that will work on the demonstration will have to follow a training course on security measures.
During the plenary meeting held in Ispra from December 9th to December 11th 2009, it was agreed about the major development tools that the Microsoft Visual Studio 2008 version will be used by the partner for the AMD development and also was considered to use the Dot Net environment and the C/C++ as a general development language.
HAI presented the AMD architecture and video server options with figures concerning consumption and connections.
ISI presented their progress about wireless communications and triggering devices. Options about communication devices were discussed, in particular about Wi-Fi and WiMax and interoperability between different components. It was decided to do some more tests about interoperability of the various solutions before finalising the choices.
ISI also presented their progress on the triggering devices. These devices will incorporate a microphone and a pressure sensor to detect either the noise of the blast or the pressure wave produced by the blast.
Thales presented different solutions for IP cameras and power supply options to feed them. For installations to be done without legacy systems to re-use, the best option is to use IP cameras with PoE. This will facilitate the installation and give the possibility to keep the power supply on battery back-up directly from the AMD. Thales proposed to use RTP/RTSP as communication protocol between the IP cameras and the AMD, which is a standard implemented by almost all camera manufacturers. A test of a Thales camera prototype was done during the meeting using VLC as player. This camera was given to JRC for further tests.
It was decided to set-up a purchase list in order to distribute the purchasing of the different parts between the partners. HAI will take care of this list.
Some additional requirements such as the capability to set-up a video and audio communication channel with between the Central Control Room and the AMD were raised by RATP. This would give the rescuers the possibility to communicate directly with the victims. It was agreed to add this feature to the specifications.
A technical meeting focussed on the development of the AMD and peripherals was held in HAI premises in Tanagra on 19th of January 2010 with all partners directly in charge of the AMD (HAI, ISI, RACTI and JRC). Thales joined the meeting by phone in order to discuss mechanical and connection issues. 13. Regarding the development of the AMD, an important decision was made about analogue video capture and digitization. So far the solution for this task was to include in the PC104 stack an analogue frame grabber with the capability to capture two streams. In the recent months and specifically after the Poznan meeting (September 2009) THALES proposed to offer their own custom boards for that task and as a backup solution a server board made by the company AXIS. So it was decided to develop both solutions in parallel (PC104 frame grabber, and AXIS 282A encoder) to reduce risk of the AXIS solution, until Thales solution is ready. JRC will work on the PC104 card and HAI on AXIS board. The AMD is proposed to include one PC104 frame grabber and one IP encoder (AXIS OR THALES).
An additional technical meeting was held in Tanagra HAI premises on February 3rd, 2010 with the presence of HAI, ISI, RACTI, JRC, ANEK and THALES. Different issues concerning video server SDK, back-up storage, camera power supply on battery mode, audio, mechanical design were presented and discussed. With reference to the RATP demo, THALES commented that in RATP line 14, the only space for the installation of the ASPIS device is under the seats in the car that lead to a 3u-19 inch standard, which may be inadequate for the ASPIS box taking into account casing considerations. A good solution would be for utilization of 2 boxes (one for WiMax equipment and the other of the AMD). This option is also good for reducing electromagnetic interference of WiMax equipment and the rest of the AMD. In the case that the 2 box solution is followed, it would be quite expensive to have two protected boxes per ASPIS Device. In this case the WiMax would not be further protected (own protection: NEMA4, Water & Dust proof), which does not threaten the overall system functionality, since it would be enough for one WiMax to survive per domain for the domain to have WiMax connectivity to the ACS. In the case that the WiMax box does not survive an event, the relevant AMD will communicate with the rest of the domain via Wi-Fi. Finally, the installation of the currently selected WiMAX device (size: 267 x 267 x 83 mm) outside the AMD box provides more advantages in terms of AMD box external dimensions, internal temperature / cooling issues and modularity.
Some points concerning power supply, back-up battery and video compression were discussed during the Athens meeting (24/02/2010) and Paris Meeting (17 to 19/03/2010). Various options were discussed but no final choice was made as these meetings were mainly devoted to the preparation of the demonstrations on Elyros ferry-boat and RATP subway (WP6).
A plenary meeting was held at HAI premises in Chimatari in June 2010. It appeared clearly that the development was late compared to the original schedule and that a delay of 6 months was foreseen.
HAI presented the progress made on the design of the AMD and the meeting gave the opportunity to clarify some options. It was decided to abandon the PC-104 MPEG4 frame grabber option and to concentrate on IP cameras or IP video servers (Thales 4 channels server or a COTS version).
Thales will have to provide 36 IP cameras for the demonstrations and 10 cameras will have to be provided by September 2010 for allowing partners to test their developments. These cameras will be PoE cameras.
Thales suggested using a COTS Mid Span Switch that is connected to one IP port and provides 8 IP ports for the cameras: JetNet 3810G Industrial 8-port PoE + 2-port GbE Switch, with DC12V/24V to DC48V Power boost. This solution will be incorporated in the AMD enclosure design.
Power supply and back-up battery are a critical function of the AMD. A solution meeting the specifications was found by HAI, but the product line was to be discontinued by the vendor and no replacement product was proposed. It was then decided to purchase the available parts in order to be able to run the demonstrations.
Intercom functionality will be implemented using CyberData VOIP intercom and standard audio conferencing solutions.
For the subway configuration, the ring connection between the AMDs cannot be achieved in wired mode for physical reasons. This ring connection will have to be achieved using a wire link form one unit to the next one and a wireless link between the last and the first units.
The WiMAX module will be placed externally of the AMD as close as possible to the antenna in order to reduce the RF attenuation. It will be connected to the AMD using and PoE Ethernet port. Transmission tests have been made in a road tunnel. They showed some transmission fluctuations when some trucks were moving in the RF path.
The wireless USB dongle will be installed inside the AMD providing the appropriate connector and cable for external antenna connection or outside the AMD by the use of the appropriate USB connection (depending on the specifications of the COTS product that will be used). Provision for both solutions must be made during the enclosure design.
The triggering module will be implemented in a separate enclosure containing the different sensors and processing and will be connected to the AMD through a USB port. Some explosion tests have to be organised to calibrate the triggering module.
It was decided that no localisation sensors will be designed but that positioning data from the train or the ship will be used. Provision will be made for a connection to the localisation function of the train or the ship.
A thermal analysis of the AMD components will have to be done for the design of the housing. This point is critical as no fan is allowed for on-board equipment. Heat draining will have to be done between the inner parts generating heat such as the processor and the external housing which will be used as a heat sink.
During the Patras plenary meeting (Dec. 14th to 16th, 2010), it was decided to schedule the delivery of the components for integration (WP5) by March 2011 and to extend WP4 until June 2011 to allow an overlap for debugging.
Decisions were taken about the number of AMDs to build (5 units), and who will build them, about the version of each AMD (with or without power management). The housing version for each of the AMD was not decided and had to be checked by RACTI according to availability of the parts.
ISI presented the final topology of the wireless communications which will include 2 Wi-Fi dongles per AMD, 2 wired Ethernet for connection to the adjacent AMDs and WiMax connected to the AMDs located at both ends of the train.
Some MeshMax transmission tests have been done by ISI in a road tunnel up to 800m in distance. The tunnel configuration does not allow line-of-sight connection. Big variations in throughput were detected depending on the traffic level on the second lane, especially in the presence of large trucks. Mini MeshMax did not work satisfactory. Additional test will have to be performed in the RATP tunnels in order t o select the best antenna configuration.
ITTI gave a presentation regarding the status of central station development. Open issues are diagnostics, synchronization, real-time video from the AMDs and localization. Regarding localization, it was decided if an interconnection to RATP is not achieved, to simulate it.
Time stamps can be derived from the video files retrieved from the AMDs.
Triggering tests were done at Hellenic Arms Industry (EBO) on January 28th 2011
The tests consisted in logging the signals from all 3 sensors at various positions of the triggering subsystem in respect to a FN light machine gun shooting normal munitions in a closed firing range as well as inside a small overpressure testing facility.
The noisy ventilation system provided a realistic background noise.
A reliable (i.e. failsafe and with few false alarms) triggering is possible. Some analysis and development tests at the EBO facilities may still be needed to establish a robust triggering algorithm.
When ISI will feel confident that it can deliver such an algorithm, then then JRC will proceed with a new set of live explosive tests within the frame of WP6 again at the EBO facilities.
Hardware and software tests were done with involved partners on Jan 31st and Feb 1st 2011 at RACTI in Patras. These tests were done with the following set of equipment:
• 2 AMD systems.
• 5 IP Cameras (1 ACTI5711 and 4 Thales) attached to one AMD (in its switch)
• 4 Wi-Fi (IEEE 802.11) usb toogles. Each AMD has attached 2 Wi-Fi toogles, one for ad-hoc connection between AMDs and one for connection with the MeshMAX (WiMAX).
• 2 MeshMAX access points (used for the first and the last wagon of a train)
• 1 Base Station with connection via WiMAX with the devices on the "train".
• 1 Computer used as ACS connected to Base Station with Ethernet.
Thermal results for the AMD were presented. It appeared that the oil cooling solution originally proposed by RACTI was not well suited for the prototypes. A conduction cooling solution will therefore be used.
The different communication paths between AMDs and AMD with ACS were tested successfully. Switching to a different path when one communication path fails was tested with success
Some state machine issues were discovered in some event sequences which were clearly identified and will have to be corrected.
Battery operation was successfully tested: when the AMD operates on batteries without DC input, the power management module monitors battery capacity and sends a command to the operating system to shut down the system when the batteries are exhausted. When DC input is restored, the system automatically restarts.
Another batch of tests was conducted involving the Greek partners and JRC at RACTI in Patras on April 19th, 2011. The object of this meeting was to verify, hands-on, the status of the implementation of the ASPIS devices and ensure a functioning 1st version of an image of the ASPIS software. Not all AMDs were available as some of them had already been sent to HAI’s premises, so all tests could not be done. A first version of the AMD software image, incorporating all components updates to date was provided. It includes the windows XP embedded image and all necessary drivers. It requires a boot from an external device and the complete re-writing of ASPIS disk C. It takes more than 90 minutes to complete. The image will be mounted and tested on the JRC AMD early in May. HAI was asked to do the same in their prototypes and provided feedback as to the coverage of the expected functionalities and both testing scenarios.
During the first 3 months of 2011, all HW and SW components should have been assembled together and the various SW modules combined in a complete Beta version of ASPIS SW. However, new delays accumulated, requiring a planning for an extension of 10 months. A limited number of specialised components are still missing. The responsibility is not with the consortium but with the commercial providers. Currently, the major issue seems to be that of the WiMax mid-spans.
ITTI, in close contact with RACTI and ISI, will complete the ASPIS simulator coherently with the real AMD capabilities. It should also ensure that the ACS meets the expected functionalities and test requirements prior to ship the ACS system to THALES on July.
It was agreed that the complete ASPIS AMDs should be handed from WP4 to WP5 (THALES) for the system integration by the beginning of July 2011.
4. Work Package 5: System integration
The first integration tests started by month 32. These tests concerned connection between AMDs and connection between AMD and ACS.
Initial integration tests were done by partners HAI, ISI, RACTI, JRC and ITTI (remote connection) beginning of February 2011 at RACTI in Patras. The main objective of these tests was the software and hardware (AMD embedded devices and network infrastructure) integration of ASPIS System in a demonstration room in order to simulate and test the functionality of the system.
Different tests were performed that proved encouraging and showed some improvements to be done:
Test 1: Devices interconnection through ASPIS Network
Results: All the devices (AMDs) in the train can exchange IP packets between them using all the type of network connections.
Test 2: Automatically Rerouting after connection fail.
Results: After different links disabling scenarios, the connection between AMDs was successfully re-established after some seconds. Also ACS could communicate with all the AMDs. In case of MeshMax Ethernet Fail, the connection to the AMD attached to MeshMax was interrupted which was expected (this connection is used for PoE for the MeshMax unit).
Test 3: AMD Software running in Learning State.
Results: The ACS (dummy) software was exchange messages with the AMDs. The AMD software did successfully load the new configuration.
Test 4: AMD Software running in Ready State.
Results: AMD Software successfully started the camera recording and backup to another AMD. AMD also started the domain monitoring.
Test 5: ASPIS system response in an alarm.
Results: AMD Software successfully propagated triggering both across the domain and the ACS.
The message exchange successfully changed AMD states according to the State Diagram of the specifications.
The captured data and the backup data successfully uploaded to the ACS.
The real time feed was received by ACS with satisfactory results
Test 6: ASPIS system response in network rerouting.
Results: In most of the cases the AMD software functionality worked fine when a connection fails. But in some tests, the following issues were spotted:
• In some connection fails the AMD software was triggering an alarm before the rerouting was taking place. This problem comes up because the test version of AMD software didn't interact with ASPIS network service and uses its own ping process. This interaction will be integrated in the next version of AMD Software.
• When the Ethernet connection is lost, the backup stops. This will be fixed in the next version of the AMD Software.
• Moreover, the second AMD which was still connected to ACS, detected the alarm and successfully sent it to ACS.
A second integration test was done by Greek partners (HAI, ISI and RACTI) and JRC at RACTI in April 2011. A first version of the AMD software image, incorporating all component updates was provided. It includes the windows XP embedded image and all necessary drivers. Not all AMD components were physically present at the RACTI labs. Consequently, only a very limited set of functionalities was demonstrated. It was stated that:
• HAI shall proceed with the HW integration of the 3 AMD boxes by the end of May. On their completion they will organise a technical meeting among HAI, RACTI and ISI to mount the complete SW images on the 3 AMDs and test their functionalities. Successively, they will handle the 3 boxes to RACTI for further debugging and SW integration and proceed with the HW integration of the remaining 2 AMD boxes.
• ITTI, in close contact with RACTI and ISI, should complete the ASPIS simulator coherently with the real AMD capabilities. It should also ensure that the ACS meets the expected functionalities and test requirements prior to ship the ACS system to THALES on July.
• JRC will test the provided SW image(s) on the JRC system, with and without development board.
• The complete ASPIS AMDs should be handed from WP4 to WP5 (THALES) for the system integration by the beginning of July.
• The next project meeting, combined with a verification / integration technical meeting, will be held on July (preferably) or early in September.
The tests continued during the Patras technical meeting on July 11th and 12th 2011. RACTI, ISI, HAI and JRC participated physically to this work session and other partner participated by phone and remote connection. The purpose of this meeting was to fully test the AMD, its configuration and the way the different communication channels are managed in various situations.
The work programme was divided in several tasks:
AMD Hardware Installation
Two AMD box were installed in the demonstration site. Both AMDs had full hardware components including: processors, POE switch, Batteries, Power supply, Hard Disk Drives (Solid State), 6 x POE outputs for digital cameras, 1 x POE output for MeshMax Access Point, 1 x POE output for VOIP, 2 x Ethernet output, 4 x D9 ports for analogue cameras (not connected), 1 x D9 auxiliary port for power output (12V), 3 x USB ports (2 for WiFi dongles, 1 for Sensor Board)
The box was ready and just plugged in the power supply. The only problem noticed is that the processor increased its temperature when the box is closed. This was fixed by adding a heat sink connected to upper cover of the box in order to cool the processor.
AMD OS's installation (Windows Embedded)
The installation of Windows Embedded OS included the following steps:
Connect a keyboard and a mouse to USB ports. Connect a display to VGA port
Connect an external USB HDD containing bootable Windows Embedded. Also this HDD includes the image files of AMD's OS. Switch on the AMD and select Boot from the external HDD
Using a laptop connected to the AMD via an Ethernet port and remote desktop, copy OS image files from the external HDD to the main HDD of AMD.
Remove external HDD and reboot the Machine. The OS image is automatically installed.
Remove monitor, keyboard and mouse.
The installation completed successfully after about one and a half hour per AMD.
WiFi dongles installation
The installation of WiFi dongles requires the installation of software drivers. The USB sticks were connected to the AMD and the drivers were installed via Remote Desktop using the installers provided by the vendors. One stick was configured as Access point and the second as AD-HOC mode using the vendors interface as we discovered that the Windows Embedded WiFi configuration menu didn’t allow a full configuration.
AMD Software installation and parameterization
The application software contained on a USB Stick was then installed using Remote Desktop:
ASPIS Network Service.
Filezilla Server Installer.
AMD Software.
An Autoboot sequence was added to the AMD setup in order to launch automatically the application at start-up.
Base station / ACS installation
The Router Server was already installed in a desktop PC and just plugged in the demonstration site. ACS software was installed in virtual machine with Windows XP and was running from a laptop.
Communications Verification
This step included network tests in order to ensure the right operation of AMD’s three networks and the connectivity between AMD and ACS.
The communications verification was done in several steps:
AMD – ACS communications / AMD Configuration
These tests included the exchange of messages between ACS/AMD during the Configuration phase.
Remarks and Results:
The messages exchanged successfully with the ACS.
Problem occurred in some SAC messages (New Configuration Post) when the string size is big. This problem was fixed by increasing networks stream buffer. Also some minor problems were found with the graphical interface of ACS when trying to add new cameras. The bugs were sent to ITTI for fixing them in the next ACS’s version.
Finally both AMD’s configured correctly.
AMD Normal Operation
During this task both AMDs were working in READY state recording and backing up video data.
Remarks and Results:
Both AMDs started to record and backup data without problems for about half hour (test’s duration).
Triggering Procedure Test
This test included the triggering of an alarm from AMD and all the operations that must be done after an incident:
Request Domain Identification.
Download Captured Data.
Download Backup Data.
Request Real Time Video.
Return to Normal Operation
Remarks and Results:
First we send a trigger (dummy) from one of the AMDs. Both AMD’s entered the Triggering State and stopped recording and backup. Triggering message was propagated successfully to ACS.
Afterwards, Domain identification was requested from both AMDs in order to change to SUCCESFULL state. The messages exchanged correctly.
In the next step we request the captured data (via ACS) from each camera. The files were uploaded successfully. There was a problem and the video player of ACS wasn’t able to start so the video files tested independently without any problems.
In the next step we had to request backup data, but ACS didn’t support requesting backup data. We use the ACS TEST SOFTWARE in order to check that the backup files will be uploaded correctly.
In step 4 we request for real time data. Although ACS received the correct RTSP link, the embedded video player didn’t start. We test the real time feed with VLC Player and the video was transferred without problems.
As conclusion, the main operations of after event procedure were made successfully, the video data files were downloaded and the real time stream worked fine.
System tolerance in network failures in Normal Mode.
This test is focused on the verification of system tolerance in network failures. Network failures are considered the loss of one of the three physical networks.
In particular, the test included the following steps:
Disconnection of Ethernet between the two AMDs.
After the Ethernet failure no alarm was triggered. – Test Passed
Disconnection of one of the Access Points (AMD2).
After Access Point disconnection no alarm triggered and ACS was able to see the both AMDs – Test Passed.
Power off one off the WiFi AP network.
We disconnect WiFi AP from AMD2. Because the WiFi is working over POE, the disconnection caused the power off of the Wifi AP. This event didn’t trigger any alarm. AMDs used the WiFi Ad Hoc network to communicate between them and the ACS. – Test Passed.
Disconnection of WiFi Ad Hoc network from one of the AMDs (AMD2).
After removing WiFi AH network of AMD2 an alarm was triggered which it is logical because AMDs is not connected to any network. – Test Passed.
After the last step the video data from AMD2’s cameras was uploaded from the backup stored inside AMD1.
VOIP Test
The VoIP device was installed and its functionality is tested. A VoIP software was installed in the ACS and communication tested. We test calling from both sides and everything worked without a problem.
Network Rerouting in After Triggering procedure.
The purpose of this test was to evaluate the behaviour of ASPIS system in case of a network failure during data uploading or real time stream.
Remarks and Results:
Test 1: Data uploading:
The network failure (Ethernet loss) caused the stop of data uploading. When the files were requested manually, the uploading worked fine. This problem can be overridden if ACS resumes the uploading automatically.
Test 2: Real time stream.
The video stream froze for about 10 seconds and then it continued. The time of 10 seconds is needed for the rerouting of network packages. This behaviour was judged acceptable.
An additional meeting was held in Patras from 18th to 22nd of July 2011 to continue the integration tests and to verify the AMD components and features that were not yet tested.
Testing sensor board: Configuration and Receiving alarm – Integration of board connector in order to receive power from one USB.
The Sensor module was connected and tested successfully.
2. Testing battery after power failure. – Integration of power management module needed on AMD.
After a power failure, the power supply of the AMD switched automatically on battery.
3. Timing captured video downloads after an alarm in various scenarios depending on network availability.
The video download time is very dependent on the radio channel quality as the available bandwidth is automatically decreased when the quality decreases. Recorded sequences will be sent using TCP-IP in order to get the full sequence in its integrity, even with some delay. Live streams will be more likely sent using UDP, with the risk to lose some images when the bandwidth decreases.
This behaviour is judged acceptable.
More tests have been done beginning of August 2011 in Patras for the preparation of the test scenarios.
The first test concerns the time needed for downloading to the ACS all the 30 min video sequences of the 6 cameras connected to an AMD. This time was found to be less than 20 min for 6 cameras in good transmission conditions, which is in line with the theoretical expectations.
Two cases were considered for measuring uploading time:
Case 1: Best Case
AMD is connected straight to MeshMax and then to Base Station (ACS).
Case 2: Worst Case
AMD is connected with WiFi Ad-Hoc network to another AMD which is connected to a MeshMax.
Results:
The uploading times are depicted in the table below:
Camera Case 1 (min:sec) Case 2 (min:sec)
#1 3:07 3:03
#2 3:02 3:12
#3 3:03 3:01
#4 3:04 2:58
#5 2:53 2:54
#6 2:54 2:54
Total 18:03 18:02
Conclusion:
In a perfect environment for wireless communications (line of site, small distance between antennas) the uploading time of captured data for 6 cameras is about 20 minutes (included possible delays from manual request of uploading videos) which is acceptable time frame according to the functional specifications of the project.
Best case (AMD directly connected to the MeshMax unit) or worse case (AMD connected to the next AMD by WiFi, the second AMD connected to the Meshmax unit) give almost same results (which is consistent with theoretical expectations.
Although we used 6 cameras we can assume that the uploading time of 8 cameras will be around 26 minutes which is also an acceptable time frame.
The second test scenario we tested the duration that AMD can operate without power input using only battery.
The scenario included two AMD – AMD1 and AMD2. AMD1 had attached 6 POE digital cameras, a sensor board, a VoIP device and a MeSH Max which took power from it. AMD2 has attached 1 POE digital camera and a MeSH Max.
At start both AMDs were at READY state, recording and backing up data. Test began when a triggering was propagated to AMD and AMD sat both AMDs to SUCCESFUL state. At this time point we unplugged the power supply from both AMDs. Afterwards we measured the two battery capacities of AMDs until one of them was close to empty. During test measure, we uploaded the recorded files from the AMDs and also we opened a real – time stream channel with a camera connected to AMD1 until the end of the test.
Results:
AMD1 battery started at 89,5 % and finalized at 3,5 % after 52 min and 12 sec.
AMD2 battery started at 100 % and finalized at 79 % after 52 min and 12 sec.
Conclusion:
An AMD can operate autonomously with it’s a battery for about an hour.
This duration frame can be extended in case of using AMD with managed power supply to its components. In that case the switch off of POE cameras is able to delay battery’s exhaustion. This conclusion came from the fact that the main difference between the two AMDs in the tests is that AMD1 has 6 cameras working and AMD2 only one.
A technical meeting took place in Patras from 19th to 21st of September 2011 with all technical partners (Thales, JRC, HAI, ISI, RACTI and ITTI) in order to continue system integration.
It was decided to upgrade all AMDs to the last software version and to send all equipment to Thales by end of September. Thales will do the tests of all the functionalities in their premises in Velizy with the help of some partners (foreseen JRC and ISI).
Most of the three days was spent in verifying that all sub-systems were working properly and had the same firmware/software configuration. This concerned mainly the AMDs, the WiFi dongles and the WiMax stations.
A complete set of new equipment ( 2 new AMDs, 1 base station and 2 subscriber stations, plus 4 WiFi dongles, that is a “second train” but with identical ip addresses as the first one, were programmed and tested. Results are as follows:
• One new AMD programmed and verified correctly.
• Second new AMD finally programmed, but not fully verified.
• 1 base station programmed and verified correctly.
• 2 subscriber units programmed and verified correctly.
• 4 new WiFi dongles programmed and verified correctly.
• VoIP verified
• Sensor boards verified.
It was decided that the ISI WiMax equipment (1 base station and two subscriber units) will remain at RACTI laboratory for debugging during integration tests in Thales, and will be brought to Paris for the RATP test event, if necessary.
In addition the fifth AMD, the one with the power management, will be kept to HAI premises, in prevision of the Maritime demonstration and also for debugging. It will be shipped to Paris for the final tests if necessary.
Problem insisted with one base station and one subscriber (from JRC).
Finally the following pieces of equipment were packed, and were ready to be shipped to Thales:
• 4 AMDs
• 1 WiMax base station unit, antennas and cables
• 2 WiMax subscriber units, antennas and cables
• 8 WiFi dongles
• 2 VoIP intercoms
• 5 sensor boards
• 3 MTN power supplies, 72V to 13.8 V, for train application
• 2 AC/DC adapters, 60Hz operation, 12V output, for maritime scenario.
In addition, a number of AMD components spare parts were also packed:
• 1 ISIS CPU board
• 1 MESA pc104+ Ethernet switch
• 4 batteries
• 1 IEI 120W power supply
• 3 IEI 100W power supplies ( wrong part number)
• 2 PoE WiMax midspans
• 1 ISIS CPU board cable kit.
The only AMD components spare parts that are missing are:
• 1 Korenix Ethernet switch
• 1 solid state disk (two are available at RACTI setup, but are used in the development boards).
The system integration and testing continued at Thales premises in Vélizy from October 2011 until end of December 2011 with the help of JRC and ISI which came on site for the tests.
A direct Internet connection had to be set-up in order to allow Remote Desktop connections and teleconferencing with the partners. Several bugs were detected and solved and the functionalities of the ACS were also adapted in order to improve the ergonomics and operations. For instance, the way the sequences are up loaded has been improved in order to give quickly and overview of the situation to the ACS operator.
At the end to the integration tests, 3 AMDs and associates peripherals (cameras, triggering sensors, WiFi dongles, WiMax units) were fully configured and tested, ready for the train demonstration.
5. WP6 – Testing and Validation
WP6 was launched during the 3rd plenary meeting hosted by ANEK in Chania, Greece from 25th to 28th May 2009. A major issue of WP6 is the establishment of a SAG (Security Advisory Group) relevant to the project. Different selections of persons were presented during the WP6 kick-off coming from the following organizations:
• The Centre for Security Studies (KEMEA) of the Greek Ministry of Interior
• The International Union of Public Transport (UITP)
• The French Ministry of Interior
• Lloyd’s and RINA
• European Ship Owner Association
Additional member will have to be proposed in order to assess ASPIS design and functionalities, but also to promote it. A SAG meeting should be organized aside next plenary meeting.
The first draft of the demonstration scenarios were presented and discussed:
• The Paris metro demonstration of the ASPIS system will require 4 ASPIS devices with 4 to 6 cameras per device. The initial assumption of 10-20 devices has to be relaxed due to the change of architecture in the ASPIS project to a more modular architecture of the ASPIS device. The demonstration will take place in a line 14 train. Typical line 14 trains have 5 cars. 2-3 devices will be installed in the train covering 2-3 cars and 1 spare device will be needed. In addition to the 3 installed devices an ACU will be needed for the test. It will not be needed that an ACS is installed in the RATP emergency room (PC2000 in “La Maison de la RATP” near Gare de Lyon).
• The two maritime demonstrations will take place on the ELYROS vessel. The scope of the second maritime demonstration (AS#3) will be modified following the discussions with ANEK commercial and security representatives as explained previously in WP2 report. At least 2 ASPIS devices will be needed in order to test each of the two maritime scenarios. Both scenarios will utilize an ACS installed on the ship bridge.
These scenarios will have to be refined in order to take into account the site constraints, installation constraints and operational expectations.
No deliveries are due for this period.
Prepare the acceptance tests and demonstrations
At the very end of the first period, the decision was taken to implement 3 demonstrations to show the capacities of the ASPIS system in various conditions and environments. The first demonstration will concern a subway situation while the second and third once will concern a maritime situation on board a ferry-boat.
A meeting held in Piraeus on 24th of February 2010 on ELYROS/ANEK vessel gave the opportunity to present and summarize ASPIS project to ELYROS’ Captain Mr Stratos KAVROS and Chief Engineer Mr Panagiotis GERONTIS. The maritime application scenarios will demonstrate the ability of the ASPIS system to help application of the IMO regulations. In the second scenario, the ASPIS system will warn the Security Officer if someone tries to enter a restricted access area and provide video sequences to help the crew to catch the intruder. The third scenario will demonstrate ASPIS as a mean to detect people re-entering an already evacuated zone in case of an abandon ship procedure. As cameras will have to be installed in public corridors for this scenario, a special operational procedure will be implemented in order to ensure privacy protection for the passengers. This procedure will stipulate that the crew member will launch the ASPIS system covering a zone once he has completed the evacuation of the zone. The ASPIS system will detect people re-entering the zone by video motion detection and send an alarm to the Captain with the video sequence showing the intrusion that will help the crewmen rescue the intruder.
Regarding the ANEK on-board, tests it was made clear that nothing from the vessel’s equipment or internal spaces will be harmed. At ELYROS bridge there are currently 4 monitors for 96 cameras. Under legislation, the watertight doors of a vessel must be sealed while sailing. On ELYROS there are 4 watertight doors at the area of the engine room which is considered as restricted area. Monitoring of these doors could be used for the restricted access scenario (scenario 2). For the abandon ship scenario, it was clarified once more that the ASPIS system will set an alarm and also take pictures of the space at the same time.
Regarding the issue on the standards for equipment fastening in ships, it was clarified by Mr KOUKLAKIS, Technical Manager/ANEK, that there are no specific limitations based on regulations. Mr NOMIKOS/ANEK explained that on ELYROS vessel there is fibre optic backbone, conversion to Ethernet and power over Ethernet.
A small tour of the vessel came next with the Captain and Chief Engineer of ELYROS showing the alternative areas for the installation of ASPIS system for the tests. It was decided that the system will be placed at Deck 9, left corridor of the crew cabins and a small PC or laptop at the vessel’s bridge for the tests. Along the corridor there are empty lockers that could be used for storing some of the tools and equipment for the tests. There are 220V sockets at 60Hz in all corridors.
A meeting took place in Paris at RATP and Thales premises on March 18th and 19th 2010 to discuss more in detail the subway demonstration. The first day was dedicated to a visit of the depot of Line 14 located at one end of the line, after station Olympiades. This depot is used as parking for the trains and is also the maintenance workshop for the trains. The participants had the opportunity to visit a train and to find where to install the ASPIS components. The AMDs could be installed inside the front car and rear car where a space is available for technical equipment under the side seat. However, there is no such space in the other cars. As a first evaluation, 4 cameras will have to be installed in each car in order to get the coverage.
A full train will be equipped with cameras and AMDs that will record the last 30 minutes in their circular buffer. The cameras will have to provide a full coverage of the train. In case of an alarm triggered by the detection of a blast for instance, the buffer will be frozen and its content will be transferred to the ACS in the central control room using ASPIS communication means in the tunnels. The day continued with a visit of the BFM Station in with base stations will have to be installed in order to provide communication with the train inside the tunnel.
Different locations have been foreseen, above the tracks where the antennas could be positioned on the footbridge across the tracks.
The meeting continued with a discussion on the HMI of the ACS and the maps to be integrated. One map should provide a view of the car, with the position of the cameras, a second map shoud provide a full view of the train and position of the AMD which sent the alarm and a third map should display the line and the position of the train on it. RATP will provide drawings that will be used to generate those maps.
During Patras meeting from 14th to 16th of December 2010, different issues concerning WP6 were discussed.
Deliverable D6.1 (test scenarios) was presented by Dr Fivos Andritsos and approved.
A first discussion was made about test event preparation both for ANEK and RATP. Regarding RATP tests, they have to be performed by night, which is a strict constrain. Installation could start from 10.00 pm and the tests be performed until 5.00 am next morning, and could last 5 working days. Each morning all components must be removed and reinstalled next evening for safety reasons. This constrain will necessitate a good preparation and training. The ASPIS system will also have to be built in a form allowing installing the components and removing them quickly.
Regarding ANEK test, overall duration could be 2- 4 days, during one or two 2-way trips of Elyros vessel from Piraeus to Chania and back. Cameras could even be installed in the ceiling of the corridor in Deck 9, as it is possible to replace the affected panels.
Mr Marinos Nomikos stated that it is possible to visit Elyros Vessel and perform preparation of the installation before the actual test date, just to make sure that everything is ok in the final event.
During the different technical meetings and Project meetings the different test scenarios have been refined in order to take into account the end users need but also the operational constrains.
So it was decided that for the maritime use case, all connections between the components (cameras, AMDs, ACS) would be done using wired connections as the cables can be easily installed in the celling. This will give the opportunity to focus more on the functional requirement such as video analytics for detecting people re-entering the evacuated zone or penetrating a restricted zone. This test configuration will be prepared by HAI and ANEK with the help of the other partners.
The subway use case needed much more preparation on both technical aspects but also on all security and administrative aspects.
Work at the RATP demonstration site has to be done by night, for both preparation of the tests and tests themselves. This obliges to get administrative authorisations at least for Thales employees to comply with the work legislation.
Prevention Plans have to be submitted for the visits at RATP sites. The participants have to be declared in advance and they have to be briefed/trained concerning the security rules and behaviours when on a RATP site. The participants must have a risk insurance that covers them if something happens. The insurance certificate has to be provided.
The programme and schedule of the tests have to be precisely prepared with a tight timing.
All equipment has to be packed in cases that can be easily transported in the tunnels (Flight cases for instance) and prepared for being easily and quickly deployed once on site.
Several tests have been done on RATP sites:
The first test in a tunnel took place on 21st and 22nd of November 2011 in the “Van Dyck loop” located on line 3. This loop is no more used today and it is used to temporarily park some cars.
As this tunnel is not in service, we could access it during normal working hours, by day.
The main purpose of these tests was to check the propagation conditions of WiMax inside a subway tunnel and select the best antenna configuration. The tests were done with RATP, ISI and Thales.
The tests were mainly consisting in setting-up an ASPIS AMD connected to a simulated camera and testing the communications with the ACS.
The first day tests revealed rather disappointing as the transmission channels were not stable and no best antenna configuration could be determined. We were lacking measurement tools to measure the communication channel itself without all the application layers of the AMD and ACS.
On second day, a management tool provided by the MeshMax vendor was installed on the Laptop used for ASC. This tool allowed to monitoring the communication channel performances
Various antenna configurations (omnidirectional, sector, panel) have been evaluated but it appeared that the signal to noise was poor and results were not satisfactory. Some small changes in the position of the antenna could provide drastic changes in the quality. The conclusion was that there were a lot of reflections in this tunnel and that more stable brackets or antenna pole should be used for further tests.
A second transmission test was done at Bibliothèque François Mitterrand station and Olympiades station during the night from Friday 16th December 2011 to Saturday 17th December 2011.
These tests were achieved by RATP and Thales.
The first test consisted in verification of the transmission of video files thru WiMax from and camera + AMD located at one end of the platform to an ACS located at the second end of the platform.
Tests were done with different antennas, mainly flat antenna for AMD side and sector antenna for ACS side. Results were much more satisfactory than during the first batch of tests at Van Dyck. No particular difficulties could be noticed.
It was then decided to do a test between two adjacent stations, namely BFM and Olympiades.
The distance between both stations is about 750 m but the tunnel is not in line of sight.
It was decided to install one sector antenna at the entrance of the tunnel at BFM station. The antenna was located on the platform side, separated from the tunnel by a glass wall.
At Olympiades station, a flat antenna was installed the same way as at BFM station.
The different antennas were installed using suction cups for quick installation and removal.
This configuration allowed easy transmission of a live video stream. Operations were coordinated using GSM cell phones as no audio channel was available from the tested link!
Testing in tunnels showed a wireless connection of 10 Mbps in each direction. The test was performed between the stations “Olympiades” and “Bibliotèque François Mitterrand”, which are connected by 750 m of tunnel and vehicles in it. In non-optimal locations, the speed was a little slower. The antenna has been placed in different positions to test the effect of the location. Each operator would decide where to put it in the commercial application.
A consortium meeting with all partners was organised at Thales Vélizy on Jan 11th to 13th 2012.
The main objectives of this meeting were to discuss the results of the evaluation, the tests done in the subway tunnel and define with precision the demonstration at RATP and at ANEK.
In the metro tests, using 2 trains would be better than using 1 (2 trains means 4 AMD, 2 on each train), so it is possible to know how the system works with the backup and 2-domain communication. Christian Fedorczak proposed to locate the other AMDs elsewhere, not in another train, so it can be installed and tested easier, without the necessity of using 2 trains. RATP thinks that it is more difficult to be able to install the cameras and everything on 2 trains and have WiMAX connections on the front and on the back of the train. A proposed solution is to connect 1 train to 2 stations, and test that the train should change from one station to the other as the train moves (roaming). RATP says that a dedicated fiber connection would be needed and that it will be complex to do all this in one night.
In this test, 3 AMD and 18 cameras are used on a train that moves from one station to another. The circuit among the AMDs is closed using wireless connections.
This test comprises several phases:
1 - Normal scenario
• Check that everything is connected and configured.
• Get live video with the train stopped.
• Get live video with the train moving.
2 - Emergency scenario
• The trigger module is activated. The train stops. The uploading starts. Maybe the light should be switched off.
• An Ethernet cable is disconnected after some minutes to test the resilience. These tests could be also done in the laboratory.
• Take power off from one AMD and see if the system triggers.
• A video capture of the screen should be recorded during the tests in the ACS.
• In case an AMD is powered off, the AMD that notices it creates the trigger, so the snapshot received will be the one from the AMD that generated the trigger. It should be better to receive the snapshot of the AMD powered off, but it would take time to change it. This is assigned with low priority. In any case, the images will come from near the place of the incident, so maybe it is enough.
For the maritime scenario test it will be necessary to use 1 AMD, 1 ACS and a minimum of 3 cameras (would be better 5 or 6). There are two maritime scenarios:
• In the first maritime scenario, 2 cameras will be used for motion detection and a 1 or 2 over a sensitive door, triggered by one relay. When it is triggered, the alarm is sent to the bridge and the video afterwards (30 - 60 s). It has not been defined yet what happens if the door remains open.
• The second maritime scenario is the evacuation scenario. Here, a minimum of 2 cameras are needed for the test. 6 cameras will be used in real applications. The system is manually put into the ready state (through a switch) after checking that all rooms are empty, and it is triggered by motion detection. Currently, the system has no button for putting it manually in the ready state; it can only be manually powered-on. When the button is pressed:
o The system goes through the power-on procedure
o After a couple of minutes it has to attain the ready state, with the motion detection activated; motion detection algorithm should be calibrated so as not to trigger on luminance or slight changes clearly not involving humans
When triggered by the motion detection algorithm, the system sends an alarm (with the snapshot), freezes its buffer, and starts streaming real time video. The buffer is uploaded in parallel for documentation purposes.
The map of the vessel for information purposes has not been configured yet, but the system is prepared to do it easily. It should have the identifications of the cameras, so it should be able to mark on the map where the cameras / doors that have triggered the alarm are. In the corridor scenario, the captain has to be able to click on one camera and see the images, as in a normal surveillance system.
Cabling and installation for the RATP demonstration was prepared from 8th to 10th February during day time between morning rush hour and evening rush hour.
Location of the 18 cameras, 3 ASPIS devices and WiMax antennas had to be selected. As it was not allowed to drill holes to install the different parts, it was decided to install all the cameras using brackets with suction cup. Antennas were installed on the front windshield using suction cups. AMD’s were installed on the floor, against a seat and firmly secured by belts. 2 AMDs were located in the first and last car, and the third was located in a car in the middle of the train. All the cables had to be taped on the walls or on the ground
.
Power supply was provided from the train (72 V DC) from behind a door panel. All cables were prepared with the right length for connecting the cameras to the AMDs, the triggering sensors to the AMD, the AMDs between them, to bring the power to the AMDs and to connect the MeshMax units to their respective AMD. The devices and the cables were labeled to allow quick installation and removal.
The second and the third day were reserved to exercise for installation and dismounting. The different task were assigned to each participant who knew exactly what to do and we managed to install the complete system in less than one hour and to dismount it and clean the train in less than half an hour.
On the ground side a Fiber Optics cable had been pulled by RATP for the ASPIS project between Olympiades station and BFM Station. This cable allowed to connect the WiMax base station of Olympiades to the “Control room” that had been set-up in a technical room at BFM Station. This gave the possibility to test the roaming capacity by switching from BFM base station to Olympiades base station and to follow the train wherever it is located inside the tunnel.
In the control room at BFM, a network had been set-up connecting the two base stations and the ACS. The Ethernet to fiber converter was installed close to the switch. A Wifi network was created to allow easy connection of the ACS. Antennas and base stations were installed using suction cups as tested during the previous test session.
The validation tests by themselves were done during two nights from 13th to 14th February and 14th to 15th. The first night was dedicated to testing the communications between train and ground in various locations. The train was moved from one station to the next one while the communication channels were monitored. The train also did some stops inside the tunnel to check if the communications remained satisfactory, event in the presence of other trains in the tunnel. Communications channels were monitored on both base stations and the quality of the communication was judged satisfactory. A bandwidth of 10 Mb/s could be achieved in almost all configurations.
Additional tests were done as the train went about 400 m in the tunnel behind Olympiades station. The communication could be kept with the base station located at BFM, which was more than 1 km away.
The second night was more dedicated to the functional tests corresponding to the requirements. Triggering of an alarm was tested and validated. The image sequences were transferred to the ACS using the WiMax channel. A mobile ACS located in the train but that was simulating a rescuer with a mobile device was able to get the connection with the AMD using the WiFi Channel of the AMDs.
All the validation could be achieved and gave satisfactory results.
The Maritime use-case was prepared mainly in Greece in close collaboration with ANEK.
Several meetings were done with ANEK representatives and visits of Elyros ship were organised for preparing the demonstration.
The maritime demonstration was organised from 19th to 21st February 2012 on the ELYROS Ferry-boat, in Piraeus. On 19th, a meeting in ANEK offices was scheduled in order to finalise the installation and the tests to be run.
The ASPIS maritime system was installed on deck 9 of the ELYROS ferry of ANEK LINES. The corridor on top right was monitored in order to detect any access in and out to the sensible rooms while the sensitive door giving access to the crew compartments and the bridge was monitored and any access dully recorded.
The AMD used for the demonstration were installed in a corridor while the ACS was installed on the bridge close to the security room.
The tests were done on 20th and 21st and were successful, in line with the requirements from WP2.
Both demonstrations, subway and ferry-boat, were done only with the partners of the project as it was difficult to invite external guests for security reasons. The results were very positive according to the end users..
All the details of the tests and results can be found in D6.1 and D6.2 respectively.
6. Blast tests
Collaboration with the SECUREMETRO project (FP7-SST-2008- 234148) was initiated in 2011 thanks to RATP who was participating in both projects. The aim of SECUREMETRO was to develop validated material selection and design strategies for building metro vehicles with intrinsic security features. SECUREMETRO planned to have a blast test with a real metro car to check the validity of their choices. This was a good opportunity to install ASPIS inside this car and check if it could support a real blast. The blast test initially planned in Sept 2011 was postponed 2 times and was finally done on Oct 17th 2012 in Burgos, Spain.
In order to do this test, one ASPIS prototype was placed in a full-scale coach, which was blown up during live explosion. The ASPIS system performed better than expected. The AMD box, placed at its nominal position at the undercarriage, survived the explosion and all the recorded sequences prior to triggering could be uploaded. Even one of the cameras survived the explosion and recorded live the blast. The other cameras were blown out as they were not attached firmly enough to the structure of the vehicle. It comes out from this test that small inexpensive cameras are likely to survive even very violent explosions if they are attached correctly with enough slack cable.
Potential Impact:
An initial market survey was done at the beginning of the project by Thales, concentrating on Train, Subway and Busses (public mass transportation systems). These sectors are already accessed by Thales who sells for instance on-board video surveillance systems to Paris commuter trains, subways in Copenhagen, Dubai, busses for RATP, etc. There is market demand for on-board video surveillance systems that are used to fight against crime and delinquency. Video provided by the cameras are recorded and in case of an incident, the records are analysed by the police in order to investigate the cases and identify the criminals. The aim of ASPIS is slightly different as it is a system dedicated to crisis management in catastrophic conditions. ASPIS uses the same basic technologies as a conventional on-board video-surveillance system: video cameras, video recorders. However, ASPIS provides additional features such as redundancy for components and communication links between these components, real time communication from inside the tunnels to the central control room and also hardened components able to resist a blast or a fire. After the bombings in Madrid and in London, an opportunity was foreseen for ruggedized equipment able to resist a blast. Some US/Canadian companies (March Networks for instance) showed some videos on YouTube of explosion tests done in a bus with a video recorder installed inside the bus. However, no such product has been proposed up to now on the market.
After the 2007 riots in Paris suburbs, several RATP busses have been fired and the question of having fire resistant devices has been discussed with RATP in order to be able to identify the pyromaniacs. Finally such a fire resistant solution has been rejected as the cameras are recording what happens inside the bus and therefore they cannot catch the pyromaniacs who stand outside the bus. More, RATP has authorisations to record what happens inside the busses but not on the streets.
However, RATP is interested by the resilient communication architecture that will be developed for ASPIS, both inside the train, and also between trains and stations, without any pieces of equipement installed in the tunnels.
On its side, HAI, as an aeronautics systems provider, is familiar with ruggedized components and recorders and ASPIS could provide a good opportunity to develop its market on the mass transport sector.
ITTI is mainly working on communication infrastructures for operators and management systems for these systems. They could find some business opportunities and benefit of the experience they will get in the management of the communications between the trains and the central control room.
The academic partners on their side are not interested in the development and sale of industrial products.
At this stage, it is not obvious if the transport operators are ready to invest in systems such as APSIS, dedicated to crisis management, as there is not regulation or legal framework that will oblige them to install such systems. The trend seems more in the development of on-board video surveillance systems that will be used for fighting against crime but that will also be used to deliver information or entertainment to the passengers. Concerning ground transport, wideband communications between trains (or busses) and the control room is a real problem that is not yet solved. Not technical solution has proven its ability to provide coverage inside tunnels without intermediate relays. The technologies and the communication architecture that will be developed for ASPIS could provide a good solution. However this critical point hasn’t been validated at this point and the credibility and the feasibility of the solution have to be proven.
After discussion with the partners, it appeared that the academic partners were not interested in the development of an industrial solution of the ASPIS project.
ITTI on its side is not present on the transport market and has no plan to develop its business in this domain.
No specific business agreement has been signed between Thales and HAI. Results of the ASPIS project are exploited in accordance with the rules described in the consortium agreement. HAI developed mainly the hardware of the AMD from COTS PC104 boards. Software of the AMD was developed by HAI and ISI on Windows embedded OS. These developments will be fully exploited by HAI.
Thales is already in the transport security business (train, subway, busses) and will continue to develop its activity in the domain. The developments made in the framework of ASPIS, mainly the IP encoding board and IP camera, will be used in the new generation of on-board video recorders with a specific software running on Linux.
Scientific Advisory Group
The Ispra plenary meeting on Dec 2009 gave the opportunity to organise the first Scientific Advisory Group (SAG) meeting with the presence of external members of the Advisory Group. The members of the SAG are:
• Lindsey BARR, International Association of Public Transport (UITP), Belgium
• Georges LEVENTAKIS, Centre for Security Studies, Hellenic Ministry of the Interior, Greece
• Thilo SAUTER, Institute for Integrated Sensor Systems, Austrian Academy of Sciences, Austria
• Pawel Kepka, Civil Safety Engineering Faculty, The Main School of Fire Service, Poland
After a presentation of the participants followed by an overview of the ASPIS project, Dr Fivos Andritsos introduced some of the implication issues related to the ASPIS project and particular attention was dedicated to the data privacy.
Thilo Sauter warned about the possible psychological effects of the camera installations since, according to his experience, just the view of all these cameras may induce into passengers the feeling of being continuously monitored.
In the afternoon Dr Andritsos presented a highlight of the LOCCATEC project and following this presentation, the Advisory Group members asked several questions about the features of the ASPIS project. It was explained that the devices are triggered only by an explosion sensor but there might be also a secondary trigger when a node is missing. It was asked about the handling of an intentional triggering activated in order just to prevent the camera to record and consequently a malicious security attack might take place. This kind of event is certainly possible but the security plan shall take care of these possible threats.
Dr Fivos Andritsos pointed out the necessity to find a least 2 more members of AAG, one from the technology and one from the end-users’ side.
Fivos Andritsos chaired the ASPIS advisory group (AAG) meeting, held at the RATP Bastille premises, Paris on March 20th 2012. C. Fedorczak, F. Sabourin and T. Kalogeras, from the ASPIS consortium, also participated to the meeting.
The AAG external members, a mix from end-users, regulators, academia and industry, included:
• Mrs Lindsay Barr – Union Internationale des Transport Publiques (UITP)
• Mrs M.Dandoulaki – Regional Planning, Attika region, GR
• Mrs Marie-Hélène Adam - Chef du Bureau de la Défense Civile, Préfecture de Police, Paris, FR
• Mrs Laila Gide – European projects, THALES, FR
• Mr Jean-Luc Planchet – MOP, RATP, FR
• Mr François Drezet – Chantiers Navals STX, St Nazaire, FR
• Dr Panayotis Kikiras – AGT Group (R&D) GmbH, Darmstadt, DE
• Dr Pawel Kepka, Main School of Fire Services, Warsaw, PL
• Prof Thilo Sauter – Austrian Academy of Sciences, Wien, AT
•
The ASPIS project results were explained in detail to the AAG members, who asked many questions. They all expressed their satisfaction on the project. A discussion on possible follow-up options followed, in particular in what regards the maritime applications. The recent wreckage of the Costa Concordia showed that the risk exists and that technology could bring a useful help to the rescue team.
Dissemination:
Dissemination activities have been done through different channels:
• A public web site
• The SAG (Security Advisory Group) whose members have also to be selected for dissemination purpose
• The demonstrations
• Conferences, workshops, publications
The website domain www.aspis-project.eu was reserved on Month 2 through AMEN, a French web access provider. The graphical design of the website was entrusted to Bruno Christen, a French Micro Enterprise. It was initially decided to have 2 parts in the ASPIS website: one public part open to everybody, presenting the project and its progress and one private part for the participants only, used for internal documents sharing.
The public part is structured in 6 pages that can be accessed individually:
• Home section presenting the project
• Organisation section
• Steps and progress section
• Partners section
• Events section
• Contact section.
A link to the partners’ web sites is provided from the logo of each of the partners.
It was decided to renew the ASPIS logo. Different logos were proposed by the graphic designer. A pool was organized and finally a new logo symbolizing a Greek shield (Aspis means shield in Greek) with a camera lens in its centre and wireless communication coming out of the shield.
Concerning the Metro application demonstration, RATP engaged a communication policy since recently in order to show their involvement in research and in security. They decided to dedicate the François Mitterrand station to such demonstration events. Initially, the aims was to demonstrate ASPIS metro application at the same time as the SIC project, a French research project led by Thales about critical infrastructures protection. One of the SIC demonstration should take place at Bibliothèque François Mitterrand station. However it appears that the planning is too tight to meet this event but also, it seems preferable to separate SIC national project from ASPIS European project.
It was decided to shoot a movie during the demonstration in order to make a DVD of it. This DVD will be used for dissemination.
For the maritime scenarios, there might be a combination of the ANEK tests with a wide dissemination activity (workshop).
These activities will be refined as the scenarios will be more advanced.
A paper was prepared for the presentation of the ASPIS project in the book “Sustainable Surface Transport Research – 7th Framework Program 2007-2013 / Project Synopses – Volume 1 – Calls 2007-2008”. The paper presentation has been included on page 228 of the book.
More dissemination actions have been achieved during the last year and after the end of the project. These actions did consist in PowerPoint presentations of the ASPIS project or the ASPIS system during security workshops or transport congresses.
Several papers, presentations and posters were prepared by the partners for various events:
• Participatory Surveillance in Emergency Situations / Fivos ANDRITSOS / CPDP 2012 (26/01/2012)
• Newspaper article after the Costa Concordia wreckage / ASPIS project / Greek newspaper (17/03/2012)
• ASPIS Maritime Outline / JRC / Leaflet for maritime transport authorities and operators (March 2012)
• ASPIS Metro brief / JRC / Leaflet for mass transport authorities and operators (March 2012)
• ASPIS Presentation / JRC / Passenger Ship Safety Conference, Brussels (24/04/2012)
• Conditional autonomous surveillance in public transport / Fivos ANDRITSOS / Public Transport International-UITP (July 2012)
• From Autonomous Sensor Networks to Participatory Surveillance / Fivos ANDRITSOS / IISA Keynote (2013)
• ASPIS Poster / ASPIS Consortium / ASPIS Workshop / (21/03/2012)
• Intelligent surveillance for managing emergencies in public transport / Fivos ANDRITSOS / Future Security, Berlin (Sept 2013)
• ASPIS : un système autonome de surveillance intelligente dans les transports publics /THALES and RATP / Videosurveillance Infos / www.videosurveillance-infos.com (05/05/2012)
A clip has been produced for the presentation of the Aspis project. This clip was prepared with the help of a communication agency named “Sansblanc” located in Paris and which was already referenced by RATP.
The story board was prepared by THALES, RATP and JRC. It has been decided to make a cartoon style clip that would present in a didactic mode the ASPIS concept in both maritime and subway applications. The duration of the clip had to be around 5 min. A first version of the clip was prepared of the final workshop in Paris (21/03/2012). It was decided to provide this clip with a French soundtrack and English subtitles. Later, a new version of the clip was produced with an English soundtrack without subtitles.
The final workshop was organised on 21st March 2012 in the Grand Amphitheatre of “La Maison de la RATP” in Paris.
This workshop was prepared by THALES, RATP and JRC with the help of a presenter Mr Gérard MAGRO.
And invitation card was created in English and in French with the help of the communication agency “Sansblanc” and sent by post mail to about 200 special guests.
This invitation was sent to EU authorities, to authorities from the different partner countries involved in transport or security or rescue, to VIPs selected by each partner and to the press journalists.
These persons have also been contacted by e-mail. 400 more persons have been contacted by e-mail.
The aim of the workshop was to present the work done in the ASPIS project and the results achieved in terms of benefits for the end-users or the public and to have this workshop organised as a TV show with a speaker asking question to the different partners. This did provide a dynamic and animated presentation of the project. Most of the presentation was on a “Question / Answer mode”.
The preparation of this presentation needed several meetings with Mr MAGRO in order to get him informed about ASPIS and to let him prepare a presentation scenario with questions about the functionalities of ASPIS and the needs to answer. Mr MAGRO prepared a set of simple questions concerning the system, the operational needs, the requirements and the results of the tests. These questions had to be answered by the speakers. This lead to a very fluid presentation.
The participants to this talk were (in order of participation):
• Sophie KLEIN, RATP
• Christian FEDORCZAK, THALES
• Fivos ANDRITSOS, JRC
• Jean-Luc PLANCHET, RATP
• Marinos NOMIKOS, ANEK Lines
• Christophe RAMBAUD, RATP
• Fabrice SABOURIN, RATP
A round table was organised at the end of the presentation with the participation of several stakeholders in the security of transport:
• Jean-Luc PLANCHET, RATP,
• Lindsey BARR, UITP,
• Marinos NOMIKOS, ANEK Lines
• Fivos ANDRITSOS, JRC
• François DREZET, STX Europe
• Gilles BETIS, THALES
• Christian FEDORCZAK, THALES
A working ASPIS system was installed in the entrance hall allowing the visitors to see physically the different components and to ask questions to the developers.
List of Websites:
web site: www.aspis-project.eu
Project Coordinator: Christian FEDORCZAK
Thales Communications & Security
christian.fedorczak@thalesgroup.com
Technical Manager: Fivos ANDRITSOS
Joint European Center
fivos.andritsos@jrc.ec.europa.eu
Introduction
The prompt availability of relevant information to the right people is the critical factor for the management of any emergency situation, in particular during the critical, early post-incident stages.
In case of a catastrophic event such as a bombing in a subway or the wreck of a ship, a quick assessment of the situation and the awareness of the number of potential victims could improve drastically the rescue operations and help to save lives.
The ASPIS project has the ambition to fill this gap by developing a video “black-box” able to send video sequences recorded just before the event to the rescue teams to help them in their tasks.
The project aims to develop and test a scalable, unattended surveillance/alarm system for public spaces, in particular for public transportation systems. Having a highly modular architecture, this innovative system is meant for the unattended surveillance of public transport, maritime transport and other public spaces. It serves primarily for the prompt and reliable situation awareness during the early, most critical emergency phase, thus greatly facilitating the overall crisis response. It is an innovative application enabling civil protection authorities to take advantage of the most recent developments in the fields of ad-hoc networking, multi-modal communications, embedded systems and microprocessor integration.
Project Context and Objectives:
The objectives and work performed can be divided into four main parts: operational and functional requirements analysis, technical analysis on the state of the art and available solutions, system design and development, demonstration
• Operational and Functional Analysis
The objectives of the operational and functional analysis were to identify the operational requirements and the functional specifications of the ASPIS system with the End-users, in the scope of improving crisis management in case of a bombing blast in a subway or the wreck of a ferryboat.
The results of this phase are input to the continued work with the systems and sub-systems design and development. They are also used for the definition of the acceptance criteria necessary for the testing and validation procedures. During this phase, the ASPIS end-users involved all the actors who interface directly with the ASPIS system in case of an emergency, like transport police, fire brigades, the ship’s captain or any other entities involved directly in metro or ferry vessel SAR operations.
• Technical analysis
In the technical analysis phase, state-of-the-art studies and feasibility testing of particular components for the ASPIS devices were performed. Three areas were mainly analysed: networking and communications, modularity and system integration and finally mechanical packaging and cost of the future solution. Technologies available and able to fulfil the functional requirements were identified and compared to the subway of ferry environment constrains allowing finally to give the inputs to design and development of the ASPIS component.
• System design and development
The systems design and development started in June 2009. The outcomes from the operational and functional analysis and from the technical analysis phases have been developed into specifications for the ASPIS sub-systems and full system. Availability and maturity of the technologies as well as environmental constrains proved to be strong factor for the selected solutions.
The architecture of the AMD (ASPIS Mobile Device) has been designed in order to be able to interface either with analogue cameras (legacy cameras) or IP cameras. The mechanical design of the AMD was achieved taking mainly into account the RATP requirements which were the most severe concerning available space (volume) and thermal requirements (heat draining without using a fan). The PC 104 form factor was selected for the processor board and frame grabber. An Ethernet switch available of the shelf has been selected for its environmental specifications and PoE capabilities meeting RATP requirements. It has been integrated in the AMD so as to provide connections for IP cameras directly powered by Ethernet (PoE). IP cameras with H.264 compression have been developed as well as a 4 channel video encoder able to compress in H.264 the videos streams provided by 4 analogue cameras and convert them into an IP stream.
The AMD communication, management and recording software has been developed in order to interface with its various peripherals (IP cameras, compression board, power management module, Wimax unit, Wifi modules) as well as with other AMDs (for redundancy and alarm spreading) and with the ASC (ASPIS Central Station). AMD power supply needed some particular attention for the selection of the battery and development of the power supply management system in order to meet the operational requirement.
Different communication paths have been developed to allow the AMDs to communicate inside the train as well as with the ACS located in the central control room. They can communicate using either a wired Ethernet link, a Wifi connection or even an ad-hoc Wifi connection. The AMD communicate with the ACS through Wimax and the Wimax unit. The Wimax unit communicates with the AMDs using either a wired Ethernet link or a Wifi connection.
This allows redundant communication paths and the ability to send data even if one communication mean is destroyed during the catastrophic event (probably the wired connection).
The ACS software has been developed in order to work either on a fixed platform (a laptop) for control room operation, or on a mobile platform (a tablet PC) for rescuers.
• Subway Demonstration
For the subway application, three AMDs were installed in a subway train and each recorded the video streams of six cameras. The triggering device composed of a microphone sensor and a pressure sensor was activated to send an alarm which froze the video buffers. The alarm as well as snapshots grabbed at the time of the alarm were transmitted to the ACS located in the Control room via the Wimax link and FO network. After alarm validation by the ACS, the AMDs transferred their video buffers, giving to the operators a clear view of the situation as it was just before the event and just after the event. The demonstration also showed the capacity to transfer a live video and audio stream from the train to the control room from anywhere in the tunnel between two stations.
• Maritime Demonstration
Two maritime scenarios were created to respond to IMO (International Maritime Organisation) requirements. The first scenario demonstrated the ability of the ASPIS system to detect an intrusion in a restricted zone using video analytics. The intrusion alarm was detected by the AMD and transferred to the ACS on the bridge with a video sequence showing the intrusion. The second scenario consisted in detecting people re-entering a zone that had been evacuated following an “Abandon Ship” order. In this scenario, cameras were installed in the passageways of the ship. The AMD and cameras are disabled in normal conditions for privacy preserving reasons. However, in case of fire or wreckage, the passengers are evacuated zone by zone by the crewmembers and when a zone had been fully evacuated, the AMD covering the zone is activated in order to detect by video analysis people trying to re-enter the zone and sent an alarm to the Captain.
Both demonstrations worked very satisfactory and demonstrated the ASPIS concept as fulfilling the requirements.
Project Results:
1. WP2 – Requirements & specifications
This work package has been launched during the kick-off meeting in Patras, Greece, involving JRC as leader of the work package, Thales providing its industrial and market knowledge on the mass transport security domain, RATP, the Paris Metro operator and ANEK Lines, a major Greek Ferry operator.
Intensive work has been done with the two end-users, RATP and ANEK, in order to define operational requirements and functional specifications for the three use-cases of ASPIS system.
The first Application Scenario (AS 1) concerns the protection of subway trains. In case of an accident or a bombing in a train running in a tunnel, the communication means between the train and the Central Station have a high probability to fall out of order, leaving the rescue team in a crisis situation where they are not able to assess the situation. RATP experienced unfortunately several bomb attacks on their network (RER B at Saint Michel station in July 1995, RER B at Port Royal Station in December 1996) and they also had very close relations with the London Underground during and after the July 2005 bombing. So their experience and analysis of such dramatic situations is really essential. In case of the London bombing, this blackout period following the blast lasted more than one hour, making the rescue operation planning and management quite difficult. Was it an accident, a fire, a derailment, a bombing? Was it a chemical attack or did a dirty bomb explode? ASPIS system as described in the DoW could prove very helpful in offering a fast assessment of the situation and providing a rescue communication channel with the train.
Several meetings were organized at RATP premises in order to work on this use-case:
• 24/07/2008 – RATP Headquarters in Paris and Thales Premises in Vélizy.
Participants: Thales, JRC, HAI, RATP
The bombing scenario was discussed and the operational requirements were specified, in terms of pre-event recording duration, frame rate and image resolution. One important requirement concerns the fact that the face of a person entering rapidly the train has to be clearly recognisable on a recorded sequence. The field of view of the cameras was also discussed in order to provide a full coverage of the space inside the cars. A state of the art of the existing technologies as well as a presentation of the systems already in use in the metro stations or on-board busses was made by Thales. Some societal issues were discussed, about covered surveillance versus deterrence effect of visible equipment. Some more capabilities were discussed, such as night vision (thermal camera), but RATP confirmed that they do not have such requirement. They tested thermal cameras for monitoring the platforms and the tracks in order to detect people falling on the tracks, but they stopped their investigations in this field, as the results were poor in comparison to the cost of the solution.
• 08/12/2008 – RATP Headquarters and Thales premises in Vélizy.
Participants: all partners.
RATP organized a visit of their Security Centre (PC 2000) where they explained the architecture of their security system and the operational procedures, focussing more deeply on the usage of live video surveillance and recorded sequences. A simulation of an alarm was done in order to illustrate the way the system is used. RATP explained the distribution of responsibility between them, the Police and the Fire brigades, and how they collaborate or exchange information. The presentation continued with a visit to the investigation room where the recorded video are analysed and where sequences relevant for legal investigations are extracted.
This presentation gave the partners a better understanding of the operational use of the video surveillance in a subway network and gave valuable inputs for the architecture of the ASPIS system.
The maritime scenarios were discussed during the kick-off meeting in Patras and during face-to-face meetings between JRC and ANEK. The outcome of these meetings was to propose two maritime application scenarios:
The second Application Scenario (AS 2) concerns a ferry use-case and more particularly the surveillance of doors and accesses to sensitive rooms or spaces of the ship. The new security regime and the ISPS code introduced a number of additional access restrictions on board of a vessel (i.e. bridge). Most doors, however, even if they have to be closed, cannot be locked (at least from both sides) as they serve for evacuation in case of emergencies. While most of the ships functions as well as the commands given from the bridge and the engine rooms are monitored at the bridge and recorded for documentation purposes, most restricted access doors are not monitored. In this use-case, the ASPIS system will be activated upon the opening of a restricted access door, signal the opening and document by a sequence of pictures showing who entered, exited or just opened a restricted access door. This information could be used by the ship’s captain for taking eventual corrective action and for documenting passages through the vessel’s restricted access doors.
The third Application Scenario (AS 3) concerns also a ferry use-case, but this time in a crisis situation when a vessel evacuation order has been given. The aim of the system, as described initially, is to provide a mean to the captain and the crew to be sure that all passengers of the ferry left the boat after an evacuation order has been given. This requirement is the consequence of several dramatic ship accidents in which passengers stayed trapped in their cabin and sunk with the ship after wreckage. The original idea, as described in the Description of Work, was to install small cameras part of the ASPIS system in all the cabins and, using video analysis, to detect if there are people in the cabin. In case of danger and need for evacuation of the ship, the ASPIS systems could detect people who did not evacuate the ship, alert the bridge and provide the crew with the location of the trapped passengers. If the usefulness of such a system in emergency conditions is undisputable, this scenario looks highly questionable for its possible effects on privacy issues, “big brother” syndrome etc.
As most of the work concerning the first deliverable had to be done over a short period across summer vacations, deliverable D2.1 on User Requirements and Operational Scenarios was finalized in Month 5, on schedule.
Deliverable 2.2 concerning Functional Specifications was more impacted by the hesitations concerning ISI and was finally issued at Month 9 instead of Month 6.
The concern about privacy issues in the third scenario described in delivery D2.1 was again discussed during the third plenary ASPIS meeting in Chania, Greece, in May 2009. As the meeting was held in ANEK headquarters, we could get the participation of people in charge of commercial issues and security issues. After extensive discussions with them, the installation of cameras in the cabins was finally rejected for privacy protection reasons, even if it could have been technically possible to de-activate the cameras in normal conditions. As a consequence, the originally foreseen scenario was modified as follows: the ASPIS cameras are no more installed in the cabins, but they are placed at all ends of the corridors giving access to the cabins. Upon an “abandon ship” signal, crew members are passing through the corridors checking that all cabins have been evacuated (this is part of the standard existing procedure). On the completion of such process they trigger the respective ASPIS device (i.e. the device controlling the access corridors of the particular set of cabins) so that ASPIS can effectively monitor that nobody accesses the cabins after these have been checked as empty. This change of scenario has minor consequences on the technical architecture of the system and it also decreases the risks concerning the complexity of image analysis in the cabins. The number of cameras will be reduced as they will no more be installed in each cabin but only in the gangways of the ship. The detection of people should be more reliable in this new configuration as the environment will be less complex in the gangways compared to the cabins were hidden zones could exist and lighting problems could occur. This change was presented to the Project Officer and approved.
This meeting gave also the partners the opportunity to visit the ANEK ferryboat ELYROS on which the ASPIS demonstration system will be installed. During this visit, the partners could discuss intensively with the captain and the officers of the ship and visit the bridge, the various decks as well as the machinery room. The partners could also exchange with Captain CHATZIDAKIS, Safety Manager of ANEK.
2. WP3 – System design
WP3 started in parallel with WP2, from the beginning of the project. This work package involved all academic and industrial partners. The end users RATP and ANEK Lines were not mentioned in the description of work; however they were regularly informed and even involved in the different choices and conclusions of this work package.
A first meeting specific to this WP took place at HAI premises in Tanagra, Greece on July 3rd 2008. It involved JRC, HAI and ISI in order to clarify the distribution of responsibilities between HAI and ISI concerning this work package. The following distribution was agreed:
• HAI
o Supervisory module
o Image acquisition module
o Embedded platform
o
• ISI
o Communication module
o Power module
o Location module
o Packaging
Deliverable 3.1 presents an analysis of the state-of-the-art of technologies that may be of use to the ASPIS project as well as of systems that are currently present on the market and that are relevant to the ASPIS functionalities. This analysis goes through technological aspects concerning embedded platforms, communication technologies, image acquisition technologies, sensor technologies for the ASPIS triggering, power module, ASPIS device mechanical aspects and finally enabling technologies for the ASPIS central station. In a second stage, D3.1 presents CCTV systems and their main components making a system state-of-the-art followed by an initial market study associated with the ASPIS expected outcome.
This report was achieved in Month 11, 5 months behind original schedule.
Deliverable 3.2 presents the Feasibility Report of the system proposed in the ASPIS project. It first presents in a tabular form the functional specifications coming from D2.2. Then, it analyses the feasibility per functional specification category referring respectively to system readiness, incident phase, uploading and processing of information and finally sustainability of the ASPIS system. It was delivered in Month 12, 3 months behind schedule.
Deliverable 3.3 is about System Architecture and Sub-Systems Specifications. A first version was issued in Month 12, almost on schedule. This first version covers almost all the system and sub-systems. However some parts such as location module, power supply or interfaces were still in discussion at this stage. As the main choices were already approved, it was decided to deliver a first version of document and not to delay furthermore the project. An updated version of this deliverable will be released later.
The interface protocols between the ASPIS sub-systems and components have been finalised in parallel with the development of the subsystems, as per work package 4. The specifications of these interfaces and communication protocols have been added to chapter 5 of deliverable 3.3 shortly after the beginning of the second period, following the Ispra plenary meeting in December 2009. The following protocol and interface definition of each software module have been described:
• Supervisory module (SUM) [Protocols 2.X)
• Triggering module (TM) [Protocols 1.X]
• Analogue camera module (frame grabber) (ACM)
• Digital camera module (DCM) [Protocols 5.X]
• Communication module (COM) [Protocols 3.X]
• ASPIS Central Station (ACS) [Protocols 4.X]
All the above modules are viewed from the AMD point of view with the exception of the ACS.
3. WP4 – Sub-systems design
WP4 started on Month 12. It was initiated during the Chania meeting in May 2009.
As the overall project suffers a delay of about 4 months, actions were discussed in order to accelerate the development of WP4 and get a chance to meet the RATP test in 2010. Therefore it was decided to avoid any technological risk and to select technologies that are already mastered by some of the partners. HAI made a presentation of the different cards that may be utilized in the framework of the ASPIS device design and implementation: PC104+ CPU boards, industrial motherboards, video grabbers, compression and analytics boards. The consortium reaffirmed its selection of the PC104 technology which was preferred compared to industrial PC board because this solution is better suited for the embedded device world.
A second discussion took place about selecting the operating system (Windows Embedded or Linux) to be used for the ASPIS Monitoring Device. Windows Embedded was finally selected as the partners in charge of the development of the AMD had lower skill with Linux. There was also a serious risk of unavailability of the Linux version of the drivers for some components to be integrated in the AMD (frame grabber for instance). In such case it would have been necessary to develop the Linux driver, with the risk of additional delay.
These structuring choices were presented to the Project officer during the 1st year meeting in Brussels on July 2nd, 2009 and the decision to make the choice of a more mature and less risky platform solution was approved.
A technical meeting on WP4 was held on 3 and 4 September at ITTI premises in Poznan, Poland. All partners but ANEK participated to this meeting. The architecture of the ASPIS Central Station (ACS) and the ASPIS Central Unit (ACU) were presented and discussed. The component diagram and state diagram were presented by RACTI and ISI and were discussed. Some priority problems were raised and discussed as well as back-up strategies in case of loss of connection between devices or lack of bandwidth.
THALES confirmed their reluctance to develop under Windows Embedded as all on-board security products they develop are under Linux. In order to overcome this difficulty, THALES proposed to completely undertake the part of imaging and audio through a dedicated PC104 sized card which can accommodate 4 IP cameras and 1 (or 4) bi-directional input links and which is connected to the PC104 processor board though a standard Ethernet port. RATP and THALES reported that the exercise for national research project SIC will be held next April in Paris and that ASPIS tests would be de-coupled for feasibility reasons. This will gives more time to the consortium to finalize the demonstrator.
An initial list of material to be purchased by the partners involved in the development of the AMD was issued at Month 14 and orders were placed following. On the ACS/ACU side, ITTI will have to buy a computer for the purpose of demonstrating the ACU. It will probably be a ruggedized laptop with a touch-screen or some function buttons. These specifications will be submitted to SAR specialists to be sure suitable equipment is used.
Following the Poznan meeting, a visit of RATP maintenance site for Metro Line 14 took place on Sept. 8th 2009 with the participation of RATP, JRC and Thales. Line 14 is an automatic driverless subway that has been selected by RATP for the demonstration. The different locations where the ASPIS components could be installed on the cars were checked. It was decided that the equipment installation for the demonstration should be light (double sided tape will be accepted for light components). RATP asked for the frequencies that will be used for the wireless transmissions in order to get approval. Site access constraints were also discussed: preparation of the demonstration will be done during the night, when the trains are out of service. Access rights for people have to be asked for well in advance. People that will work on the demonstration will have to follow a training course on security measures.
During the plenary meeting held in Ispra from December 9th to December 11th 2009, it was agreed about the major development tools that the Microsoft Visual Studio 2008 version will be used by the partner for the AMD development and also was considered to use the Dot Net environment and the C/C++ as a general development language.
HAI presented the AMD architecture and video server options with figures concerning consumption and connections.
ISI presented their progress about wireless communications and triggering devices. Options about communication devices were discussed, in particular about Wi-Fi and WiMax and interoperability between different components. It was decided to do some more tests about interoperability of the various solutions before finalising the choices.
ISI also presented their progress on the triggering devices. These devices will incorporate a microphone and a pressure sensor to detect either the noise of the blast or the pressure wave produced by the blast.
Thales presented different solutions for IP cameras and power supply options to feed them. For installations to be done without legacy systems to re-use, the best option is to use IP cameras with PoE. This will facilitate the installation and give the possibility to keep the power supply on battery back-up directly from the AMD. Thales proposed to use RTP/RTSP as communication protocol between the IP cameras and the AMD, which is a standard implemented by almost all camera manufacturers. A test of a Thales camera prototype was done during the meeting using VLC as player. This camera was given to JRC for further tests.
It was decided to set-up a purchase list in order to distribute the purchasing of the different parts between the partners. HAI will take care of this list.
Some additional requirements such as the capability to set-up a video and audio communication channel with between the Central Control Room and the AMD were raised by RATP. This would give the rescuers the possibility to communicate directly with the victims. It was agreed to add this feature to the specifications.
A technical meeting focussed on the development of the AMD and peripherals was held in HAI premises in Tanagra on 19th of January 2010 with all partners directly in charge of the AMD (HAI, ISI, RACTI and JRC). Thales joined the meeting by phone in order to discuss mechanical and connection issues. 13. Regarding the development of the AMD, an important decision was made about analogue video capture and digitization. So far the solution for this task was to include in the PC104 stack an analogue frame grabber with the capability to capture two streams. In the recent months and specifically after the Poznan meeting (September 2009) THALES proposed to offer their own custom boards for that task and as a backup solution a server board made by the company AXIS. So it was decided to develop both solutions in parallel (PC104 frame grabber, and AXIS 282A encoder) to reduce risk of the AXIS solution, until Thales solution is ready. JRC will work on the PC104 card and HAI on AXIS board. The AMD is proposed to include one PC104 frame grabber and one IP encoder (AXIS OR THALES).
An additional technical meeting was held in Tanagra HAI premises on February 3rd, 2010 with the presence of HAI, ISI, RACTI, JRC, ANEK and THALES. Different issues concerning video server SDK, back-up storage, camera power supply on battery mode, audio, mechanical design were presented and discussed. With reference to the RATP demo, THALES commented that in RATP line 14, the only space for the installation of the ASPIS device is under the seats in the car that lead to a 3u-19 inch standard, which may be inadequate for the ASPIS box taking into account casing considerations. A good solution would be for utilization of 2 boxes (one for WiMax equipment and the other of the AMD). This option is also good for reducing electromagnetic interference of WiMax equipment and the rest of the AMD. In the case that the 2 box solution is followed, it would be quite expensive to have two protected boxes per ASPIS Device. In this case the WiMax would not be further protected (own protection: NEMA4, Water & Dust proof), which does not threaten the overall system functionality, since it would be enough for one WiMax to survive per domain for the domain to have WiMax connectivity to the ACS. In the case that the WiMax box does not survive an event, the relevant AMD will communicate with the rest of the domain via Wi-Fi. Finally, the installation of the currently selected WiMAX device (size: 267 x 267 x 83 mm) outside the AMD box provides more advantages in terms of AMD box external dimensions, internal temperature / cooling issues and modularity.
Some points concerning power supply, back-up battery and video compression were discussed during the Athens meeting (24/02/2010) and Paris Meeting (17 to 19/03/2010). Various options were discussed but no final choice was made as these meetings were mainly devoted to the preparation of the demonstrations on Elyros ferry-boat and RATP subway (WP6).
A plenary meeting was held at HAI premises in Chimatari in June 2010. It appeared clearly that the development was late compared to the original schedule and that a delay of 6 months was foreseen.
HAI presented the progress made on the design of the AMD and the meeting gave the opportunity to clarify some options. It was decided to abandon the PC-104 MPEG4 frame grabber option and to concentrate on IP cameras or IP video servers (Thales 4 channels server or a COTS version).
Thales will have to provide 36 IP cameras for the demonstrations and 10 cameras will have to be provided by September 2010 for allowing partners to test their developments. These cameras will be PoE cameras.
Thales suggested using a COTS Mid Span Switch that is connected to one IP port and provides 8 IP ports for the cameras: JetNet 3810G Industrial 8-port PoE + 2-port GbE Switch, with DC12V/24V to DC48V Power boost. This solution will be incorporated in the AMD enclosure design.
Power supply and back-up battery are a critical function of the AMD. A solution meeting the specifications was found by HAI, but the product line was to be discontinued by the vendor and no replacement product was proposed. It was then decided to purchase the available parts in order to be able to run the demonstrations.
Intercom functionality will be implemented using CyberData VOIP intercom and standard audio conferencing solutions.
For the subway configuration, the ring connection between the AMDs cannot be achieved in wired mode for physical reasons. This ring connection will have to be achieved using a wire link form one unit to the next one and a wireless link between the last and the first units.
The WiMAX module will be placed externally of the AMD as close as possible to the antenna in order to reduce the RF attenuation. It will be connected to the AMD using and PoE Ethernet port. Transmission tests have been made in a road tunnel. They showed some transmission fluctuations when some trucks were moving in the RF path.
The wireless USB dongle will be installed inside the AMD providing the appropriate connector and cable for external antenna connection or outside the AMD by the use of the appropriate USB connection (depending on the specifications of the COTS product that will be used). Provision for both solutions must be made during the enclosure design.
The triggering module will be implemented in a separate enclosure containing the different sensors and processing and will be connected to the AMD through a USB port. Some explosion tests have to be organised to calibrate the triggering module.
It was decided that no localisation sensors will be designed but that positioning data from the train or the ship will be used. Provision will be made for a connection to the localisation function of the train or the ship.
A thermal analysis of the AMD components will have to be done for the design of the housing. This point is critical as no fan is allowed for on-board equipment. Heat draining will have to be done between the inner parts generating heat such as the processor and the external housing which will be used as a heat sink.
During the Patras plenary meeting (Dec. 14th to 16th, 2010), it was decided to schedule the delivery of the components for integration (WP5) by March 2011 and to extend WP4 until June 2011 to allow an overlap for debugging.
Decisions were taken about the number of AMDs to build (5 units), and who will build them, about the version of each AMD (with or without power management). The housing version for each of the AMD was not decided and had to be checked by RACTI according to availability of the parts.
ISI presented the final topology of the wireless communications which will include 2 Wi-Fi dongles per AMD, 2 wired Ethernet for connection to the adjacent AMDs and WiMax connected to the AMDs located at both ends of the train.
Some MeshMax transmission tests have been done by ISI in a road tunnel up to 800m in distance. The tunnel configuration does not allow line-of-sight connection. Big variations in throughput were detected depending on the traffic level on the second lane, especially in the presence of large trucks. Mini MeshMax did not work satisfactory. Additional test will have to be performed in the RATP tunnels in order t o select the best antenna configuration.
ITTI gave a presentation regarding the status of central station development. Open issues are diagnostics, synchronization, real-time video from the AMDs and localization. Regarding localization, it was decided if an interconnection to RATP is not achieved, to simulate it.
Time stamps can be derived from the video files retrieved from the AMDs.
Triggering tests were done at Hellenic Arms Industry (EBO) on January 28th 2011
The tests consisted in logging the signals from all 3 sensors at various positions of the triggering subsystem in respect to a FN light machine gun shooting normal munitions in a closed firing range as well as inside a small overpressure testing facility.
The noisy ventilation system provided a realistic background noise.
A reliable (i.e. failsafe and with few false alarms) triggering is possible. Some analysis and development tests at the EBO facilities may still be needed to establish a robust triggering algorithm.
When ISI will feel confident that it can deliver such an algorithm, then then JRC will proceed with a new set of live explosive tests within the frame of WP6 again at the EBO facilities.
Hardware and software tests were done with involved partners on Jan 31st and Feb 1st 2011 at RACTI in Patras. These tests were done with the following set of equipment:
• 2 AMD systems.
• 5 IP Cameras (1 ACTI5711 and 4 Thales) attached to one AMD (in its switch)
• 4 Wi-Fi (IEEE 802.11) usb toogles. Each AMD has attached 2 Wi-Fi toogles, one for ad-hoc connection between AMDs and one for connection with the MeshMAX (WiMAX).
• 2 MeshMAX access points (used for the first and the last wagon of a train)
• 1 Base Station with connection via WiMAX with the devices on the "train".
• 1 Computer used as ACS connected to Base Station with Ethernet.
Thermal results for the AMD were presented. It appeared that the oil cooling solution originally proposed by RACTI was not well suited for the prototypes. A conduction cooling solution will therefore be used.
The different communication paths between AMDs and AMD with ACS were tested successfully. Switching to a different path when one communication path fails was tested with success
Some state machine issues were discovered in some event sequences which were clearly identified and will have to be corrected.
Battery operation was successfully tested: when the AMD operates on batteries without DC input, the power management module monitors battery capacity and sends a command to the operating system to shut down the system when the batteries are exhausted. When DC input is restored, the system automatically restarts.
Another batch of tests was conducted involving the Greek partners and JRC at RACTI in Patras on April 19th, 2011. The object of this meeting was to verify, hands-on, the status of the implementation of the ASPIS devices and ensure a functioning 1st version of an image of the ASPIS software. Not all AMDs were available as some of them had already been sent to HAI’s premises, so all tests could not be done. A first version of the AMD software image, incorporating all components updates to date was provided. It includes the windows XP embedded image and all necessary drivers. It requires a boot from an external device and the complete re-writing of ASPIS disk C. It takes more than 90 minutes to complete. The image will be mounted and tested on the JRC AMD early in May. HAI was asked to do the same in their prototypes and provided feedback as to the coverage of the expected functionalities and both testing scenarios.
During the first 3 months of 2011, all HW and SW components should have been assembled together and the various SW modules combined in a complete Beta version of ASPIS SW. However, new delays accumulated, requiring a planning for an extension of 10 months. A limited number of specialised components are still missing. The responsibility is not with the consortium but with the commercial providers. Currently, the major issue seems to be that of the WiMax mid-spans.
ITTI, in close contact with RACTI and ISI, will complete the ASPIS simulator coherently with the real AMD capabilities. It should also ensure that the ACS meets the expected functionalities and test requirements prior to ship the ACS system to THALES on July.
It was agreed that the complete ASPIS AMDs should be handed from WP4 to WP5 (THALES) for the system integration by the beginning of July 2011.
4. Work Package 5: System integration
The first integration tests started by month 32. These tests concerned connection between AMDs and connection between AMD and ACS.
Initial integration tests were done by partners HAI, ISI, RACTI, JRC and ITTI (remote connection) beginning of February 2011 at RACTI in Patras. The main objective of these tests was the software and hardware (AMD embedded devices and network infrastructure) integration of ASPIS System in a demonstration room in order to simulate and test the functionality of the system.
Different tests were performed that proved encouraging and showed some improvements to be done:
Test 1: Devices interconnection through ASPIS Network
Results: All the devices (AMDs) in the train can exchange IP packets between them using all the type of network connections.
Test 2: Automatically Rerouting after connection fail.
Results: After different links disabling scenarios, the connection between AMDs was successfully re-established after some seconds. Also ACS could communicate with all the AMDs. In case of MeshMax Ethernet Fail, the connection to the AMD attached to MeshMax was interrupted which was expected (this connection is used for PoE for the MeshMax unit).
Test 3: AMD Software running in Learning State.
Results: The ACS (dummy) software was exchange messages with the AMDs. The AMD software did successfully load the new configuration.
Test 4: AMD Software running in Ready State.
Results: AMD Software successfully started the camera recording and backup to another AMD. AMD also started the domain monitoring.
Test 5: ASPIS system response in an alarm.
Results: AMD Software successfully propagated triggering both across the domain and the ACS.
The message exchange successfully changed AMD states according to the State Diagram of the specifications.
The captured data and the backup data successfully uploaded to the ACS.
The real time feed was received by ACS with satisfactory results
Test 6: ASPIS system response in network rerouting.
Results: In most of the cases the AMD software functionality worked fine when a connection fails. But in some tests, the following issues were spotted:
• In some connection fails the AMD software was triggering an alarm before the rerouting was taking place. This problem comes up because the test version of AMD software didn't interact with ASPIS network service and uses its own ping process. This interaction will be integrated in the next version of AMD Software.
• When the Ethernet connection is lost, the backup stops. This will be fixed in the next version of the AMD Software.
• Moreover, the second AMD which was still connected to ACS, detected the alarm and successfully sent it to ACS.
A second integration test was done by Greek partners (HAI, ISI and RACTI) and JRC at RACTI in April 2011. A first version of the AMD software image, incorporating all component updates was provided. It includes the windows XP embedded image and all necessary drivers. Not all AMD components were physically present at the RACTI labs. Consequently, only a very limited set of functionalities was demonstrated. It was stated that:
• HAI shall proceed with the HW integration of the 3 AMD boxes by the end of May. On their completion they will organise a technical meeting among HAI, RACTI and ISI to mount the complete SW images on the 3 AMDs and test their functionalities. Successively, they will handle the 3 boxes to RACTI for further debugging and SW integration and proceed with the HW integration of the remaining 2 AMD boxes.
• ITTI, in close contact with RACTI and ISI, should complete the ASPIS simulator coherently with the real AMD capabilities. It should also ensure that the ACS meets the expected functionalities and test requirements prior to ship the ACS system to THALES on July.
• JRC will test the provided SW image(s) on the JRC system, with and without development board.
• The complete ASPIS AMDs should be handed from WP4 to WP5 (THALES) for the system integration by the beginning of July.
• The next project meeting, combined with a verification / integration technical meeting, will be held on July (preferably) or early in September.
The tests continued during the Patras technical meeting on July 11th and 12th 2011. RACTI, ISI, HAI and JRC participated physically to this work session and other partner participated by phone and remote connection. The purpose of this meeting was to fully test the AMD, its configuration and the way the different communication channels are managed in various situations.
The work programme was divided in several tasks:
AMD Hardware Installation
Two AMD box were installed in the demonstration site. Both AMDs had full hardware components including: processors, POE switch, Batteries, Power supply, Hard Disk Drives (Solid State), 6 x POE outputs for digital cameras, 1 x POE output for MeshMax Access Point, 1 x POE output for VOIP, 2 x Ethernet output, 4 x D9 ports for analogue cameras (not connected), 1 x D9 auxiliary port for power output (12V), 3 x USB ports (2 for WiFi dongles, 1 for Sensor Board)
The box was ready and just plugged in the power supply. The only problem noticed is that the processor increased its temperature when the box is closed. This was fixed by adding a heat sink connected to upper cover of the box in order to cool the processor.
AMD OS's installation (Windows Embedded)
The installation of Windows Embedded OS included the following steps:
Connect a keyboard and a mouse to USB ports. Connect a display to VGA port
Connect an external USB HDD containing bootable Windows Embedded. Also this HDD includes the image files of AMD's OS. Switch on the AMD and select Boot from the external HDD
Using a laptop connected to the AMD via an Ethernet port and remote desktop, copy OS image files from the external HDD to the main HDD of AMD.
Remove external HDD and reboot the Machine. The OS image is automatically installed.
Remove monitor, keyboard and mouse.
The installation completed successfully after about one and a half hour per AMD.
WiFi dongles installation
The installation of WiFi dongles requires the installation of software drivers. The USB sticks were connected to the AMD and the drivers were installed via Remote Desktop using the installers provided by the vendors. One stick was configured as Access point and the second as AD-HOC mode using the vendors interface as we discovered that the Windows Embedded WiFi configuration menu didn’t allow a full configuration.
AMD Software installation and parameterization
The application software contained on a USB Stick was then installed using Remote Desktop:
ASPIS Network Service.
Filezilla Server Installer.
AMD Software.
An Autoboot sequence was added to the AMD setup in order to launch automatically the application at start-up.
Base station / ACS installation
The Router Server was already installed in a desktop PC and just plugged in the demonstration site. ACS software was installed in virtual machine with Windows XP and was running from a laptop.
Communications Verification
This step included network tests in order to ensure the right operation of AMD’s three networks and the connectivity between AMD and ACS.
The communications verification was done in several steps:
AMD – ACS communications / AMD Configuration
These tests included the exchange of messages between ACS/AMD during the Configuration phase.
Remarks and Results:
The messages exchanged successfully with the ACS.
Problem occurred in some SAC messages (New Configuration Post) when the string size is big. This problem was fixed by increasing networks stream buffer. Also some minor problems were found with the graphical interface of ACS when trying to add new cameras. The bugs were sent to ITTI for fixing them in the next ACS’s version.
Finally both AMD’s configured correctly.
AMD Normal Operation
During this task both AMDs were working in READY state recording and backing up video data.
Remarks and Results:
Both AMDs started to record and backup data without problems for about half hour (test’s duration).
Triggering Procedure Test
This test included the triggering of an alarm from AMD and all the operations that must be done after an incident:
Request Domain Identification.
Download Captured Data.
Download Backup Data.
Request Real Time Video.
Return to Normal Operation
Remarks and Results:
First we send a trigger (dummy) from one of the AMDs. Both AMD’s entered the Triggering State and stopped recording and backup. Triggering message was propagated successfully to ACS.
Afterwards, Domain identification was requested from both AMDs in order to change to SUCCESFULL state. The messages exchanged correctly.
In the next step we request the captured data (via ACS) from each camera. The files were uploaded successfully. There was a problem and the video player of ACS wasn’t able to start so the video files tested independently without any problems.
In the next step we had to request backup data, but ACS didn’t support requesting backup data. We use the ACS TEST SOFTWARE in order to check that the backup files will be uploaded correctly.
In step 4 we request for real time data. Although ACS received the correct RTSP link, the embedded video player didn’t start. We test the real time feed with VLC Player and the video was transferred without problems.
As conclusion, the main operations of after event procedure were made successfully, the video data files were downloaded and the real time stream worked fine.
System tolerance in network failures in Normal Mode.
This test is focused on the verification of system tolerance in network failures. Network failures are considered the loss of one of the three physical networks.
In particular, the test included the following steps:
Disconnection of Ethernet between the two AMDs.
After the Ethernet failure no alarm was triggered. – Test Passed
Disconnection of one of the Access Points (AMD2).
After Access Point disconnection no alarm triggered and ACS was able to see the both AMDs – Test Passed.
Power off one off the WiFi AP network.
We disconnect WiFi AP from AMD2. Because the WiFi is working over POE, the disconnection caused the power off of the Wifi AP. This event didn’t trigger any alarm. AMDs used the WiFi Ad Hoc network to communicate between them and the ACS. – Test Passed.
Disconnection of WiFi Ad Hoc network from one of the AMDs (AMD2).
After removing WiFi AH network of AMD2 an alarm was triggered which it is logical because AMDs is not connected to any network. – Test Passed.
After the last step the video data from AMD2’s cameras was uploaded from the backup stored inside AMD1.
VOIP Test
The VoIP device was installed and its functionality is tested. A VoIP software was installed in the ACS and communication tested. We test calling from both sides and everything worked without a problem.
Network Rerouting in After Triggering procedure.
The purpose of this test was to evaluate the behaviour of ASPIS system in case of a network failure during data uploading or real time stream.
Remarks and Results:
Test 1: Data uploading:
The network failure (Ethernet loss) caused the stop of data uploading. When the files were requested manually, the uploading worked fine. This problem can be overridden if ACS resumes the uploading automatically.
Test 2: Real time stream.
The video stream froze for about 10 seconds and then it continued. The time of 10 seconds is needed for the rerouting of network packages. This behaviour was judged acceptable.
An additional meeting was held in Patras from 18th to 22nd of July 2011 to continue the integration tests and to verify the AMD components and features that were not yet tested.
Testing sensor board: Configuration and Receiving alarm – Integration of board connector in order to receive power from one USB.
The Sensor module was connected and tested successfully.
2. Testing battery after power failure. – Integration of power management module needed on AMD.
After a power failure, the power supply of the AMD switched automatically on battery.
3. Timing captured video downloads after an alarm in various scenarios depending on network availability.
The video download time is very dependent on the radio channel quality as the available bandwidth is automatically decreased when the quality decreases. Recorded sequences will be sent using TCP-IP in order to get the full sequence in its integrity, even with some delay. Live streams will be more likely sent using UDP, with the risk to lose some images when the bandwidth decreases.
This behaviour is judged acceptable.
More tests have been done beginning of August 2011 in Patras for the preparation of the test scenarios.
The first test concerns the time needed for downloading to the ACS all the 30 min video sequences of the 6 cameras connected to an AMD. This time was found to be less than 20 min for 6 cameras in good transmission conditions, which is in line with the theoretical expectations.
Two cases were considered for measuring uploading time:
Case 1: Best Case
AMD is connected straight to MeshMax and then to Base Station (ACS).
Case 2: Worst Case
AMD is connected with WiFi Ad-Hoc network to another AMD which is connected to a MeshMax.
Results:
The uploading times are depicted in the table below:
Camera Case 1 (min:sec) Case 2 (min:sec)
#1 3:07 3:03
#2 3:02 3:12
#3 3:03 3:01
#4 3:04 2:58
#5 2:53 2:54
#6 2:54 2:54
Total 18:03 18:02
Conclusion:
In a perfect environment for wireless communications (line of site, small distance between antennas) the uploading time of captured data for 6 cameras is about 20 minutes (included possible delays from manual request of uploading videos) which is acceptable time frame according to the functional specifications of the project.
Best case (AMD directly connected to the MeshMax unit) or worse case (AMD connected to the next AMD by WiFi, the second AMD connected to the Meshmax unit) give almost same results (which is consistent with theoretical expectations.
Although we used 6 cameras we can assume that the uploading time of 8 cameras will be around 26 minutes which is also an acceptable time frame.
The second test scenario we tested the duration that AMD can operate without power input using only battery.
The scenario included two AMD – AMD1 and AMD2. AMD1 had attached 6 POE digital cameras, a sensor board, a VoIP device and a MeSH Max which took power from it. AMD2 has attached 1 POE digital camera and a MeSH Max.
At start both AMDs were at READY state, recording and backing up data. Test began when a triggering was propagated to AMD and AMD sat both AMDs to SUCCESFUL state. At this time point we unplugged the power supply from both AMDs. Afterwards we measured the two battery capacities of AMDs until one of them was close to empty. During test measure, we uploaded the recorded files from the AMDs and also we opened a real – time stream channel with a camera connected to AMD1 until the end of the test.
Results:
AMD1 battery started at 89,5 % and finalized at 3,5 % after 52 min and 12 sec.
AMD2 battery started at 100 % and finalized at 79 % after 52 min and 12 sec.
Conclusion:
An AMD can operate autonomously with it’s a battery for about an hour.
This duration frame can be extended in case of using AMD with managed power supply to its components. In that case the switch off of POE cameras is able to delay battery’s exhaustion. This conclusion came from the fact that the main difference between the two AMDs in the tests is that AMD1 has 6 cameras working and AMD2 only one.
A technical meeting took place in Patras from 19th to 21st of September 2011 with all technical partners (Thales, JRC, HAI, ISI, RACTI and ITTI) in order to continue system integration.
It was decided to upgrade all AMDs to the last software version and to send all equipment to Thales by end of September. Thales will do the tests of all the functionalities in their premises in Velizy with the help of some partners (foreseen JRC and ISI).
Most of the three days was spent in verifying that all sub-systems were working properly and had the same firmware/software configuration. This concerned mainly the AMDs, the WiFi dongles and the WiMax stations.
A complete set of new equipment ( 2 new AMDs, 1 base station and 2 subscriber stations, plus 4 WiFi dongles, that is a “second train” but with identical ip addresses as the first one, were programmed and tested. Results are as follows:
• One new AMD programmed and verified correctly.
• Second new AMD finally programmed, but not fully verified.
• 1 base station programmed and verified correctly.
• 2 subscriber units programmed and verified correctly.
• 4 new WiFi dongles programmed and verified correctly.
• VoIP verified
• Sensor boards verified.
It was decided that the ISI WiMax equipment (1 base station and two subscriber units) will remain at RACTI laboratory for debugging during integration tests in Thales, and will be brought to Paris for the RATP test event, if necessary.
In addition the fifth AMD, the one with the power management, will be kept to HAI premises, in prevision of the Maritime demonstration and also for debugging. It will be shipped to Paris for the final tests if necessary.
Problem insisted with one base station and one subscriber (from JRC).
Finally the following pieces of equipment were packed, and were ready to be shipped to Thales:
• 4 AMDs
• 1 WiMax base station unit, antennas and cables
• 2 WiMax subscriber units, antennas and cables
• 8 WiFi dongles
• 2 VoIP intercoms
• 5 sensor boards
• 3 MTN power supplies, 72V to 13.8 V, for train application
• 2 AC/DC adapters, 60Hz operation, 12V output, for maritime scenario.
In addition, a number of AMD components spare parts were also packed:
• 1 ISIS CPU board
• 1 MESA pc104+ Ethernet switch
• 4 batteries
• 1 IEI 120W power supply
• 3 IEI 100W power supplies ( wrong part number)
• 2 PoE WiMax midspans
• 1 ISIS CPU board cable kit.
The only AMD components spare parts that are missing are:
• 1 Korenix Ethernet switch
• 1 solid state disk (two are available at RACTI setup, but are used in the development boards).
The system integration and testing continued at Thales premises in Vélizy from October 2011 until end of December 2011 with the help of JRC and ISI which came on site for the tests.
A direct Internet connection had to be set-up in order to allow Remote Desktop connections and teleconferencing with the partners. Several bugs were detected and solved and the functionalities of the ACS were also adapted in order to improve the ergonomics and operations. For instance, the way the sequences are up loaded has been improved in order to give quickly and overview of the situation to the ACS operator.
At the end to the integration tests, 3 AMDs and associates peripherals (cameras, triggering sensors, WiFi dongles, WiMax units) were fully configured and tested, ready for the train demonstration.
5. WP6 – Testing and Validation
WP6 was launched during the 3rd plenary meeting hosted by ANEK in Chania, Greece from 25th to 28th May 2009. A major issue of WP6 is the establishment of a SAG (Security Advisory Group) relevant to the project. Different selections of persons were presented during the WP6 kick-off coming from the following organizations:
• The Centre for Security Studies (KEMEA) of the Greek Ministry of Interior
• The International Union of Public Transport (UITP)
• The French Ministry of Interior
• Lloyd’s and RINA
• European Ship Owner Association
Additional member will have to be proposed in order to assess ASPIS design and functionalities, but also to promote it. A SAG meeting should be organized aside next plenary meeting.
The first draft of the demonstration scenarios were presented and discussed:
• The Paris metro demonstration of the ASPIS system will require 4 ASPIS devices with 4 to 6 cameras per device. The initial assumption of 10-20 devices has to be relaxed due to the change of architecture in the ASPIS project to a more modular architecture of the ASPIS device. The demonstration will take place in a line 14 train. Typical line 14 trains have 5 cars. 2-3 devices will be installed in the train covering 2-3 cars and 1 spare device will be needed. In addition to the 3 installed devices an ACU will be needed for the test. It will not be needed that an ACS is installed in the RATP emergency room (PC2000 in “La Maison de la RATP” near Gare de Lyon).
• The two maritime demonstrations will take place on the ELYROS vessel. The scope of the second maritime demonstration (AS#3) will be modified following the discussions with ANEK commercial and security representatives as explained previously in WP2 report. At least 2 ASPIS devices will be needed in order to test each of the two maritime scenarios. Both scenarios will utilize an ACS installed on the ship bridge.
These scenarios will have to be refined in order to take into account the site constraints, installation constraints and operational expectations.
No deliveries are due for this period.
Prepare the acceptance tests and demonstrations
At the very end of the first period, the decision was taken to implement 3 demonstrations to show the capacities of the ASPIS system in various conditions and environments. The first demonstration will concern a subway situation while the second and third once will concern a maritime situation on board a ferry-boat.
A meeting held in Piraeus on 24th of February 2010 on ELYROS/ANEK vessel gave the opportunity to present and summarize ASPIS project to ELYROS’ Captain Mr Stratos KAVROS and Chief Engineer Mr Panagiotis GERONTIS. The maritime application scenarios will demonstrate the ability of the ASPIS system to help application of the IMO regulations. In the second scenario, the ASPIS system will warn the Security Officer if someone tries to enter a restricted access area and provide video sequences to help the crew to catch the intruder. The third scenario will demonstrate ASPIS as a mean to detect people re-entering an already evacuated zone in case of an abandon ship procedure. As cameras will have to be installed in public corridors for this scenario, a special operational procedure will be implemented in order to ensure privacy protection for the passengers. This procedure will stipulate that the crew member will launch the ASPIS system covering a zone once he has completed the evacuation of the zone. The ASPIS system will detect people re-entering the zone by video motion detection and send an alarm to the Captain with the video sequence showing the intrusion that will help the crewmen rescue the intruder.
Regarding the ANEK on-board, tests it was made clear that nothing from the vessel’s equipment or internal spaces will be harmed. At ELYROS bridge there are currently 4 monitors for 96 cameras. Under legislation, the watertight doors of a vessel must be sealed while sailing. On ELYROS there are 4 watertight doors at the area of the engine room which is considered as restricted area. Monitoring of these doors could be used for the restricted access scenario (scenario 2). For the abandon ship scenario, it was clarified once more that the ASPIS system will set an alarm and also take pictures of the space at the same time.
Regarding the issue on the standards for equipment fastening in ships, it was clarified by Mr KOUKLAKIS, Technical Manager/ANEK, that there are no specific limitations based on regulations. Mr NOMIKOS/ANEK explained that on ELYROS vessel there is fibre optic backbone, conversion to Ethernet and power over Ethernet.
A small tour of the vessel came next with the Captain and Chief Engineer of ELYROS showing the alternative areas for the installation of ASPIS system for the tests. It was decided that the system will be placed at Deck 9, left corridor of the crew cabins and a small PC or laptop at the vessel’s bridge for the tests. Along the corridor there are empty lockers that could be used for storing some of the tools and equipment for the tests. There are 220V sockets at 60Hz in all corridors.
A meeting took place in Paris at RATP and Thales premises on March 18th and 19th 2010 to discuss more in detail the subway demonstration. The first day was dedicated to a visit of the depot of Line 14 located at one end of the line, after station Olympiades. This depot is used as parking for the trains and is also the maintenance workshop for the trains. The participants had the opportunity to visit a train and to find where to install the ASPIS components. The AMDs could be installed inside the front car and rear car where a space is available for technical equipment under the side seat. However, there is no such space in the other cars. As a first evaluation, 4 cameras will have to be installed in each car in order to get the coverage.
A full train will be equipped with cameras and AMDs that will record the last 30 minutes in their circular buffer. The cameras will have to provide a full coverage of the train. In case of an alarm triggered by the detection of a blast for instance, the buffer will be frozen and its content will be transferred to the ACS in the central control room using ASPIS communication means in the tunnels. The day continued with a visit of the BFM Station in with base stations will have to be installed in order to provide communication with the train inside the tunnel.
Different locations have been foreseen, above the tracks where the antennas could be positioned on the footbridge across the tracks.
The meeting continued with a discussion on the HMI of the ACS and the maps to be integrated. One map should provide a view of the car, with the position of the cameras, a second map shoud provide a full view of the train and position of the AMD which sent the alarm and a third map should display the line and the position of the train on it. RATP will provide drawings that will be used to generate those maps.
During Patras meeting from 14th to 16th of December 2010, different issues concerning WP6 were discussed.
Deliverable D6.1 (test scenarios) was presented by Dr Fivos Andritsos and approved.
A first discussion was made about test event preparation both for ANEK and RATP. Regarding RATP tests, they have to be performed by night, which is a strict constrain. Installation could start from 10.00 pm and the tests be performed until 5.00 am next morning, and could last 5 working days. Each morning all components must be removed and reinstalled next evening for safety reasons. This constrain will necessitate a good preparation and training. The ASPIS system will also have to be built in a form allowing installing the components and removing them quickly.
Regarding ANEK test, overall duration could be 2- 4 days, during one or two 2-way trips of Elyros vessel from Piraeus to Chania and back. Cameras could even be installed in the ceiling of the corridor in Deck 9, as it is possible to replace the affected panels.
Mr Marinos Nomikos stated that it is possible to visit Elyros Vessel and perform preparation of the installation before the actual test date, just to make sure that everything is ok in the final event.
During the different technical meetings and Project meetings the different test scenarios have been refined in order to take into account the end users need but also the operational constrains.
So it was decided that for the maritime use case, all connections between the components (cameras, AMDs, ACS) would be done using wired connections as the cables can be easily installed in the celling. This will give the opportunity to focus more on the functional requirement such as video analytics for detecting people re-entering the evacuated zone or penetrating a restricted zone. This test configuration will be prepared by HAI and ANEK with the help of the other partners.
The subway use case needed much more preparation on both technical aspects but also on all security and administrative aspects.
Work at the RATP demonstration site has to be done by night, for both preparation of the tests and tests themselves. This obliges to get administrative authorisations at least for Thales employees to comply with the work legislation.
Prevention Plans have to be submitted for the visits at RATP sites. The participants have to be declared in advance and they have to be briefed/trained concerning the security rules and behaviours when on a RATP site. The participants must have a risk insurance that covers them if something happens. The insurance certificate has to be provided.
The programme and schedule of the tests have to be precisely prepared with a tight timing.
All equipment has to be packed in cases that can be easily transported in the tunnels (Flight cases for instance) and prepared for being easily and quickly deployed once on site.
Several tests have been done on RATP sites:
The first test in a tunnel took place on 21st and 22nd of November 2011 in the “Van Dyck loop” located on line 3. This loop is no more used today and it is used to temporarily park some cars.
As this tunnel is not in service, we could access it during normal working hours, by day.
The main purpose of these tests was to check the propagation conditions of WiMax inside a subway tunnel and select the best antenna configuration. The tests were done with RATP, ISI and Thales.
The tests were mainly consisting in setting-up an ASPIS AMD connected to a simulated camera and testing the communications with the ACS.
The first day tests revealed rather disappointing as the transmission channels were not stable and no best antenna configuration could be determined. We were lacking measurement tools to measure the communication channel itself without all the application layers of the AMD and ACS.
On second day, a management tool provided by the MeshMax vendor was installed on the Laptop used for ASC. This tool allowed to monitoring the communication channel performances
Various antenna configurations (omnidirectional, sector, panel) have been evaluated but it appeared that the signal to noise was poor and results were not satisfactory. Some small changes in the position of the antenna could provide drastic changes in the quality. The conclusion was that there were a lot of reflections in this tunnel and that more stable brackets or antenna pole should be used for further tests.
A second transmission test was done at Bibliothèque François Mitterrand station and Olympiades station during the night from Friday 16th December 2011 to Saturday 17th December 2011.
These tests were achieved by RATP and Thales.
The first test consisted in verification of the transmission of video files thru WiMax from and camera + AMD located at one end of the platform to an ACS located at the second end of the platform.
Tests were done with different antennas, mainly flat antenna for AMD side and sector antenna for ACS side. Results were much more satisfactory than during the first batch of tests at Van Dyck. No particular difficulties could be noticed.
It was then decided to do a test between two adjacent stations, namely BFM and Olympiades.
The distance between both stations is about 750 m but the tunnel is not in line of sight.
It was decided to install one sector antenna at the entrance of the tunnel at BFM station. The antenna was located on the platform side, separated from the tunnel by a glass wall.
At Olympiades station, a flat antenna was installed the same way as at BFM station.
The different antennas were installed using suction cups for quick installation and removal.
This configuration allowed easy transmission of a live video stream. Operations were coordinated using GSM cell phones as no audio channel was available from the tested link!
Testing in tunnels showed a wireless connection of 10 Mbps in each direction. The test was performed between the stations “Olympiades” and “Bibliotèque François Mitterrand”, which are connected by 750 m of tunnel and vehicles in it. In non-optimal locations, the speed was a little slower. The antenna has been placed in different positions to test the effect of the location. Each operator would decide where to put it in the commercial application.
A consortium meeting with all partners was organised at Thales Vélizy on Jan 11th to 13th 2012.
The main objectives of this meeting were to discuss the results of the evaluation, the tests done in the subway tunnel and define with precision the demonstration at RATP and at ANEK.
In the metro tests, using 2 trains would be better than using 1 (2 trains means 4 AMD, 2 on each train), so it is possible to know how the system works with the backup and 2-domain communication. Christian Fedorczak proposed to locate the other AMDs elsewhere, not in another train, so it can be installed and tested easier, without the necessity of using 2 trains. RATP thinks that it is more difficult to be able to install the cameras and everything on 2 trains and have WiMAX connections on the front and on the back of the train. A proposed solution is to connect 1 train to 2 stations, and test that the train should change from one station to the other as the train moves (roaming). RATP says that a dedicated fiber connection would be needed and that it will be complex to do all this in one night.
In this test, 3 AMD and 18 cameras are used on a train that moves from one station to another. The circuit among the AMDs is closed using wireless connections.
This test comprises several phases:
1 - Normal scenario
• Check that everything is connected and configured.
• Get live video with the train stopped.
• Get live video with the train moving.
2 - Emergency scenario
• The trigger module is activated. The train stops. The uploading starts. Maybe the light should be switched off.
• An Ethernet cable is disconnected after some minutes to test the resilience. These tests could be also done in the laboratory.
• Take power off from one AMD and see if the system triggers.
• A video capture of the screen should be recorded during the tests in the ACS.
• In case an AMD is powered off, the AMD that notices it creates the trigger, so the snapshot received will be the one from the AMD that generated the trigger. It should be better to receive the snapshot of the AMD powered off, but it would take time to change it. This is assigned with low priority. In any case, the images will come from near the place of the incident, so maybe it is enough.
For the maritime scenario test it will be necessary to use 1 AMD, 1 ACS and a minimum of 3 cameras (would be better 5 or 6). There are two maritime scenarios:
• In the first maritime scenario, 2 cameras will be used for motion detection and a 1 or 2 over a sensitive door, triggered by one relay. When it is triggered, the alarm is sent to the bridge and the video afterwards (30 - 60 s). It has not been defined yet what happens if the door remains open.
• The second maritime scenario is the evacuation scenario. Here, a minimum of 2 cameras are needed for the test. 6 cameras will be used in real applications. The system is manually put into the ready state (through a switch) after checking that all rooms are empty, and it is triggered by motion detection. Currently, the system has no button for putting it manually in the ready state; it can only be manually powered-on. When the button is pressed:
o The system goes through the power-on procedure
o After a couple of minutes it has to attain the ready state, with the motion detection activated; motion detection algorithm should be calibrated so as not to trigger on luminance or slight changes clearly not involving humans
When triggered by the motion detection algorithm, the system sends an alarm (with the snapshot), freezes its buffer, and starts streaming real time video. The buffer is uploaded in parallel for documentation purposes.
The map of the vessel for information purposes has not been configured yet, but the system is prepared to do it easily. It should have the identifications of the cameras, so it should be able to mark on the map where the cameras / doors that have triggered the alarm are. In the corridor scenario, the captain has to be able to click on one camera and see the images, as in a normal surveillance system.
Cabling and installation for the RATP demonstration was prepared from 8th to 10th February during day time between morning rush hour and evening rush hour.
Location of the 18 cameras, 3 ASPIS devices and WiMax antennas had to be selected. As it was not allowed to drill holes to install the different parts, it was decided to install all the cameras using brackets with suction cup. Antennas were installed on the front windshield using suction cups. AMD’s were installed on the floor, against a seat and firmly secured by belts. 2 AMDs were located in the first and last car, and the third was located in a car in the middle of the train. All the cables had to be taped on the walls or on the ground
.
Power supply was provided from the train (72 V DC) from behind a door panel. All cables were prepared with the right length for connecting the cameras to the AMDs, the triggering sensors to the AMD, the AMDs between them, to bring the power to the AMDs and to connect the MeshMax units to their respective AMD. The devices and the cables were labeled to allow quick installation and removal.
The second and the third day were reserved to exercise for installation and dismounting. The different task were assigned to each participant who knew exactly what to do and we managed to install the complete system in less than one hour and to dismount it and clean the train in less than half an hour.
On the ground side a Fiber Optics cable had been pulled by RATP for the ASPIS project between Olympiades station and BFM Station. This cable allowed to connect the WiMax base station of Olympiades to the “Control room” that had been set-up in a technical room at BFM Station. This gave the possibility to test the roaming capacity by switching from BFM base station to Olympiades base station and to follow the train wherever it is located inside the tunnel.
In the control room at BFM, a network had been set-up connecting the two base stations and the ACS. The Ethernet to fiber converter was installed close to the switch. A Wifi network was created to allow easy connection of the ACS. Antennas and base stations were installed using suction cups as tested during the previous test session.
The validation tests by themselves were done during two nights from 13th to 14th February and 14th to 15th. The first night was dedicated to testing the communications between train and ground in various locations. The train was moved from one station to the next one while the communication channels were monitored. The train also did some stops inside the tunnel to check if the communications remained satisfactory, event in the presence of other trains in the tunnel. Communications channels were monitored on both base stations and the quality of the communication was judged satisfactory. A bandwidth of 10 Mb/s could be achieved in almost all configurations.
Additional tests were done as the train went about 400 m in the tunnel behind Olympiades station. The communication could be kept with the base station located at BFM, which was more than 1 km away.
The second night was more dedicated to the functional tests corresponding to the requirements. Triggering of an alarm was tested and validated. The image sequences were transferred to the ACS using the WiMax channel. A mobile ACS located in the train but that was simulating a rescuer with a mobile device was able to get the connection with the AMD using the WiFi Channel of the AMDs.
All the validation could be achieved and gave satisfactory results.
The Maritime use-case was prepared mainly in Greece in close collaboration with ANEK.
Several meetings were done with ANEK representatives and visits of Elyros ship were organised for preparing the demonstration.
The maritime demonstration was organised from 19th to 21st February 2012 on the ELYROS Ferry-boat, in Piraeus. On 19th, a meeting in ANEK offices was scheduled in order to finalise the installation and the tests to be run.
The ASPIS maritime system was installed on deck 9 of the ELYROS ferry of ANEK LINES. The corridor on top right was monitored in order to detect any access in and out to the sensible rooms while the sensitive door giving access to the crew compartments and the bridge was monitored and any access dully recorded.
The AMD used for the demonstration were installed in a corridor while the ACS was installed on the bridge close to the security room.
The tests were done on 20th and 21st and were successful, in line with the requirements from WP2.
Both demonstrations, subway and ferry-boat, were done only with the partners of the project as it was difficult to invite external guests for security reasons. The results were very positive according to the end users..
All the details of the tests and results can be found in D6.1 and D6.2 respectively.
6. Blast tests
Collaboration with the SECUREMETRO project (FP7-SST-2008- 234148) was initiated in 2011 thanks to RATP who was participating in both projects. The aim of SECUREMETRO was to develop validated material selection and design strategies for building metro vehicles with intrinsic security features. SECUREMETRO planned to have a blast test with a real metro car to check the validity of their choices. This was a good opportunity to install ASPIS inside this car and check if it could support a real blast. The blast test initially planned in Sept 2011 was postponed 2 times and was finally done on Oct 17th 2012 in Burgos, Spain.
In order to do this test, one ASPIS prototype was placed in a full-scale coach, which was blown up during live explosion. The ASPIS system performed better than expected. The AMD box, placed at its nominal position at the undercarriage, survived the explosion and all the recorded sequences prior to triggering could be uploaded. Even one of the cameras survived the explosion and recorded live the blast. The other cameras were blown out as they were not attached firmly enough to the structure of the vehicle. It comes out from this test that small inexpensive cameras are likely to survive even very violent explosions if they are attached correctly with enough slack cable.
Potential Impact:
An initial market survey was done at the beginning of the project by Thales, concentrating on Train, Subway and Busses (public mass transportation systems). These sectors are already accessed by Thales who sells for instance on-board video surveillance systems to Paris commuter trains, subways in Copenhagen, Dubai, busses for RATP, etc. There is market demand for on-board video surveillance systems that are used to fight against crime and delinquency. Video provided by the cameras are recorded and in case of an incident, the records are analysed by the police in order to investigate the cases and identify the criminals. The aim of ASPIS is slightly different as it is a system dedicated to crisis management in catastrophic conditions. ASPIS uses the same basic technologies as a conventional on-board video-surveillance system: video cameras, video recorders. However, ASPIS provides additional features such as redundancy for components and communication links between these components, real time communication from inside the tunnels to the central control room and also hardened components able to resist a blast or a fire. After the bombings in Madrid and in London, an opportunity was foreseen for ruggedized equipment able to resist a blast. Some US/Canadian companies (March Networks for instance) showed some videos on YouTube of explosion tests done in a bus with a video recorder installed inside the bus. However, no such product has been proposed up to now on the market.
After the 2007 riots in Paris suburbs, several RATP busses have been fired and the question of having fire resistant devices has been discussed with RATP in order to be able to identify the pyromaniacs. Finally such a fire resistant solution has been rejected as the cameras are recording what happens inside the bus and therefore they cannot catch the pyromaniacs who stand outside the bus. More, RATP has authorisations to record what happens inside the busses but not on the streets.
However, RATP is interested by the resilient communication architecture that will be developed for ASPIS, both inside the train, and also between trains and stations, without any pieces of equipement installed in the tunnels.
On its side, HAI, as an aeronautics systems provider, is familiar with ruggedized components and recorders and ASPIS could provide a good opportunity to develop its market on the mass transport sector.
ITTI is mainly working on communication infrastructures for operators and management systems for these systems. They could find some business opportunities and benefit of the experience they will get in the management of the communications between the trains and the central control room.
The academic partners on their side are not interested in the development and sale of industrial products.
At this stage, it is not obvious if the transport operators are ready to invest in systems such as APSIS, dedicated to crisis management, as there is not regulation or legal framework that will oblige them to install such systems. The trend seems more in the development of on-board video surveillance systems that will be used for fighting against crime but that will also be used to deliver information or entertainment to the passengers. Concerning ground transport, wideband communications between trains (or busses) and the control room is a real problem that is not yet solved. Not technical solution has proven its ability to provide coverage inside tunnels without intermediate relays. The technologies and the communication architecture that will be developed for ASPIS could provide a good solution. However this critical point hasn’t been validated at this point and the credibility and the feasibility of the solution have to be proven.
After discussion with the partners, it appeared that the academic partners were not interested in the development of an industrial solution of the ASPIS project.
ITTI on its side is not present on the transport market and has no plan to develop its business in this domain.
No specific business agreement has been signed between Thales and HAI. Results of the ASPIS project are exploited in accordance with the rules described in the consortium agreement. HAI developed mainly the hardware of the AMD from COTS PC104 boards. Software of the AMD was developed by HAI and ISI on Windows embedded OS. These developments will be fully exploited by HAI.
Thales is already in the transport security business (train, subway, busses) and will continue to develop its activity in the domain. The developments made in the framework of ASPIS, mainly the IP encoding board and IP camera, will be used in the new generation of on-board video recorders with a specific software running on Linux.
Scientific Advisory Group
The Ispra plenary meeting on Dec 2009 gave the opportunity to organise the first Scientific Advisory Group (SAG) meeting with the presence of external members of the Advisory Group. The members of the SAG are:
• Lindsey BARR, International Association of Public Transport (UITP), Belgium
• Georges LEVENTAKIS, Centre for Security Studies, Hellenic Ministry of the Interior, Greece
• Thilo SAUTER, Institute for Integrated Sensor Systems, Austrian Academy of Sciences, Austria
• Pawel Kepka, Civil Safety Engineering Faculty, The Main School of Fire Service, Poland
After a presentation of the participants followed by an overview of the ASPIS project, Dr Fivos Andritsos introduced some of the implication issues related to the ASPIS project and particular attention was dedicated to the data privacy.
Thilo Sauter warned about the possible psychological effects of the camera installations since, according to his experience, just the view of all these cameras may induce into passengers the feeling of being continuously monitored.
In the afternoon Dr Andritsos presented a highlight of the LOCCATEC project and following this presentation, the Advisory Group members asked several questions about the features of the ASPIS project. It was explained that the devices are triggered only by an explosion sensor but there might be also a secondary trigger when a node is missing. It was asked about the handling of an intentional triggering activated in order just to prevent the camera to record and consequently a malicious security attack might take place. This kind of event is certainly possible but the security plan shall take care of these possible threats.
Dr Fivos Andritsos pointed out the necessity to find a least 2 more members of AAG, one from the technology and one from the end-users’ side.
Fivos Andritsos chaired the ASPIS advisory group (AAG) meeting, held at the RATP Bastille premises, Paris on March 20th 2012. C. Fedorczak, F. Sabourin and T. Kalogeras, from the ASPIS consortium, also participated to the meeting.
The AAG external members, a mix from end-users, regulators, academia and industry, included:
• Mrs Lindsay Barr – Union Internationale des Transport Publiques (UITP)
• Mrs M.Dandoulaki – Regional Planning, Attika region, GR
• Mrs Marie-Hélène Adam - Chef du Bureau de la Défense Civile, Préfecture de Police, Paris, FR
• Mrs Laila Gide – European projects, THALES, FR
• Mr Jean-Luc Planchet – MOP, RATP, FR
• Mr François Drezet – Chantiers Navals STX, St Nazaire, FR
• Dr Panayotis Kikiras – AGT Group (R&D) GmbH, Darmstadt, DE
• Dr Pawel Kepka, Main School of Fire Services, Warsaw, PL
• Prof Thilo Sauter – Austrian Academy of Sciences, Wien, AT
•
The ASPIS project results were explained in detail to the AAG members, who asked many questions. They all expressed their satisfaction on the project. A discussion on possible follow-up options followed, in particular in what regards the maritime applications. The recent wreckage of the Costa Concordia showed that the risk exists and that technology could bring a useful help to the rescue team.
Dissemination:
Dissemination activities have been done through different channels:
• A public web site
• The SAG (Security Advisory Group) whose members have also to be selected for dissemination purpose
• The demonstrations
• Conferences, workshops, publications
The website domain www.aspis-project.eu was reserved on Month 2 through AMEN, a French web access provider. The graphical design of the website was entrusted to Bruno Christen, a French Micro Enterprise. It was initially decided to have 2 parts in the ASPIS website: one public part open to everybody, presenting the project and its progress and one private part for the participants only, used for internal documents sharing.
The public part is structured in 6 pages that can be accessed individually:
• Home section presenting the project
• Organisation section
• Steps and progress section
• Partners section
• Events section
• Contact section.
A link to the partners’ web sites is provided from the logo of each of the partners.
It was decided to renew the ASPIS logo. Different logos were proposed by the graphic designer. A pool was organized and finally a new logo symbolizing a Greek shield (Aspis means shield in Greek) with a camera lens in its centre and wireless communication coming out of the shield.
Concerning the Metro application demonstration, RATP engaged a communication policy since recently in order to show their involvement in research and in security. They decided to dedicate the François Mitterrand station to such demonstration events. Initially, the aims was to demonstrate ASPIS metro application at the same time as the SIC project, a French research project led by Thales about critical infrastructures protection. One of the SIC demonstration should take place at Bibliothèque François Mitterrand station. However it appears that the planning is too tight to meet this event but also, it seems preferable to separate SIC national project from ASPIS European project.
It was decided to shoot a movie during the demonstration in order to make a DVD of it. This DVD will be used for dissemination.
For the maritime scenarios, there might be a combination of the ANEK tests with a wide dissemination activity (workshop).
These activities will be refined as the scenarios will be more advanced.
A paper was prepared for the presentation of the ASPIS project in the book “Sustainable Surface Transport Research – 7th Framework Program 2007-2013 / Project Synopses – Volume 1 – Calls 2007-2008”. The paper presentation has been included on page 228 of the book.
More dissemination actions have been achieved during the last year and after the end of the project. These actions did consist in PowerPoint presentations of the ASPIS project or the ASPIS system during security workshops or transport congresses.
Several papers, presentations and posters were prepared by the partners for various events:
• Participatory Surveillance in Emergency Situations / Fivos ANDRITSOS / CPDP 2012 (26/01/2012)
• Newspaper article after the Costa Concordia wreckage / ASPIS project / Greek newspaper (17/03/2012)
• ASPIS Maritime Outline / JRC / Leaflet for maritime transport authorities and operators (March 2012)
• ASPIS Metro brief / JRC / Leaflet for mass transport authorities and operators (March 2012)
• ASPIS Presentation / JRC / Passenger Ship Safety Conference, Brussels (24/04/2012)
• Conditional autonomous surveillance in public transport / Fivos ANDRITSOS / Public Transport International-UITP (July 2012)
• From Autonomous Sensor Networks to Participatory Surveillance / Fivos ANDRITSOS / IISA Keynote (2013)
• ASPIS Poster / ASPIS Consortium / ASPIS Workshop / (21/03/2012)
• Intelligent surveillance for managing emergencies in public transport / Fivos ANDRITSOS / Future Security, Berlin (Sept 2013)
• ASPIS : un système autonome de surveillance intelligente dans les transports publics /THALES and RATP / Videosurveillance Infos / www.videosurveillance-infos.com (05/05/2012)
A clip has been produced for the presentation of the Aspis project. This clip was prepared with the help of a communication agency named “Sansblanc” located in Paris and which was already referenced by RATP.
The story board was prepared by THALES, RATP and JRC. It has been decided to make a cartoon style clip that would present in a didactic mode the ASPIS concept in both maritime and subway applications. The duration of the clip had to be around 5 min. A first version of the clip was prepared of the final workshop in Paris (21/03/2012). It was decided to provide this clip with a French soundtrack and English subtitles. Later, a new version of the clip was produced with an English soundtrack without subtitles.
The final workshop was organised on 21st March 2012 in the Grand Amphitheatre of “La Maison de la RATP” in Paris.
This workshop was prepared by THALES, RATP and JRC with the help of a presenter Mr Gérard MAGRO.
And invitation card was created in English and in French with the help of the communication agency “Sansblanc” and sent by post mail to about 200 special guests.
This invitation was sent to EU authorities, to authorities from the different partner countries involved in transport or security or rescue, to VIPs selected by each partner and to the press journalists.
These persons have also been contacted by e-mail. 400 more persons have been contacted by e-mail.
The aim of the workshop was to present the work done in the ASPIS project and the results achieved in terms of benefits for the end-users or the public and to have this workshop organised as a TV show with a speaker asking question to the different partners. This did provide a dynamic and animated presentation of the project. Most of the presentation was on a “Question / Answer mode”.
The preparation of this presentation needed several meetings with Mr MAGRO in order to get him informed about ASPIS and to let him prepare a presentation scenario with questions about the functionalities of ASPIS and the needs to answer. Mr MAGRO prepared a set of simple questions concerning the system, the operational needs, the requirements and the results of the tests. These questions had to be answered by the speakers. This lead to a very fluid presentation.
The participants to this talk were (in order of participation):
• Sophie KLEIN, RATP
• Christian FEDORCZAK, THALES
• Fivos ANDRITSOS, JRC
• Jean-Luc PLANCHET, RATP
• Marinos NOMIKOS, ANEK Lines
• Christophe RAMBAUD, RATP
• Fabrice SABOURIN, RATP
A round table was organised at the end of the presentation with the participation of several stakeholders in the security of transport:
• Jean-Luc PLANCHET, RATP,
• Lindsey BARR, UITP,
• Marinos NOMIKOS, ANEK Lines
• Fivos ANDRITSOS, JRC
• François DREZET, STX Europe
• Gilles BETIS, THALES
• Christian FEDORCZAK, THALES
A working ASPIS system was installed in the entrance hall allowing the visitors to see physically the different components and to ask questions to the developers.
List of Websites:
web site: www.aspis-project.eu
Project Coordinator: Christian FEDORCZAK
Thales Communications & Security
christian.fedorczak@thalesgroup.com
Technical Manager: Fivos ANDRITSOS
Joint European Center
fivos.andritsos@jrc.ec.europa.eu