Mainframe-y System-on-Chips

In the 1970's, an application written for a 64-bit computer that maintained an 8 terabyte database would have been viewed as a major government project. PCs have had this capacity for quite some time. It’s now filtering down to Raspberry Pi's and similarly sized embedded devices. Some of the publicly visible latency in these projects is evident from announcements made in 2023Q1 that didn’t ship until 2023Q4. Others become evident after-the-fact, as the Raspberry Pi organization describes the Pi 5 as taking several years and $25 million to develop. There are other ‘pending’ devices not available in anything more than sample quantities - months after being announced by their vendors.

Assuming that the US has 250 million automobiles in use, 1 terabyte divided by 250 million is 4000 bytes per car - certainly enough room to store the vehicle make and model, color, model year, state registration, tag number, VIN number, owner’s name, insurance status, and so forth. A Raspberry Pi 5 is already overkill for any application limited to one state.

This raises the question of ‘why make such efforts?’. Who is going to hire a team of developers headed by a project manager to develop a system for a $100 device? The $100 (or so) comes from the maxed out memory, ‘hat’ board for PCI, and the SSD. Walking into the ‘data center’, one might find this machine hanging off the wall-wart USB cable by the coffee-maker.

Hitching a Ride

Given that the Pi 5 can have enough storage to model the entire North American rail network, it becomes interesting think of how freight cars might be augmented to maximize the time value of their freight. Assume a hypothetical device attached to every freight car in the network which keeps track of what it contains, its state of repair, its location, and its destination if it is loaded with freight and underway.

One of the problems that has been emerging with railroads recently is sporadic inspections, so freight cars are derailing, often due to bad bearings. If a car 'knows' what stretch of track it is on then it should know what its orientation should be, and if it drifting off course it could immediately raise an alarm that would register with the train crew, as well as the railroad’s central dispatch. This might trigger an emergency stop earlier than might otherwise happen.

Many cars are owned by leasing companies. In any case cars carry freight that belongs to the shipper, not the the carrier. There may be some ability at this point to reroute-in-transit, meaning that if the freight owner wants to change the destination while the freight is in transit, they can notify the railroad, who would then shuttle the car onto the appropriate train at the classification yard. The more valuable the freight, the more likely this is to be used. Whether this makes sense for cars full of coal or pulp wood remains to be seen.

‘Reefers’ (refrigerated cars) are usually carrying frozen food. Derailments or other delays may affect the market value of the contents. In such circumstances, a delayed shipment might justify delivery to an altered destination, one far closer to the present freight location. If some wreck occurs in Nebraska, a reefer headed to New York may be waiting for the tracks to clear. Some shipment elsewhere in the country is rerouted to New York to 'make up' for the delay. The car in Nebraska is then sent to the unfilled shipment that was left when the other care was rerouted, perhaps to Chicago or St. Louis.

Another situation can result from changing commodity values, particularly wheat, ethanol, or liquified petroleum gas (LPG). A shipping disturbance in the Black Sea might justify rerouting wheat from mills in the Midwest to ports on the Great Lakes or the Gulf Coast. A refinery shutdown would necessitate redirecting ethanol to a different tank farm. A severe weather event might significantly increase the value of LPG in an area of the country experiencing a freeze. And so forth.

If a car has a route map and a current train schedule in its database, it might be possible to instruct the car to go to a different terminal, and leave it up to the computer in the car to figure out the most efficient route, and forward that to the dispatcher. Given it’s ‘knowledge’ of scheduled freight operations in the relative time frame and the substantial processing power of the on-board computer, this isn't an excessive demand.

Exponential Expectations

Much of this data already exists. At present, there's no reason for it to reside ‘on-board’, either on individual freight cars or with the train crew. Such information is typically maintained in the dispatch centers, and individual shippers keep track of whatever they think they need to know.

The development work, this being the case, would involve migrating already available data to the onboard computer, then coding a new application for the cars present disposition and intended use. A lot of freight cars sit for months, or even years, doing nothing. Given that it is now possible to link these via satellite, they can be updated regardless of whether they are within range of railroad wireless data transmission towers or conventional cell phone exchanges.

If this is generalized to OTR trailers, motor homes, boats, shipping containers, etc. it becomes evident that a lot of work will be needed to deploy these to begin with, code their respective applications, synchronize their data, replace and repair broken devices, and so forth. More than likely, applications like this might sop up the ‘excess’ IT workforce that was let go from the ‘big tech’ companies. Even if this particular collection of applications doesn’t make sense, it illustrates what is likely to happen as enterprises come to terms with the processing power, storage capacity, and data communication infrastructure that has recently shown up in the embedded device market.