Enhanced traffic positioning system and method

Abstract

The invention relates to an enhanced traffic positioning system and method. A computer-implemented method includes receiving, at a first one of first electronic devices, a first wireless signal transmitted by a second electronic device attached to a vehicle; a second wireless signal is sent from the first electronic device, and the second electronic device determines the position of the vehicle along the transportation path according to the second wireless signal; receiving, at the first electronic device, a third wireless signal transmitted by the second electronic device, where the third wireless signal identifies a determined location of the vehicle; and transmitting a fourth wireless signal from the first electronic device, where the fourth wireless signal identifies a determined location of the vehicle, where other electronic devices in the first electronic device wirelessly relay a fifth wireless signal along the transport path, where the fifth wireless signal identifies the determined location of the vehicle.

Description

[0001] This application is a divisional application of Chinese patent application No. 202080075742.4, filed on August 31, 2020, entitled “Enhanced Traffic Positioning System and Method”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 893,724, filed on August 29, 2019, entitled “ENHANCED TRANSIT LOCATION SYSTEMS AND METHODS,” the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0004] The present disclosure relates generally to traffic intelligence and, more particularly, to systems and methods for enhanced traffic location identification. Summary of the invention

[0005] Embodiments of the present disclosure provide systems and methods for tracking information related to transportation vehicles. For example, some embodiments of the present disclosure provide a system for enhancing the collection of location and data from vehicles traveling along a vehicle path. The system may include a communication grid architecture of a vehicle tag device and an anchor transceiver fixed to a vehicle path segment. For example, the vehicle may be a light rail train, a commuter train, a freight train, a car, an airplane, a ship, a spacecraft, a ski lift, a gondola, or other forms of transportation known in the art. The transportation path may be any path along which the corresponding vehicle moves, such as a train track, a highway, a canal or a waterway, a runway, an airway, or other vehicle paths known in the art. By providing a communication grid architecture, an enhanced transportation positioning system can be fault-tolerant while still providing highly accurate real-time positioning data for the vehicle.

[0006] The system may include a mesh network of anchor transceivers and vehicle tagging devices. Both the anchor transceivers and vehicle tagging devices may incorporate an impulse radio ultra-wideband (IR-UWB) transceiver for range ranging and backhaul data transmission, as well as transmission of other attributes relevant to vehicle tracking, including vehicle speed, charge or fuel level, warning signs, etc.

[0007] The vehicle tagging device may be mounted on the front and / or rear of a vehicle or vehicle segment (e.g., a train car). The vehicle tagging device may acquire ranging data and distance information from anchor transceivers fixed along a vehicle path (e.g., a train track, a train tunnel, a road, etc.). As the vehicle moves along the vehicle path, the vehicle tagging device may transmit a data beacon (e.g., a "ping") and the anchor transceiver may respond with a corresponding anchor identification signal including a unique identifier of the corresponding anchor and a relative distance to the vehicle tagging device.

[0008] A vehicle marker device on the vehicle may receive the anchor identification signal. The vehicle marker device may also include a processor and a non-transitory computer readable memory having computer executable instructions embedded thereon, the computer executable instructions being configured to cause the processor to calculate a real-time multilateration position fix. The vehicle marker device may inject the vehicle location (e.g., xy coordinates, xyz coordinates, track number, and distance) into the backhaul. The backhaul may represent a series of anchor transceivers that are proximate to each other and extend along the vehicle path.

[0009] In some examples, the vehicle can be a subway train, the vehicle path can be a train track, a train track substrate, or a subway tunnel, and the backhaul can be a chain of anchored transceivers extending along the train track, train track substrate, or subway tunnel to a base station (e.g., a boundary anchored transceiver).

[0010] The anchor transceiver may include a processor and a non-transitory computer-readable memory having computer-executable instructions embedded thereon configured to cause the processor to calculate a relative distance to an approaching vehicle marker device.

[0011] The anchor transceiver can send the relative distance to the vehicle tag device along with the location data to the bridge anchor transceiver through the backhaul. To improve reliability, accuracy, and fault tolerance, the anchor transceivers can be placed relatively close to each other at regular intervals along the backhaul. In some examples, the anchor transceivers can be placed at intervals between 5 and 20 meters along the girders along the tunnel wall.

[0012] These and other objects, features, and characteristics of the systems and / or methods disclosed herein, as well as the methods of operation and functionality and economy of manufacture of the associated elements of the structures and combinations of parts, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals represent corresponding parts in the various figures. It should be expressly understood, however, that the drawings are for illustration and description purposes only and are not intended as a definition of limitations of the invention. As used in the specification and claims, the singular forms of "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The technology disclosed herein according to one or more different embodiments is described in detail with reference to the following figures. The figures are provided for illustration purposes only and depict only typical or example embodiments of the disclosed technology. These figures are provided to facilitate the reader's understanding of the disclosed technology and should not be considered to limit its breadth, scope or applicability. It should be noted that for clarity and ease of description, these figures are not necessarily drawn to scale.

[0014] Figure 1A An example system for enhancing the collection of location and data from a vehicle traveling along a vehicle path consistent with embodiments disclosed herein is illustrated.

[0015] Figure 1B-1D An example method for enhanced location tracking consistent with embodiments disclosed herein is illustrated.

[0016] Figure 1E-1F Illustrated are example transceiver devices that may be implemented in an enhanced position tracking system consistent with embodiments disclosed herein.

[0017] Figure 2 An example system for enhancing the collection of location and data from a vehicle traveling along a vehicle path consistent with embodiments disclosed herein is illustrated.

[0018] Figure 3 An example system for enhancing the collection of location and data from a vehicle traveling along a vehicle path consistent with embodiments disclosed herein is illustrated.

[0019] Figure 4A An example system for enhancing the collection of location and data from a vehicle traveling along a vehicle path consistent with embodiments disclosed herein is illustrated.

[0020] Figure 4B-4E An example spatial anchor tag device layout consistent with embodiments disclosed herein is illustrated.

[0021] Figure 5AAn example graphical user interface of an app for communicating and interacting with a system for enhancing the collection of location and data from a vehicle traveling along a vehicle path is illustrated, consistent with embodiments disclosed herein.

[0022] Figure 5B An example graphical user interface of an app for communicating and interacting with a system for enhanced location tracking, consistent with embodiments disclosed herein, is illustrated.

[0023] Figure 5C An example graphical user interface of an app for communicating and interacting with a system for enhancing the collection of location and data from a vehicle traveling along a vehicle path is illustrated, consistent with embodiments disclosed herein.

[0024] Fig. 6A An example graphical user interface for displaying data from a system for enhancing location and data collection from a vehicle traveling along a vehicle path is illustrated consistent with embodiments disclosed herein.

[0025] Figure 6B An example graphical user interface for displaying data from a system for enhancing location and data collection from a vehicle traveling along a vehicle path is illustrated consistent with embodiments disclosed herein.

[0026] Figure 6C An example graphical user interface for displaying data from a system for enhancing location and data collection from a vehicle traveling along a vehicle path is illustrated consistent with embodiments disclosed herein.

[0027] Fig.6D An example graphical user interface for displaying data from a system for enhancing location and data collection from a vehicle traveling along a vehicle path is illustrated consistent with embodiments disclosed herein.

[0028] Figure 7 An example computing system is illustrated that can be used to implement various features of embodiments of the disclosed technology.

[0029] Figure 8 A Piper anchor is depicted, according to some embodiments.

[0030] Fig. 9 Depicted is a Piper border router in accordance with some embodiments.

[0031] Fig.10 A mockup of the Piper label design is depicted.

[0032] Fig.11Shown are two Piper tags installed on a test train before altitude adjustment.

[0033] Fig.12 An example of vehicle-to-roadside routing with static IP assignment is shown.

[0034] Fig.13 is an example illustration of UWB ranging between a vehicle-mounted tag and an anchor.

[0035] Fig.14 is an example illustration of an on-ramp / off-ramp showing data.

[0036] Fig.15 Depicting a subway train tunnel.

[0037] Fig.16 Depicted is a Piper anchor mounted on a subway train tunnel wall.

[0038] Fig.17 Depicted is a sheet metal mounting bracket for mounting a Piper anchor.

[0039] Fig.18 The steel beam support assembly is shown.

[0040] Fig.19 Depicted is a Piper anchor installed on a steel beam in a subway tunnel.

[0041] Fig. 20 Depicted is a Piper anchor installed on a steel beam in a subway station.

[0042] Fig.21 Depicted is the Piper 1U tag controller mounted in a Thales vehicle-mounted rack.

[0043] Fig. 22 Depicts the intended location of the label controller in the VOBC rack.

[0044] Fig.23 Depicted is the practical placement of the tag controller due to USB cable length limitations.

[0045] Fig.24 Depicted is an example communication path through the Piper data communications network.

[0046] Fig.25 Depicts an example Piper wireless distribution system network configuration supporting multiple tunnels.

[0047] Fig.26 Depicted is an example of the Piper wireless distribution system heartbeat and beacon paths.

[0048] Fig. 27Depicted is an example of Piper WDS routing around an offline anchor point.

[0049] Fig.28 Depicts the results of North Tag Controller Test 1.

[0050] Fig.29 Depicts the results of South tag controller test 1.

[0051] Fig.30 Depicts the results of North Tag Controller Test 2.

[0052] Fig.31 Depicts the results of South tag controller test 2.

[0053] Fig.32 Depicts the results of North Tag Controller Test 3.

[0054] Fig.33 Depicts the results of South tag controller test 3.

[0055] Fig.34 Depicts the results of North Tag Controller Test 4.

[0056] Fig.35 Depicts the results of South tag controller test 4.

[0057] Fig.36 Depicts the results of North Tag Controller Test 5.

[0058] Fig.37 Depicts the results of South tag controller test 5.

[0059] Fig.38 Depicts the results of North Tag Controller Test 6.

[0060] Fig.39 Depicts the results of South tag controller test 6.

[0061] Fig.40 Depicts the results of North Tag Controller Test 7.

[0062] Fig.41 Depicts the results of South tag controller test 7.

[0063] Fig.42 Depicts the results of North Tag Controller Test 8.

[0064] Fig.43 Depicts the results of South tag controller test 8.

[0065] Fig.44 Depicts the results of North Tag Controller Test 9.

[0066] Fig.45Depicts the results of South tag controller test 9.

[0067] Fig.46 Depicts the results of the North Tag Controller Test 10.

[0068] Fig.47 Depicts the results of the South tag controller test 10.

[0069] Fig.48 The original label-to-anchor distances for all 10 tests starting from the south label are plotted (including a manual run through the 7th test).

[0070] Fig.49 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0071] Fig.50 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0072] Fig.51 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0073] Fig.52 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0074] Fig.53 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0075] Fig.54 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0076] Fig.55 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0077] Fig.56 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0078] Fig.57 Depicted are odometry test results at 19 mph northbound using a south tag controller.

[0079] Fig.58 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller. Fig.59 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0080] Fig.60Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0081] Fig.61 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0082] Fig.62 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0083] Fig.63 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0084] Fig.64 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0085] Fig.65 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0086] Fig.66 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0087] Fig.67 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0088] Fig.68 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0089] Fig.69 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0090] Fig.70 Depicts some results from the day after formal testing, after a full firmware update of all anchor and tag controllers to run an experimental version of DCS (internally referred to as "DWD").

[0091] Fig.71 Depicted is the architecture of a Piper train locating system in accordance with some embodiments of the disclosed technology.

[0092] Fig.72 Depicted is a high-level positioning architecture for a Piper train positioning system in accordance with some embodiments of the disclosed technology.

[0093] Fig.73 Depicted is an example communication flow via the Piper DCS.

[0094] Fig.74Depicted is a Piper network configuration supporting multi-channel streaming according to some embodiments of the disclosed technology.

[0095] Fig.75 Depicted is an example of Piper routing with a faulty anchor.

[0096] Fig.76 An example of Piper road worker protection architecture is depicted.

[0097] Fig.77 A wearable rail worker safety device according to some embodiments of the disclosed technology is depicted.

[0098] Fig.78 Snake Tray example depicted.

[0099] Fig.79 An inter-train network (ITN) according to some embodiments of the disclosed technology is depicted.

[0100] Fig.80 A continuous integrity detection system (CIDS) in accordance with some embodiments of the disclosed technology is depicted.

[0101] Fig.81 Depicts the proposed Piper project organizational chart.

[0102] Fig.82 Depicts the proposed Piper Verification and Validation (V&V) responsibility structure.

[0103] Fig.83 Depicts the proposed Piper system lifecycle.

[0104] The drawings are not intended to be exhaustive or to limit the invention to the precise forms disclosed. It should be understood that the invention can be practiced with modification and alteration, and that the disclosed technology is limited only by the claims and their equivalents. DETAILED DESCRIPTION

[0105] Embodiments of the present disclosure provide systems and methods for enhancing location and data collection from a vehicle traveling along a vehicle path. In some embodiments of the present disclosure, a system for enhanced location and data collection includes a plurality of vehicle tag devices and a plurality of anchor transceivers configured to communicate using mesh network technology. For example, the vehicle tag devices and the anchor transceivers may include IR-UWB positioning transceivers.

[0106] In some examples, the vehicle can be a train and the vehicle path can be a train track, a train platform or a train tunnel, such as a subway tunnel system. The interaction between the anchor transceiver installed on the tunnel girder and the vehicle marking device installed on the train may help collect the geographic location of a given train. When the train passes through the tunnel, the arrival time (TOA) and / or the flight time (TOF) can be measured between the anchor transceiver and the vehicle marking device. The vehicle marking device may include a processor and a non-temporary computer readable memory with computer executable instructions embedded thereon, which is configured to cause the processor to calculate real-time multi-point positioning to effectively triangulate the location of the vehicle marking device and inject the track position of the train and the distance from the previous train station into the return trip. The vehicle marking device may include a data storage device or be communicatively coupled to the data storage device, for example, using a wireless network. The data storage device may include the location data of multiple anchor transceivers in the system. The vehicle marking device may be configured to identify and distinguish between intersections on the track and intersections behind the wall in order to identify the correct vehicle marking device geographic location.

[0107] In some examples, the interaction between stationary (e.g., anchor sensors mounted on fixed structures) and mobile sensors (e.g., tag sensors mounted on mobile vehicles) will generate sensor signals that can be processed by a distributed sensor network (e.g., including anchors and tags) for accurate positioning of the vehicle relative to the fixed structure. The positioning data generated by the distributed sensor network can be used in a vehicle tracking system to track and display relative positions and other characteristics associated with the vehicle.

[0108] The use of a sensor network as described herein can overcome the problems associated with retrofitting a vehicle tracking system in an existing transportation system (e.g., an existing subway or train system). For example, in an existing subway system where there is no network infrastructure in the tunnel, a wireless network is required to provide a location signal to the central vehicle tracking system. Existing subway trains may not have the technical means to transmit their location data in real time. In addition, based on the cost of electricity to power the tunnel, any viable system must be able to provide its own electricity or use an existing power system, such as on a moving train. The embodiments disclosed herein solve these problems by using tag sensors mounted on the train to measure data about the positioning of the train in the tunnel, and wirelessly sending the collected data to the tunnel entrance / both ends, where the data can be input into the existing subway network infrastructure available at the subway station (e.g., a backhaul network using anchor sensors). Sending data to both ends of the tunnel may also introduce redundancy and improve reliability.

[0109] Figure 1AAn example system for enhancing the location and data collection of a vehicle traveling along a vehicle path is illustrated. As shown, in some examples, the vehicle can be a train and the vehicle path can be a subway tunnel system. However, it will be appreciated by those of ordinary skill in the art that other example vehicles and vehicle paths can employ the same system. As shown, the system can calculate the distance from, for example, a first vehicle marker device on a southbound train on track 3. As shown, anchor transceivers A9, A10, A11, and A12 can all be within the communication range of the first vehicle marker device, and their relative distances (e.g., from any starting point) and / or transmission times can be sent to the first vehicle marker device. The first vehicle marker device can calculate its geographic location with high accuracy by determining the intersection distance between anchor transceivers within the range and using a triangulation algorithm.

[0110] Figure 1B-1D An example method for enhancing location tracking consistent with the embodiments disclosed herein is illustrated. For example, Figure 1B A Time of Arrival (TOA) method is illustrated, where the tag device is located at the intersection of three circles centered at three readers (Base Stations, BS); this method is called triangulation. Figure 1C The diagram shows a time difference of arrival (TDOA) method where the tag device is located at the intersection of three hyperbolas whose focal points are the reader; this method is called trilateration. Figure 1D The Direction of Arrival (DOA) approach is illustrated, where the tag device is located at the intersection of three rays emitted from three readers. There are many technical options available to implement Figure 1B-1D The enhanced position tracking method shown in .

[0111] In some examples, the enhanced positioning system can implement an ultra-wideband (UWB) positioning method. For example, location tracking can be based on the interaction between an anchor point and an active tag. In some examples, time domain UWB (TD-UWB) or software defined radio (SDR) UWB (SDR-UWB) can be used. TD-UWB can provide multiple spectrums instantaneously, while SDR-UWB can provide equivalent spectrums using multiple sequential signal transmissions. In either method, time of arrival (TOA) and / or time of flight (TOF) can be measured between anchor and tag devices. TOA measurements using TD-UWB can be performed using, for example, an 802.15.4 distance measurement protocol. TOA measurements using SDR-UWB can be performed using multi-carrier (MC) UWB (MC-UWB) and other algorithms. For both TD-UWB and SDR-UWB options, the entire operating cycle for sending, receiving and processing such TOA signals is comparable. To reduce power consumption, the anchor can be mounted at a fixed location on the wall and / or on the ceiling of a fixed structure (e.g., a subway tunnel), while the tag device can be mounted on a vehicle (e.g., a train car, a train sidewall, or a roof). In some examples, the reader can be mounted on the wall or roof of the vehicle, while the tag device is mounted on a fixed structure. The geolocation data can be delivered to both ends of the fixed structure (e.g., a subway tunnel) to provide them to the RCC through a network gateway available in the station. In some examples, the anchor and / or tag device can be powered by a small battery. The battery can be permanently charged by a suitable energy harvesting device. The difference between the power consumed and the power obtained from the collection can be small or close to zero to extend battery life.

[0112] In some examples, the enhanced location tracking system can implement a reader device and a passive or active tag device. For example, a passive tag device can include an RFID tag.

[0113] In some examples, two or more transceivers may be implemented on the tag device to communicate with the UHF RFID reader. As described herein, location estimation may implement techniques such as received signal strength indicator (RSSI), time of arrival (TOA), time difference of arrival (TDOA), and fingerprinting methods.

[0114] For TOA positioning, a tag device can be visible to multiple readers at the same time. The positioning capability of the tag device can be further improved by implementing a "trajectory" tracking algorithm, for example, the car coordinates are not only from a single observation, but from a set of continuous measurements and predicted in the processor. Machine learning algorithms (e.g., Gaussian process regression with interpolation / extrapolation, etc.) can also be implemented to improve accuracy.

[0115] TD-UWB chips configured to work as readers can communicate with each other to exchange TOA data that needs to be processed for geolocation. Since there is no network infrastructure available inside the subway tunnels, the system must provide network capabilities in the tunnels. For the low-power, low-rate data exchange expected for tag geolocation data, the 915MHz band can provide a suitable option. Since readers based on TD-UWB chips do not support this communication protocol, additional transceivers can be used to enable 915MHz wireless networking.

[0116] SDR-UWB geolocation has many similar features to the TD-UWB geolocation described above. The main difference is in the implementation. TD-UWB generates pulsed signals with instantaneous wide spectrum. SDR-UWB can generate wide spectrum by frequency stepping by generating several / many CW tones or a sequence of several baseband signals one by one. In SDR-UWB, such received signal components are processed to "synthesize" an equivalent time-domain UWB signal. A typical SDR can form a digital baseband signal with up to 50-60MHz instantaneous bandwidth with a clock of hundreds of MHz. The overall time budget for the complete transmit-receive-processing cycle of a UWB signal in TD-UWB and SDR-UWB can be compared, because time-domain reception is not performed in true real-time in TD-UWB, but by sequential sampling. SDR-UWB waveforms can be updated at a rate of 10-20ps. One hundred such generated spectral components are sufficient to “synthesize” any UWB pulse within a time budget of a few milliseconds, thus achieving a refresh rate of ≥100 Hz for SDR-UWB geolocation.

[0117] In SDR-UWB, wider signal bandwidths require more power, while narrower signal bandwidths require less power. Certain minimum UWB signal bandwidths are required to provide key system functions such as (1) good range resolution and accuracy, (2) multipath propagation mitigation, etc. This bandwidth will be evaluated first in simulation and then verified in hardware testing.

[0118] In SDR-UWB, a power-saving, one-way tag reader communication protocol can be implemented using a multi-carrier (MC) UWB (MC-UWB) positioning method. MC-UWB uses transmissions of several (many) subcarriers with an equalized (zeroed) initial phase. When such a signal is received, its FFT will be performed, and the phases of all major spectral components will be measured and processed to estimate TOA. Multiple access (multi-tag) coding can be provided by setting weighted specific subcarrier components (binary weight 0 / 1 or a few bit weights).

[0119] In a typical TD-UWB chip, at least half of the power is consumed by a permanently running clock, while SDR-UWB can be set to run with less power requirements. In addition, SDR-UWB tunable narrowband receivers may be more sensitive than sampler-based TD-UWB receivers. Finally, SDR-UWB-based radios should have better RF power budgets than TD-UWB radios.

[0120] Importantly, the UWB-SDR, as a reprogrammable radio, can be set up for networking in addition to its geolocation operation function. In particular, the SDR supports 915MHz communications. Typical SDR chips have several Tx / Rx antenna terminals, thereby implementing at least a 2x2 MIMO scheme. Thus, one pair of Tx and Rx antenna terminals can be used to support geolocation, while a second pair of Tx and Rx terminals can be used to operate 915MHz networking, as shown below for a generic 2x2 Tx / Rx MIMO SDR chip.

[0121] Additional ad hoc wireless networking is required to pass all tag location data to dedicated external users. This can be done if all geolocation measurements can be passed to both ends of the tunnel where they can enter the existing subway network at the subway station. For this purpose, the same 915MHz frequency or UWB grid can be selected. This can be achieved by installing a set of distributed repeaters or store-and-forward functions along the tunnel.

[0122] In some examples, a network mesh of UWB nodes can be connected via firmware to create a mesh and transmit tag device location data to both the previous stop gateway and the next stop gateway simultaneously.

[0123] Some embodiments may be combined with SDR-UWB geolocation. Whereas TD-UWB generates pulse signals with instantaneous wide spectrum, SDR-UWB can generate wide spectrum by frequency stepping by generating a sequence of several / many CW tones or several baseband signals one by one. In SDR-UWB, such received signal components can be processed to "synthesize" an equivalent time domain UWB signal. SDR can form a digital baseband signal with an instantaneous bandwidth of up to 50-60MHz with hundreds of MHz clocks. The overall time budget of the complete transmission-reception-processing cycle of UWB signals in TD-UWB and SDR-UWB can be compared, because time domain reception is not performed in real time in TD-UWB, but by sequential sampling. SDR-UWB waveforms can be updated at a rate of 10-20μs. One hundred spectral components generated in this way are sufficient to "synthesize" any UWB pulse within a time budget of a few milliseconds, thereby achieving a refresh rate of ≥100Hz for SDR-UWB geolocation.

[0124] In SDR-UWB, a wider signal bandwidth may use more power, while a narrower signal bandwidth may use less power. One way in which the tag device-anchor communication protocol can be implemented to save power is to use a multi-carrier (MC) UWB (MC-UWB) positioning method. MC-UWB can use transmissions of several (many) subcarriers with equalized (zeroed) initial phases. When such a signal is received, a fast Fourier transform can be performed, and the phases of all major spectral components can be measured and processed to estimate TOA. Multiple access (multi-tag) coding can be provided by setting weights for specific subcarrier components (e.g., binary weights 0 / 1 or several bit weights).

[0125] In a TD-UWB chip, at least half of the power is consumed by a continuously running clock, whereas SDR-UWB can be set to operate with reduced power requirements. Additionally, SDR-UWB can include a tunable narrowband receiver that may be more sensitive than a sampler-based TD-UWB receiver. An SDR-UWB-based radio may have a better RF power budget than a TD-UWB radio.

[0126] In some examples, in addition to its geolocation operating functionality, a UWB-SDR may include a reprogrammable radio that is set up for networking. In particular, the SDR supports 915MHz communications. An SDR chip may include several Tx / Rx antenna terminals, implementing at least a 2x2 MIMO scheme. Thus, one pair of Tx and Rx antenna terminals may be used to support geolocation, while a second pair of Tx and Rx terminals may be used to operate 915MHz networking, as shown below for a generic 2x2 Tx / Rx MIMO SDR chip.

[0127] Figure 1E-1F An example transceiver device that can be implemented in an enhanced location tracking system is illustrated. For example, Figure 1E An example 2x2 Tx / Rx SDR layout is illustrated to enable geolocation and 915MHz operation. Both geolocation and networking operation functions can use different types of antennas connected to their respective Tx / Rx terminals. The antennas can be omni-directional, 180 degree, high gain, circular array, or other antennas known in the art.

[0128] The system for enhanced location tracking can implement different example communication modes. For example, TOA data communication exchange between all readers involved in the geolocation of the same tag device can be implemented to combine individual TOA measurements for tag geolocation. In some examples, communication between readers and in-tunnel network nodes can be implemented to collect calculated tag geolocation data. In some examples, communication within the in-tunnel network can be used to pass the calculated geolocation data to both ends / entrances of the tunnel to make them available through the in-station subway network gateway.

[0129] In some examples, the system can implement a low-power wireless network at a frequency of 915 MHz. In other examples, Bluetooth, ZigBee, Wi-Fi, or cellular can be used. Figure 1F An example communication module consistent with embodiments disclosed herein is illustrated.

[0130] In some examples, a UHF / UWB hybrid radio with an asymmetric wireless link can be implemented as an anchor and / or tag device. In the downlink (reader-tag), similar to traditional passive backscatter RFID, a UHF transmission protocol can be used to control and activate the tag device. In the uplink (tag-reader), the energy obtained from the UHF CW can be adapted to the IR-UWB transmitter to send data at a high data rate in a short duration.

[0131] A Real-Time Location System (RTLS) solution can be implemented. Operating at low frequencies, such as within the AM broadcast band (530-1710kHz), the NFER system can exploit the near-field behavior of radio signals within about one-third of a wavelength. If close to a small antenna, the electromagnetic components of the radio wave are 90 degrees out of phase. Far away from the small transmitting antenna, these components converge to be in phase. By detecting, measuring and comparing the electrical and magnetic phases separately, a distance measurement can be obtained.

[0132] Some example systems may implement LIDAR to provide the distance to a target by illuminating the target with a pulsed laser and measuring the reflected pulses with a sensor.Some example systems may implement millimeter wave (MW) radar.

[0133] Figure 2 Another embodiment of the example shown in Figure 1 is illustrated. Figure 2 As shown, the system can calculate the distance measurement of the second vehicle marker device on the northbound train on Track 1. As shown, the anchor transceiver devices A9, A10, A11 and A12 can be within the range of the second vehicle marker device and can send their relative distances to the second vehicle marker device. The second vehicle marker device can calculate its position with high accuracy by identifying the intersecting distances between the anchor transceivers within its range and applying a triangulation algorithm.

[0134] exist Figure 1A and 2 In some examples of the illustrated embodiments, an anchor transceiver in a first wall adjacent to a vehicle path (e.g., a west wall as shown) can forward packets along a corresponding return trip (e.g., northbound), and an anchor transceiver along a second wall adjacent to the vehicle path and opposite to the first wall (e.g., an east wall as shown) can forward packets along a corresponding return trip (e.g., southbound). When the vehicle tag device calculates its position, it can inject (e.g., send) its position into the return trip by sending data to the farthest anchor transceiver (e.g., still within range) that it can reach in the direction in which the train is traveling and the nearest anchor transceiver (n+ / -1) that it can reach in the opposite direction. The receiving anchor transceivers forward the position data to the farthest anchor transceivers that they can reach, respectively. The forwarding process can be iteratively repeated until the position data reaches a base station (e.g., a boundary anchor transceiver). The position data can then be sent to a centralized enhanced traffic location system (ETLS). In some examples, ETLS can be a cloud-based computer server or computer server network.

[0135] and Figure 1A and 2 The embodiment shown is consistent with Figure 3 The diagram illustrates a position data signal propagating from a first vehicle tag device along multiple return paths, and Figure 4A The position data signal is illustrated as propagating from the second vehicle marker device along multiple backhauls. In some embodiments, the position data signal may propagate in both directions via one or two backhauls.

[0136] Figure 4B , 4C 4D illustrates an example spatial anchor tag device layout. For example, Figure 4B An example configuration is shown that implements readers on two tunnel side walls to locate tags on the roofs of cars. Figure 4C In another example shown, a tag on the roof of a car is positioned relative to a reader on the side wall of a tunnel. Figure 4D In another example shown, readers on two tunnel sidewalls can locate two tags on the roof of a car. Figure 4E A multi-track configuration is shown. In such a configuration, using multiple anchors to introduce redundancy can improve accuracy.

[0137] In some examples, the ETLS backhaul may include an auto-healing chained mesh. Each backhaul packet may be acknowledged by the receiving anchor transceiver (n). In the event that the anchor transceiver n fails to acknowledge a packet for any reason, the transmitting anchor transceiver (x) may attempt to re-forward the packet to an alternative receiving anchor transceiver (n-1). To optimize this process, the backhaul anchor transceivers may be weighted according to their reliability in successfully forwarding packets, thereby using the most reliable path for any given environment.

[0138] The anchor transceiver can calculate and transmit the relative distance to the approaching vehicle tag device and transmit the location data to the bridge anchor transceiver via the backhaul.

[0139] In some examples, the anchor transceiver may include one or more UWB radios operating across multiple channels (e.g., between 3 and 12 channels). In some examples, the radio may operate in a range between 3.5 GHz and 6.5 GHz. Example anchor transceivers may include a high gain bidirectional antenna, a low gain hemispherical antenna, a Bluetooth low energy 2.4Ghz radio for device configuration, an ultra-low power microcontroller, a controller button or switch, a battery pack, and / or a DC input for an energy harvesting device or an external power source. In some examples, energy harvesting may be accomplished using wind generated by a moving train, ambient heat, solar energy, induction, or other energy harvesting means known in the art. The anchor transceiver may be securely deployed via BLE.

[0140] In some examples, the vehicle marker device can be mounted on an exterior surface of a vehicle. In the example of a subway train, the vehicle marker device can be fixed to the front and / or rear of each train car. The vehicle marker device can obtain ranging and distance data, for example, as provided in a data signal sent from an anchor transceiver along the vehicle path. The vehicle marker device can send a ping. The anchor transceiver can respond to the ping with a corresponding anchor identification signal. In some examples, the anchor transceiver can also send a relative distance to the vehicle marker device that sent the initial ping. The vehicle marker device can calculate real-time multi-point positioning and inject the location data into the return trip.

[0141] In some embodiments, the vehicle marking device may include one or more UWB radios operating across multiple channels (e.g., between 3 and 12 channels). In some examples, the radio may operate in a range between 3.5 GHz and 6.5 GHz. The example vehicle marking device may include a high-gain bidirectional antenna, a low-gain hemispherical antenna, a Bluetooth low energy 2.4Ghz radio for device configuration, an ultra-low power microcontroller, a controller button or switch, a battery pack, and / or a DC input for an energy harvesting device or an external power supply. The example vehicle marking device may also include a microcomputer (e.g., a 1GHz SBC based on Linux, or other microcomputers known in the art). The example vehicle marking device may also include a power input port (e.g., a micro USB DC power input, or other power ports known in the art). The vehicle marking device may be securely provided with a unique vehicle identification via BLE.

[0142] In some embodiments, a vehicle tagging device may include two transceivers, such as UWB radios. The transceivers may be positioned to send and receive data in opposite directions, such that a first transceiver may coordinate with an anchor device to acquire vehicle ranging data, and a second transceiver may send and receive location data along the return trip. By installing a tagging device on each side of a vehicle (e.g., the front of a train and the rear of a train), a leading tagging device may use a leading transceiver to acquire ranging data and use a rear transceiver to send ranging data to an onboard computer and a rear tagging device. A rear tagging device may use its rear transceiver to send location data along the return trip.

[0143] The bridge anchor transceiver can be used as an Internet gateway to the UWB backhaul. An example bridge anchor transceiver can send vehicle location data to the ETLS cloud. The bridge anchor transceiver can be installed at access points of the vehicle path, such as entry and exit points of a train tunnel. The bridge anchor transceiver can be communicatively coupled to the Internet via wired or wireless network technology.

[0144] In some embodiments, the bridging anchor transceiver may include one or more UWB radios operating across multiple channels (e.g., between 3 and 12 channels). In some examples, the radio may operate in a range between 3.5 GHz and 6.5 GHz. The example vehicle marking device may include a high gain bidirectional antenna, a low gain hemispherical antenna, a Bluetooth low energy 2.4Ghz radio for device configuration, an ultra-low power microcontroller, a controller button or switch, a battery pack, and / or a DC input for an energy harvesting device or an external power source. The example bridging anchor transceiver may also include a microcomputer and a power input port (e.g., Power over Ethernet). The example bridging anchor transceiver may also include an energy harvesting device.

[0145] In some embodiments, the ETLS cloud may aggregate vehicle location data from bridge anchor transceivers and provide a real-time user interface, for example, using a graphical user interface disclosed herein.

[0146] Some embodiments of the present disclosure provide a method for improving the accuracy of an enhanced traffic location system. A method for improving the accuracy of an enhanced traffic location system may include coupling a digital image sensor (e.g., a digital camera) to a vehicle marking device and longitudinally positioning the digital image sensor along the axis of travel of the vehicle to capture image data in front of or behind the vehicle as the vehicle moves. Survey markers may be provided along the path of travel of the vehicle (e.g., a train track or a road) within the field of view of the digital image sensor. The method may include acquiring image data from the digital image sensor while the vehicle is in motion, identifying the vehicle position at any given time based on a visual queue captured in the image data from the survey markers, and verifying the vehicle position identified from the vehicle marking device and the anchor transceiver using the vehicle position identified from the image data.

[0147] Some embodiments of the present disclosure provide an ETLS provisioning App. For example, to facilitate the provisioning, installation, and testing of the Piper ETLS system, a mobile device application can be deployed on a smart phone (e.g., a rugged smart phone) and distributed to personnel responsible for installing and testing UWB devices on site. The ETLS provisioning App can be communicatively coupled to an anchor transceiver using a secure wireless connection (e.g., Bluetooth or WiFi). The anchor transceiver can communicate with nearby anchor transceivers within range to convey the current location of one or more vehicle marking devices and nearby survey markers to reduce the provisioning time of the anchor transceiver. The list of survey markers can be stored in a database located in the ETLS cloud and synchronized with the ETLS provisioning App when the provisioning App is connected to the network. In addition to provisioning, the ETLS provisioning App can also include a ranging function for testing the overall health of the UWB backhaul.

[0148] Figures 5A-5C is a screenshot illustrating provisioning of an anchor transceiver based on the mounting wall, originating station, anchor MAC address (via QR code scan or manual entry), and the distance from the survey marker to the south of the anchor transceiver.

[0149] Figures 6A-6D An example graphical user interface for displaying vehicle positioning information is illustrated. Fig. 6A A graphical user interface showing a graphical view with the next station on a route highlighted along with the track the train is leaving is illustrated. Figure 6BA graphical user interface is illustrated showing a graphical view of a train track with a highlighted line and the track that the train is leaving. Figure 6C and 6D A graphical user interface is illustrated showing an animation of a vehicle position on a route and corresponding data received from a vehicle marking device and / or anchor transceiver. The user interface may show the track on which the train is located, with the station located at the far edge of the page. In some examples, the station background image may fade out. In some examples, the train background image may fade in. The user interface may provide a "heads-up display (HUD)" to display and / or scroll data on the screen. The train moves from one side of the screen until it reaches the horizontal middle of the screen, then it remains centered, and then the track moves, with the survey mark updated based on the train position in the tunnel.

[0150] In some examples, the user interface can update the data displayed in real time or semi-real time. For example, the distance and / or speed data along the return trip of a given vehicle can be regularly updated in the user interface.

[0151] As will be appreciated, the method as described herein can be performed using a computing system having machine executable instructions stored on a tangible medium. The instructions can be executed to perform each portion of the method, either autonomously or with the help of input from an operator.

[0152] Those skilled in the art will appreciate that the disclosed embodiments described herein are intended only as examples and that there will be many variations. The present invention is limited only by the claims, which include the embodiments described herein and variations that are obvious to those skilled in the art. In addition, it should be understood that the structural features or method steps shown or described in any embodiment herein may also be used in other embodiments.

[0153] As used herein, the terms logic circuit and component can describe a given functional unit that can be performed according to one or more embodiments of the technology disclosed herein. As used herein, any form of hardware, software or combination thereof can be used to implement a logic circuit or component. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines or other mechanisms can be implemented to form components. In an embodiment, the various components described herein can be implemented as discrete components, or the functions and features described can be partially or completely shared between one or more components. In other words, as will be apparent to those of ordinary skill in the art after reading this description, the various features and functions described herein can be implemented in any given application and can be implemented in various combinations and arrangements in one or more separate or shared components. Even if the various features or elements of a function can be described or required as separate components separately, it will be understood by those of ordinary skill in the art that these features and functions can be shared between one or more general software and hardware elements, and such a description should not require or imply the use of separate hardware or software components to implement such features or functions.

[0154] Where components, logic circuits or components of the present technology are implemented in whole or in part using software, in one embodiment, these software elements may be implemented to operate together with a computing or logic circuit capable of performing the functions described with respect thereto. Various embodiments are described based on this example logic circuit 1100. After reading this description, it will be clear to a person skilled in the relevant art how to implement the technology using other logic circuits or architectures.

[0155] Reference now Figure 7 , computing system 1100 may represent computing or processing capabilities found in, for example, desktop, laptop, and notebook computers; handheld computing devices (PDAs, smart phones, cell phones, handhelds, etc.); mainframes, supercomputers, workstations, or servers; or any other type of special-purpose or general-purpose computing device that may be desirable or appropriate for a given application or environment. Logic circuitry 1100 may also represent computing capabilities embedded in or otherwise available to a given device. For example, logic circuitry may be present in other electronic devices such as, for example, digital cameras, navigation systems, cell phones, portable computing devices, modems, routers, WAPs, terminals, and other electronic devices that may include some form of processing capabilities.

[0156] The computing system 1100 may include, for example, one or more processors, controllers, control components, or other processing devices, such as a processor 1104. The processor 1104 may be implemented using a general or special purpose processing component, such as, for example, a microprocessor, controller, or other control logic. In the example shown, the processor 1104 is connected to a bus 1102, although any communication medium may be used to facilitate interaction with other components of the logic circuit 1100 or to communicate externally.

[0157] The computing system 1100 may also include one or more memory components, referred to herein as main memory 1108. For example, preferably, a random access memory (RAM) or other dynamic memory may be used to store information and instructions to be executed by the processor 1104. The main memory 1108 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by the processor 1104. The logic circuit 1100 may also include a read-only memory ("ROM") or other static storage device coupled to the bus 1102 for storing static information and instructions for the processor 1104.

[0158] The computing system 1100 may also include one or more different forms of information storage mechanisms 1110, which may include, for example, a media drive 1112 and a storage unit interface 1120. The media drive 1112 may include a drive or other mechanism to support fixed or removable storage media 1114. For example, a hard drive, a floppy disk drive, a tape drive, an optical drive, a CD or DVD drive (R or RW), or other removable or fixed media drive may be provided. Thus, the storage media 1114 may include, for example, a hard disk, a floppy disk, a tape, a cassette, an optical disk, a CD or DVD, or other fixed or removable media 1112 that is read, written, or accessed by a media drive. As shown in these examples, the storage media 1114 may include a computer-usable storage medium having computer software or data stored therein.

[0159] In alternative embodiments, the information storage mechanism 1110 may include other similar means for allowing computer programs or other instructions or data to be loaded into the logic circuit 1100. Such means may include, for example, a fixed or removable storage unit 1122 and an interface 1120. Examples of such storage units 1122 and interfaces 1120 may include program cartridges and cartridge interfaces, removable memory (e.g., flash memory or other removable memory components) and memory slots, PCMCIA slots and cards, and other fixed or removable storage units 1122 and interfaces 1120 that allow software and data to be transferred from the storage unit 1122 to the logic circuit 1100.

[0160] The logic circuit 1100 may also include a communication interface 1124. The communication interface 1124 may be used to allow software and data to be transferred between the logic circuit 1100 and external devices. Examples of the communication interface 1124 may include a modem or soft modem, a network interface (such as Ethernet, a network interface card, WiMedia, IEEE 802.XX or other interface), a communication port (such as, for example, a USB port, an IR port, an RS232 port, The software and data transmitted via the communication interface 1124 may generally be carried on signals, which may be electronic, electromagnetic (including optical), or other signals capable of being exchanged by a given communication interface 1124. These signals may be provided to the communication interface 1124 via a channel 1128. The channel 1128 may carry signals and may be implemented using a wired or wireless communication medium. Some examples of a channel may include a telephone line, a cellular link, an RF link, an optical link, a network interface, a local or wide area network, and other wired or wireless communication channels.

[0161] In this document, the terms "computer program medium" and "computer-usable medium" are generally used to refer to media such as, for example, memory 1108, storage unit 1120, medium 1114, and channel 1128. These and other various forms of computer program media or computer-usable media may involve transmitting one or more sequences of one or more instructions to a processing device for execution. Such instructions contained on the medium are generally referred to as "computer program code" or "computer program product" (which may be grouped in the form of a computer program or other grouping). When executed, such instructions may enable logic circuit 1100 to perform the features or functions of the disclosed technology discussed herein.

[0162] although Figure 7 A computer network is depicted, but it should be understood that the present disclosure is not limited to operation using a computer network, but rather the present disclosure may be implemented in any suitable electronic device. Figure 7 The computer network depicted in FIG. 1 is for illustrative purposes only and is not meant to limit the present disclosure in any respect.

[0163] More details can be found in the accompanying appendices: Appendix A and Appendix B.

[0164] Although various embodiments of the disclosed technology have been described above, it should be understood that they are presented only by way of example and not by way of limitation. Similarly, various figures may depict example architectures or other configurations of the disclosed technology, which is done to help understand the features and functions that may be included in the disclosed technology. The disclosed technology is not limited to the illustrated example architectures or configurations, but various alternative architectures and configurations may be used to achieve the desired features. In fact, it will be apparent to those skilled in the art how to implement alternative functional, logical or physical partitions and configurations to achieve the desired features of the technology disclosed herein. In addition, many different component names may be applied to the various partitions in addition to those described herein.

[0165] Furthermore, with respect to flow diagrams, operational descriptions, and method claims, the order in which the steps are presented herein shall not obligate the various embodiments to perform the recited functions in the same order unless the context dictates otherwise.

[0166] Although the disclosed technology is described above according to various exemplary embodiments and implementations, it should be understood that the various features, aspects, and functions described in one or more individual embodiments are not limited to their applicability to the specific embodiments with which they are described, but can be applied alone or in various combinations to one or more of the other embodiments of the disclosed technology, whether or not such embodiments are described and whether or not such features are presented as part of the described embodiments. Therefore, the breadth and scope of the technology disclosed herein should not be limited by any of the above-described exemplary embodiments.

[0167] Unless expressly stated otherwise, the terms and phrases used in this document and variations thereof should be interpreted as open ended and not limiting. As examples of the foregoing: the term "including" should be interpreted as "including but not limited to" or similar meanings; the term "example" is used to provide an illustrative example of the items discussed, rather than an exhaustive or limiting list; the term "one" or "an" should be interpreted as "at least one," "one or more," or similar meanings; and adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to items available in a given time period or at a given time, but should be interpreted as including conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Similarly, when this document refers to technologies that are obvious or known to a person of ordinary skill in the art, such technologies include technologies that are obvious or known to a person of ordinary skill in the art now or at any time in the future.

[0168] In some cases, the presence of expanders and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be understood to mean that the narrow context is intended or required where such expanders may be absent. The use of the term "component" does not imply that the components or functionality described or claimed as part of the component are all configured in a common package. In fact, any or all of the various components of the component, whether control logic or other components, may be combined in a single package or kept separately, and may be further distributed in multiple groups or packages or across multiple locations.

[0169] In addition, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts, and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives may be implemented without limitation to the illustrated examples. For example, the block diagrams and their accompanying descriptions should not be construed as mandating a particular architecture or configuration.

[0170] Annex A

[0171]

[0172] Ultra-Wideband (UWB)

[0173] Enhanced Traffic Location System (ETLS)

[0174] &Secure Communications Network Proof of Concept 2

[0175] Final Report

[0176] Revision 1.06, November 2018

[0177] Piper Networks

[0178] Piper Networks proprietary and confidential information may not be reproduced and / or redistributed without Piper Networks prior written consent.

[0179]

[0184]

[0194] Contractor Instructions

[0196] Confidentiality

[0197] This document describes the functionality of Piper Networks, Inc.’s proprietary equipment as defined in the Individual Services Agreement, dated November 22, 2017, between the Metropolitan Transportation Authority and Piper Networks, Inc. (the “Agreement”). This document and its contents are proprietary information of Piper Networks, Inc. and are its Confidential Information (as defined in the Agreement). This document is intended for the recipient’s internal review only and must be maintained and treated as strictly confidential. This document may not be distributed or reproduced for distribution in whole or in part in any form without the prior written permission of Piper Networks, Inc.

[0198] summary

[0199] Piper Networks, in collaboration with Thales Group Canada, has successfully demonstrated the integration of UWB-based Enhanced Train Location System (ETLS) positioning technology with Communications-Based Train Control (CBTC) and Next Generation Positioning System (NGPS). In addition, Piper successfully demonstrated the implementation of a new wireless Data Communications System (DCS) to manage secure data transmission between CBTC area controllers and onboard VOBCs. The Piper technology exceeded all requirements defined by the MTA and Thales in the Interface Concept and Specification Document (ICD). The system enabled Thales to operate a CBTC test train in Automatic Train Operation (ATO) mode with no communication loss, an average total packet loss of <2%, and a latency of 17.5ms between the VOBC and area controller, which is significantly below the allowable thresholds of 10% packet loss and an average one-way latency of 35ms, respectively. In summary, Piper and Thales designed, installed, tested and demonstrated a fully operational UWB powered CBTC system on live trains along an interlocking path in less than a year, using an innovative unhindered wireless data communications system – all within budget and with minimal inconvenience to passengers.

[0200] Project Requirements

[0201] Installation of a real-time train location system based on ultra-wideband technology to provide Thales onboard VOBC with precisely calculated position data along the B4 track on the F Line between Church Ave. and Seventh Avenue stations.

[0202] Facilitates secure, reliable data communications between the Thales onboard VOBC and the roadside zone controller in the CBTC room at Church Avenue, enabling connectivity to be maintained throughout the test area without signal loss.

[0203] Piper originally proposed a hybrid wireless and fiber optic loop solution for data communications systems.

[0204] But it was directed by the MTA to deliver a 100 percent wireless data communications system that would not require the installation of fiber optics or data loops in tunnels in the test area.

[0205] ● >= 120kbps UDP throughput from Piper communications equipment at each end of the train connected to the Thales VOBC.

[0206] ● Provides an aggregate throughput of >= 2.4Mbps, sufficient to sustain data communications for up to 10 trains per wireless segment.

[0207] ● Operate the system reliably with <10% packet loss.

[0208] ●Achieve an average one-way packet latency of less than 35 milliseconds from the Piper vehicle tag controller to the Thales zone controller.

[0209] ● Provides Thales with the calculated position of the train along the path as an integrated data feed from the Piper tag controller to the Thales VOBC and NGPS onboard computers.

[0210] Enables Thales to test the reliability of UWB-based positioning technology as a measure of certainty of train location, compared to both conventional CBTC and new NGPS position data.

[0211] Collect all positioning and communication data during the testing period and provide a comprehensive report to the MTA at the end of the project.

[0212] System components

[0213] Piper Anchor

[0214] Figure 8 A Piper anchor is depicted, according to some embodiments.

[0215] Purpose

[0216] Piper anchors provide the following features:

[0217] UWB ranging to Piper tags

[0218] UWB on-ramp / off-ramp for Piper 5GHz data communications network

[0219] Piper 5GHz data communication network

[0220] The Piper Anchor provides a UWB ranging response to the Piper Tag when queried.

[0221] The Piper anchor is also equipped with two 5GHz radios to form the Piper communications network.

[0222] The Piper Anchor receives IP data from the Piper Label and forwards this data to the Piper Border Router.

[0223] Additionally, the Piper Anchor receives IP data from the Piper Border Router and forwards it to the Piper Label.

[0224] hardware

[0225] The Piper anchor consists of the following electrical and mechanical components:

[0226] ●Main system board, including:

[0227] ○ Quad-core CPU, 4x ARM Cortex A7 SoC.

[0228] ○ Two 2x2 MIMO 5GHz transceivers for data communications

[0229] ○ One 2x2 MIMO 2.4GHz transceiver for deployment and maintenance

[0230] ○ Two Gigabit Ethernet controllers

[0231] Four directional 5GHz antennas for data communications

[0232] Two 2.4GHz omnidirectional antennas for maintenance radio

[0233] UWB daughter board with a UWB radio operating on 6 channels between 3.5 GHz and 6.5 GHz for precise ranging and data communications

[0234] 1 high-gain bidirectional UWB antenna

[0235] 2 externally accessible buttons (deployment / power reset)

[0236] ●Main power supply 120V AC to 12V 2.5A switching power supply

[0237] ●Watertight plastic housing with heat sink for thermal management

[0238] ●Chemically resistant Amphenol MiniBOSS M22 power cable assembly Piper border router

[0239] Fig. 9 Depicted is a Piper border router in accordance with some embodiments.

[0240] Purpose

[0241] The Piper Border Router acts as a gateway to the 5GHz Piper data communications network. It is responsible for routing data between the MTA network and the Piper DCN. Border Routers are installed at the entry and exit points of each tunnel. They are powered via Power over Ethernet (PoE) and connected to the Internet. In addition, the Piper Border Router provides the same ranging capabilities as the Piper Anchor.

[0242] hardware

[0243] The Piper Boundary Router is a Piper anchor with an additional NPT threaded Ethernet jack for weatherproof conduit connection.

[0244] Piper Tags

[0245] Fig.10 A mockup showing the Piper label design.

[0246] Fig.11 Shown are two Piper tags installed on a test train before altitude adjustment.

[0247] Purpose

[0248] The Piper tag is mounted on horizontal plastic strips supplied by Thales at the front and rear of the train. It is responsible for ranging the Piper anchors and collecting distance information from them. It is also used to send and receive network data from the Piper anchors along the train tunnels for injection into the Piper data communications network.

[0249] The electronics and antenna used for the POC2 test are mounted on an adjustable mounting device that allows the antenna to be positioned to match the height of the train. The round teardrop-shaped housing on the top contains the antenna; in a production deployment, this will be the only part mounted on the outside of the train. The square section contains the UWB tag board electronics - in production it will be mounted inside the hood, as close to the antenna as possible to minimize signal loss or interference. The tag board connects to the Piper tag controller mounted inside the CBTC cabinet in the train cab.

[0250] hardware

[0251] The Piper tag consists of the following electrical and mechanical components:

[0252] Single board computer, including:

[0253] ○ Low-power ARM-based microcontroller.

[0254] ○ 1 UWB radio operating on 6 channels between 3.5GHz and 6.5GHz for precise ranging and data communications.

[0255] ○ Micro USB jack for powering and communicating with the tag controller.

[0256] ●1 omnidirectional UWB antenna.

[0257] ● Height-adjustable mounting tower with triangular base to match mounting poles supplied by Thales.

[0258] ●Weather-resistant plastic housing for SBC.

[0259] Aerodynamic teardrop-shaped housing for UWB antenna.

[0260] Piper Tag Controller

[0261] Purpose

[0262] The Piper Tag Controller is the main onboard processing unit for Piper Odging data to calculate trilateration and to send and receive network data from the Piper DCS network. The Piper Tag Controller has two separate physically and electrically identical sections (A and B) that are responsible for data communications and Odging, respectively. Each side is connected to a Piper Tag mounted at the end of the train.

[0263] Side A provides the Piper DCS network with an on / off ramp for data sent and received by the VOBC through its Piper tag.

[0264] Side B receives the raw odometry data from its Piper tags, processes it to calculate the train's position, and then sends the resulting position data via UDP to a set of IP addresses on the train's LAN belonging to NGPS.

[0265] Piper tags belonging to the A side are mounted on the port side of the train, and Piper tags belonging to the B side are mounted on the starboard side of the train. Each Piper tag connects to the corresponding side of the tag controller via a 15-foot long USB Type-A male to micro USB male cable.

[0266] hardware

[0267] The Piper Tag Controller hardware consists of two separate single board computers (one on each side, A and B) in a rack unit box. Each includes two Tag Controllers. The Tag Controller for VOBC-1, at the north end is Tag Controller 03, and the Tag Controller for VOBC-2, at the south end is Tag Controller 02. Two additional Tag Controllers were built, Tag Controller 04 in New York City to be used as a backup and to test network functionality without trains, and Tag Controller 01 in San Diego to replicate the hardware configuration deployed on the test network. Both devices are configured to exactly replicate the configuration of the installed Tag Controller 03.

[0268] Each Piper tag controller is powered by a UPS with a direct USB power output that connects to a 110V AC outlet provided on the train.

[0269] The Piper tag controller includes two identical sets of the following ports:

[0270] 5V USB-A power input port

[0271] USB-A input port for docking with Piper tags

[0272] Two RJ-45 Ethernet ports for ranging and positioning data transmission

[0273] USB-A debug port

[0274] Architecture

[0275] Fig.12 An example of vehicle-to-roadside routing with static IP assignment is shown.

[0276] Fig.13 is an example illustration of UWB ranging between a vehicle-mounted tag and an anchor.

[0277] Fig.14 is an example illustration of an on-ramp / off-ramp showing data.

[0278] Train positioning

[0279] The interaction between the Piper anchors mounted on the tunnel walls and the Piper tags mounted on the trains facilitates the geolocation of a given train. As the train moves through the tunnel, the distance between the anchors and tags is measured using calculations based on the arrival times of the radio pulses. The tag controller uses the ranging data, the known positions of the anchors and a mathematical model of the track to calculate the train's position. The Piper tag controller then generates a UDP packet defined by the Thales API and injects it into the Thales onboard network.

[0280] Tag controller B broadcasts a location update message every 500 milliseconds. The location update report (for POC2) contains:

[0281] tag_id — identifies the tag the report refers to

[0282] edge_id – the edge of the track where the train is located

[0283] ●Offset - the arc length measured on the edge from the starting node of the edge

[0284] [x,y,z] – Train position reported in 3D local coordinates (not used in POC2)

[0285] Estimated – Flag identifying whether the train position is “measured” or “estimated” (all data generated by Piper for POC2 is “measured”).

[0286] Anchor Placement

[0287] Direct track placement

[0288] Anchors are installed along the tunnel perimeter wall approximately 4 inches below the ceiling (or in a given section of the tunnel as required). Anchors are installed approximately every 25-30 meters along the center / wall structure between tracks B3 and B4.

[0289] Placement in a high multipath environment

[0290] Piper anchors are highly immune to multipath environments (due to reliance on TOA), so placement in tunnels and stations is generally not affected.

[0291] Anchor radius

[0292] Given optimal LOS conditions, the Piper anchor performs ranging up to a radius of 125 meters using a Piper tag mounted on the train.

[0293] Anchor bandwidth

[0294] UWB

[0295] The anchor communicates with the Piper tag at a raw data rate of 6.81Mbps, however, the current hardware design limits throughput to 1.8Mbps. Additional framing and protocol overhead reduces this to about 0.5Mbps of usable bandwidth. Software and hardware design improvements are currently underway that will increase usable bandwidth to about 3Mbps.

[0296] Data from iperf3 test

[0297] TCP-iperf3 (no flags)

[0298] [5]local 10.42.0.225port 5201connected to 10.42.0.238port 60744

[0299] [ID]Interval Transfer Bitrate

[0300] [5]0.00-1.00sec 15.9KBytes 130Kbits / sec

[0301] [5]1.00-2.00sec 13.5KBytes 111Kbits / sec

[0302] [5]2.00-3.00sec 17.5Kbytes 144Kbits / sec

[0303] [5]3.00-4.00sec 20.3KBytes 166Kbits / sec

[0304] [5]4.00-5.00sec 21.7KBytes 178Kbits / sec

[0305] [5]5.00-6.00sec 38.6KBytes 317Kbits / sec

[0306] [5]6.00-7.00sec 32.5KBytes 266Kbits / sec

[0307] [5]7.00-8.00sec 22.9KBytes 188Kbits / sec

[0308] [5]8.00-9.00sec 21.7KBytes 178Kbits / sec

[0309] [5]9.00-10.00sec 10.6KBytes 86.5Kbits / sec

[0310] [5]10.00-10.03sec 1.79KBytes 467Kbits / sec

[0311] -------------------------

[0312] [ID]Interval Transfer Bitrate

[0313] [5]0.00-10.03sec 217KBytes 177Kbits / sec receiver

[0314] TCP, 220-byte packets

[0315] Commands used:

[0316] iperf3-l 220

[0317] result:

[0318] [5]local 10.42.0.225port 5201connected to 10.42.0.238port 60752

[0319] [ID]Interval Transfer Bitrate

[0320] [5]0.00-1.00sec 14.2KBytes 115Kbits / sec

[0321] [5]1.00-2.00sec 24.9KBytes 204Kbits / sec

[0322] [5]2.00-3.00sec 47.0KBytes 385Kbits / sec

[0323] [5]3.00-4.00sec 56.2KBytes 459Kbits / sec

[0324] [5]4.00-5.00sec 21.5KBytes 176Kbits / sec

[0325] [5]5.00-6.00sec 35.7KBytes 293Kbits / sec

[0326] [5]6.00-7.00sec 32.5KBytes 265Kbits / sec

[0327] [5]7.00-8.00sec 7.17KBytes 58.8Kbits / sec

[0328] [5]8.00-9.00sec 17.9KBytes 147Kbits / sec

[0329] [5]9.00-10.00sec 20.7KBytes 169Kbits / sec

[0330] -------------------------

[0331] [ID]Interval Transfer Bitrate

[0332] [5]0.00-10.04sec 278Kbytes 227Kbits / sec receiver UDP, 220 byte packet, 570Kbps target bandwidth

[0333] Commands used:

[0334] iperf3-ub 570-l 220

[0335] result:

[0336] [5]local 10.42.0.225port 5201connected to 10.42.0.238port 47129

[0337] [ID]Interval Transfer Bitrate Jitter Lost / Total Datagrams[5]0.00-1.00sec 59.5KBytes 486Kbits / sec 5.310ms 0 / 277(0%)

[0338] [5]1.00-2.00sec 69.2KBytes 568Kbits / sec 5.480ms 0 / 322(0%)

[0339] [5]2.00-3.00sec 70.0KBytes 573Kbits / sec 5.116ms 0 / 326(0%)

[0340] [5]3.00-4.00sec 69.0KBytes 565Kbits / sec 5.915ms 0 / 321(0%)

[0341] [5]4.00-5.01sec 69.6KBytes 568Kbits / sec 5.497ms 0 / 324(0%)

[0342] [5]5.01-6.00sec 70.0KBytes 577Kbits / sec 5.325ms 0 / 326(0%)

[0343] [5]6.00-7.00sec 69.2KBytes 566Kbits / sec 4.822ms 0 / 322(0%)

[0344] [5]7.00-8.00sec 68.8KBytes 564Kbits / sec 7.109ms 0 / 320(0%)

[0345] [5]8.00-9.00sec 70.5KBytes 576Kbits / sec 5.335ms 0 / 328(0%)

[0346] [5]9.00-10.00sec 69.4KBytes 570Kbits / sec 5.829ms 0 / 323(0%)

[0347] [5]10.00-10.06sec 4.08KBytes 524Kbits / sec 9.461ms 0 / 19(0%)

[0348] -------------------------

[0349] [ID]Interval Transfer Bitrate Jitter Lost / Total Datagrams[SUM]0.0-10.1sec 20datagrams received out-of-order

[0350] [5] 0.00-10.06sec 689KBytes 561Kbits / sec 9.461ms 0 / 3208(0%)receiver5GHz data communication network

[0351] Anchor-to-anchor communication is accomplished using a modified 802.11a WDS network. Data is sent from anchor to anchor until it reaches its destination. Each hop adds up to 1 millisecond of latency and reduces available bandwidth by 10%, so effective bandwidth depends on the distance to the nearest border router and the number of hops.

[0352] Data from iperf3 The following is the worst case scenario, from the 7th Avenue th Ave.) site to the anchor halfway to Church Avenue, 20 hops.

[0353] TCP-iperf3 (no flags)

[0354] [7]local 10.42.0.87port 52616connected to 10.42.0.77port 5201

[0355] [ID]Interval Transfer Bitrate Retr Cwnd

[0356] [7]0.00-1.00sec 916KBytes 7.51Mbits / sec 1 74.9KBytes

[0357] [7]1.00-2.00sec 911KBytes 7.46Mbits / sec 0 83.4KBytes

[0358] [7]2.00-3.00sec 895KBytes 7.33Mbits / sec 1 90.5KBytes

[0359] [7]3.00-4.00sec 902KBytes 7.39Mbits / sec 0 97.6KBytes

[0360] [7]4.00-5.00sec 908KBytes 7.44Mbits / sec 0 105KBytes

[0361] [7]5.00-6.00sec 963KBytes 7.89Mbits / sec 0 115KBytes

[0362] [7]6.00-7.00sec 1018KBytes 8.34Mbits / sec 0 143KBytes

[0363] [7]7.00-8.00sec 954KBytes 7.82Mbits / sec 0 191Kbytes

[0364] [7]8.00-9.00sec 1.37MBytes 11.5Mbits / sec 0 255KBytes

[0365] [7]9.00-10.00sec 1.37MBytes 11.5Mbits / sec 0 332KBytes

[0366] -------------------------

[0367] [ID]Interval Transfer Bitrate Retr

[0368] [7]0.00 - 10.00 sec 10.0 MBytes 8.41 Mbits / sec 2 sender[7]0.00 - 10.06 sec 9.42 MBytes 7.86 Mbits / sec receiver UDP, 20 Mbps target bandwidth

[0369] Commands used:

[0370] iperf3 - u - b 20M

[0371] Results:

[0372] [7]local 10.42.0.87 port 49056 connected to 10.42.0.77 port 5201

[0373] [ID]Interval Transfer Bitrate Total Datagrams

[0374] [7]0.00 - 1.01 sec 2.38 MBytes 19.8 Mbits / sec 1727

[0375] [7]1.01 - 2.00 sec 2.38 MBytes 20.1 Mbits / sec 1722

[0376] [7]2.00 - 3.01 sec 2.39 MBytes 19.9 Mbits / sec 1731

[0377] [7]3.01 - 4.00 sec 2.38 MBytes 20.2 Mbits / sec 1727

[0378] [7]4.00 - 5.01 sec 2.38 Mbytes 19.8 Mbits / sec 1726

[0379] [7]5.01 - 6.01 sec 2.38 MBytes 20.0 Mbits / sec 1726

[0380] [7]6.01 - 7.00 sec 2.38 MBytes 20.2 Mbits / sec 1725

[0381] [7]7.00 - 8.00 sec 2.38 MBytes 20.0 Mbits / sec 1726

[0382] [7]8.00-9.01sec 2.39MBytes 19.8Mbits / sec 1729

[0383] [7]9.01-10.00sec 2.38MBytes 20.1Mbits / sec 1723

[0384] -------------------------

[0385] [ID]Interval Transfer Bitrate Jitter Lost / Total Datagrams[7]0.00-10.00sec 23.8MBytes 20.0Mbits / sec 0.000ms 0 / 17262(0%)sender[7]0.00-10.44sec23.8MBytes 19.1Mbits / sec 0.784ms 0 / 17207(0%)receiver installation method

[0386] Installation Environment

[0387] Fig.15 Depicting a subway train tunnel.

[0388] Fig.16 Depicted is a Piper anchor mounted on a subway train tunnel wall.

[0389] Fig.17 Depicted is a sheet metal mounting bracket for mounting a Piper anchor.

[0390] Mounting Hardware

[0391] Due to the variation in possible and accessible mounting locations, we created 7 different sheet metal brackets (shown in the photos below) that attach to common mounting points on the anchor equipment. Brackets were designed and custom made by Piper Networks to accommodate mounting anchors on 1) vertical concrete walls, 2) circular concrete walls, 3) vertical steel beams, and 4) concrete ceilings. Some pieces can be mixed and matched between the different bracket types to accommodate unusual or unforeseen circumstances.

[0392] For more complete information on mounting hardware, refer to the document “Piper POC2 Anchor Mounting Bracket Assembly and Installation Reference, by Duane Maxwell, August 24, 2018.”

[0393] Fig.18 The steel beam support assembly is shown.

[0394] Fig.19 Depicted is a Piper anchor installed on a steel beam in a subway tunnel.

[0395] Outside the tunnel

[0396] All Piper edge routers are installed in stations, so most of the time the vertical steel beam mounting brackets are used. In some cases, we were able to utilize existing mounting structures. th Ave., a ceiling mount was used because no other mounting opportunities were available. Each Piper edge router then connected to the nearest help point on the platform to access the MTA network.

[0397] Fig. 20 Depicted is a Piper anchor installed on a steel beam in a subway station.

[0398] Vehicle Equipment

[0399] Piper Tags

[0400] Piper tags are mounted externally on the north and south ends of the assembly. Two tags are mounted on each end, one on the starboard side and the other on the port side. Nylon mounting hardware and 3D printed plastic housings are used to ensure security in the event of a fall onto the track. Silicone, waterproof tape and rubber gaskets are used for weatherproofing. The cables are routed through the side windows into the CBTC cabinet in the wheelhouse.

[0401] Piper Tag Controller

[0402] Fig.21 Depicted is the Piper 1U tag controller mounted in a Thales vehicle-mounted rack.

[0403] The Piper 1U tag controller is designed to be mounted in a Thales onboard rack, as shown in this photo. The actual installation is done inside the CBTC cabinet in the train cab. An uninterruptible power supply (UPS) is also installed to prevent downtime due to AC power interruptions in the train cab. The Piper tag controller and UPS are secured using heavy-duty cable ties and vibration-damping foam to protect the electronics.

[0404] Fig. 22 Depicts the intended location of the label controller in the VOBC rack.

[0405] Fig.23 Depicted is the practical placement of the tag controller due to USB cable length limitations.

[0406] Data communication network

[0407] The Piper data communications network consists of three main components:

[0408] On / off-ramp

[0409] WDS network

[0410] Border router

[0411] Piper Tags and Piper Anchors use UWB radios to provide on-ramp / off-ramp (to and from trains). Piper Tags send data via UWB to Piper Anchors (on-ramp). This data is then forwarded to the Piper Data Communications Network, which is a Wireless Distribution System (WDS) consisting of two 5GHz radios on the Piper Anchors. One 5GHz radio is used to send data northbound and the other 5GHz radio is used to send data southbound. This provides a full-duplex solution, mitigating the drop in bandwidth per hop. Any data received by the 5GHz radio is forwarded to the UWB radio and sent to the Piper Tag (exit ramp) as dictated by the routing table.

[0412] The Piper border router receives data from the Piper anchor and forwards this data to the EMD switch. The Piper border router also routes data received by the EMD switch to the Piper data communication network.

[0413] Fig.24 Depicted is an example communication path through the Piper data communications network.

[0414] Piper anchors send beacons every 333 milliseconds. These beacons contain the anchor's tunnel location (relative distance to the "origin") and additional information used to form the Piper WDS. The Piper anchor uses this beacon data and the RSSI from the received beacons to create a path from the anchor to the Piper border router. The routing algorithm minimizes latency (by skipping adjacent anchors to distant anchors with sufficient RSSI). Since RSSI is affected by the train's location, the routing algorithm must also take the train's location into account to ensure that the path is routed to the Piper border router. Dynamically and temporarily shorten the hop distance to bypass the train.

[0415] Beacons are sent out from border routers and UDP heartbeats are sent toward border routers. Anchors use the beacon and heartbeat data to determine the health of the system (and its associated neighbors). If a certain number of beacons or heartbeats are lost, the anchors will effectively "heal" the network by updating the routing table to bypass any anchors that may have gone "offline".

[0416] When a Piper tag moves from one anchor to another, information is sent to the Piper border router, which then causes a Gratuitous ARP (GARP) to be sent to the EMD switch. This provides the EMD switch with the necessary information to update its routing table and port assignments in order to continue to correctly route data from the Zone Controller (ZC) to the Piper tag and ultimately to the VOBC.

[0417] Fig.25 Depicts an example Piper wireless distribution system network configuration supporting multiple tunnels.

[0418] Fault Tolerance

[0419] The Piper data communication network is designed so that any single Piper anchor failure will not affect overall throughput or latency. Piper anchors continuously send and receive beacons and heartbeat messages. Beacon data is sent from Piper border routers to Piper anchors that do not contain child nodes (leaves). Similarly, leaf Piper anchors initiate heartbeat messages sent to Piper border routers. Therefore, there is health data sent in both directions. Piper anchors and Piper border routers use this data (or lack thereof) to determine the health of neighboring anchors. If a certain number of heartbeats or beacons are missed, the surrounding anchors will consider the anchor failed and bypass that anchor. Once that anchor is back online, routing to that anchor will be restored.

[0420] Fig.26 Depicted is an example of the Piper wireless distribution system heartbeat and beacon paths.

[0421] Fig. 27 Depicted is an example of Piper WDS routing around an offline anchor point.

[0422] Firmware Upgrade

[0423] The system has a mechanism for single or bulk firmware upgrades that are remotely managed via the wireless Piper data communications network. Each device will occasionally attempt to connect to Piper's update server to check if an upgrade is available, and if so, download and install the upgrade. Upgrades can also be downloaded and installed manually by the network administrator.

[0424] Final Demo

[0425] The ETLS POC2 demonstration was presented to key MTA leaders on October 26, 2018. Robert Hanczor, CEO of Piper Networks, and Walter Kinio, Vice President of Research and Innovation at Thales Group, performed the demonstration – showing how the UWB ETLS network performed under several different scenarios, including data loss from different sources that were part of the Thales VOBC network and the Piper UWB ETLS network.

[0426] During the demonstration, Piper and Thales performed multiple runs on the F Line's express tracks between Church Avenue and Seventh Avenue stations. During the runs, attendees saw that the UWB ETLS network was reliable and could work with the Thales VOBC network to provide accurate, precise and timely position data for the trains.

[0427] Robert Hanczor explained that the anchors are easy to install and can be deployed in a short time, adding that Piper Networks is working with Reliabotics on future robotic deployments to increase efficiency. He also answered several questions about the UWB ETLS network, explaining that the network is robust enough to survive the catastrophic loss of multiple anchors and still report accurate location data from the train. He also explained that the anchors can provide wireless internet to passengers in the tunnel using the 2.4GHz radio installed in the device but not used in the POC.

[0428] suggestion

[0429] Intrusion Detection and Prevention

[0430] The firmware on the Anchor is capable of running IDS / IPS software to detect and mitigate known network-based denial-of-service attacks. The system should be enabled for production deployments.

[0431] Cryptographic Engine and UWB Wireless Security

[0432] For POC2, the tag (train) to anchor (roadside) wireless communication over UWB relies on the fact that the VOBC data is encrypted using an IPSec tunnel before being sent. Both the Piper Anchor and the Piper Tag contain a cryptographic processor that should be used to encrypt / decrypt the UWB packets if any unencrypted data is required to be sent to the anchor.

[0433] Secure Boot and Trusted Execution Environment

[0434] The SoC used by Piper Anchor supports secure boot and ARM TrustZone. In production deployments, secure boot should be enabled to ensure that the device can only run cryptographically signed and trusted firmware. The keys for signature verification should be kept in TrustZone to mitigate boot / firmware attacks by anyone with physical access to the device.

[0435] Border router redundancy

[0436] For POC2, the border router serving each WDS network can act as a single point of failure. The border router is able to operate in active or passive state, and if the active BR fails, the passive BR will become active and take over control of the WDS network. This feature should be used in production deployments.

[0437] 2.4GHz fast roaming

[0438] Our hardware is capable of fast wireless roaming transitions using 802.11r and 802.11k, and software support is under active development. Testing in our lab has shown that roaming transition latency is consistently around 70 milliseconds. Using this feature requires an additional antenna to be installed at each end of the train and connected to the tag controller. For production deployments that require higher data rates for non-critical services such as onboard WiFi, it is recommended to enable this feature.

[0439] Test with train

[0440] Testing and data collected during GO service 5600-18 between 10 a.m. and 3:30 p.m. on Thursday, November 8.

[0441] Test data on November 8, 2018

[0442] Test route: Church Avenue to Seventh Avenue, Track B4

[0443] Test start time: 11:30 am (16:32 am (UTC))

[0444] Test end time: 2:30 pm (19:26 pm (UTC))

[0445] The versions of FW and SW used in the test are:

[0446] Label:

[0447] Piper RTLS Firmware v3.018

[0448] Tab Controller:

[0449] Linux 4.4.34-v7+

[0450] Piper RTLS tag node invested 227d3db107a49eb08caa51cb1175811ca5ddbsa 2

[0451] anchor:

[0452] Linux 4.9.77

[0453] Piper RTLS label node slot build 203

[0454] Piper RTLS Firmware v3.018

[0455] Testing Procedure

[0456] The test runs consisted of a short trip, either northbound (from Church Avenue to Seventh Avenue) or southbound (from Seventh Avenue to Church Avenue). Data was collected from both the North and South tag controllers. To monitor the performance of the network, for each run, Piper recorded the output of ping -0 -i 0.25 10.42.0.1, which shows the round-trip time for a small packet sent every quarter second. The ping data was collected from Tag Controller A. To monitor the performance of the positioning service, Piper recorded the raw tag-to-anchor distance data generated every half second during each run. This distance data was collected from Tag Controller B. The actual along-track distance values ​​provided to Thales' system were calculated from the raw data. The results for each run are provided below.

[0457] Note: Piper is unable to test the inherent latency of the EMD network, therefore latency data cannot be definitively attributed to the Piper network.

[0458] result

[0459] Test 1

[0460] Cathedral Avenue to Seventh Avenue NB (Northbound) ATO 29MPH

[0461] Start time: 16:32UTC

[0462] End time: 16:43UTC

[0463] North Label Results

[0464] One-way delay: minimum: 4.8ms / average: 13ms / maximum: 730ms

[0465] Ping Summary:

[0466] 1950packets transmitted, 1921received, 1% packet loss, time 489074msrttmin / avg / max / mdev=9.605 / 26.016 / 1459.616 / 60.821ms, pipe 6

[0467] Fig.28 Depicts the results of North Tag Controller Test 1.

[0468] South label results

[0469] One-way delay: minimum: 4.4ms / average: 16.4ms / maximum: 694ms

[0470] Ping Summary:

[0471] 1363packets transmitted,1339received,1%packet loss,time 341644msrttmin / avg / max / mdev=8.721 / 32.730 / 1388.113 / 64.216ms,pipe 6

[0472] Fig.29 Depicts the results of South tag controller test 1.

[0473] Test 2

[0474] 7th Avenue to Cathedral Avenue SB (Southbound) ATO 10MPH

[0475] Start time: 16:43UTC

[0476] End time: 16:56UTC

[0477] North Label Results

[0478] One-way delay: minimum: 4.9ms / average: 17.7ms / maximum: 914ms

[0479] Ping Summary:

[0480] 2452packets transmitted, 2413received, 1% packet loss, time 614833msrttmin / avg / max / mdev=9.790 / 35.399 / 1828.898 / 63.469ms, pipe 8

[0481] Fig.30 Depicts the results of North Tag Controller Test 2.

[0482] South label results

[0483] One-way delay: minimum: 4.9ms / average: 18.6ms / maximum: 421ms

[0484] Ping Summary:

[0485] 2481packets transmitted, 2445received, 1% packet loss, time 622058msrttmin / avg / max / mdev=9.771 / 37.161 / 841.961 / 51.354ms, pipe 4

[0486] Fig.31 Depicts the results of South tag controller test 2.

[0487] Test 3

[0488] Cathedral Avenue to Seventh Avenue NB (Northbound) ATO

[0489] Start time: 16:56 UTC

[0490] End time: 17:04UTC

[0491] North Label Results

[0492] One-way delay: minimum: 4.9ms / average: 17.2ms / maximum: 261ms

[0493] Ping Summary:

[0494] 1005packets transmitted,984received,2%packet loss,time 251889msrttmin / avg / max / mdev=9.683 / 34.441 / 522.166 / 46.573ms,pipe 3

[0495] Fig.32 Depicts the results of North Tag Controller Test 3.

[0496] South label results

[0497] One-way delay: minimum: 4.4ms / average: 18.5ms / maximum: 264ms

[0498] Ping Summary:

[0499] 933packets transmitted,914received,2%packet loss,time 233866ms

[0500] rtt min / avg / max / mdev=8.862 / 37.063 / 529.133 / 52.032ms,pipe 3

[0501] Fig.33 Depicts the results of South tag controller test 3.

[0502] Test 4

[0503] 7th Avenue to Cathedral Avenue SB (Southbound) Manual 10MPH

[0504] Start time: 17:04UTC

[0505] End time: 17:17UTC

[0506] North Label Results

[0507] One-way delay: minimum: 4.8ms / average: 19.2ms / maximum: 500ms

[0508] Ping Summary:

[0509] 2717packets transmitted, 2684 received, 1% packet loss, time 681357msrttmin / avg / max / mdev=9.641 / 38.491 / 999.534 / 58.477ms, pipe 4

[0510] Fig.34 Depicts the results of North Tag Controller Test 4.

[0511] South label results

[0512] One-way delay: minimum: 4.5ms / average: 19.5ms / maximum: 1213ms

[0513] Ping Summary:

[0514] 2661packets transmitted, 2607received, 2% packet loss, time 667342msrttmin / avg / max / mdev=9.009 / 39.129 / 2426.700 / 80.522ms, pipe 10

[0515] Fig.35 Depicts the results of South tag controller test 4.

[0516] Test 5

[0517] Cathedral Avenue to Seventh Avenue NB (Northbound) ATO 29MPH>19MPH>29MPH

[0518] Start time: 17:27UTC

[0519] End time: 17:32UTC

[0520] North Label Results

[0521] One-way delay: minimum: 5.3ms / average: 16.3ms / maximum: 260ms

[0522] Ping Summary:

[0523] 1213packets transmitted,1190received,1%packet loss,time 304073msrttmin / avg / max / mdev=10.652 / 32.666 / 520.237 / 39.552ms,pipe 3

[0524] Fig.36 Depicts the results of North Tag Controller Test 5.

[0525] South label results

[0526] One-way delay: minimum: 4.4ms / average: 18.3ms / maximum: 1164ms

[0527] Ping Summary:

[0528] 1712packets transmitted,1661received,2%packet loss,time 429436msrttmin / avg / max / mdev=8.795 / 36.581 / 2328.199 / 105.061ms,pipe 10

[0529] Fig.37 Depicts the results of South tag controller test 5.

[0530] Test 6

[0531] 7th Avenue to Cathedral Avenue ATPM SB (Southbound) from VOBC2

[0532] Start time: 17:43UTC

[0533] End time: 17:54UTC

[0534] North Label Results

[0535] One-way delay: minimum: 4.8ms / average: 18.2ms / maximum: 1424ms

[0536] Ping Summary:

[0537] 2644packets transmitted, 2598received, 1% packet loss, time 663008msrttmin / avg / max / mdev=9.673 / 36.455 / 2848.528 / 101.748ms, pipe 12

[0538] Fig.38 Depicts the results of North Tag Controller Test 6.

[0539] South label results

[0540] One-way delay: minimum: 4.5ms / average: 19.8ms / maximum: 749ms

[0541] Ping Summary:

[0542] 2611packets transmitted,2578received,1%packet loss,time 654747msrttmin / avg / max / mdev=9.061 / 39.639 / 1498.866 / 71.566ms,pipe 6

[0543] Fig.39 Depicts the results of South tag controller test 6.

[0544] Test 7

[0545] Cathedral Avenue to Seventh Avenue NB (Northbound) ATPM 29MPH

[0546] Start time: 18:14UTC

[0547] End time: 18:18UTC

[0548] North Label Results

[0549] One-way delay: minimum: 5.0ms / average: 15.6ms / maximum: 337ms

[0550] Ping Summary:

[0551] 999packets transmitted,978received,2%packet loss,time 250354ms

[0552] rtt min / avg / max / mdev=9.981 / 31.196 / 674.597 / 36.205ms,pipe 3

[0553] Fig.40 Depicts the results of North Tag Controller Test 7.

[0554] South label results

[0555] One-way delay: minimum: 4.9ms / average: 16.5ms / maximum: 267ms

[0556] Ping Summary:

[0557] 916packets transmitted,902received,1%packet loss,time 229558ms

[0558] rtt min / avg / max / mdev=9.820 / 33.073 / 533.942 / 40.413ms,pipe 3

[0559] Fig.41 Depicts the results of South tag controller test 7.

[0560] Test 8

[0561] 7th Avenue to Cathedral Avenue SB (Southbound) ATO 10MPH VOBC2

[0562] Start time: 18:22UTC

[0563] End time: 18:35UTC

[0564] North Label Results

[0565] One-way delay: minimum: 5.1ms / average: 18.5ms / maximum: 682ms

[0566] Ping Summary: (Note: ping was interrupted and then resumed, so two summaries are shown)

[0567] 1748packets transmitted, 1672received, 4% packet loss, time 438461msrttmin / avg / max / mdev=10.406 / 37.118 / 651.142 / 41.375ms, pipe 3

[0568] 753packets transmitted,736received,2%packet loss,time 188749ms

[0569] rtt min / avg / max / mdev=10.195 / 36.151 / 1364.715 / 89.467ms,pipe 6

[0570] Fig.42 Depicts the results of North Tag Controller Test 8.

[0571] South label results

[0572] One-way delay: minimum: 4.7ms / average: 16.2ms / maximum: 518ms

[0573] Ping Summary:

[0574] 3052packets transmitted, 2986 received, 2% packet loss, time 765383msrttmin / avg / max / mdev=9.476 / 32.473 / 1036.664 / 47.389ms, pipe 5

[0575] Fig.43 Depicts the results of South tag controller test 8.

[0576] Test 9

[0577] 7th Avenue to Cathedral Avenue SB (Southbound) ATO

[0578] Start time: 19:05UTC

[0579] End time: 19:19UTC

[0580] North Label Results

[0581] One-way delay: minimum: 5.1ms / average: 16.4ms / maximum: 960ms

[0582] Ping Summary:

[0583] 3305packets transmitted, 3246received, 1% packet loss, time 828861msrttmin / avg / max / mdev=10.270 / 32.848 / 1921.060 / 74.715ms, pipe 8

[0584] Fig.44Depicts the results of North Tag Controller Test 9.

[0585] South label results

[0586] One-way delay: minimum: 4.7ms / average: 18.2ms / maximum: 619ms

[0587] Ping Summary:

[0588] 2511packets transmitted, 2465received, 1% packet loss, time 629622msrttmin / avg / max / mdev=9.427 / 36.484 / 1238.060 / 53.748ms, pipe 5

[0589] Fig.45 Depicts the results of South tag controller test 9.

[0590] Test 10

[0591] Cathedral Avenue to Seventh Avenue NB (Northbound) ATO

[0592] Start time: 19:21UTC

[0593] End time: 19:26UTC

[0594] North Label Results

[0595] One-way delay: minimum: 4.7ms / average: 15.3ms / maximum: 649ms

[0596] Ping Summary:

[0597] 1262packets transmitted, 1236received, 2% packet loss, time 316394msrttmin / avg / max / mdev=9.401 / 30.579 / 1297.210 / 61.231ms, pipe 6

[0598] Fig.46 Depicts the results of the North Tag Controller Test 10.

[0599] South label results

[0600] One-way delay: minimum: 5.4ms / average: 19.6ms / maximum: 507ms

[0601] Ping Summary:

[0602] 954packets transmitted,935received,1%packet loss,time 239146ms

[0603] rtt min / avg / max / mdev=10.801 / 39.248 / 1014.028 / 63.175ms,pipe 4

[0604] Fig.47 Depicts the results of South tag controller test 10.

[0605] Data Visualization

[0606] Distance measurement test:

[0607] All distances along the track from the zero point defined by Thales in meters.

[0608] Fig.48 The original label-to-anchor distances for all 10 tests starting from the south label are plotted (including a manual run through the 7th test).

[0609] Note that on the right side of the graph, the point running from the top is due to the train rolling beyond the reach of the anchor from test 7 to test 4. The horizontal gap corresponds to the time between test runs.

[0610] The following graphs are created by plotting the calculated positions of the labels using the raw ranging data from the specified file. The number of "localization successes" is calculated by dividing the number of successful localization calculations by the number of ranging sets that were valid for the calculation.

[0611] For a given run, some gaps may appear in the odometry data for a given tag. Note that looking at the data from opposing tags in the same run will generally not have the same gaps, in other words, In a given run, merge Data from both tags will provide a complete, uninterrupted stream of position data.

[0612] Fig.49 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0613] File:ranging-11_08_nb_30_n-01.json

[0614] Description: 30mph northbound, north tag controller

[0615] Start time: 16:35:19 GMT, 8 November 2018

[0616] End time: 16:43:56 GMT, 8 November 2018

[0617] Positioning success rate: 1008 / 1019=98.92%

[0618] Fig.50 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0619] File:ranging-11_08_nb_30_s-20.json

[0620] Description: 30mph northbound, south tag controller

[0621] Start time: 16:37:09 GMT, 8 November 2018

[0622] End time: 16:43:42 GMT, 8 November 2018

[0623] Fig.51 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0624] File:ranging-11_08_sb_10_s-21.json

[0625] Description: 10mph southbound, south tag controller

[0626] Start time: 16:45:22 GMT, 8 November 2018

[0627] End time: 16:55:50 GMT, 8 November 2018

[0628] Positioning success rate: 1182 / 1208 = 97.84%

[0629] Fig.52 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0630] File:ranging-11_06_sb_10_n-02.json

[0631] Description: 10mph southbound, northbound tag controller

[0632] Start time: 16:45:41 GMT, 8 November 2018

[0633] End time: 16:55:46 GMT, 8 November 2018

[0634] Positioning success rate: 1133 / 1153=98.26%

[0635] Fig.53 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0636] File:ranging-11_08_nb_30_n-03.json

[0637] Description: 30mph northbound, north tag controller

[0638] Start time: 17:00:02 GMT, 8 November 2018

[0639] End time: 17:04:05 GMT, 8 November 2018

[0640] Positioning success rate: 452 / 459 = 98.47%

[0641] Fig.54 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0642] File:ranging-11_08_nb_30_n-22.json

[0643] Description: 30mph northbound, north tag controller

[0644] Start time: 17:00:11 GMT, 8 November 2018

[0645] End time: 17:04:02 GMT, 8 November 2018

[0646] Positioning success rate: 420 / 427 = 98.36%

[0647] Fig.55 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0648] File:ranging-11_08_sb_10_n-04.json

[0649] Description: 10mph southbound, northbound tag controller

[0650] Start time: 17:05:34 GMT, 8 November 2018

[0651] End time: 17:16:51 GMT, 8 November 2018

[0652] Positioning success rate: 98.31%

[0653] Fig.56 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0654] File:ranging-11_08_sb_man_s-23.json

[0655] Description: Manual 10mph southbound, south tag controller

[0656] Start time: 17:05:40 GMT, 8 November 2018

[0657] End time: 17:16:56 GMT, 8 November 2018

[0658] Positioning success rate: 1248 / 1279 = 97.57%

[0659] Fig.57 Depicted are odometry test results at 19 mph northbound using a south tag controller.

[0660] File:ranging-11_08_nb_19_s-24.json

[0661] Description: 19mph Northbound, South tag controller

[0662] Start time: 17:25:34 GMT, 8 November 2018

[0663] End time: 17:32:24 GMT, 8 November 2018

[0664] Positioning success rate: 692 / 734 = 94.27%

[0665] Fig.58 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0666] File:ranging-11_08_nb_30_n-05.json

[0667] Description: 30mph northbound, north tag controller

[0668] Start time: 17:27:20 GMT, 8 November 2018

[0669] End time: 17:32:35 GMT, 8 November 2018

[0670] Positioning success rate: 584 / 591 = 98.81%

[0671] Fig.59 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0672] File:ranging-11_08_sb_30_n-06.json

[0673] Description: 10mph southbound, northbound tag controller

[0674] Start time: 17:42:55 GMT, 8 November 2018

[0675] End time: 17:54:47 GMT, 8 November 2018

[0676] Positioning success rate: 1553 / 1274 = 98.35%

[0677] Fig.60 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0678] File:ranging-11_08_sb_10_s-25.json

[0679] Description: 10mph southbound, south tag controller

[0680] Start time: 17:43:58 GMT, 8 November 2018

[0681] End time: 17:54:44 GMT, 8 November 2018

[0682] Positioning success rate: 1206 / 1221=98.77%

[0683] Fig.61 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0684] File:ranging-11_08_nb_30_n-07.json

[0685] Description: 30mph northbound, north tag controller

[0686] Start time: 2018-11-08 18:13:51 GMT

[0687] End time: 18:17:57 GMT, 8 November 2018

[0688] Positioning success rate: 468 / 472 = 99.15%

[0689] Fig.62 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0690] File:ranging-11_08_nb_30_s-26.json

[0691] Description: 30mph northbound, south tag controller

[0692] Start time: 18:14:16 GMT, 8 November 2018

[0693] End time: 18:18:00 GMT, 8 November 2018

[0694] Positioning success rate: 439 / 442 = 99.32%

[0695] Fig.63 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0696] File:ranging-11_08_sb_10_s-27.json

[0697] Description: 10mph southbound, south tag controller

[0698] Start time: 18:22:36 GMT, 8 November 2018

[0699] End time: 18:35:31 GMT, 8 November 2018

[0700] Positioning success rate: 1449 / 469 = 98.69%

[0701] Fig.64 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0702] File:ranging-11_08_sb_10_n-09.json

[0703] Description: 10mph southbound, northbound tag controller

[0704] Start time: 18:25:01 GMT, 8 November 2018

[0705] End time: 18:35:22 GMT, 8 November 2018

[0706] Positioning success rate: 1190 / 1209 = 98.42%

[0707] Fig.65 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0708] File:ranging-11_08_nb_30_n-10.json

[0709] Description: 30mph northbound, north tag controller

[0710] Start time: 18:38:14 GMT, 8 November 2018

[0711] End time: 18:42:03 GMT, 8 November 2018

[0712] Positioning success rate: 432 / 441 = 97.95%

[0713] Fig.66 Depicted are odometry test results at 10 mph southbound using a north tag controller.

[0714] File:ranging-11_08_sb_10_n-11.json

[0715] Description: 10mph southbound, northbound tag controller

[0716] Start time: 2018-11-08 19:05:22 GMT

[0717] End time: 19:18:09 GMT, 8 November 2018

[0718] Positioning success rate: 1547 / 1570 = 98.53%

[0719] Fig.67 Depicted are the results of an odometry test at 30 mph northbound using a north tag controller.

[0720] File:ranging-11_08_nb_30_n-12.json

[0721] Description: 30mph northbound, north tag controller

[0722] Start time: 2018-11-08 19:21:00 GMT

[0723] End time: 19:26:12 GMT, 8 November 2018

[0724] Positioning success rate: 616 / 619 = 99.51%

[0725] Fig.68 Depicted are odometry test results using a south tag controller at 10 mph southbound.

[0726] File:ranging-11_08_sb_10_s-29.json

[0727] Description: 10mph southbound, south tag controller

[0728] Start time: 2018-11-08 19:08:36 GMT

[0729] End time: 19:19:06 GMT, 8 November 2018

[0730] Positioning success rate: 1182 / 1201=98.33%

[0731] Fig.69 Depicted are the results of a range test at 30 mph northbound using a south tag controller.

[0732] File:ranging-11_08_nb_30_s-30.json

[0733] Description: 30mph northbound, south tag controller

[0734] Start time: 2018-11-08 19:22:21 GMT

[0735] End time: 19:26:26 GMT, 8 November 2018

[0736] Positioning success rate: 444 / 452 = 98.23%

[0737] Further testing

[0738] Piper identified several opportunities to improve system performance. Firmware updates implemented after testing and witnessed by Thales and the MTA resulted in significant improvements in latency and mean deviation. We encourage the MTA to provide additional testing opportunities to further improve results, with the understanding that the Thales onboard equipment is not essential for us to continue testing.

[0739] For example, Fig.70 Depicts some results obtained the day after formal testing, after a full firmware update was done on all anchor and tag controllers to run an experimental version of DCS (internally referred to as "DWD"). In general, average latency is the same, however, minimum one-way latency has improved significantly from about 5ms to below 3ms, and maximum latency has been reduced. While there are some additional issues that need to be addressed, the overall system shows improvement and we recommend further experimentation.

[0740] Cathedral Avenue to Seventh Avenue NB (Northbound) ATO

[0741] Start time: 18:13 GMT, 9 November 2018

[0742] End time: 18:42 GMT, 9 November 2018

[0743] North Label Results

[0744] One-way delay: minimum: 2.93ms / average: 18.57ms / maximum: 281.38ms

[0745] Ping Summary:

[0746] 2549 packets transmitted, 2509 received, 1% packet loss, time 639144msrttmin / avg / max / mdev=5.854 / 37.141 / 562.755 / 51.010ms, pipe 3 Glossary

[0747] DCN / DCS-Data Communication Network / SystemWDS-Wireless Distribution System

[0748] VOBC - Vehicle Onboard Computer

[0749] ZC-Zone Controller

[0750] UWB - Ultra Wideband

[0751] TC-Tag Controller

[0752] BR - Border Router

[0753] NGPS - Next Generation Positioning System

[0754] CBTC - Communication Based Train Control

[0755] Annex B

[0756]

[0757] Unsolicited Proposal Number: TP-01-01

[0758] Communication-based Train Control System Enhancement Plan Rev.:0.0.1

[0759] Date: August 22, 2019

[0760] Prepared for Piper Networks, Inc. (MTA) New York City Metropolitan Rail Transit Piper Networks, Inc. proprietary and confidential information may not be reproduced and / or redistributed without the prior written consent of Piper Networks, Inc. Documents are uncontrolled unless otherwise marked.

[0761] TP-01-01CBTC System Enhancement Plan

[0762] Revision History

[0763] Revisions date File Owner / Originator Release Notes 0.0.1 08 / 22 / 2018 R. Hanczor Initial Release

[0764] content

[0765]

[0784] picture

[0793] Fig.71 Top-level block diagram

[0794] Fig.72 Advanced Positioning Architecture

[0795] Fig.73 Example communication flow via Piper DCS

[0796] Fig.74 Piper network configuration to support multi-channel streaming

[0797] Fig.75 Piper routing with failed anchors

[0798] Fig.76 Piper Road Worker Protection Architecture

[0799] Fig.77 Piper road worker protection

[0800] Fig.78 Snake Tray Example

[0801] Fig.79 ITN Architecture

[0802] Fig.80 Continuous integrity testing system

[0803] Fig.81 Piper project organizational chart

[0804] Fig.82 V&V Responsibility Structure

[0805] Fig.83 System Lifecycle

[0806] 1 Executive Summary

[0807] This document serves as a proposal for Piper Networks Inc.’s (“Piper”) unsolicited Communications Based Train Control (CBTC) system enhancement program. The core products of the program are:

[0808] 1. An ultra-wideband navigation system with Safety Integrity Level (SIL)-4 certification, which has physical and logical interfaces and is integrated with the CBTC system (also known as the UWB-based train control UBTC system);

[0809] 2. UWB roadside infrastructure, which is manufactured as the core of the UWB navigation system components, while also providing a wireless "mesh" data communication system (DCS) that exceeds the bandwidth requirements of CBTC.

[0810] The program will be supported by five (5) major contract options based on NYCT's business needs. The options include:

[0811] 1. Road Worker Protection (RWP)

[0812] 2. Rapid roadside installation

[0813] 3. Inter-Train Network (ITN)

[0814] 4. Carriage Integrity Detection System (CIDS)

[0815] 5. Asset Management (AM)

[0816] The goal of the program is to lay the core foundation of the navigation subsystem for the UBTC system and then promote it as a revenue service. Each option in the program is presented as a function of UWB as a technology that will enhance the CBTC system by providing additional safety benefits, reduce the physical hardware requirements of the system while improving reliability, or provide cost savings to NYCT in the implementation / maintenance of CBTC.

[0817] Piper Networks' ultimate goal is to support the overall goal of the MTA's Fast Forward Program, which is to rapidly deploy upgraded CBTC to improve transit service in New York City. To ensure the successful implementation of this program, Piper Networks will work collaboratively with NYCT and our partners, which will be a key factor in the success and timely completion of the project. We will operate as "one team" and fully participate as necessary to support working groups and other meetings required during the project. In the spirit of the "one team" approach, Piper Networks intends to employ a local project management team with expertise in train control systems / safety systems and complex project delivery.

[0818] 2. Implementation

[0819] 2.1 Deployment Area

[0820] Piper offers three (3) options for deployment areas, however, Piper will ultimately support any approach that aligns with NYCT's implementation strategy and business needs (even if not listed below). The three (3) options are:

[0821] 1. Deployed on the Queens Boulevard Line (QBL) between Grand Avenue-Newtown Station and Forest Hills-71st Avenue limits (≈2 miles).

[0822] 2. Deployed on the Eighth Avenue Line at 207th Street Station (207 th Street Station and 168th Street Station th Street Station) (≈2.1 miles).

[0823] 3. Deployed in Zone A, on the Lexington line, between the limits of 59th Street–Lexington Avenue Station and 14th Street–Union Square Station (≈2.3 miles).

[0824] Each approach has its advantages, which are described in further detail below.

[0825] 2.1.1 Queen's Road Line (QBL)

[0826] The Queens Boulevard Line (QBL) is a line in the B District of the New York City Subway located in the boroughs of Manhattan and Queens in New York City, United States. The line is underground throughout its entirety, contains 23 stations, and is served by four (4) overlapping lines, the E train, the F train, the M train, and the R train. The selection of an area on the QBL has advantages because the QBL line is currently being retrofitted with CBTC, into which the proposed system can be integrated. Additionally, the diversity of train routes / train types allows Piper to demonstrate the robustness of the UWB positioning system.

[0827] 2.1.2 Eighth Avenue

[0828] The Eighth Avenue Line is a rapid transit line in New York City, United States, and is part of the B District of the New York City Subway. The line runs from 207th Street south of Inwood to thThe 207th Street stretches from 1910 to an intersection south of High Street in Brooklyn Heights, including large tracts under St. Nicholas Avenue, Central Park West, and Eighth Avenue. The entire stretch is underground, although the 207th Street Courtyard, which branches off near the north end, is a subterranean street. th The entire line is served by the A train, which runs express trains except late at night. Similar to the above, the line is currently being retrofitted with CBTC, into which the proposed system could be integrated.

[0829] 2.1.3A Area-Lexington Line

[0830] The Lexington Avenue Line is a line in the New York City Subway's Section A that runs from the northern part of Lower Manhattan to 125th Street in East Harlem. The line is served by the 4, 5, and 6 trains. Section A presents a very favorable opportunity for the installation of UWB for the simple reason that CBTC work on Section A has not yet begun, so current CBTC work will not be impacted by UWB construction, and Section A's lines and trains will not be interoperable with Section B, so it is a perfect area where a non-I2S CBTC system can be implemented. For this implementation, the Lexington Line is proposed, where Piper will demonstrate the ability to accurately track the location of trains as they traverse the project limits, as well as the system's ability to provide a high-bandwidth wireless mesh DCS underground, and demonstrate accurate asset reporting to the RTO.

[0831] 2.2 Architecture

[0832] Fig.71 Depicted is the architecture of the Piper Train Location System in accordance with some embodiments of the disclosed technology.The Piper Train Location (detection system) determines position based on redundant mobile radio units (onboard) through geographic cross-referencing of three or more fixed lineside broadband radio beacons.

[0833] To achieve the required safety integrity level (SIL4 requirement) for the single main safety function of train positioning, the system should be based on a composite fail-safe architecture.

[0834] Current anchor spacing along the roadside is primarily dependent on the ambient RF conditions in the area, the frequency selected by Piper to ensure optimal communication between UWB devices, and track geometry - accounting for curves, grades, and elevation angles. During the 2019 UBTC pilot program, Piper deployed anchors at an average of 250-300' spacing. During the shadow mode data collection process, Piper will review the collected ranging data and perform simulations to determine the necessary spacing in the revenue system to achieve complete communication coverage in the event of a roadside unit failure. It is expected that significantly smaller anchor density will be required to meet safety requirements.

[0835] 2.3 Core System Functions

[0836] The core system functions presented are a SIL-4 certified navigation system that can interface with CBTC, and a wireless DCS mesh network. These core functions and core infrastructure are prerequisites for enabling the options listed in this document. This section provides the benefits that these functions can provide to NYCT.

[0837] 2.3.1 Positioning

[0838] Piper Networks is developing a SIL-4 compliant UWB standalone subsystem for train positioning. System identifier: ETLS-1003.3. For all system, hardware and software development processes, Piper adheres to all required safety processes and design requirements as specified by the CENELEC EN50129

[101] , EN50128

[102] and EN50159

[103] standards. Piper has invested in the necessary compliance consulting to ensure that a safety-certifiable UWB train positioning system can be delivered to NYCT, making NYCT the only organization to adopt a SIL-4 UWB positioning system. To this end, the SIL-4 certified positioning system is the foundation on which Piper intends to provide additional capabilities (e.g., RWP, CIDS, etc.) and is confident that these additional system capabilities will meet NYCT's safety requirements for implementation into revenue services.

[0839] 2.3.2 Data Communication System (DCS)

[0840] Installing the Piper DCS system has many benefits for NYCT. For starters, Piper DCS does not require any additional roadside infrastructure, as Piper anchors will be equipped with UWB radios for positioning and DCS radios for DCS. This allows NYCT to get more out of the work already planned. In addition, Piper proposes a wireless mesh network that exceeds the data bandwidth requirements of CBTC as shown in the MTAIT POC2 plan and can be expanded with fiber to be able to provide "passenger Wi-Fi" or generate additional revenue through advertising streaming.

[0841] It is important to distinguish the differences between a wireless mesh network and a fiber-supported network and identify the implementation advantages this provides to NYCT. Piper’s DCS network, which does not require any fiber, can be quickly installed and fully supports CBTC data bandwidth requirements. This provides a distinct advantage to NYCT, allowing it to quickly “turn on” sections of track without having to run miles of fiber as is currently required. With the wireless mesh network activated to support the train control system, NYCT can return to the appropriate time to begin laying fiber with minimal impact to the public, as the fiber will not be driving anything in the critical path for train control. With this in mind, additional features such as passenger Wi-Fi or advertising streaming can be enabled once fiber is available.

[0842] 2.4 System Function Options

[0843] The business cases made for each optional feature of the project are described below.

[0844] 2.4.1 Road Worker Protection (RWP)

[0845] Piper's Roadside Worker Protection System is specifically designed to improve roadside worker safety by enabling train crews (and train control systems) to be aware of roadside workers on their routes. The Piper RWP system will enable the train control system to take safety measures, such as emergency braking, when a moving train gets too close to a work area without authorization or confirmation from a roadside worker. The system can be used as a means to reduce workplace injuries and streamline NYCT processes for roadside work. For example, if a safety system is provided to roadside workers and integrated into the train control system, NYCT can reduce the number of signals required to work without GO, thereby improving work efficiency.

[0846] 2.4.2 Rapid roadside installation

[0847] If this option is selected, Piper will engage Snake Tray as a subcontractor to develop a rapid installation kit for the UWB anchor. The Snake Train will provide a flexible integration point in the deployment structure, be pressurized with a fire-resistant foam containment kit, and simplify installation / changes to wayside infrastructure. Piper will work with Snake Tray to design a bracket that meets NYCT specifications and demonstrate that the anchor can be installed with minimal service disruption.

[0848] 2.4.3 Inter-Train Network (ITN)

[0849] A significant area of ​​expenditure for NYCT is the procurement and installation of train-to-train networks. Piper proposes the use of inactive tags and tag controllers installed on UWB-equipped trains as a method of achieving wireless unit-to-unit networking.

[0850] 2.4.4 Carriage Integrity Detection System (CIDS)

[0851] NYCT currently uses several different approaches as an Auxiliary Wayside System (AWS). AWS is a backup or auxiliary train control system that is capable of providing full or partial automatic train protection for trains not equipped with onboard CBTC equipment and / or trains equipped with onboard CBTC equipment that is partially or completely inoperative. The auxiliary wayside systems currently used by NYCT are traditional track circuits and axle counters. One problem with these AWS systems is that they are expensive to install and maintain.

[0852] Piper proposes to demonstrate a Combination Integrity Detection System (CIDS) that can be introduced into the NYCT system at a lower cost than axle counters, with the capability to report its status to the RCC for enhanced maintenance capabilities, the ability to share the collected data with the CBTC system for combination integrity checks, and the ability to mechanically shunt the signal system. The synergy between the CBTC intelligence and the CIDS output data can be profitably leveraged in a number of ways: e.g., detection of train movement between two occupied track areas, integrity checks of train lengths, and determination of direction of travel through an independent intelligent radio network. More details on the CIDS design are described in Section 3.

[0853] 2.4.5 Asset Management (AM)

[0854] The Piper Asset Management System can be seamlessly integrated into NYCT’s Rail Control Center (RCC) either as a standalone application or as an input to NYCT’s existing AM system, where applicable. The NYCT operations team can utilize the Piper AM system to record and track the location of UWB assets deemed critical to the safe operation of rail operations. These assets include, but are not limited to, UWB Anchors, UWB Tag Controllers, and UWB RWP devices. Alternatively, Piper can use the health status of external devices to provide NYCT’s RCC with a central monitor with a holistic view of the entire network.

[0855] All assets report a configurable number of health states, enabling NYCT’s operations team to perform trend analysis, respond quickly to failed equipment, and determine preventive maintenance schedules. While the decision not to enable the interface to the RCC will not impact the safety functionality of the system, enabling the Piper AM system will improve system reliability and NYCT’s operational efficiency.

[0856] 3 System Functions - Technical Description

[0857] 3.1 Core Function - Positioning

[0858] The Piper Train Location (detection system) is based on redundant mobile radio units (onboard) determining position through geographical cross-referencing of three or more fixed lineside broadband radio beacons.

[0859] In order to achieve the required safety integrity level (SIL4 requirement) for the single main safety function of train positioning, the system should be based on a composite fault-safe architecture.

[0860] The interaction between the Piper anchors mounted high on the tunnel walls and the Piper tags mounted on the trains facilitates the geolocation of a given train. As the train passes through the tunnel, the distance between the anchors and tags is measured using calculations based on the arrival times of the radio pulses. The tag controller uses the ranging data, the known positions of the anchors and a mathematical model of the track to calculate the train's position. The Piper tag controller then generates a UDP packet defined by the OBCU and injects it into the Thales onboard network.

[0861] Fig.72 Depicted is a high-level positioning architecture for a Piper train positioning system in accordance with some embodiments of the disclosed technology.

[0862] Note that the dual-channel architecture shows complete independence between the processing units and the final stage combination, providing train positioning information to higher-level systems.

[0863] 3.2 Core Function - Data Communication System (DCS)

[0864] The Piper data communications network consists of three main components:

[0865] Data on-ramp / off-ramp

[0866] Redundant WDS network

[0867] Border routers connected to regional controllers or roadside networks

[0868] Note: The descriptions and illustrations provided in this section are based on a WDS network deployed by Piper during a proof-of-concept program at the Culver Test Track in 2018.

[0869] Piper Tags and Piper Anchors use UWB radios to provide entry / exit ramps (to and from trains). Piper Tags send data via UWB to Piper Anchors (entry ramps). This data is then forwarded to the Piper Data Communications Network, which is a Wireless Distribution System (WDS) consisting of two 5GHz radios on the Piper Anchors. One 5GHz radio is used to send data northbound and the other 5GHz radio is used to send data southbound. This provides a full-duplex solution, mitigating bandwidth drops per hop. Any data received by the 5GHz radio is forwarded to the UWB radio and sent to the Piper Tag (exit ramp) as dictated by the routing table.

[0870] The Piper border router receives data from the Piper anchor and forwards this data to the EMD switch. The Piper border router also routes data received by the EMD switch to the Piper data communication network.

[0871] Fig.73 Depicted is an example communication flow via the Piper DCS.

[0872] Piper anchors send beacons at regular intervals, typically 3-10 times per second. These beacons contain the anchor's tunnel location (relative distance to the "origin") and additional information used to form the Piper WDS. The Piper anchor uses this beacon data and the RSSI from received beacons to create a route from the anchor to the Piper border router. A proprietary routing algorithm minimizes latency and increases communication efficiency.

[0873] Fig.74 Depicted is a Piper network configuration supporting multi-channel streaming according to some embodiments of the disclosed technology.

[0874] Fault Tolerance

[0875] The Piper data communication network is designed so that any single Piper anchor failure will not affect overall throughput or latency. Piper anchors continuously send and receive beacons and heartbeat messages. Beacon data is sent from Piper border routers to Piper anchors that do not contain child nodes (leaves). Similarly, leaf Piper anchors initiate heartbeat messages sent to Piper border routers. So, there is health data sent in both directions. Piper anchors and Piper border routers use this data (or lack thereof) to determine the health of neighboring anchors. If a certain number of heartbeats or beacons are lost, the surrounding anchors will consider the anchor failed and route around that anchor. Once the anchor is back online, routing to that anchor will be restored.

[0876] Fig.75 Depicted is an example of Piper routing with a faulty anchor.

[0877] 3.3 Optional function - Road Worker Protection (RWP)

[0878] Piper has successfully demonstrated the use of wearable devices to determine the exact location of track workers. These devices are designed to alert track workers and train operators to dangerous proximity events. Wearable devices equipped with UWB radios connect with wayside anchors and DCS networks to determine location on or near the track in real time. Piper calculates the distance between the worker and the train through continuous detection of the worker's location and the train's location, and issues alerts in real time based on safe separation rules. Unlike point-to-point systems that perform distance ranging only when the worker and the radio on the train have a line of sight connection, Piper has developed a system that utilizes the wayside UWB network to monitor both locations simultaneously, trigger alarms, and integrate with the onboard EB controller to stop the train if no warning is heeded.

[0879] Fig.76 An example of Piper road worker protection architecture is depicted.

[0880] Piper has developed two iterations of UWB wearable rail worker safety devices. Both are rechargeable and have a battery life of more than 24 hours for a full duty cycle. In addition, Piper has developed a rail worker vest equipped with ultra-bright LEDs that are activated during an alarm. The devices use a shared PCB platform and are scalable to accommodate NYCT’s specific functional requirements.

[0881] Fig.77 Depicted are wearable rail worker safety devices according to some embodiments of the disclosed technology. 3.4 Optional Feature - Rapid Roadside Installation

[0882] Snake Tray was proposed as a subcontractor for this scope of work. Snake Tray will work with Piper Company and NYCT to develop a bracket design that meets NYCT standards and enables quick installation at the curb for the Piper anchors and power sources that also serve as fiber optic network switches. An example of a potential design is shown below.

[0883] Fig.78 Snake Tray example depicted.

[0884] The design of the seal provided more mechanical information through professional engineers, but Piper would need to know the selected deployment line to be used to design a custom bracket specific to the domain. Piper was able to immediately begin working with Snake Tray to design the forks necessary to accommodate the roadside equipment.

[0885] 3.5 Optional Function - Inter-Train Network (ITN)

[0886] Piper uses ITN as a way to network the tag controllers on the coupled units, compare ranging and positioning information, and provide reliable position data to the OBCU. In a typical configuration, 4 tag controllers are installed per unit, and there are 8 tag controllers per coupled train. In the figure below, the active units (green) are located at both ends of the coupled train. The inactive units (blue) can be reused to handle the telemetry data networking required for CBTC and provide a fully connected train. The rich bandwidth, combined with redundant, multi-directional networking capabilities achieved on the UWB network, make this solution a viable alternative to traditional and expensive ITN systems.

[0887] Fig.79 An inter-train network (ITN) according to some embodiments of the disclosed technology is depicted.

[0888] 3.6 Optional function - Carriage integrity detection system (CIDS)

[0889] Piper's Car-Cluster Integrity Detection System provides a cost-effective alternative to CBTC integrated axle counters. By installing an inexpensive "car-cluster counter" that is easy to deploy and maintain, Piper CIDS provides NYCT with a viable alternative to axle counters, or as a safety overlay for non-CBTC track circuits.

[0890] The system works by counting UWB radios on trains, each with a unique identifier recognized by the network. If the counter misses the expected car, possibly indicating a damaged train set, it interfaces with both the zone controller (in the CBTC system) and the Piper controlled circuit shunt to dynamically trigger a signal alerting approaching trains that the train is in danger.

[0891] The system can also communicate the location of non-revenue trains to the CBTC system and the AWS system.

[0892] Fig.80 A continuous integrity detection system (CIDS) in accordance with some embodiments of the disclosed technology is depicted.

[0893] 3.7 Optional Function - Asset Management (AM)

[0894] The Piper Asset Management System provides three (3) feature sets as described below:

[0895] 1. Remote monitoring

[0896] a. Regular Monitoring - Piper's AM system will send asset messages and trend data at regular intervals.

[0897] b. Detected Conditions - Piper's AM will send out alerts when a specified asset changes or exceeds normal conditions. Examples, high radio temperature, firmware version change, etc.

[0898] c. On-demand monitoring - Piper's AM will perform specific monitoring actions on demand. Example - Query current configuration parameters.

[0899] d. Monitoring and Management-Piper's AM system can provide remote management functions. These remote management functions can include modifying configuration parameters or executing corrective actions.

[0900] 2. Remote Software Deployment - Piper provides remote deployment capabilities, allowing users to remotely stage, verify, install, modify, roll back, and uninstall packaged software using complex rules and conditional checks.

[0901] 3. Remote Readiness Check - Piper's AM system can check and return asset information and the status of onboard subsystems. Piper can work with NYCT to design a scoring system (e.g., pass / fail; or score a unit from 1-10) to assess the current status of the onboard train control system and compare the relative readiness of the units.

[0902] 4 Project Execution

[0903] 4.1 Organizational Chart

[0904] Piper Network intends to hire a project management team with expertise in train control systems / safety systems and the delivery of complex projects for NYCT. Key personnel from this project management team will be based locally to support implementation and provide a consistent customer interface to NYCT. The proposed organizational chart is listed below and names and resumes will be provided separately to NYCT should NYCT confirm interest in the proposed program.

[0905] Fig.81 Depicts the proposed Piper project organizational chart.

[0906] 4.2 Security Plan

[0907] Piper is developing a safety-compliant UWB subsystem for train positioning.

[0908] For all system, hardware, and software development processes, Piper shall adhere to all required safety processes and design requirements consistent with CENELEC EN50129

[101] , EN50128

[102] , and EN50159

[103] standards (and any referenced standards).

[0909] Piper's safety program outlines the safety assurance tasks applied during the development of the above systems. The safety verification approach follows a proven structure that identifies and analyzes all safety-related functions performed by the product. Verification will show through inspection, testing, demonstration or analysis that the basic requirements for product safety have been implemented in the design.

[0910] The safety plan defines the planning, implementation, monitoring, and controls necessary to ensure the safety of the system. It also defines the tasks necessary to identify, track, evaluate, and eliminate or control hazards and unsafe failures. The specific goals of the safety plan are summarized below:

[0911] ·Develop, implement, and document the safety program's objectives, agreements, and practices in a verifiable manner.

[0912] ·Identify and evaluate all hazards and eliminate, control or minimize them to acceptable levels.

[0913] ·Perform qualitative and quantitative analyses that demonstrate that designs meet specified standards, requirements, and product safety objectives.

[0914] Establish verification and validation processes for all safety-related design elements and document the V&V activities performed.

[0915] Establish testing requirements for safety-related product elements and demonstrate through inspection, testing, demonstration or analysis that product safety is adequately verified.

[0916] Support product safety approval.

[0917] 4.3 Survey

[0918] Piper will conduct a comprehensive RF site survey in several phases. The goal is to actually measure the frequency, signal strength, and modulation characteristics of existing RF activity along the entire deployment area. This scan will be limited to the frequency bands of interest used in the selected implementation, as well as lower frequency usage that may also occupy the frequency band of interest due to harmonics.

[0919] We will conduct multiple surveys along the right-of-way (ROW) in the identified deployment area. The survey phase will include the following:

[0920] 1. Measurements taken during normal business peak hours on suitable open vehicles. (Measurements must be taken during normal business hours to accurately understand peak hour usage frequencies). Vehicles may move at normal service speeds while the initial presence scan is completed. Locations of particular interest will be noted and visited on foot as needed for additional scanning studies.

[0921] 2. Measurements made in and around each type of vehicle during normal vehicle operation. This can be done along a vehicle test track.

[0922] 3. Measurements taken at each station along the deployment area during daytime operations.

[0923] 4. Extended surveys of locations of interest identified during earlier surveys.

[0924] The data captured during this RF site survey will be studied to determine if action is necessary to avoid interference to or caused by the Piper UWB System operations.

[0925] 4.4 Verification and Validation (V&V)

[0926] Piper will form a dedicated team to develop this project. The team will consist of core team members and external independent consultants who will perform V&V tasks such as Fig.82 shown.

[0927] Piper defines Verification and Validation (V&V) as follows:

[0928] Validation: The process of evaluating a system or component during or at the end of the development process to determine whether it meets the specified requirements. The process of providing evidence that the software and its related products meet the system requirements assigned to the software at the end of each life cycle activity, solve the right problem (e.g., correctly model the laws of physics, implement business rules, use appropriate system assumptions), and meet the intended use and user needs.

[0929] Verification: The process of evaluating a system or component to determine whether the product of a given development phase meets the conditions imposed at the beginning of that phase. Provide objective evidence that the software and its related products meet the requirements (e.g., correctness, completeness, consistency, accuracy) of all life cycle activities (acquisition, provision, development, operation, and maintenance) during each life cycle process; meet standards, practices, and conventions during the life cycle process; and successfully complete each life cycle activity and meet all criteria for initiating subsequent life cycle activities (e.g., the software is correctly built).

[0930] Testable requirements and untestable requirements:

[0931] · Testable requirements are functional requirements with specific actions or outputs.

[0932] Untestable requirements are non-functional. Untestable requirements will be verified and confirmed through analysis, inspection, submission or review.

[0933] Fig.83 (Extracted from relevant standards) Identifies verification tasks and highlights the differences between verification and validation activities.

[0934] Piper has developed a V&V plan that is used to bridge project and subcontractor software V&V activities and guide both software integration and software V&V tasks. All aspects of software V&V will be monitored at the overall project level. The Piper V&V plan will be delivered as part of this proposed project and will be applied to all V&V activities performed for this project, including system and subsystem integration, demonstration, inspection and testing.

[0935] Piper's V&V program meets the following standards:

[0936] 1. IEEE STD 1012 - IEEE Standard for Software Verification and Validation

[0937] 2. IEEE STD 1012a - Supplement to the IEEE Standard for Software Verification and Validation

[0938] 4.5 Interface Management

[0939] Ensuring integration at all levels between systems and subsystems begins during the project design phase where an Interface Control Document (ICD) is developed to track and manage interface points. Critical interfaces may generate derived requirements that must be incorporated into subsystem design and planning. ICDs are an effective way to proactively track open interfaces and provide clear documentation of all closed interfaces. The key ICD delivered to NYCT will be the UWB to OBCU ICD, which Piper is providing to work with NYCT, its consultants, and the CBTC vendors to develop an agreed-upon interoperable ICD that can be inherited into the Interoperable Interface Specification (I2S). Other ICDs that Piper will generate will be specific to optional portions of this proposal, such as the RWP and CIDS.

[0940] Piper will work with all team members to establish regular integration meetings using the ICD to establish the project ICD matrix during the design phase. During the project construction phase, the ICD will continue to be tracked and often modified due to field change requests. A project change control process will be in place to address any modifications in the ICD, including adjustments or clarifications to the final derived requirements as necessary. The ICD is then monitored during the project testing phase. Interfaces then become critical in the use of the entire system. An ICD is included to fully document the testing requirements for the interfaces. Interfaces form the basis for integration testing, which is a prerequisite for final system safety certification.

[0941] 4.6CDRL

[0942] All CDRL lists will be available in the final proposal.

Claims

1. A system provided on a vehicle travelling along a transport path, the system include: An ultra-wideband UWB software defined radio, or SDR, implementing at least a 2x2 multiple-input multiple-output MIMO scheme and having a first transmit / receive terminal and a second transmit / receive terminal; one or more hardware processors; as well as one or more non-transitory machine-readable storage media encoded with instructions that, when executed by the one or more hardware processors, cause the system to perform operations comprising: receiving, via the first transmit / receive terminal of the SDR, a first wireless signal from one of a plurality of electronic devices anchored along the transport path, wherein the first wireless signal identifies a location of the one of the plurality of electronic devices and a transmission time of the first wireless signal; determining a position of the vehicle along the transport path based on the first wireless signal; and transmitting a second wireless signal via the second transmit / receive terminal of the SDR, wherein the second wireless signal identifies the location of the vehicle; wherein another one of the plurality of electronic devices receives the second wireless signal, and wherein the plurality of electronic devices wirelessly relays a third wireless signal along the transportation path, wherein the third wireless signal identifies the location of the vehicle.

2. The system of claim 1 , wherein the position of the vehicle along the transport path is determined based on the first wireless signal. include: determining a time of arrival of the first wireless signal; determining a flight time of the first wireless signal based on the transmission time and the arrival time; as well as The position of the vehicle along the transport route is determined based on the flight time and the position of the one of the plurality of electronic devices.

3. The system according to claim 2, in: The first wireless signal includes a plurality of carriers having equalized initial phases; as well as Determining the arrival time of the first wireless signal includes: obtaining a plurality of spectral components of the first wireless signal, and The obtained spectral components are processed to determine the arrival times.

4. The system of claim 3, wherein the obtained spectral components are processed to determine the arrival time include: A Fast Fourier Transform, or FFT, is performed on the obtained spectral components.

5. The system of claim 2, wherein determining the position of the vehicle along the transport path based on the first wireless signal further comprises: include: determining a distance based on the flight time; as well as Based on the distance and the location of the one of the plurality of electronic devices, the location of the vehicle along the transport path is determined.

6. The system according to claim 1, in: The transport path includes a plurality of tracks, each track being identified by a corresponding track number; and The operations also include determining a track on which the vehicle is located based on the first wireless signal, wherein the second wireless signal and the third wireless signal identify the track number of the track.

7. The system according to claim 1, in: a first other of the electronic devices wirelessly relaying the third wireless signal along the transport path in a first direction; and A second other electronic device among the first electronic devices wirelessly relays the third wireless signal along the transport path in a second direction.

8. One or more non-transitory machine-readable storage media encoded with instructions that, when executed by one or more hardware processors of a system disposed on a vehicle traveling along a transportation path, cause the system to perform operations, the operations include: receiving a first wireless signal from one of a plurality of electronic devices anchored along the transport path via a first transmit / receive terminal of an ultra-wideband (UWB) software defined radio (SDR), the SDR implementing at least a 2x2 multiple-input multiple-output (MIMO) scheme and having the first transmit / receive terminal and a second transmit / receive terminal, wherein the first wireless signal identifies a location of the one of the plurality of electronic devices and a transmission time of the first wireless signal; determining a position of the vehicle along the transport path based on the first wireless signal; as well as transmitting a second wireless signal via the second transmit / receive terminal of the SDR, wherein the second wireless signal identifies the location of the vehicle; wherein another one of the plurality of electronic devices receives the second wireless signal, and wherein the plurality of electronic devices wirelessly relays a third wireless signal along the transportation path, wherein the third wireless signal identifies the location of the vehicle.

9. The one or more non-transitory machine-readable storage media of claim 8, wherein the position of the vehicle along the transportation path is determined based on the first wireless signal. include: determining a time of arrival of the first wireless signal; determining a flight time of the first wireless signal based on the transmission time and the arrival time; as well as The position of the vehicle along the transport route is determined based on the flight time and the position of the one of the plurality of electronic devices.

10. One or more non-transitory machine-readable storage media according to claim 9, in: The first wireless signal includes a plurality of carriers having equalized initial phases; as well as Determining the arrival time of the first wireless signal includes: obtaining a plurality of spectral components of the first wireless signal, and The obtained spectral components are processed to determine the arrival times.

11. The one or more non-transitory machine-readable storage media of claim 10, wherein the obtained spectral components are processed to determine the arrival time include: A Fast Fourier Transform, or FFT, is performed on the obtained spectral components.

12. The one or more non-transitory machine-readable storage media of claim 9, wherein determining the position of the vehicle along the transport path based on the first wireless signal further comprises: include: determining a distance based on the flight time; as well as Based on the distance and the location of the one of the plurality of electronic devices, the location of the vehicle along the transport path is determined.

13. The one or more non-transitory machine-readable storage media of claim 8, in: The transport path includes a plurality of tracks, each track being identified by a corresponding track number; and The operations also include determining a track on which the vehicle is located based on the first wireless signal, wherein the second wireless signal and the third wireless signal identify the track number of the track.

14. The one or more non-transitory machine-readable storage media of claim 8, in: a first other of the electronic devices wirelessly relaying the third wireless signal along the transport path in a first direction; and A second other electronic device among the first electronic devices wirelessly relays the third wireless signal along the transport path in a second direction.

15. A computer-implemented method for a system provided on a vehicle traveling along a transport path, the computer-implemented method include: receiving a first wireless signal from one of a plurality of electronic devices anchored along the transport path via a first transmit / receive terminal of an ultra-wideband (UWB) software defined radio (SDR), the SDR implementing at least a 2x2 multiple-input multiple-output (MIMO) scheme and having the first transmit / receive terminal and a second transmit / receive terminal, wherein the first wireless signal identifies a location of the one of the plurality of electronic devices and a transmission time of the first wireless signal; determining a position of the vehicle along the transport path based on the first wireless signal; as well as transmitting a second wireless signal via the second transmit / receive terminal of the SDR, wherein the second wireless signal identifies the location of the vehicle; wherein another one of the plurality of electronic devices receives the second wireless signal, and wherein the plurality of electronic devices wirelessly relays a third wireless signal along the transportation path, wherein the third wireless signal identifies the location of the vehicle.

16. The computer-implemented method of claim 15, wherein determining the location of the vehicle along the transport path based on the first wireless signal include: determining a time of arrival of the first wireless signal; determining a flight time of the first wireless signal based on the transmission time and the arrival time; as well as The position of the vehicle along the transport route is determined based on the flight time and the position of the one of the plurality of electronic devices.

17. The computer-implemented method of claim 16, in: The first wireless signal includes a plurality of carriers having equalized initial phases; as well as Determining the arrival time of the first wireless signal includes: obtaining a plurality of spectral components of the first wireless signal, and The obtained spectral components are processed to determine the arrival times.

18. The computer-implemented method of claim 17, wherein the obtained spectral components are processed to determine the arrival time include: A Fast Fourier Transform, or FFT, is performed on the obtained spectral components.

19. The computer-implemented method of claim 16, wherein determining the position of the vehicle along the transport path based on the first wireless signal further comprises: include: determining a distance based on the flight time; as well as Based on the distance and the location of the one of the plurality of electronic devices, the location of the vehicle along the transport path is determined.

20. The computer-implemented method of claim 15, in: The transport path includes a plurality of tracks, each track being identified by a corresponding track number; and The operations also include determining a track on which the vehicle is located based on the first wireless signal, wherein the second wireless signal and the third wireless signal identify the track number of the track.

21. The computer-implemented method of claim 15, in: a first other of the electronic devices wirelessly relaying the third wireless signal along the transport path in a first direction; and A second other electronic device among the first electronic devices wirelessly relays the third wireless signal along the transport path in a second direction.

Images