Currently we are expanding one of our products for a large container ship owner so we can import these loading condition files into the product for both long-term analysis and also short-term alerting. Once this project is complete, a fleet superintendent will be able to set up alerts so that they get a push notification when we calculate that a load is risky or unbalanced. Hopefully this sort of thing will add an extra layer of validation before a ship sails from port.
Fortunately, for our customer, they build quite robust ships and do not skimp on cost. But due to the economics of shipping right now, a number of owners in the world cut costs wherever they can. This includes reducing the amount of steel used in critical support beams which could increase the risk of a vessel breaking in half [1]. Sadly this makes a hack like this even more risky, because the combination of marginal errors, bad weather and a frail ship could be more than enough to cause a big problem.
It's possible to cut the ship in half in port if the ship is loaded or unloaded in the wrong order. Each cargo hold must be filled evenly. Filling one hold first and leaving others empty bends the ship and breaks it.
I have seen a picture of broken bulk carrier in the Rotterdam harbor when loadmaster made an error.
Yes that can definitely happen. I went scuba diving on the Eurobulker X shipwreck in Greece. It was a bulk freighter that broke amidship and sank because the three holds weren't loaded evenly. (Some of the locals suspect it was done intentionally as insurance fraud.)
<Chuckle> -- with all of the containerization metaphors these days I assumed "container ships" was just some logical collection of containers. Heck, the docker logo uses these same shipping containers.
Fiction was inspired by fact for a change. ;) IRL 30 years ago, I remember getting loaned a warez copy of something from another kid at school containing the Michelangelo DOS bootsector virus. No more trading with that fool. That was back in the day when McAfee and Norton were the only usable DOS CLI/TUI virus scanners.
I don't have enough domain knowledge to provide a reality check, but wouldn't the ship or loading staff notice something isn't correct and stop the load? It's not like these systems have never had bugs and should be trusted wholeheartedly.
Pentest companies like to put up bogeymen to scare people into using their services.
Simply making it so that heavy containers go high and light ones low would likely not affect the ship until it it hits bad weather. The load is still centered on the ship at the dock, so it would not list. The total weight is still correct, so the ship is the right depth in the water.
However, the loading crew might not even notice a modest list. The EL FARO, while loading before its fatal trip into a hurricane, had a bit of a list. The loading crew didn’t notice, but someone else at the port took a photo[1], emailed it to the relevant people, and got it fixed.
Isn't there a watch on the ship to monitor the key information at pretty much any time? I think most ships over 30 meters or so have constant staff there.
Plus there must be a checklist when departing, ship balance info, etc.
The Saewol used a tactic of overloading with cargo and compensating by emptying ballast tanks so that the hull depth would be the same for inspection. There's already a need to overcome malicious actors.
They might, but at the same time, loading / unloading is a high pressure, high speed and stressful job; when you've got 5000 containers aboard, you can't expect most people to keep track of the weight distribution themselves. Of course I'm sure the ship would start to list and the ballast / balance system give alerts at some point, but maybe it would be too late by then.
The article also talks about more subtle things like changing the position of containers; wouldn't cause safety issues, would be hard to detect (gotta trust the software), but would cause delays and (by extension) costs.
Sounds like the "easy" answer is to use software from a different vendor to check the output of the CSV file. Calculating center of mass is straightforward, and much easier than solving the problem of container placement.
Normally at least two different companies already look at it. One, the container shipping company creates a plan where the containers should go (stowage plan). They then send it to the terminal who will look at it again.
The article talks about USB/floppy disks and suggests they are 1) used 2) insecure 3) easily can be attacked. This without ever explaining how. They also suggest that the someone on the vessel themselves creates this stowage plan. This is utterly strange. Stowage plans aren't normally made by people on the vessel for the companies I know.
Loads of details in this article make no sense at all. That said, container shipping should be hugely improved is true :-P The main bit is true as well: if you mess up the stowage plan you'd easily cause a lot of damage: yeah. Plus there's probably enough ways to do this.
More and more ports are going automated. Since the containers are uniform in size the CV required is pretty basic and very fast. Most container ships are only in port for a few hours and they can load and unload a lot of containers. I think by the time anyone realizes things are off it could be too late.
> Most container ships are only in port for a few hours
That's not true at all. The container ships are getting bigger, but port productivity hasn't kept up at all. You can put more cranes on the vessel if it's longer, but lately it's often getting wider, not longer (=which would allow additional cranes to be used).
Containers ships are often in a port for a really long time, can be days.
That said, containers toppling over has happened in the past, including capsized feeders (small container vessels).
Often the cause is not hackers, just wrong data given by shippers. Basically saying that a container is heavy while it is light weight and vice versa. That's why every container loaded now needs their weight to be certified. http://www.imo.org/en/MediaCentre/HotTopics/container/Pages/...
Interestingly enough, up to that new requirement loads of containers could get on a container vessel without ever really knowing what their real weight was.
That Husky Racer incident is interesting - particularly because correct weight data was eventually given by the shippers, but that data didn't propagate through Maersk's systems. Wonder if a dependence on removable media had anything to do with it.
> The MAIB preliminary examination of the accident found that the inaccurate container weights were on the loading plan because of a system shortcoming which did not update the operations department when the shipper provided more accurate contents details to the carrier.
> The Deputy Chief Inspector of Marine Accidents has written to Maersk Line advising that its operations department should use the most accurate container weights and ship stability data available. [1]
> Wonder if a dependence on removable media had anything to do with it.
Not at all. It's better to ignore that bit out of the article.
You actually have loads of parties giving a weight of a container. E.g. when the booking is made, then when they give the shipping instructions, then later maybe from a trucker when it's delivered to the terminal, lastly possibly given by the terminal itself (though most don't have it).
What might have occurred that instead of having a sane design whereby you just update a weight of a container it works by having multiple different fields for these things. This as not always you can trust some input. E.g. weight given by a trucker in Germany might be ok, but it might be utter xxx in another country.
I find it interesting that it was just an advice though. I'd prefer if they would have more ability to force changes and also across companies.
I live by the Port of Miami and that's not what I'm observing. It's a different ship I see on my daily commute. The ship I see at 9AM isn't the same at 6PM. So I stand by my statement that they move them fast. It might not be the case everywhere, at the busiest ports (in my experience Miami and Savannah) they want you done and out.
I work at a big container shipping company and I'm highly certain that you're mistaken. This based on thousands of calls as well as insight into terminal productivity data.
The port probably makes a difference. Ships stopping in Miami may be on a mulitpojt route and not have as many containers to unload and load than in long beach where it's more likely to be a back and forth route between US and (pick an Asian country), in which case essentially all containers on board will be unloaded and others would be loaded.
This is probably the case. Port Miami is on an tiny island and space is a premium. Ships also bunker. They might be "in port" for many days but they'll be anchored in designated areas. Port charges add up quickly.
Are you saying that the automation of cranes is faster than that of humans and results in a much shorter load/unload time? I would think the unload time would be dominated by the time for the crane to move the container physically rather than the CV problem of identifying a container. Automation could just result in labor cost savings rather than decrease load/unload time significantly.
If load/unload time were a big $$ problem, I can imagine one could design a system which effectively threw containers on and off the ship. ie. acceleration at 1G upwards on the way out, and freefall on the way in.
The same acceleration rates can be used for the automated clamps which lock onto the corners of the containers for movement.
Assuming a dockside + ship is 100 yards wide, a one second lock/unlock time for clamps, that should work out at 14 seconds per container. Assume we have a grid of cranes over the ship, able to pick up every container on top at once.
Assume the worst-case complete unload of the whole ships capacity (10,000 40 ft containers on the largest vessels), and reload of another complete load.
That comes out as 8 minutes!
Current loading times are multiple hours for even a partial unload of a much smaller ship. That tells me that there isn't enough $$$ involved to get serious engineering efforts to make it quicker.
In a port there the big ship to shore cranes and there are the smaller mobile gantry cranes. The smaller gantry cranes look like this [0] and 1 operator may be controlling half dozen simultaneously. There are huge cost savings involved because 1 person can move multiple containers, simultaneously.
These systems aren't cheap and it requires more skill closer to IT than your typical stevedore. So it can take years to recoup any savings in labor. Recouping time costs are almost immediate.
This is essentially what capsized the Saewol and killed hundreds of people.
It can be detected with empirical tests however. Almost every ship should right itself from a roll within ten seconds or so, so anyone with a stopwatch can detect misloading. There are monitors that measure this continuously as well.
At one point I was thinking of making a phone app for this, so that ferry passengers could check stability themselves.
Just to make sure I understand - are you saying that on a properly loaded ship, no more than ten seconds should pass between the deck going out of level and then returning to level? Does it matter if it's rolling side to side, or front to back?
Also, there's random motion that may look like roll when it's the sea surface that's showing the motion, so there are methods to filter that out and extract the actual rolling period.
Isn't there verifying load software built in on the dock? The crane lifts the box so it knows how much it weighs and it also knows where it put it. How is there not a 3D map of load distribution at the time the ship is loaded and before it sails?
It's interesting that the lack of this data was one of the failure points for Target's $4.4 billion USD Canadian expansion that ended in failure. It's a really interesting story [0]
> A team assigned to investigate the problem discovered an astounding number of errors. Product dimensions would be in inches, not centimetres or entered in the wrong order: width by height by length, instead of, say, length by width by height. Sometimes the wrong currency was used. Item descriptions were vague. Important information was missing. There were myriad typos. “You name it, it was wrong,” says a former employee. “It was a disaster.”
> Getting the details from suppliers largely fell on the young merchandising assistants. In the industry, information from vendors is notoriously unreliable, but merchandising assistants were often not experienced enough to challenge vendors on the accuracy of the product information they provided.
> The investigative team estimated information in the system was accurate about 30% of the time.
Quality of data is probably one of the saddest reasons why systems can be unreliable and bad decisions can be easily made in many organizations that aren't technically oriented. It's the biggest reason why I think data analysis logic and/or data modeling should somehow be incorporated into public high school curriculum plans. Systems will work better when the people who use them have a better appreciation for caring about the quality of their data and also the nature of data relationships in databases. This is completely separate from the concepts taught in programming classes, but of course related.
Better understanding of the nature of data -> better data -> more useful systems -> better business decisions -> better business performance. I see too many people get frustrated and make poor decisions because they are unable to comprehend the nature of data. Productivity would soar if people understood how to model and take care of data. It's only one aspect of a complex issue, of course. Good UI, system uptime reliability, and so many other things also matter for whether an organization gets everything it really needs from a system.
Thank you for posting the story. I hadn't heard about it previously. Having spent a couple years at various businesses, getting accurate data and understanding exactly what you're looking at is more of a pain than I would have ever imagined.
There was a blogpost [1] a while back from a guy who runs a candy subscription business. He goes into some approaches and issues with this and also mentions a python package called pyShipping [2] which has an existing implementation using some heuristics to speed up the calculations.
I've built something like this for a client that manages shipping containers (like those in the article). There are a number of applications on the market which deal with this problem, but the pisk/packing bits tend to be part of much larger systems (ERP, WMS, and other fulfillment solutions) rather than standalone and those solutions can be a bit pricey. This is why we decided to build a solution into an existing enterprise package rather than buy something. I think the problem you're asking about is so narrow, the motivation for developing something that stands on its own is not really there... certainly on a commercial basis.
Solving the knapsack problem for practical instances is actually really easy. (That's a general pattern with NP hard problem: most of them are easy in practice.)
I struggled with this for many years, trying to get accurate shipping quotes for furniture and other items that get charged by 'volumetric weight'. I got stuck at the combinatorial explosion of currencies, location 'zones', taxes, product setup data inconsistencies and what happens if not all items can be shipped together.
I spoke to a specialist developer that had been in the game longer than myself and she said 'nope, it can't be done that easily in real world situations' and proceeded to go all computer-science on me. If you are in ecommerce you might know of Karen from WebShopApps. If anyone can get you a best solution it is her team.
It's often integrated into application specific software - for example, I worked on metal center management software which performed load and route planning for steel warehouse delivery trailers. To another poster's point, it's a twist on 3D bin packing with lots of custom heuristic possibilities as well as an obvious application for a genetic solver.
Currently we are expanding one of our products for a large container ship owner so we can import these loading condition files into the product for both long-term analysis and also short-term alerting. Once this project is complete, a fleet superintendent will be able to set up alerts so that they get a push notification when we calculate that a load is risky or unbalanced. Hopefully this sort of thing will add an extra layer of validation before a ship sails from port.
Fortunately, for our customer, they build quite robust ships and do not skimp on cost. But due to the economics of shipping right now, a number of owners in the world cut costs wherever they can. This includes reducing the amount of steel used in critical support beams which could increase the risk of a vessel breaking in half [1]. Sadly this makes a hack like this even more risky, because the combination of marginal errors, bad weather and a frail ship could be more than enough to cause a big problem.
[1] https://en.wikipedia.org/wiki/MOL_Comfort