Understanding Hyperloop’s Neural Network
For a majority of our population, software and our current way of life cannot be seen as separate entities. The entire concept of software has revolutionized our lives, morphing into various forms found in every industry and being part of the core of innovation around us. In the automotive industry, it has become one of the major decisive competitive factors that make one mode of transport more appealing and successful among consumers than the others. So, it is no surprise that our supersonic Hyperloop incorporates a complex software system for its operation.
Software systems in Hyperloop can be broken down into three major components, namely:
1) Embedded Systems, 2) Control Systems, and 3) Communication Systems that, together, account for what forms the central nervous system communicating and establishing control between all the different parts of the pod. This blog will be primarily focused on elucidating the Embedded Systems involved.
The Embedded System consists of a huge palette of sensors and actuators that range in function from providing vital output data to locate the pod within the Hyper tube, ensuring connections between the pod and a remote control dashboard, as well as the controlling of all other subsystems that we have discussed before. These control boards each are dedicated to major functions such as braking, power management, and all onboard sensor data aggregation and executing control command of pod components. The entire system operates on what is known as a “Master-Slave Design,” elaborating into two primary collaborative units: 1) Master units which constitute the main computing device units (for transmission of data to the main control panel and vice versa) connected to subordinate 2) hub units (convenient as it allows to add onboard sensors if required through expansion of these hub units) which are connected through a “CAN-BUS Network.” A “CAN-BUS Network” is a serial network technology that helps with the network’s fast communication between complex systems of microcontrollers to meet real-time requirements. They are used in current day vehicles as well for purposes of automation, and have been chosen for the Hyperloop design as they are promising in terms of functionality and reliability.
GOOSE V’s Status Report
Harking from our previous prototypes and welcoming improvements to create a better design, Team Waterloop has been working with communication protocols, namely the CAN and I2C. The CAN networks, as previously seen, were chosen for being the automotive standard that ensures high noise resistance and reliable high-speed communication with reduced latency times. Similarly, the I2C (intended to allow multiple digital integrated circuits to communicate with one or more “master” chips) was preferred as they account for a simple network for multiple devices that conveniently avoid carrying analog signals over long distances. However, it is to be noted that the I2C is not intended for long-range off-board signal carrying. So, controller boards must be physically nearby (have been designed to meet competition requirements). All these cables and connections are shielded to protect the signal carrying lines against noise and solderless connectors for vibration resistance. The multitude of sensors employed from previous blogs are used for purposes such as liquid cooling, temperature maintenance of the LIM, brakes, inverter, monitoring of the navigation system and for lateral stability of the pod on the track. In the unlikely event of a failure, the Embedded System is equipped with a fail-safe system that continually monitors the functioning of the brakes and power controllers that switches to operation in safe mode immediately if the respective systems are unresponsive.
VALIDATION IS KEY
Currently, for validating and enhancing our design further, our team has been earnestly testing the embedded network on different grounds mainly through signal testing, noise testing, temperature and environment testing procedures. The signal testing helps in terms of overviewing for proper operation and integration of our I2C, CAN, and sensors, with a special focus for clean waveforms and slew rates of the signal recorded. Noise testing is primarily targeted for the LIM as it could generate significant noise that affect the Embedded Systems. Hence, they are probed under the LIM operation to ensure all empirical ripple voltages and noise are below the absolute maximums by employing infrared inspections and arc flash studies. Finally, our temperature and environmental testing procedures help observe the high-power dissipative components so that they do not exceed safe operation limits and vacuum testing to verify any outgassing for consistent functionality in low-pressure conditions respectively.
In terms of our future goals, if permissible, we optimistically seek to implement more enhancements to our design, possibly shifting to a network with a faster bandwidth which is currently under study and research by the team. All in all, the Embedded System defines one among three segments that create the software system for a Hyperloop, so keep up as we decode all the complexities for your understanding!
