System and Method for Hyperloop Transponder Communication

Abstract

A solution is disclosed related to hyperloop vehicle communication using a transponder system. The transponder system comprises a plurality of transponder subnetwork controllers configured to provide one or more pluralities of transponders with connectivity. The pluralities of transponders are disposed at intervals such that the failure of a particular transponder is mitigated based on the interval of the transponders along with the connectivity of the supporting transponder subnetwork controllers. A hyperloop vehicle is configured to interact with the transponder system such that vehicle-side safety systems may rely on the transponder system as configured. The disclosed solution provides for enhanced traffic safety for hyperloop passengers and/or cargo, thus enabling green transportation.

Description

CROSS REFERENCE AND PRIORITY TO RELATED APPLICATIONS

This application claims the benefit of priority to: U.S. Provisional No. 63/254,025 entitled “SYSTEM AND METHOD FOR HYPERLOOP TRANSPONDER COMMUNICATION,” filed on Oct. 8, 2021.

All the aforementioned applications are hereby incorporated by reference in their entirety.

BACKGROUND

Hyperloop is a new mode of transportation relying on a hyperloop vehicle traveling through a tube having a near-vacuum environment. The projected velocity of the hyperloop vehicle may exceed 700 mph (1,127 km/h) in commercialized implementations. A hyperloop vehicle may rely on many types of tracks for guidance. However, magnetic levitation (“maglev”) is generally favored over traditional wheeled implementations because maglev provides a substantially frictionless means of guidance, levitation, and propulsion. Having maglev coupled with near-vacuum environments provides for high, sustainable velocities of hyperloop vehicles moving through the tube. Thus, passengers and cargo can be transported with reduced carbon impact.

One area of concern is collision avoidance. With such high-velocities, traditional solutions to determining braking distance are inadequate. For example, traditional rail still relies on human operators as a fallback to engage braking systems. With hyperloop, however, such human operation is virtually impossible given the high speeds that would exceed any conceivable human reaction time. As such, algorithms embedded in autonomous systems are largely responsible for braking and control.

Any reliable autonomous system requires input regarding downstream pods. Transponder-based safety systems are providing more safety for railway applications. However, traditional rail has an average speed of 30 km/h (18 mph) which is an order of magnitude smaller than hyperloop. Therefore, such existing solutions are essentially inapplicable to the operating environment of hyperloop. A hyperloop vehicle may be traveling at 500 km/h (310 mph) and require up to 1,400 meters of braking distance (assuming proportional to velocity squared). As such, the transponder network for hyperloop needs to address extremely high velocities where human intervention simply cannot be relied upon as a fallback safety measure.

The existing solutions are designed to be retrofitted to existing railways and support slow-moving objects. As such, the deployment of transponders is haphazard at best. Further, the redundancy of the newly deployed transponder networks is wholly inadequate for hyperloop. In general, the existing, retrofitted transponder networks are deployed in serial without the redundancy necessary to support hyperloop autonomous safety systems.

Another problem area for existing transponder networks is the inability to communicate data sufficient to ensure safety systems have adequate information. Transponders are simple devices in the current state of the art. But transponders provide some of the most recent and relevant information about the state of vehicles in the rail system. However, for hyperloop, more data may be necessary to ensure safe operation.

What is needed is a system and a method for hyperloop transponder communication that provides for reliable and robust communication between a hyperloop vehicle and a transponder network. The system and the method enable safety systems to adequately meet the extreme operating velocities of a hyperloop system.

SUMMARY

A solution is disclosed for a transponder system and a hyperloop vehicle system, as well as associated methods and processes. A transponder system is configured for communicating with a hyperloop vehicle operating along a path of travel. The transponder system comprises a first transponder subnetwork controller and a second transponder subnetwork controller, wherein the second transponder subnetwork controller is connected to the first transponder subnetwork controller. The transponder system further comprises a first plurality of transponders, wherein the first plurality of transponders is connected to the first transponder subnetwork controller. The transponder system further comprises a second plurality of transponders, wherein the second plurality of transponders is connected to the second transponder subnetwork controller.

The transponder system comprises a third plurality of transponders, wherein the third plurality of transponders is connected to the first transponder subnetwork controller. The transponder system further comprises a fourth plurality of transponders, wherein the fourth plurality of transponders is connected to the second transponder subnetwork controller. The first plurality of transponders and the second plurality of transponders are disposed at a first interval. The third plurality of transponders and the fourth plurality of transponders are disposed at a second interval. The first interval and the second interval are interposed along the path of travel. The first plurality of transponders further comprises a first transponder, wherein the first transponder subnetwork controller is configured to detect a failure state of the first transponder, wherein the first transponder subnetwork controller is configured to report the failure state to the second transponder subnetwork controller, wherein the first transponder subnetwork controller is further configured to communicate the failure state to the third plurality of transponders. The second transponder subnetwork controller is configured to communicate the failure state to the fourth plurality of transponders.

The first transponder subnetwork controller is further configured to communicate, via a high-speed communication network, the first failure state to a third-party server. The first transponder subnetwork controller is further configured to detect a second failure state, wherein the second failure state is associated with the second transponder subnetwork controller, and communicate, via the high-speed network, the second failure state to the third-party server.

The first plurality of transponders, the second plurality of transponders, the third plurality of transponders, and the fourth plurality of transponders are configured to communicate hyperloop vehicle data with the hyperloop vehicle. The hyperloop vehicle data comprises vehicle ID data, vehicle velocity data, transponder ID data, timestamp data, critical data, and time-to-live data.

A hyperloop vehicle system is configured to communicate with a transponder system disposed along a path of travel. The hyperloop vehicle system comprises a memory and a processor. The processor is configured to determine transponder interval data, wherein the transponder interval data indicates a plurality of positions of a first plurality of transponders, respectively. The first plurality of transponders comprises a first transponder. The processor is further configured to determine a first braking distance, communicate with the first transponder, and detect whether the first transponder is in a failure state.

The processor is further configured to report, if the first transponder is in the failure state, the failure state to a first transponder subnetwork controller, wherein the first transponder subnetwork controller is connected to the first transponder. The reporting is performed using a high-speed network. Further, the reporting is performed via a second plurality of transponders, wherein the second plurality of transponders is connected to the first transponder subnetwork controller. The processor is further configured to determine, if the first transponder is in a failure state, a second braking distance, wherein the second braking distance is based on the failure state and transponder interval data.

A process is configured for a hyperloop vehicle system to communicate with a transponder system disposed along a path of travel. The process is configured to determine transponder interval data, wherein the transponder interval data indicates a plurality of positions of a first plurality of transponders, respectively. The first plurality of transponders comprises a first transponder. The process is further configured to determine a first braking distance, communicate with the first transponder, and detect whether the first transponder is in a failure state.

The process is further configured to report, if the first transponder is in the failure state, the failure state to a first transponder subnetwork controller, wherein the first transponder subnetwork controller is connected to the first transponder. The reporting is performed using a high-speed network. Further, the reporting is performed via a second plurality of transponders, wherein the second plurality of transponders is connected to the first transponder subnetwork controller. The process is further configured to determine, if the first transponder is in a failure state, a second braking distance, wherein the second braking distance is based on the failure state and transponder interval data.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary aspects of the claims, and together with the general description given above and the detailed description given below, serve to explain the features of the claims.

FIG. 1 illustrates a block diagram of a track assembly with a hyperloop vehicle.

FIG. 2A illustrates a block diagram of a transponder system.

FIG. 2B illustrates a block diagram of a transponder system.

FIG. 2C illustrates a block diagram of a transponder system.

FIG. 2D illustrates a block diagram of a transponder system.

FIG. 2E illustrates a block diagram of a transponder system.

FIG. 3A illustrates a block diagram of a hyperloop vehicle system.

FIG. 3B illustrates a block diagram of a transponder system.

FIG. 4 illustrates a block diagram of a hyperloop vehicle data structure.

FIG. 5A illustrates a flowchart of a process for a hyperloop vehicle communicating with a transponder system.

FIG. 5B illustrates a flowchart of a process for a hyperloop vehicle communicating with a transponder system.

FIG. 6 is a block diagram illustrating an example computing device suitable for use with the various aspects described herein.

FIG. 7 is a block diagram illustrating an example server suitable for use with the various aspects described herein.

DETAILED DESCRIPTION

Various aspects will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

A hyperloop vehicle is a new mode of transportation that relies on maglev and a near-vacuum environment within a tube structure. Similar to traditional rail, hyperloop has a convoying system whereby a first hyperloop vehicle is downstream from a second hyperloop vehicle, ad infinitum. Unlike traditional rail however, hyperloop operates at incredible speeds when compared to traditional rail—with hyperloop velocities being an order of magnitude higher. Therefore, collision avoidance is paramount to the successful commercialization of hyperloop.

Collision avoidance systems require information related to the locations of the hyperloop vehicles within the hyperloop system. Also, the hyperloop vehicles are required to store the locations of other vehicles such that control of the hyperloop vehicle accounts for the other vehicles. Without such information, collision avoidance is unreliable and outright dangerous. Further, basic control systems within the hyperloop vehicle become similarly unreliable and dangerous because a hyperloop vehicle is operating with such high velocity that human operators cannot be used as a fallback. As such, the hyperloop system needs to communicate the position and state of the hyperloop vehicles operating in the hyperloop system. Such information is critical to safety systems.

The disclosed solution provides data to passing hyperloop vehicles such that safety objectives may be met. A hyperloop wayside system is disclosed herein and is generally configured to be fixed at or near the hyperloop track. The hyperloop wayside system may be integrated into the tube structure (and sections) that support the hyperloop track. The hyperloop wayside system may include anything that is not on the hyperloop vehicle itself. For example, the hyperloop wayside system may have high-speed network access points (e.g., 5G hotspots). The hyperloop wayside system may comprise a vacuum system that creates the near-vacuum environment found within the hyperloop tube. For the purpose of this disclosure, the wayside transponders are of keen interest.

A wayside transponder (or simply a transponder) is a device affixed at or near the hyperloop track such that passing hyperloop vehicles may be detected and communicated with. A transponder may be integrated into a tube section that forms part of the hyperloop track. A passing hyperloop vehicle may trigger detection by the transponder in a number of manners. For example, the transponder may detect a passing hyperloop pod by use of a Hall effect sensor which activates when the ferromagnetic fuselage and/or bogie of the hyperloop vehicle passes by the transponder. Other implementations of transponders may include use of a laser sensor, an ultrasonic sensor, a mechanical sensor, etc. In any configuration, the wayside transponder is generally tasked with reliable communication of critical information.

Transponders are relatively low-power devices that have limited capability to transmit large amounts of data. In general, a high-speed network is utilized for larger amounts of data (e.g., fleet management control signals, entertainment for passengers, weather information, etc.). However, the transponders have a critical role in providing relevant, recent information about nearby hyperloop vehicles, particularly those downstream from a hyperloop vehicle at or near the transponder. Given the high-velocity nature of hyperloop locomotion, line-of-sight detection of downstream vehicles is a risky approach. For instance, a downstream hyperloop vehicle may be stopped. If the line-of-sight is shorter than an operating braking distance, a collision might result unless a solution exists to notify the upstream vehicle of the downstream vehicle. The braking distance of a hyperloop vehicle may be more than one kilometer under certain operating conditions.

Line-of-sight systems are highly useful and not to the exclusion of any transponder-based solution for detection of hyperloop vehicles. Typical line-of-sight systems include laser sensors, lidar, ultrasonic, thermal imaging, computer vision, or a combination thereof. In the event that the transponder network encounters a fault, the hyperloop vehicle may fallback to line-of-sight detection. However, fallback to line-of-sight detection naturally implies a fallback to lower velocities in order to maintain a braking distance that is less than the line-of-sight distance. Therefore, high velocities require some type of transponder-based detection of vehicles.

With high-speeds, a hyperloop vehicle may require more information to reliably, safely, and efficiently operate than that required of a traditional rail vehicle (e.g., train, trolley, etc.). As stated, traditional rail may rely on human operators and line-of-sight detection (whether by machine or by human operator); hyperloop cannot rely on those same mechanisms to such an extent. Unless new approaches to transponder-based safety systems are developed, the hyperloop vehicle may encounter a fault, resulting in reduced efficiency, reduced speed or even reduced safety. Commercialization of hyperloop requires high levels of safety.

A transponder network that is not reliable and redundant is very dangerous to hyperloop vehicles (and the cargo and/or passengers inside). At best, a faulty transponder network only results in reduced speeds and increased traffic. At worst, a collision occurs resulting in the loss of property and life. Complete loss of life is likely given the high-speed nature of hyperloop. If hyperloop cannot be trusted as being as safe, then hyperloop technology may not reach the commercial adoption necessary to be economically viable.

Hyperloop is green. Given that hyperloop is a shared mode of transportation, road congestion may be reduced as more people can share a hyperloop vehicle than an automobile. Likewise, the high-speed nature of hyperloop implies a higher throughput of passengers/cargo than that of traditional rail. Further, hyperloop offers many improvements in passenger/cargo loading and unloading because of the autonomous nature of hyperloop vehicles. As the population of the world continues to grow, hyperloop is one of the few modes of transportation that offers a solution capable of addressing the many needs of large- and medium-sized cities affected by overcrowding.

Environmental concerns are substantial, whether expressed by governments or individuals. The world is seeking ways to maintain its standard of living while adapting to the understanding that manmade activity is affecting the global climate. To address this long-felt need, hyperloop offers an attractive solution to environmental concerns because hyperloop may be operated on electrical power that may be generated by solar panels affixed to the structure of the hyperloop track assembly (e.g., on the dorsal side of the hyperloop tube). In some configurations, hyperloop may be deployed as a carbon-neutral mode of transportation. However, without commercial adoption, hyperloop may not reach this goal. And collision avoidance and traffic control are necessary to support commercial adoption.

A solution to the above-stated problems is a system and method for a wayside transponder network that is configured to be reliable, efficient, and robust. The disclosed solution provides for a redundant transponder network that is configured to provide transponder-related data in operating conditions that may encounter faults. Further, the disclosed solution provides for the transmission of additional, relevant data between the hyperloop vehicle and the wayside transponder. The benefits of the disclosed solution include improved safety, increased power efficiency, increased commercial adoption, increased traffic efficiency, reduced deployment costs, reduced environmental impact, and many others.

FIG. 1 illustrates a block diagram of a track assembly 100 with a hyperloop vehicle 110. A plurality of axes is shown to orient the reader viz. a first axis 214X, a second axis 214Y, and a third axis 214Z.

A plurality of tube sections 105N has a first tube section 105A, a second tube section 105B, a third tube section 105C, a fourth tube section 105D, a fifth tube section 105E, a sixth tube section 105F, a seventh tube section 105G, an eighth tube section 105H, and a ninth tube section 105I. The plurality of tube sections 105N are generally assembled together on the site of the track assembly 100. In one aspect, the plurality of tube sections 105N may be supported by pylons or other superstructures that elevate the tube above ground level. Such support structures are commonly referred to as “hyperstructure.” In another aspect, the plurality of tube sections 105N may have a near-vacuum environment such that the hyperloop vehicle 110 may operate with reduced air resistance. However, low air resistance enables high velocities that increase risk to passengers and/or cargo, hence the need for the disclosed solution.

The plurality of tube sections 105N has a track (not shown) disposed therein. In one aspect, the track may be made of laminated steel that is configured to enable maglev locomotion of the hyperloop vehicle 110. Other ferromagnetic materials may be similarly utilized.

A bogie assembly of the hyperloop vehicle 110 possesses the necessary systems to provide locomotion that is safe, energy efficient, and reliable. For instance, the bogie assembly may have propulsion systems that generate force by use of electromagnetic engines disposed near the rails of the track. The bogie assembly may have additional systems including braking systems, levitation systems, guidance systems, lighting systems, sensor systems, fault tolerance systems, passenger management systems, cargo management systems, navigation systems, communication systems, emergency systems, maintenance systems, etc.

The hyperloop vehicle comprises a pod assembly, that is configured to provide transportation of cargo, passengers, or a combination thereof. The pod assembly may have some of the systems of the bogie assembly (and vice versa). For the purposes of this disclosure, the hyperloop vehicle 110 will be generally referred to for both the bogie assembly and the pod assembly. One of skill in the art will appreciate that the internal configuration of the hyperloop vehicle 110 may vary depending on the operating environment of the hyperloop implementation.

A direction of travel 133 is shown to indicate the direction along which the hyperloop vehicle 110 is traveling. As shown, the hyperloop vehicle 110 is traveling along the axis 214X toward the tube section 105D at which point the hyperloop vehicle 110 will turn toward the section 105H. Thus, the direction of travel 133 transitions to become substantially parallel with the axis 214Y. The hyperloop vehicle 110 is configured to turn at high speeds; if a second hyperloop vehicle is traveling through the tube sections 105E, 105F, 105G, the hyperloop vehicle 110 may need to have such information in order to avoid a collision with the second hyperloop vehicle.

A plurality of transponders 109N are disposed at or near the plurality of tube sections 105N. The plurality of transponders 109N comprises a first transponder 109A, a second transponder 109B, a third transponder 109C, a fourth transponder 109D, a fifth transponder 109E, a sixth transponder 109F, a seventh transponder 109G, an eighth transponder 109H, and a ninth transponder 109I. The transponders 109A, 109B, 109C, 109D are interconnected by a link 117A. The transponders 109E, 109F, 109G, 109H, 109I are connected via a link 117B. In one aspect, the links 117A, 117B may be connected such that the plurality of transponders 109N are interconnected and understood be one network (or subnetwork). For clarity, a diamond symbol is shown to depict that the links 117A, 117B are interconnected.

A transponder is generally configured to communicate with the hyperloop vehicle 110 when in proximity to the transponder. Information may be sent from the transponder to the hyperloop vehicle 110 or vice versa, depending on operating conditions and parameters. For instance, the hyperloop vehicle 110 is shown as passing the transponder 109A in the instant view. The hyperloop vehicle 110 will pass the transponder 109B when traveling through the tube section 105B. In one aspect, the plurality of transponders 109N may correspond to each of the plurality of tube sections 105N. For instance, the tube section 105A corresponds to the transponder 109A. In one aspect, the tube section 105A may have the transponder 109A attached thereto and deployed as part of the tube section 105A.

A high-speed network 111 is available at or near the track assembly 100 such that the elements within the track assembly 100 may communicate with other elements in the track assembly 100. The high-speed network 111 is connected to the plurality of transponders 109N via a link 142. In one aspect, the plurality of transponders 109N may provide access to information communicated by the high-speed network 111. The high-speed network 111 may be a combination of wired and wireless communication means, in one aspect. In one aspect, the high-speed network 111 may be 5G. In another aspect, the high-speed network 111 may be WIFI. In general, the hyperloop vehicle 110 may be in communication with the high-speed network 111 as well as the plurality of transponders 109N, wherein each communication means has an assigned role. For instance, the plurality of transponders 109N may be charged with delivering short, critical messages whereas the high-speed network 111 may be charged with delivering long, less-critical messages.

The hyperloop vehicle 110 may communicate with a fleet management center (not shown) via the high-speed network 111 in order to communicate fleet-management data. For example, a message may be sent to the hyperloop vehicle 110 to instruct the hyperloop vehicle 110 to enter a stable for service. Such messages provide yet another source of data for the disclosed solution to enable guidance control of the hyperloop vehicle 110. For instance, the hyperloop vehicle 110 may require messages to guide the hyperloop vehicle through a non-moving switch (e.g., at or near the tube section 105D).

A first braking distance 141A is depicted as the braking distance of the hyperloop vehicle 110 multiplied by two. Thus, if the braking distance of the hyperloop vehicle 110 is fifty meters then the first braking distance 141A is 100 meters. As shown, the braking distance 141A is measured from the transponder 109B to the transponder 109D. The braking distance 141A may be any multiple of the actual braking distance of the hyperloop vehicle 110 such that a margin of error is maintained.

A second braking distance 141B is depicted between the transponders 109E, 109G. The second braking distance 141B may be less than that of the first braking distance 141A because a hyperloop vehicle approaching the tube section 105D may be slowing due to the presence of the hyperloop vehicle 110. A third braking distance 141C is depicted between the transponder 109I and a transponder (not shown) that is beyond the perspective of the instant illustration. One of skill in the art will appreciate that the tube section 105H would be followed by yet another tube section and so on.

In sum, the braking distances 141A, 141B, 141C should be understood to be related to the operating velocity of a hyperloop vehicle. In general, the braking distances 141A, 141B, 141C are measured from each of the transponders within the plurality of transponders 109N. Such measurement provides for accurate braking-distance determination because the plurality of tube sections 105N are disposed at fixed intervals that are known by safety systems within the hyperloop vehicle 110.

FIG. 2A illustrates a block diagram of a transponder system 201. The transponder system 201 is generally configured to provide robust, reliable, and efficient communication among a plurality of transponders (e.g., the plurality of transponders 109N). As shown, the transponder system 201 is comprised of a number of transponders that are connected via a subnetwork that, in turn, is connected to form a network. One benefit of the transponder system 201 is increased redundancy in the event that a given transponder (or network of transponders) fails. As discussed, the failure of the hyperloop vehicle 110 to obtain relevant, recent information about other hyperloop vehicles may lead to catastrophic outcomes which include the loss of human life (as discussed above).

The transponder system 201 is shown having a path of travel 221 on which the hyperloop vehicle 110 travels. In the instant view, the hyperloop vehicle 110 is traveling substantially parallel to the direction of travel 133. One of skill in the art will appreciate that the instant view is simplified with a straight segment of track; however, the transponder network 201 may be deployed in any configuration adjacent to a track (e.g., a track formed using spirals and curves). In one aspect, the path of travel 221 may be a maglev track that is disposed within a given tube section (e.g., the tube section 105A) having a transponder located therein (and even integrated therein). For example, the transponder 109E may be physically integrated into the tube section 105E. Turning back to FIG. 1, the path of travel 221 may be substantially similar to the hyperloop vehicle 110 traveling through the plurality of tube section 105N.

A plurality of tube sections 241N is depicted. The plurality of tube sections 241N may have a first tube section 241A, a second tube section 241B, a third tube section 241C, a fourth tube section 241D, a fifth tube section 241E, a sixth tube section 241F, a seventh tube section 241G, an eighth tube section 241H, a ninth tube section 241I, a tenth tube section 241J, an eleventh tube section 241K, and a twelfth tube section 241L. The plurality of tube sections 241N may be substantially similar to the plurality of tube sections 105N as shown in FIG. 1, above.

The plurality of tube sections 241N comprises a first plurality of transponders 231N, a second plurality of transponders 233N, and a third plurality of transponder 235N. The first plurality of transponders 231N is formed by a first transponder 231A, a second transponder 231B, a third transponder 231C, and a fourth transponder 231D. The transponder 231A is disposed in the tube section 241A. The transponder 231B is disposed in the tube section 241D. The transponder 231C is disposed in the tube section 241G. The transponder 231D is disposed in the tube section 241J. The plurality of transponders 231N is connected via a link 251A.

The plurality of transponders 233N is formed by a first transponder 233A, a second transponder 233B, a third transponder 233C, and a fourth transponder 233D. The transponder 233A is disposed in the tube section 241B. The transponder 233B is disposed in the tube section 241E. The transponder 233C is disposed in the tube section 241H. The transponder 233D is disposed in the tube section 241K. The plurality of transponders 233N is connected via a link 251B.

The plurality of transponders 235N comprises a first transponder 235A, a second transponder 235B, a third transponder 235C, and a fourth transponder 235D. The transponder 235A is disposed in the tube section 241C. The transponder 235B is disposed in the tube section 241F. The transponder 235C is disposed in the tube section 241I. The transponder 235D is disposed in the tube section 241L. The plurality of transponders 235N is connected via a link 251C.

The links 251A, 251B, 251C form a plurality of links 251N. The plurality of links 251N is generally configured to create a transponder network (or subnetwork) for each of the respective pluralities of transponders 231N, 233N, 235N. The plurality of links 251N may be any type of communication means, whether wired or wireless. Typically, transponder-based communication relies on wired means since wired communication is generally more robust and reliable. Therefore, an ethernet-based protocol may be utilized within the plurality of links 251N.

The plurality of links 251N continue beyond the instant view in order to continue the transponder system 201 along the path of travel 221. Turning back to the plurality of transponders 109N in FIG. 1, if the links 117A, 117B fail, the hyperloop vehicle 110 may not be able to determine the position and/or velocity of nearby hyperloop vehicles. As such, the hyperloop vehicle 110 may need to enter a safety mode and proceed at a velocity with a highly conservative braking distance. Those skilled in the art refer to this safety mode often as “limp mode” where the hyperloop vehicle 110 is understood to limp along the path of travel 221 at a reduced speed. The safety mode provides for stronger reliance on line-of-sight systems to detect downstream objects (such as other hyperloop vehicles). Such line-of-sight systems are enumerated above.

However, the transponder system 201 is arranged such that every third tube section has a transponder belonging to a different plurality of transponders. For example, the plurality of transponders 231N has the transponder 231A in the tube section 241A, and the plurality of transponders 233N has the transponder 233A in the tube section 241B (and so on). By interposing the pluralities of transponders 231N, 233N, 235N among the plurality of tube sections 241N, redundancy is increased. In hyperloop, redundancy increases safety.

A plurality of transponder subnetwork controllers 211N is comprised of a transponder subnetwork controller 211A and a second transponder subnetwork controller 211B. The transponder subnetwork controllers 211A, 211B are connected via a link 225. The link 225 provides for communication between the transponder subnetwork controllers 211A, 211B as well as other transponder subnetwork controllers (not shown) connected via the link 225.

The transponder subnetwork controllers 211A, 211B are connected to the pluralities of transponders 231N, 233N, 235N via a first link 223A and a second link 223B. The link 223A connects the transponder subnetwork controller 211A to the transponders 231A, 231B, 233A, 233B, 235A, 235B. The link 223B connects the transponder subnetwork controller 211B to the transponders 231C, 231D, 233C, 233D, 235C, 235D.

The links 223A, 223B, 225 may wired, wireless, or a combination thereof. In one aspect, the links 223A, 223B, 225 may be 5G. In another aspect, the links 223A, 223B, 225 may be a wired connection. Wired connections may be required by regulatory authorities that mandate anti-collision requirements, including the interconnectivity of transponders. Therefore, the plurality of links 251N may be substantially similar to the links 223A, 223B, 225, in one aspect.

Since the pluralities of transponders 231N, 233N, 235N are separate networks, the transponder subnetwork controllers 211A, 211B ensure coordination among the plurality of transponders 231N, 233N, 235N. For example, the transponder 233A may communicate information to the transponder 235A via the link 223A by assistance of the transponder subnetwork controller 211A.

The high-speed network 111 is shown in the instant (and related) views. The high-speed network 111 may be operatively connected to the transponder network 201 via the transponder subnetwork controllers 211A, 211B. For example, if the transponder 231A enters a failure state, the transponder subnetwork controller 211A may communicate the failure state via the high-speed network 111 to a relevant entity (i.e., a third-party server). For instance, the operator may operate a third-party server which interfaces with elements of the track assembly 100. As such, the high-speed network 111 may transmit messages to the third-party server. The messages may then be accessed from the third-party server via a terminal device (e.g., personal computer). Likewise, emergency crews may be notified for extreme situations (e.g., fire damage). Therefore, governments may similarly have third-party servers connected to the track assembly 100.

FIG. 2B illustrates a block diagram of the transponder system 201. The instant view depicts the plurality of transponders 231N as being in a failure state. The failure state relates to a specific transponder or plurality of transponders being incapable of communication. Failures resulting in the failure state may include signal noise, damaged physical wires, electromagnetic interference (“EMI”), static discharge, mechanical connection failure, component failure, or a combination thereof.

In the instant view, the plurality of transponders 231N are shown grayed out to illustrate the failure state. When the hyperloop vehicle 110 passes the tube section 241A, no communication will occur between the transponder 231A and the hyperloop vehicle 110. However, the hyperloop vehicle 110 will be able to communicate with the transponder 233A upon entering the tube section 241B. Likewise, when the hyperloop vehicle 110 enters the tube section 241C, the transponder 235A will communicate with the hyperloop vehicle 110.

Therefore, as the hyperloop vehicle 110 proceeds along the path of travel 221, the hyperloop vehicle 110 will continue to communicate with every two out of three transponders passed by. While not ideal, the hyperloop vehicle 110 has enough information to adequately determine the position of a downstream pod at a reasonable interval. As such, the braking distances may be adjusted accordingly; for example, the distances 141A, 141B, 141C from FIG. 1 may still be determined and relied upon even though the plurality of transponders 233N has failed. Only if the three pluralities of transponders 231N, 233N, 235N fail will the hyperloop vehicle 110 be operating without information regarding downstream pods, thus being forced to fallback to a safety mode with reduced velocity and reduced braking distances (i.e., limp mode).

One of skill in the art will appreciate that the transponder system 201 provides for a highly robust, fault-resistance network of transponders. Two out of three of the pluralities of transponders 231N, 233N, 235N may fail without causing the transponder system 201 to fail. Likewise, information may still be communicated across the transponder system 201 via the transponder subnetwork controllers 211A, 211B. As such, the braking distances 141A, 141B, 141C (from FIG. 1 above) may be maintained at or near nominal levels.

FIG. 2C illustrates a block diagram of the transponder system 201. The instant view is similar to the view in FIG. 2B above. However, the transportation system 201 is now shown with the plurality of transponders 233N being in a failure state. As such, the pluralities of transponders 231N, 233N are inoperative. Therefore, the plurality of transponders 235N are responsible for providing critical communication to the hyperloop vehicle 110.

In spite of the failures, the hyperloop vehicle 110 is still capable of communication at every third tube section, namely the tube sections 241C, 241F, 241I, 241L. While not optimal, the transponder system 201 still provides a substantial amount of data to the hyperloop vehicle 110. Current solutions would fail in the existing situation because typical transponder networks rely on serially configured transponders. However, given the transponders at every third tube section, the operators and technicians of the hyperloop vehicle 110 may engage in remediation of the failure (e.g., removal of hyperloop vehicles from service, closure of a tube section, etc.).

In one aspect, the hyperloop vehicle 110 may rely on the high-speed network 111 to communicate in the absence of a transponder. For example, when the hyperloop vehicle 110 encounters the failed transponders 231A, 233A, the hyperloop vehicle 110 may communicate for assistance via the high-speed network 111. While typically used for high-bandwidth applications, the high-speed network 111 may provide high-speed-based data to the hyperloop vehicle 110. For instance, the high-speed-based data may include traffic schedules, fleet management data, portal schedules, non-failed transponder data, accident reports, environmental conditions (e.g., fire, smoke), or a combination thereof. High-speed-based data may therefore supplement any transponder-based data where such transponder-based data is still available.

FIG. 2D illustrates a block diagram of the transponder system 201. The plurality of transponder subnetwork controllers 211N may comprise many transponder subnetwork controllers such that redundancy is increase throughout the transponder system 201. In the instant view, the plurality of transponder subnetwork controllers 211N further comprises a transponder subnetwork controller 211C and a transponder subnetwork controller 211D. The transponder subnetwork controllers 211A, 211B, 211C, 211D are still interconnected by the link 225, as described above in FIG. 2A.

As shown, the transponder system 201 is operational with all transponders being connected to one another via the plurality of transponder subnetwork controllers 211N. As discussed above, the transponder system 201 is highly redundant at the transponder-level given that a transponder is positioned at intervals. Further, such intervals reduce the chance of long segments of track having no transponder-based communication. However, the plurality of transponder subnetwork controllers 211N may be placed and/or interposed such that the failure of a transponder subnetwork is mitigated due to the presence of nearby, functioning transponder subnetwork controllers.

FIG. 2E illustrates a block diagram of the transponder system 201. The instant view depicts the transponder subnetwork controller 211B as being in a failure state. The hyperloop vehicle 110 will be able to communicate with the transponders connected to the transponder subnetwork controller 211A (e.g., the transponders 231A, 231B). However, upon reaching the transponder subnetwork controller 211B, no transponder-based communication is possible (e.g., no communication with the transponders 231C, 231D).

At a later point in time, the hyperloop vehicle 110 will reach the transponder subnetwork controller 211C and will be capable of transponder-based communication again. Therefore, the hyperloop vehicle 110 will only encounter a gap in communication and not a complete failure of communication along the path of travel 221.

FIG. 3A illustrates a block diagram of a hyperloop vehicle system 301. The hyperloop vehicle system 301comprises a transponder communication subsystem 313, a flight control subsystem 317, a high-speed network communication subsystem 319, a processor 324, and a memory 326.

The transponder communication subsystem 313 is generally configured to communicate with the transponder system 201. The transponder communication subsystem 313 may communicate via passive systems, inductive systems, radio systems, or a combination thereof.

The flight control subsystem 317 is generally configured to provide autonomous control to the hyperloop vehicle 110. In one aspect, the flight control subsystem 317 may be configured to receive information via the transponder communication subsystem 313 in order to determine whether the braking distance (e.g., the braking distance 141A) of the hyperloop vehicle 110 exceeds a safety margin based on the position of a downstream hyperloop vehicle. In response, the flight control subsystem 317 provides acceleration and deceleration of the hyperloop vehicle 110 in order to maintain the desired braking distance.

The high-speed network communication subsystem 319 is generally configured to communicate via the high-speed network 111. The transponder communication subsystem 331 may, in some configurations, only transmit small amounts of data that is critical to flight of the hyperloop vehicle 110. As such, the high-speed network 111 may provide a means by which the hyperloop vehicle 110 may communicate other data (e.g., fleet management data, maintenance data, infotainment data, etc.).

In the event that the transponder system 201 encounters a failure state, the high-speed network 111 provides a fallback means of communication. For instance, in FIG. 2B, the plurality of transponders 231N are in a failure state. As such, the hyperloop vehicle 110 will not communicate transponder-related data when passing through the tube sections 241A, 241D, 241G, 241J. However, the high-speed network 111 is configured to provide data to the hyperloop vehicle 110, including data typically sent via a transponder (e.g., the transponder 231A).

The processor 324 may be a shared processor which is utilized by other systems, modules, etc. within the disclosed solution. For example, the processor 324 may be configured as a general-purpose processor (e.g., x86, ARM, etc.) that is configured to manage operations from many disparate systems, including the hyperloop vehicle system 301. In another aspect, the processor 324 may be an abstraction because any of the modules, systems, and/or components disclosed herein may have a local processor (or controller) that handles aspects of the hyperloop vehicle system 301 (e.g., ASICs, FPGAs, etc.).

The memory 326 is generally configured to store and retrieve information. The memory 326 may be comprised of volatile memory, non-volatile memory, or a combination thereof. The memory 326 may be closely coupled to the processor 324, in one aspect. For example, the memory 326 may be a cache that is co-located with the processor 324. As with the processor 324, the memory 326 may, in one aspect, be an abstraction wherein the modules, systems, and/or components each have a memory that acts in concert across the hyperloop vehicle system 301.

FIG. 3B illustrates a block diagram of a transponder communication system 302. The transponder communication system 302 is operatively connected to and/or part of the transponders within the pluralities of transponders 109N, 231N, 233N, 235N, as discussed in FIG. 1 and FIG. 2A above. The transponder communication system 302 has a vehicle management subsystem 353, a sensor subsystem 355, a high-speed network communication subsystem 357, a processor 361, and a memory 363.

The vehicle management subsystem 353 is generally configured to manage data related to hyperloop vehicles (e.g., the hyperloop vehicle 110). For instance, the vehicle management subsystem 353 may contain hyperloop vehicle data relating to vehicle IDs, velocity data, timestamp data, etc. The vehicle management subsystem 353 communicates such hyperloop vehicle data with passing hyperloop vehicles (e.g., the hyperloop vehicle 110).

The sensor subsystem 355 is generally configured to detect a passing hyperloop vehicle. A Hall effect is created by the ferromagnetic material within the passing hyperloop vehicle and may be detected via use of a Hall sensor. The sensor subsystem 355 may include use of a laser sensor, an ultrasonic sensor, a mechanical sensor, etc.

The processor 361 may be a shared processor which is utilized by other systems, modules, etc. within the disclosed solution. For example, the processor 361 may be configured as a general-purpose processor (e.g., x86, ARM, etc.) that is configured to manage operations from many disparate systems, including the transponder communication system 302. In another aspect, the processor 361 may be an abstraction because any of the modules, systems, and/or components disclosed herein may have a local processor (or controller) that handles aspects of the transponder communication system 302 (e.g., ASICs, FPGAs, etc.).

The memory 363 is generally configured to store and retrieve information. The memory 363 may be comprised of volatile memory, non-volatile memory, or a combination thereof. The memory 363 may be closely coupled to the processor 361, in one aspect. For example, the memory 363 may be a cache that is co-located with the processor 361. As with the processor 361, the memory 363 may, in one aspect, be an abstraction wherein the modules, systems, and/or components each have a memory that acts in concert across the transponder communication system 302.

The instant view shows the hyperloop vehicle 110 in communication with the transponder communication system 302 and the high-speed network 111. In a typical deployment, the hyperloop vehicle 110 will encounter hundreds of transponders at regular intervals and correspondingly communicate with the transponder communication system 302 belonging to each of the transponders (e.g., the transponder 231A).

FIG. 4 illustrates a hyperloop vehicle data 411 structure. Hyperloop vehicle data 411 comprises vehicle identification (“ID”) data 413, vehicle velocity data 415, transponder ID data 417, timestamp data 419, time-to-live data 421, and critical data 423. In one aspect, the hyperloop vehicle 110 receives the hyperloop vehicle data 411 via the transponder communication subsystem 313 described in FIG. 3A. Likewise, the hyperloop vehicle 110 is configured to communicate hyperloop vehicle data 411 via the transponder system 201 in FIG. 2A above.

A vehicle ID is a unique value associated with a particular hyperloop vehicle (e.g., the hyperloop vehicle 110). Such uniqueness provides a means by which to identify each hyperloop vehicle for the purposes of flight control. The vehicle ID data 413 may contain one or more vehicle IDs of downstream hyperloop vehicles.

Vehicle velocity data 415 comprises the velocities associated with each of the vehicle IDs contained in the vehicle ID data 413. The vehicle velocity data 415 provides information sufficient for the hyperloop vehicle 110 to determine the state of downstream vehicles in order to adjust braking distances (e.g., the braking distances 141A, 141B, 141C from FIG. 1 above).

The transponder ID data 417 contains transponder IDs associated with each of the vehicle IDs in the vehicle ID data 415. In one aspect, the hyperloop vehicle 110 contains a map of the plurality of tube sections (e.g., the plurality of tube sections 105N, 241N). As such, the hyperloop vehicle 110 is able to accurately determine the position of itself as well as downstream pods. Such determination informs the calculation of the braking distances 141A, 141B, 141C described in FIG. 1 above.

The timestamp data 419 provides time and date information relating to when a vehicle ID was detected by a particular transponder. The time-to-live data 421 provides a value that indicates how long the entry of hyperloop vehicle data 411 is valid. After the time-to-live condition has been met, the hyperloop vehicle data 411 is considered invalid for the purposes of flight control and braking distance calculations.

The critical data 423 is generally configured to contain short, critical messages that the hyperloop vehicle 110 may utilize to adjust flight control parameters. For example, emergency information may be sent to the hyperloop vehicle 110 when passing a transponder (e.g., the transponder 109A above). An emergency message such as “cabin fire” may be embedded in the critical data 423 in order to alert personnel and systems.

An example of hyperloop vehicle data 411 is found in Table 1 below. One of skill in the art will appreciate that the order and arrangement of the data in Table 1 may be adapted for a different implementation without departing from the purpose and design of the hyperloop vehicle data 411 as described herein.

TABLE 1
Hyperloop Vehicle Data 411 Example
	Vehicle	Trans-
Vehicle	Velocity	ponder	Time-	Time-to-	Critical
ID Data	Data	ID Data	stamp Data	Live Data	Data
413	415	417	419	421	423
A	550 km/h	109E	2021-09-28	1,500 ms	N/A
			00:03:33:20
B	250 km/h	109I	2021-09-28	3,000 ms	N/A
			00:03:33:19
C	450 km/h	109A	2021-09-28	2,000 ms	N/A
			00:03:33:18
D	510 km/h	109C	2021-09-28	2,000 ms	EMERGENCY
			00:03:33:20		STOP
Z	531 km/h	109D	2021-09-28	5000 ms	N/A
			00:03:33:18

FIG. 5A illustrates a flowchart of a process 501 for the hyperloop vehicle 110 communicating with the transponder system 201. The process 501 is generally configured to enable communication of the hyperloop vehicle data 411 between the hyperloop vehicle 110 (via the hyperloop vehicle system 301) and the transponder system 201. The instant figure and FIG. 5B both will use FIG. 2B (above) to illustrate the activity of the hyperloop vehicle 110 while traveling the path of travel 221 and encountering the transponder 231B in a failure state. The process 501 begins at the start block and proceeds to the block 505.

At the block 505, the process 501 determines the transponder interval data. The transponder interval data is generally associated with the tube sections 105N. For example, the operator of the hyperloop vehicle 110 will designate which tube sections are fitted with a transponder. In the example shown in FIG. 1, above, a transponder is fitted at each tube section. For example, the tube section 105A is associated with the transponder 109A. However, one of skill in the art will appreciate that the relationship between a tube section and a transponder may not be 1:1. For example, an operator may determine that every other tube section is adequate for a transponder installation. Another 1:1 configuration is shown in FIG. 2A through FIG. 2D. For instance, the tube section 241A is associated with the transponder 231A.

In any case, the flight control subsystem 317 stores transponder interval data to determine the exact placement of transponders with respect to one another. Transponder interval data includes the position of a transponder, the associated tube segment, the transponder subnetwork controller, or a combination thereof. Such transponder interval data may be used by the flight control subsystem 317 such that a simple measurement along the path of travel 221 will yield a substantially precise position of a given transponder within the track assembly 100. The process 501 then proceeds to the block 507.

At the block 507, the process 501 determines the braking distance. As shown in FIG. 1 above, the braking distances 141A, 141B, 141C vary. The flight control subsystem 317 determines the braking distance based on a number of factors related to traffic management. In general, the braking distance is such that the hyperloop vehicle 110 avoids any collision with downstream hyperloop vehicles and/or downstream objects in the plurality of tube sections 105N. The process 501 then proceeds to the block 509.

At the block 509, the process 501 communicates with a transponder. Given that the instant example traces the view of FIG. 2B above, two transponders are of interest viz. the transponder 235A and the transponder 231B. The transponder 235A is operating according to specifications. In contrast, the transponder 231B is in a failure state. The flight control subsystem 317 has stored the transponder interval data such that the hyperloop vehicle system 301 is aware that communication within the tube section 241D should be enabled by the transponder 231B (which is in a failure state). The process 501 then proceeds to the decision block 511.

At the decision block 511, the process 501 determines whether a transponder is in the failure state. Based on the communication in the block 509, the process 501 will determine that the transponder 235A is in operation and the transponder 231B has entered a failure state. If the process 501 determines that the transponder 235A is not in the failure state, the process 501 proceeds along the NO branch to the callout block B. Essentially, the hyperloop vehicle system 301 proceeds along the path of travel 221 and is substantially within normal operating conditions. However, the process 501 is configured to address the failure state of the transponder 231B. If the process 501 determines that the transponder 231B is in a failure state, the process 501 proceeds along the YES branch to the callout block A.

FIG. 5B illustrates a flowchart of the process 501 for the hyperloop vehicle 110 communicating with the transponder system 201 (via the hyperloop vehicle system 301). The process 501 proceeds from the callout blocks A and B. Taking the simpler path first, the process 501 proceeds from the callout block B to the end block and terminates. Essentially, the hyperloop vehicle system 301 is operating without encountering a failed transponder and continues along the path of travel 221. However, at the callout block A, the process 501 is addressing the failure state of the transponder 231B.

At the block 513, the process 501 reports a failure state of the transponder 231B. The failure state may be communicated to a subsequent transponder at a later time, in one aspect. For example, the hyperloop vehicle system 301 may store the failure state in the memory 326 and report the failure state at or near the transponder 233B (which is operational in the FIG. 2B). In another aspect, the hyperloop vehicle 110 may communicate via the high-speed network communication subsystem 319 to notify operators of the failed transponder 231B. Such high-speed communication provides near instantaneous notification of failed transponders such that emergency situations can be avoided, not just for the hyperloop vehicle 110 but for any vehicle in the track assembly 100. In one aspect, the transponder interval data is utilized to make the reporting of the failure state richer. The process 501 then proceeds to the block 515.

At the block 515, the process 501 determines the braking distance. The braking distance determination at the block 515 is substantially similar to the determination at the block 507. However, the braking distance calculated by the process 501 at the block 515 is likely shorter than the braking distance determined at the block 507 since the transponder 231B is now in a failure state. In one aspect, the flight control subsystem 317 is charged with determining any reduced braking distance. The process 501 then proceeds to the decision block 517.

At the decision block 517, the process 501 determines whether the hyperloop vehicle 110 should enter the safety mode. The entering of the safety mode is generally determined based on the flight control subsystem 317. In general, if the braking distance is such that the hyperloop vehicle 110 has an undesirable risk of collision, then the safety mode provides for safe operation. If the determination is that the hyperloop vehicle 110 should enter the safety mode, the process 501 proceeds along the YES branch to the block 519.

At the block 519, the hyperloop vehicle 110 enters a safety mode. For example, the safety mode may rely on line-of-sight systems (e.g., lidar, etc.). In one aspect, the process 501 utilizes the high-speed network communication system 357 to notify the operators of the use of the safety mode. The process 501 then proceeds to the end block and terminates. Returning to the decision block 517, if the process 501 determines that the hyperloop vehicle 110 should not enter the safety mode, the process 501 proceeds along the NO branch to the end block and terminates.

At the FIG. 2A, reference C indicates that the process 501 is iterative for each transponder along the path of travel 221. For instance, the transponder 233B may be communicated with via the process 501 and have a determination substantially similar to the determination made with respect to the transponder 235A. At a later point in time, the reference C will start the process 501 for the failed transponder 231C and result in a determination substantially similar to the determination made with respect to the failed transponder 231B.

FIG. 6 is a block diagram illustrating a computing device 700 suitable for use with the various aspects described herein. The computing device 700 may store and process the processes and data associated with the track assembly 100, the transponder system 201, the hyperloop vehicle system 301, the transponder communication system 302, the hyperloop vehicle data 411, and the process 501.

The computing device 700 may include a processor 711 (e.g., an ARM processor) coupled to volatile memory 712 (e.g., DRAM) and a large capacity nonvolatile memory 713 (e.g., a flash device). Additionally, the computing device 700 may have one or more antenna 708 for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver 716 coupled to the processor 711. The computing device 700 may also include an optical drive 714 and/or a removable disk drive 715 (e.g., removable flash memory) coupled to the processor 711. The computing device 700 may include a touchpad touch surface 717 that serves as the computing device's 700 pointing device, and thus may receive drag, scroll, flick etc. gestures similar to those implemented on computing devices equipped with a touch screen display as described above. In one aspect, the touch surface 717 may be integrated into one of the computing device's 700 components (e.g., the display). In one aspect, the computing device 700 may include a keyboard 718 which is operable to accept user input via one or more keys within the keyboard 718. In one configuration, the computing device's 700 housing includes the touchpad 717, the keyboard 718, and the display 719 all coupled to the processor 711. Other configurations of the computing device 700 may include a computer mouse coupled to the processor (e.g., via a USB input) as are well known, which may also be used in conjunction with the various aspects described herein.

FIG. 7 is a block diagram illustrating a server 800 suitable for use with the various aspects described herein. The server 800 may store and process the processes and data associated with the track assembly 100, the transponder system 201, the hyperloop vehicle system 301, the transponder communication system 302, the hyperloop vehicle data 411, and the process 501.

The server 800 may include one or more processor assemblies 801 (e.g., an x86 processor) coupled to volatile memory 802 (e.g., DRAM) and a large capacity nonvolatile memory 804 (e.g., a magnetic disk drive, a flash disk drive, etc.). As illustrated in instant figure, processor assemblies 801 may be added to the server 800 by insertion into the racks of the assembly. The server 800 may also include an optical drive 806 coupled to the processor 801. The server 800 may also include a network access interface 803 (e.g., an ethernet card, WIFI card, etc.) coupled to the processor assemblies 801 for establishing network interface connections with a network 805. The network 805 may be a local area network, the Internet, the public switched telephone network, and/or a cellular data network (e.g., LTE, 5G, etc.).

The foregoing method descriptions and diagrams/figures are provided merely as illustrative examples and are not intended to require or imply that the operations of various aspects must be performed in the order presented. As will be appreciated by one of skill in the art, the order of operations in the aspects described herein may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the operations; such words are used to guide the reader through the description of the methods and systems described herein. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an,” or “the” is not to be construed as limiting the element to the singular.

Various illustrative logical blocks, modules, components, circuits, and algorithm operations described in connection with the aspects described herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, operations, etc. have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. One of skill in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

The hardware used to implement various illustrative logics, logical blocks, modules, components, circuits, etc. described in connection with the aspects described herein may be implemented or performed with a general purpose processor, a digital signal processor (“DSP”), an application specific integrated circuit (“ASIC”), a field programmable gate array (“FPGA”) or other programmable logic device, discrete gate logic, transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, a controller, a microcontroller, a state machine, etc. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such like configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions (or code) on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or as processor-executable instructions, both of which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor (e.g., RAM, flash, etc.). By way of example but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, NAND FLASH, NOR FLASH, M-RAM, P-RAM, R-RAM, CD-ROM, DVD, magnetic disk storage, magnetic storage smart objects, or any other medium that may be used to store program code in the form of instructions or data structures and that may be accessed by a computer. Disk as used herein may refer to magnetic or non-magnetic storage operable to store instructions or code. Disc refers to any optical disc operable to store instructions or code. Combinations of any of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

The preceding description of the disclosed aspects is provided to enable any person skilled in the art to make, implement, or use the claims. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the aspects illustrated herein but is to be accorded the widest scope consistent with the claims disclosed herein.

Claims

1. A transponder system for communicating with a hyperloop vehicle operating along a path of travel, the transponder system comprising:

a first transponder subnetwork controller;

a second transponder subnetwork controller, the second transponder subnetwork controller being connected to the first transponder subnetwork controller;

a first plurality of transponders, the first plurality of transponders being connected to the first transponder subnetwork controller; and

a second plurality of transponders, the second plurality of transponders being connected to the second transponder subnetwork controller.

2. The transponder system of claim 1, the transponder system further comprising:

a third plurality of transponders, the third plurality of transponders being connected to the first transponder subnetwork controller; and

a fourth plurality of transponders, the fourth plurality of transponders being connected to the second transponder subnetwork controller.

3. The transponder system of claim 2, wherein the first plurality of transponders and the second plurality of transponders are disposed at a first interval and the third plurality of transponders and the fourth plurality of transponders are disposed at a second interval.

4. The transponder system of claim 3, wherein the first interval and the second interval are interposed along the path of travel.

5. The transponder system of claim 1, the first plurality of transponders further comprising:

a first transponder, wherein the first transponder subnetwork controller is configured to detect a first failure state of the first transponder, the first transponder subnetwork controller being configured to report the first failure state to the second transponder subnetwork controller, the first transponder subnetwork controller being further configured to communicate the first failure state to the third plurality of transponders.

6. The transponder system of claim 5, wherein the second transponder subnetwork controller is configured to communicate the first failure state to the fourth plurality of transponders.

7. The transponder system of claim 5, wherein the first transponder subnetwork controller is further configured to:

communicate, via a high-speed communication network, the first failure state to a third-party server.

8. The transponder system of claim 7, wherein the first transponder subnetwork controller is further configured to:

detect a second failure state, the second failure state being associated with the second transponder subnetwork controller; and

communicate, via the high-speed network, the second failure state to the third-party server.

9. The transponder system of claim 7, wherein the hyperloop vehicle data comprises vehicle ID data, vehicle velocity data, transponder ID data, time-to-live data, critical data, and timestamp data.

10. The transponder system of claim 1, wherein the first plurality of transponders, the second plurality of transponders, the third plurality of transponders, and the fourth plurality of transponders are configured to communicate hyperloop vehicle data with the hyperloop vehicle.

11. A hyperloop vehicle system configured to communicate with a transponder system disposed along a path of travel, the hyperloop vehicle system comprising:

a memory;

a processor, the processor being configured to: determine transponder interval data, the transponder interval data indicating a plurality of positions of a first plurality of transponders, respectively, the first plurality of transponders comprising a first transponder; determine a first braking distance; communicate with the first transponder; and detect whether the first transponder is in a failure state.

12. The hyperloop vehicle system of claim 11, the processor being further configured to:

report, if the first transponder is in the failure state, the failure state to a first transponder subnetwork controller, the first transponder subnetwork controller being connected to the first transponder.

13. The hyperloop vehicle system of claim 12, wherein the reporting is performed using a high-speed network.

14. The hyperloop vehicle system of claim 12, wherein the reporting is performed via a second plurality of transponders, the second plurality of transponders being connected to the first transponder subnetwork controller.

15. The hyperloop vehicle system of claim 11, the processor being further configured to:

determine, if the first transponder is in a failure state, a second braking distance, the second braking distance being based on the failure state and transponder interval data.

16. A method for a transponder system to communicate with a hyperloop vehicle on a path of travel, the method comprising:

determining, at a processor, transponder interval data, the transponder interval data indicating a plurality of positions of a first plurality of transponders, respectively, the first plurality of transponders comprising a first transponder;

determining, at the processor, a first braking distance;

communicating, at the processor, with the first transponder; and

detecting, at the processor, whether the first transponder is in a failure state.

17. The method of claim 16, the method further comprising:

reporting, at the processor and if the first transponder is in the failure state, the failure state to a first transponder subnetwork controller, the first transponder subnetwork controller being connected to the first transponder.

18. The method of claim 17, wherein the reporting is performed using a high-speed network.

19. The method of claim 17, wherein the reporting is performed via a second plurality of transponders, the second plurality of transponders being connected to the first transponder subnetwork controller.

20. The method of claim 16, the method further comprising:

determining, at the processor and if the first transponder is in a failure state, a second braking distance, the second braking distance being based on the failure state and transponder interval data.