Building Next Generation Rail Systems With Rust: Tom Praderio of Parallel

Drew: So, Parallel is probably a newer name for a lot of people who aren't combing the internet for rust companies like I do. Could you start with just the elevator pitch to orient people to what you guys are doing?

Tom: Absolutely. At Parallel, we are taking the efficiencies of rail transport and combining it with the point to point service quality of truck transport. Behind all that, you get all of the environmental benefits that come with using battery electric rail vehicles. So, we're really trying to make shipping easier, faster, cleaner, and safer for our customers using the rail infrastructure that already exists in the United States and worldwide as well.

Drew: One of the things I like to ask about is the founding team. I think that founder-market fit can be really important. Tell me a little bit about how the company was founded, who was involved in that, and why this is the right team to work on this problem.

Tom: A lot of the core team, including the founders of the company and myself, had all worked together at SpaceX. SpaceX is a wild place to work. It really teaches you a lot of lessons about building reliable hardware and finding ways to build software and hardware that is going to work the way you think it is. A lot of it is the testing methodology. “Testing like you fly” is a big way that SpaceX manages to be so successful. So, when we decided to move on and tackle the next challenge, the team here was looking for opportunities to take that approach of building really reliable, well-tested hardware and software into an application that was going to help humanity and the planet a little bit more directly.

Tom: A lot of things were considered. My founders finally settled on the rail industry. There's so much capacity in the rail industry in terms of the occupancy on the track. You can expand the rail corridors a lot more easily than expanding roads for trucking. And, this was also during the coronavirus pandemic when a lot of logistical stackups were happening, ports were congested, and there weren't enough truck drivers.

Tom: So, the solution kind of just came together all by itself. We applied this rigorous hardware and software development to enabling efficiencies in the rail sector. We're trying to bring all the good elements of that SpaceX culture, including rapid hardware iteration, a strong emphasis on safety and testing and reliability, and radical ownership of components in the team. And, also just an appetite for making the world a better place.

Drew: We talked before and you mentioned the SpaceX thing, but I didn't think too deeply about it then. But, that testing culture obviously is kind of famous. What does that look like for you? Are you throwing your vehicles into the fire pretty frequently?

Tom: Yeah. So, we took inspiration from SpaceX and the aerospace industry in general. In the aerospace industry, when you're building a plane or a rocket, your opportunities of testing the whole integrated system are pretty limited. You have to fly it in order to get it into real conditions. That's a really high risk scenario. If you don't get everything right or if you're not very confident the system is going to work, you can have a really expensive failure. So this by necessity dictates that you have to have a really, really strong testing environment and testing culture. At SpaceX and a lot of other aerospace companies, there's this concept of “testing like you fly”, building entire representative sets of hardware and software, and having very complete test environments that capture all of the environmental conditions of where you're trying to operate.

Tom: At SpaceX we had hardware in the loop tables and test setups that would allow us to conduct entire missions with the real hardware that was on the rocket and the capsule. We could run it through thousands and thousands of different configurations, simulating real inputs. The hardware thinks it's flying and we're just stimulating it to make sure it all happens correctly. We've taken that approach straight out of the aerospace industry and applied it to the rail industry. So, our rail vehicles, and our software all the way from our firmware and vehicle control software up to cloud software and user terminals are all simulated in very high fidelity simulation environments along with our hardware. This makes sure that we can test every single scenario for performance and safety, making sure that the system fails safely and that it's following the rules of the road.

Drew: So the other thing you said that I wanted to follow up on was about trucking. When you talk about trains, most people in the U.S. think about long freight trains, and I guess in Europe it’s more like passenger rail. But, you guys are looking at taking on trucking, which I guess is a form of freight, but its smaller loads potentially shorter distances. Why is that the target rather than anything else that you could do on rails?

Tom: Great question. This might be one of the most kind of misunderstood aspects of Parallel. We are train people. We love trains. We think traditional railroading is an extremely efficient way of moving goods. Our technology is not intended to compete with or replace traditional trains. If you have thousands and thousands of boxes of intermodal containers or a lot of ore or coal or whatever to move, there's no better way to move it than with one big power unit at the front. What we're trying to do here is bring the unit economics of that really efficient system down to smaller shipments and lower distances. If you think about it, the way that modern railroading works right now is that there's efficiency in getting a single control unit, a single locomotive, and then stacking as many cargo units behind it. So, the longer your trains are, the better your efficiencies are. That's really important for railroads to be able to achieve the really high efficiency that they do. The problem is that all of that comes at a cost for smaller shippers. If you're a shipper that wants to move, say, five containers, and you only want to go a small distance, you're going to stack those five containers in the middle of a two mile long freight train. That means that to drop those containers off, you're going to delay every single other car on that train. There's a lot of complicated maneuvers to disconnect your cars from the middle of the train. It could take hours to do this on a standard industrial siding. A lot of times these complications mean the railroads just aren't interested in delivering smaller shipments and shorter distances. So, they let the trucking market just kind of eat that up. Because trucks really are point-to-point, whereas longer trains need to be broken up and sorted at various yards throughout the country, the quality of service you can get out of a truck is usually a lot better. You'll get your cars cheaper with a train but it might take anywhere from 72 hours to a week to get the delivery, and you don't know when it's going to show up. That's not super useful for a lot of just-in-time delivery use cases. So, what we're trying to do is blend those two forms of transport. We want to bring trucking volume back to rail. If Parallel is successful, this should end up making more rail traffic than less rail traffic. I would expect more traditional trains to be running. And, we think that we can be a solution not just for first mile or last mile deliveries from big intermodal yards but also for providing that point to point service like a truck would. We can get all the benefits of rail while still being able to provide the high quality of trucking service.

Drew: Does all the rail that you would need to do that effectively exist?

Tom: There is a lot of rail infrastructure in the United States, and even the rail infrastructure that currently exists is a small portion of what used to exist in the heyday of the rail industry back in the 1920s and 1930s, or basically up until World War II when the interstate highway system started being built. There are a lot of different ways you can solve this problem. For example, there are many industrial facilities, especially large ones, that still have rail linked to them directly and get rail shipments today. So, that's a really easy first market for us to be able to do point-to-point shipments for. Beyond that, there are a lot of industrial development clusters or development areas where a developer builds a large amount of heavy industry that's co-located near a highway or something. A lot of times these are located next to rail and the question just becomes whether or not the volume exists to justify building a small spur line. We think that if we can justify the cost of doing that, we can serve an entire industrial hub with just really short drays to and from a micro terminal located very close. This gives all the benefits of rail without having to involve long distance truckers. You're talking about moving a last mile that's sometimes less than even a mile. It’s often just back and forth from a terminal, kind of like in a port.

Tom: The more long-term use case is that if you make it very efficient, then now it becomes profitable for the railroads to build brand new rail, whether over existing corridors that used to have rail or branching out into new areas.

Tom: It really all just comes down to unit economics. It’s a question of if you can make it effective and you can make money doing it. That's ultimately what our pitch is. We're trying to make this a profitable business for the railroads and the shippers. Then, whoops, we happen to electrify the whole system as well, right? We're not leading with the green part. It is very important to us as a company and we want to lean into that.

Drew: In terms of the existing infrastructure that we've been talking about, it seems like that's gotta be an interesting challenge to figure out how to integrate with everything that exists already. What are the specific problems you've seen there and how have you tackled them?

Tom: So, you know, we just talked about profitability and efficiency. You have to make it worth the railroads while, and worth the customers while. We live in a market economy, and no one's giving away stuff for free. Capital improvements on rail lines are also very expensive. There’s just a lot of horizontal infrastructure. So, you have really show that it's gonna make the money back and the investment's gonna be profitable. So, one of our core tenets here is we want to make it so that the capex involved in deploying our technologies is as low as possible. That means that we need to integrate with the existing infrastructure as it stands right now. So, we don't require a special type of tracks or mag levs or anything like that. We don't even need an overhead catenary to be installed. That would obviously be a really awesome thing for the U S freight rail network, but it would be very expensive to do. The ROI isn't there to do that for most of the routes.

Tom: When it comes to software and that integration, that's a big part too. We want to make sure that our system is totally compatible with current train control and dispatching systems, including more modern systems like PTC. But, it can also work down to the absolute lowest level of train control, including things like yard limits. Other than main operation, you also have work zones and such, all these special conditions that happen out in the real world. We want our system to be fully compatible with the railroad operating rules as they stand and not require any sort of special infrastructure. And, that's kind of where the fun comes in. I thought I knew a lot about train control before I started this company, but I've learned even more and there's so much more to learn too. It's a very exciting software challenge to be compatible with all the ways that railroads do things right now.

Drew: I bet. You were talking about how one of the disadvantages with current freight trains is that you're trying to stack as many cars as you can and then you end up with this problem of trying to disconnect certain cars at certain points. Is that where the platooning aspect of your solution comes in? I’m not a railroad person, so I don't totally understand all the benefits of that or how it would work.

Tom: Yeah, so it's very beneficial for trains to travel in long sections of cars. You don't necessarily want a rail system that's operating like a highway system where there's just individual cars. For one, that’s kind of a safety issue. Trains are really heavy and take a long time to stop. So, you really want them to be traveling together in batches. Also, when it comes to crossing infrastructure, you don't want the gates to be coming down every two seconds because another train has gone by. So, there are real network efficiencies to trains even though our vehicles are all individually powered and are capable of traveling by themselves. So, when we're out on the main track, we want to be traveling like a train does. This is part of integrating with the way that trains currently work. The big difference between our technology and the way that traditional rail equipment works is that we don't physically couple together our cars because every single one of our cars is a fully self-contained and capable electric vehicle. We have them push up against each other and maintain the train line through bumper compression. All of our vehicles have a bumper that senses force and displacements, so the lead vehicle in the train sets the pace and every other car behind it just maintains that constant pressure on the bumper. If it detects that the car in front of it starts speeding up, it will speed up to catch it. And, if there's a braking event and the bumper compresses, it'll brake too. The actual algorithm is much more complicated than that and takes into account a lot of safety and train line maintenance issues to make sure that we can operate the way that a normal train does. But, the idea here is that if you can maintain your train line with compression only, then when you want to break it up, there's almost no cost to doing so. For instance, in the case where you want to drop off some cars, depending on the type of equipment you have and the conditions on the rail, this can be a very complicated operation for a traditional locomotive. For us, the train simply will come to a stop or even drop them off on the fly if necessary. It can just separate wherever it wants to as long as the rules of the road permit it at that time. The vehicles themselves can then back into a siding and be ready for loading and unloading all by themselves. There's no secondary moves required by the engine crew. So, the platooning is very core to this concept. It allows us to operate like trains do, but it also allows us to do things that trains could never do, which is this rapid drop off and deployments and then also bringing cars together to make trains on the fly. A lot of this requires a lot of integration with the way that the dispatching software runs today and making sure we're compliant with all the rules. We think that this platooning concept is going to be able to unlock the best of both worlds.

Tom: We have a test track, and there are some videos online of this. We have a fleet of vehicles right now that we use for demonstration purposes and pilots. So, we’ll go into customer environments and try delivering freight and prove that the unit economics works. So, we can do platooning with those vehicles at our test track. We show the coming together and coming apart to customers, investors, and regulatory agencies. It shows them what exactly this technology allows to happen. It's pretty exciting to see it in action.

Drew: You said before that you don't really center the fact that the vehicles are electric. However, I have an electric car and so I know there are some new problems that come with electrification. You have to deal with charging and there's also range anxiety, which really isn't a big deal with cars, but it seems like it could be a problem here. How do you think about these issues?

Tom: Yeah, so I guess let me start off by just acknowledging that electric rail is by no means a new concept. We are standing on the shoulders of giants here. Back in the 1920s, a lot of long distance mainline tracks in the United States, including a few transcontinentals, were fully electrified with overhead wires. There's no substitute for that. That is pretty awesome. You don't have to worry about any range anxiety in that case because you're just plugged into the grid as you move. Most of Europe is able to move freight this way. Japan does this as well.

Tom: We are attempting to bring back a lot of those benefits of electric trains. Obviously, there's carbon benefits. And, you don't have to have the refueling infrastructure the same way. It's a lot cleaner in communities where you operate. And, it’s a lot safer because there’s less toxic material and pollution. But, there's also some other benefits that come along with electric technology. For example, when it comes to braking you can conserve the energy that you would otherwise lose during braking events. For trains, braking events are really, really large. If you have a huge train coming down a mountain, that generates a ton of power. On a traditional locomotive, even using dynamic braking, the power just gets burned off into heat and doesn't actually get captured anywhere. So, whether you're doing overhead catenary or battery electric, you can store that energy and then use it for the next climb. This also just generates a lot less wear on braking components because it's a lot less heat to remove.

Tom: The big problem though, and what the technology that we're building is attempting to solve, is getting the amount of power that you need to operate a freight train onto a train. This is actually a really hard challenge. For a long time it was hard to even get that amount of power into a car. Thanks to a lot of advances in electric motors and batteries, we're able to get there, but the energy involved in moving a car is just so much lower than moving an entire freight train. So, there's two ways you can solve this. You can put the power off board and you can have overhead catenary, but the ROI isn't there for the railroads to go do that on long distance routes right now. The other thing you can do is put a ton of batteries into a locomotive. And, there are a few other companies that are working on doing this. The issue with this is that the amount of batteries you need to put into a locomotive to pull a massive amount is so large that the charging infrastructure actually is the breaking point. How do you plug in a locomotive with several megawatt hours worth of battery capacity and get power into that thing in a way that's not going to take a week? It's really hard to do. Also just the weight of that number of batteries becomes an unwieldy problem.

Tom: What we're attempting to do here is spread that problem out throughout the entire train. Rather than trying to focus all of the batteries up front inside one or two locomotives and battery tender cars, we are distributing the battery power throughout the entire train. This makes it a way more solvable problem. And, this solution comes with the benefit where now all the cars are self powered and can make their own movements. You unlock that platooning stuff that we were talking about before.

Tom: On the planning and kind of range anxiety side, one of the nice things about the rail network versus driving a car is that most train maneuvers are well planned in advance. This allows us to use our planning software and integrate it with the business systems and freight delivery systems that exist in the railroads. This makes it so we can plan our charging ahead. We have charging infrastructure that we can deploy either where the cars are, where they're loading, or even as midpoint chargers. So, we can design a service where the charging is just another element like refueling a locomotive is right now. We can do fast charging just like most cars can today so that you don't have a whole lot of downtime. So, there are a lot of benefits to electric and the way the electric technology has been moving, it's ready for rail right now.

Drew: Existing freight trains are diesel electric, right? So it's like a diesel generator driving electric motors?

Tom: Correct, most mainline trains in the United States are diesel electric.

Drew: But you're not getting all that benefit of being fully electric, like the braking case you mentioned?

Tom: No, you’re not. I mean, most trains brake in several different ways. They have brake shoes on all the cars that are air brakes and those just kind of burn off over time. For the most part, when a train is braking, it'll do dynamic braking. That is very similar to what we do with regenerative braking, but there's no place to put the energy. So, a traditional locomotive will just use a large resistor bank to send that current through and convert the electricity into heat that can be vented out. Because we have batteries on board, just like an electric car, we can capture it and then use it later. It's very nice for operational efficiency.

Drew: So as these trains are moving, there's always the chance they're going to run into unexpected conditions on the track and need to stop. I understand that's usually a big problem for existing trains because of the braking issue, but in your case the issue is the train needs to be able to recognize that on its own and react. What does the solution look like for that? Is there a suite of sensors? Also, what's the software? Is it AI, or something deterministic?

Tom: Our vehicles are equipped with a perception suite that allows us to sense the environment and respond in ways that a human driver would respond. Though, it's typically a lot faster. And, hopefully we get to a point where we can really prove the reliability. The suite includes lidars, cameras, and computer vision. A lot of this is standing on the shoulders of giants of the autonomous vehicle industry, but it’s adapted for and run through the very strict testing requirements that you need to operate on the rail network. To some degree trains aren't really fully autonomous in any case. They do what the dispatching network wants them to do. And, if you're doing it right, you're following exactly the rules in the train movement plan that you've been given. But, to cover those unexpected circumstances, we use this sensor suite to handle cases where there's a branch that fell across the track, or a crossing gate is non-functional, or we need to move through a restricted speed area. Not only do we have those autonomous sensor suites that can help the train move and make safe decisions, but we also have a tele-operation backup. If the train gets into a situation where it needs assistance, it can remote home. This is very similar to the way the autonomous vehicle industry works today where there's a backhaul that can get you out of sticky situations. As we continue to refine our approach, we'll be able to handle more and more cases. And again, all this is being done with the intention to prove in a very strict manner that the system meets safety requirements. We have a lot of data to make sure that we're doing the right thing in any given circumstance.

Drew: Given that each car has its own regenerative braking capabilities, is there anything about your architecture that makes it able to stop better than a traditional freight train?

Tom: Yeah, we can. In any case, freight trains are just heavy and the freight you're carrying is extremely heavy. The friction of the steel wheel and steel rail in one direction helps you achieve really good efficiency when you're moving forward because there's very little rolling resistance. But, when it comes to stopping, the steel wheel and steel rail can't provide the friction that, for example, a rubber tire on asphalt can provide. So, we still are limited by physics there. We can't ever stop the way that a car can stop. That’s just not gonna happen. However, what we do have over traditional locomotives is that every single vehicle is loaded with sensors and can control its own braking pressure. So, we can close loop control and really maximize the braking efficiency or the braking friction, sort of like anti-lock braking on a passenger vehicle. We can sense when we're at the threshold limit of static friction between the wheel and the rail and can maximize the stopping distance. So, whatever the maximum braking potential of the wheel rail interface is at that moment, we can utilize that. Generally, that means we can stop a lot faster than a traditional train. You've seen traditional trains, they’re famous for not being able to stop fast. Also, sometimes the braking pressure from a locomotive can take a very long time to pressurize up and hit the cars at the very end. We just immediately and actively close the loop on that and make sure that it happens faster.

Drew: So that’s maybe another side benefit for society safety-wise.

Tom: It just so happens that when you do this it does unlock a lot of side benefits that are really useful for the industry. I want to also clarify there too, even though the business case doesn't rely on this being green, that's really important to us philosophically. It's one of the reasons why I got into this. I wanted to make a difference in the way that we produce carbon in the world. Not that this is the biggest contributor. But, it is pretty big. I think globally freight takes up something like 10% of the global carbon emissions. If everyone else is working on all the other parts, then we can all together bring down the carbon footprint.

Drew: That makes sense to me. This strategy tracks with the breakthrough for electric cars. People wanted to do an electric car because it's better for the world, but it had to be compelling outside of that. So, in the railroad industry, there's got to be a bunch of regulatory hurdles that are coming up. How's that all going?

Tom: We have a very good working relationship with the Federal Railroad Administration in the United States and various other countries' regulatory bodies. This is so central to our business. As I said before, we need to be able to fit into the way that trains currently work. A lot of that means behaving like they do and conforming to the same safety standards that they do. We take this extremely seriously at the company. So, built into our system requirements and testing requirements we have a whole suite of regulatory validation and safety validation that we do to make sure that we can satisfy the requirements and the regulators, as well as just be as safe as we possibly can when we're out on the rail. We've become, or we're trying to become, experts as fast as possible in all of these different regulatory environments.

Tom: There are a lot of common things that various countries and municipalities share in railroads. But, there are also a lot of divergent things. The divergent things can be as small as what color temperature the headlights need to be on any given rail vehicle or the exact geometry. So, there might end up being small differences in our system from locale to locale, just like with the automotive industry. But, at the end of the day, trains are trains. You need to make sure that they follow the rules of the road, that they don't go faster than they're supposed to, that they only go exactly where you tell them to go, that they're accurate in their position reporting, and that they fail safe in a way that isn't going to harm the public or interfere with other road users. We're very committed to that. It's been a learning process and we have a lot more to go.

Tom: One of the ways that we're making progress on this is through a pilot program in the state of Georgia. We're going through a multi-phase test program where we’re heavily involved with the FRA. We have a very good working relationship with them. And, we're kind of stepping through, slowly introducing more and more elements of our technology. We're just about to complete our second phase of that where we are showing crossing behaviors.

Drew: I imagine that pilot is probably the biggest milestone for you guys lately. Are there any other big milestones that you think would be worth mentioning?

Tom: Yeah, that's certainly the most public milestone. Right now our fleet is made up of what we call our Mark II generation vehicles. Those are the ones that are out in the field and performing the pilots with various customers right now. But, we are also working on the design and manufacturing of our production level Mark III generation. No public milestones yet with that, but we're really excited to reveal that when we finish building the first prototype and start serial productionizing them. This is sort of like a cost-optimized, production-ready variant that incorporates a lot of the lessons learned with the previous vehicles. The train control software is all still the same as what we used before. So, no public milestones to share yet, but we're pretty excited to keep moving forward with this Georgia pilot. I'm very excited to work with the FRA on getting long-term railworthiness proven.

Drew: Yeah, that sounds like an important hurdle to clear. What you described about the variance in regulations from different jurisdictions sounds daunting.

Tom: It's daunting, but we're up to the task. Like I said, it has to be a huge portion of what you do as a company in order to be successful in this industry. We intend to be compliant.

Drew: We've gone all this time just talking about Parallel. We haven't talked about Rust. So, let's talk about it. How does it fit in your stack, where do you use it, and what does it do for you?

Tom: We started in 2020, so Rust was stable for maybe two or three years at that point. And, we are a full Rust shop. Our product software is all in Rust. From the firmware running on bare metal devices through the vehicle software running on our custom Linux distribution. I guess that isn't in Rust, but it's Linux. And then you go all the way up to our web software stack running on cloud servers. That's all Rust too. Even a little bit of our user interface is Rust. I won't say all, there's some JavaScript in there. We're not 100 % web ready. We utilize the Rust test framework to be able to get a really high degree of confidence in our system when we run through all these tests. Our other test software is largely in Python, just because that's an easier test framework language to work with, but our product is almost 100% Rust. We're committed to the language, and we think it’s the way forward.

Drew: It seems to be a pattern that most newer companies doing embedded stuff seem to be adopting Rust.

Tom: I learned Rust when I started at this company. I was not a founder, but I was one of the original technical hires. I was a firmware and embedded engineer. I learned it, and obviously there are some little bumps at the beginning when you’re coming from C and C++. But, after about a month I was like I'm never coding in anything else ever again. This is unbelievable. The language is basically what someone who's worked with C++ their entire life and shot themselves in the foot a million times would create if you asked them to rewrite a language from the ground up to not do that. I've time after time seen people come to our company, start working with the language without having any Rust experience and then just become Rust evangelists. It’s just so much better than what they were working with before. You don't need any crazy frameworks. And, the system enforces itself. We’re big Clippy users here too, so there's sort of like a common style element that provides as well. It’s not that people aren't allowed their own style here and there, but it does enforce a unified way of thinking about using the elements of the language itself. It’s a meta style, and that helps speed the development process throughout an entire team. It's just a joy to work with, to be honest.

Drew: It seems to be the case for most teams that it’s kind of hard ramping. but then once they're past that, the momentum that the team is able to sustain is much greater. For example, refactors become easier because you change something in one spot and the compiler just sort of tells you everywhere else that needs to be updated

Tom: And that can be annoying at first when you're just trying to get something off the ground and you're like it’s making me do all this stuff but I just want to get something running. So, there's still the human tendency to want to get something done really quick. But, then you get through all the compiler nags and suddenly it works and it works perfectly. You kind of get the sense that at least for lower level functions when you hit the compile button and it compiles, it's probably going to work the way that you wanted it to.

Tom: Things get a little more complicated with firmware where you're doing direct memory access and register writes and everything. There's a little bit of unsafe that needs to happen there, but for application level code the way that I think about this is that it just moves all of the troubleshooting and figuring out what is busted to before you hit the compile button. It's a total rethinking of the way that I program. Then, you combine that with the error handling system that's native to Rust. It really makes you just think through what you're doing before you actually go and try to run it. After all that, you are rewarded with the fact that it works the way you intended to when you click the button. That just is a game changer once you get used to it.

Drew: You mentioned that you have to use unsafe in the firmware, and I've heard that a bunch of times from embedded people. I never really dug deeper into that. Why is that?

Tom: Well, this used to be my bread and butter. I used to be an FPGA and firmware programmer. Basically, when you're interacting with microcontrollers, you get a register list from the manufacturer as part of the hardware abstraction layer. So, if you write a certain register, it'll set these bits and it'll turn on this part of the machine. There's no way for the Rust compiler to know that it's actually going to work the way that the manual says. So, a lot of times when you're really minutely dealing with the hardware you have to just trust that it's going to do the thing that you want to do and be really careful with your error handling to bubble up errors for when things don't work the way that you expect them to. For that, you do have to use a little bit of unsafe. But, the challenge for embedded firmware development in Rust is to get above the harbor abstraction layer as soon as possible so you can then utilize the full features of the Rust language. If you can minimize the amount of work that you're doing underneath the HAL, then you get the full benefits of the system on top of it.

Drew: I'm so excited about Rust for embedded right now. I mentioned before that I feel like it's exploding. I'm seeing it everywhere. Obviously, the benefits are huge of having this language that's a lot safer that you can use to build things that are going to be in the real world and really need to be safe. Do you see any remaining blockers for further Rust adoption in that space? Is there anything that sticks out to you having worked at this intersection?

Tom: You're bringing up some good points here. Everyone who works in especially safety critical embedded development understands that this is the direction that things need to go. So, there's an industry zeitgeist that Rust adoption into critical safety standards is inevitable and that we're going to get there because everyone wants it to happen. The big roadblock is just that you need to do it enough times. There's a reason why safety critical and functional safety standards need to exist. You need to be very careful that the thing that you say the system is gonna do is actually the thing that the system does. There are some companies that are working in the background making this happen, like Ferrocene is working on like a formally proven rust compiler.

Tom: I think when we get a little bit further along the breakthrough will just need to be a killer case. I hate to put words in someone else's mouth here, but I believe VW did a little bit of a test of this a few years ago where they used Rust to go through a full safety certification of one of their components. Don't quote me on that. It might have been a different manufacturer. I can't remember. But, we're gonna need to see some big player use Rust for real and forge their way through a 26262 compliance process or some sort of aerospace compliance process. I can't remember the exact standard number. I think that'll be a waterfall once a “big boy” has done it and there's a proven path. Then, the standards will recognize that this is the way you can do it. You can kind of see this if you want to use C to write functionally safe code. You have to follow a set of standards. People usually use the MISRA C guide, which restricts a lot of the ways you can use the C language in order to make it work. One of the reasons everyone's so excited about Rust is because a lot of those restrictions are just built-in. They're just the rules that the Rust compiler and language follows from the beginning. So it's like, you have to handle all your edge cases upfront. You have to comply with the borrow checker’s rules. You can't just let null pointers hang out. There's a lot of these little things that are just style pointers in other safety languages, but are enforced by definition in the Rust standard. I think the pieces are all there. We just need to see it happen and get some industry acceptance, and then the gates will open and we'll be able to do it.

Drew: It feels like it really should be easier to comply with these standards using Rust, but it's just kind of the history. It’s almost a form of technical debt or something.

Tom: You could call it a well-earned conservatism on the safety side, right? You want to make sure that if you're going to accept a new methodology as part of your safety standard that you have some data that says it’s going to work. Working in such a safety-critical industry, I understand that. We'll get there, though. I think everyone wants to get there.

Drew: How does that rub up against your work? Are there things that you're doing that need to be certified?

Tom: Yeah, there's a number of ways to do this. I mentioned that different industries have certain standards that they use to prove functionally safe hardware and software. For instance, the ISO 26262 standard in the automotive industry is a pretty common one. So, if you want to make an embedded brake controller that is going to stop when you step on the pedal, you go through the 26262 process to prove that you've identified the functionally safe requirements, that you've designed the system to the required level of safety analysis and hazard analysis and documentation. You're writing code the right way. You've done the numerical analysis on the failure rates of the hardware that's involved. A lot of the software-facing standards are best practices and an engineering process. For example, you need to make sure that you have a change control process and that code is being reviewed and isn't just being updated willy-nilly in the field. Rust and our system are both designed around a lot of these from the beginning. The safety standards are not flexible in the sense that you can just do whatever you want, but if you can prove that you're following what it asks, you can get a little bit of leeway in exactly the method you use to do it.

Tom: So yeah, there's a little bit of friction for us in proving that we are hitting all of the required elements of the safety plan in a new language like Rust where it's not as accepted. We'd like to get to the point where Rust is accepted enough and the compilers are formally proven enough that you can just rely on the guarantees and say, hey, well, we built it in Rust, therefore you don't have to worry about it. But, right now we have to go through the process of actually proving it ourselves and that does slow us down a little bit. But, we can't be in this industry without proving functional safety. So, we are committed to the process and we're going to take as long as it takes to get it done and hopefully Rust is accepted in the meantime. Then, our next generation of vehicles will be even faster to get through the process.

Drew: I did one of these interviews with a company called Sonair. They're building an ultrasound sensor for robots, though it could be used for multiple applications. They're going through the certification process with Rust, and it was just very interesting to hear what that’s like. It sounded very hard. He was describing how they’re basically trying to get a certified compiler, which I think is the Ferrocene work you mentioned. Then, he said that he thought if they could get the standard library also certified they can just kind of build up the rest on their own.

Tom: There are a lot of companies in this space. Shout out to Pictorus for doing this on the MATLAB Simulink emulation side. There's a few others that I'm probably not mentioning, but yeah there's a lot of people invested in this and invested in making it easier to pick up the tools and run with them. I think we're going to get there in the next few years.

Drew: Yeah, it'll just take some work. With these interviews, my goal is always to kind of shed light on companies that hire Rust engineers. So, as we're winding down, I want to ask some questions about what it's like to work in engineering at Parallel. Could you tell me about a really interesting technical challenge your team had to solve recently?

Tom: Yeah, I mean, we're a hardware company, right? A lot of what we do and kind of our core competency is in software, but there's no way that our software works without the hardware working. So, we are a hands-on company. We have a lot of hardware here in the office, and we have test stands and HIL tables, and even a real vehicle that we can move around in the office. We also have a test site that's not too far away. We're always up at the test site. Our engineers are getting real time on the hardware platforms to test their code once it gets through all of the required software checks in our engineering process. We’re very hardware focused. And, I think that ends up being a really fun environment. I'm still a kid at heart. I love working with hardware. It's kind of fun that even with the smallest thing, like changing the way a certain behavior works with one of the vehicles in a platooning action, you can go up there and you drop it in the deployment and then you can move these 50,000 pound vehicles around and slam them together and break them apart. We have an engineering UI that allows us to do low-level moves of the vehicles. That's really fun. So, we have a lot of ways for the engineers to get really in touch with the hardware.

Tom: In terms of technical challenges, I mean they’re happening all the time. Let me try to think of one that's particularly relevant right now.

Tom: We have cameras that stream live video off the vehicle. And, we rely on a number of technologies in order to get that video link off of the vehicle and back to our central servers to distribute it out to the platforms that consume it. We rely mostly on commercial LTE providers and on satellite links. Anyone who's worked in this space knows that this is not a solved problem. Getting low latency, high quality streaming video from a mobile platform out in the field is very difficult to do. It's easy to get it working poorly, but it’s very difficult to get it working reliably enough to move a very large vehicle. This is work that we're constantly doing. So, we have a number of innovative solutions to this to both utilize commercially available networks and also cover dead zones in the networks along our routes so that our vehicles can get out there and have constant connectivity. Without going into details of all the challenges we're solving, that's a fun problem. You’re out there trying different technologies, different radio technologies, different video streaming technologies, and live gathering metrics to make sure that we're making improvements in our latencies and in our quality.

Tom: We also get feedback from the real operators. You get people that are actually using these things day to day and you get to deploy a change and gather feedback from the users. Did this actually make your job easier or not? You get that tight feedback loop that is really validating.

Drew: That's all very cool. I certainly smiled when you were talking about going and testing your code and actually moving around these big vehicles. Sounds pretty fun.

Tom: Yeah, it's definitely the most metal I've ever moved with a code change, that's for sure.

Drew: That's a great phrase. I guess another thing that would be good to ask about is employees. You've probably hired a good number of people at this point and seen people come and go. What do you think are big predictors of whether or not someone's going to be successful at Parallel?

Tom: We do hire a lot of people who are passionate about Rust. I always spring for it if I see Rust passion on a resume. That goes right to the top of my stack because it's my personal opinion that people who love Rust tend to be really good programmers and tend to think about things in a way that is helpful to solve real world problems. So, that's number one. And, a lot of our employees are here because they want to work with Rust on a real world problem. Those employees are definitely the most successful just because they know the language and they can jump right in, but also because they have the mentality of what actually makes code reliable and what makes it work.

Tom: In general with any hard tech company or when you're interfacing with things in the real world, the mentality's a little bit different than working on things that are more in the web space. When a web app crashes, you can reload it. There might be some externalities or some effects of that web app crashing, but generally people don't die from TikTok not loading fast enough or something like that. So, there's a little bit of a mentality shift when you come over to the hard tech space. Stuff has to work, and there's no excuses. And, it can’t just work empirically. You have to know it's gonna work before you go test it. That testing upfront mentality just jives right with the Rust philosophy. You're going to do everything ahead of time and prove that it works before. Employees that come into Parallel and have that mindset, that have worked with hardware before, and who know what it takes to make things work in the real world and can't just accept restarting the system as a solution are what we look for. That's pretty critical for being successful. We have a track record of people coming in that have done really well with that.

Drew: You mentioned at the very beginning of the interview that Parallel has some SpaceX heritage. The Elon family of companies have a hardcore reputation. Is anybody sleeping on the floor at Parallel?

Tom: No! (laughing) The way that I like to phrase this is that we strive to import the positive elements of that SpaceX culture. I love SpaceX. I cheer for them at every launch. I really relish the time that I spent there. One of the things that we do carry with us is a radical ownership culture, which is very big at SpaceX. One of the reasons they're so successful is that they empower individual employees to own the outcomes of their projects from very early on in their time at the company and even in their career. We really think that's the best way. You give an engineer full control over the thing that they're working on and they can make decisions. With really big decisions of course you want to write it out and make sure everyone agrees. But, giving engineers a lot of autonomy in how they solve problems really enables the engineer to go find the right solutions, to act quickly, and to kind of be their own advocate. When it comes time for that product to work or for that feature to be demonstrated, it's their job. It's their responsibility to make sure it works. I think that's exhilarating. It can be stressful at times for sure. When crunch times happen, we do have to put in a little bit of extra hours here. When we're deployed, we need to be on call. We need to make sure that our vehicles that are out in the field are supported properly and that we're making changes that are responsible and meet all the safety requirements. But, I wouldn't say that we're telling people that they've got to sleep on the floor. We want to make sure that people aren't burning out, but when crunch time happens, you've got to pick it up a little bit and make sure that you can meet deadlines and support the field teams. The nice thing too is that a lot of our engineers have spent time in the field, so they know what it's like to be on the other end of the phone when something breaks or doesn't work the way it's supposed to. So, there's a lot of respect for making sure that you put the extra effort in when it counts.

Drew: That sounds fair. I just wanted to glean a sense of the work life balance. And, I think there's such an appetite for people to work on stuff like this- real stuff that's going to make a real difference in the real world. So, even as you talk about having to show up at crunch time, I think a lot of people want that.

Tom: Yeah, I wouldn't have it any other way. I'm kind of addicted to the startup way of life. I think there's a lot of cultural alignment that comes with that, especially with that ownership culture. You kind of look to your left and look to your right and realize, I'm the person that needs to solve this problem right now. I have to step up. I have to make sure it happens. I have to make sure that I can get this done on time and it's gonna work correctly. And, if it doesn't work correctly I know quickly how to resolve it. We've got a pretty positive culture around that right now, and people are excited to make things happen in the real world. Who wouldn't get excited to go move trains around with their software? It lends itself to that kind of excitement.

Drew: My last question is how would you distill the vibe of the people that work at Parallel?

Tom: We are a small team. I would sometimes describe it like a pirate ship where it's sort of a motley crew of very motivated characters. We all have our individual specialties, but we are also very used to pulling together and making magic happen. Whether it's hardware or software, we’re pulling rabbits out of hats and putting a very small amount of resources together to do really big things. And, we’re having a lot of fun while we're doing it. We are going to stay lean, and we're going to stay scrappy. So, we don't have plans to massively scale up the team anytime soon. Really what I'm looking for in new hires is a willingness to do a lot with a little, to work on things that are gonna affect the planet in a positive way, and to be motivated by all that in such a way that they can come together with this crew of characters to make some trains move around.

Drew: I think that's a good place to stop. Thanks, Tom.

Tom: No problem, it's been a pleasure.