Introduction
I have been following the cube storage market for some time. It is remarkable how many variations of the original AutoStore concept have emerged in recent years, some with very interesting approaches that address AutoStore’s limitations. In this article, I would like to introduce and review another new entrant in the dynamic cube storage (high density storage) segment, Volume Dive from Volume Lagersysteme GmbH, and compare it with the industry’s benchmark AutoStore.
After a few people told me about the company within a short period of time, I got in touch with the founder and CEO Mikhail Voloskov and was able to talk to him for an hour. Besides the technical facts and features, what I am about to present to you is of course my personal view.
Volume Lagersysteme was founded in 2017 in Dresden, Germany. They launched a pallet shuttle system (called Volume Wave), but shortly thereafter were approached by a (former) Q-Commerce Giant to develop a solution to meet Q-Commerce’s needs. And I’m glad I didn’t know Mikhail back then, because I would have advised him not to spend a dime on developing a solution for Q-Commerce, and perhaps he wouldn’t have come up with this beautiful concept. Not only was it obvious to me that most, if not all, Q-Commerce companies would go bust and the industry would cease to exist because the business model was flawed and doomed to failure, but also that they would actually need to square the circle for automation-assisted picking. My prediction about the economic viability of the Q-Commerce industry was correct, by the way (that was easy, though obviously not for venture capital firms). As for squaring the circle, the inherent trade-off between efficiency and speed makes it nearly impossible to find a solution that is affordable, space efficient, installs quickly, keeps pickers busy (and not waiting), and allows for short lead times. Now, I don’t know about “affordable” because we have not talked about money, and at this point it’s likely that the company doesn’t really know its actual cost for the system and may still be in the process of finding the right price to sell it at. Mikhail disagrees with me in this point, but pretty much everybody gets the pricing wrong in the beginning, partly because they get their true cost wrong, especially when they are new to the project business. But they do check a lot of other boxes. Let’s get right to it!
Volume Dive: The Concept
Volume Dive is an automated cube storage solution, and as with several other systems in this segment (e.g., Ocado, Gridstore, Gebhardt Upstream), the storage and retrieval process closely resembles AutoStore: hive robots move on a grid and store or retrieve bins vertically. That’s the simple core idea on which AutoStore was built and which AutoStore, dare I say it, implements perfectly. Now, AutoStore has a number of inherent systemic limitations or weaknesses. And although this article is not mainly about AutoStore, but about Volume Dive, it is helpful to briefly discuss AutoStore’s limitations in order to fully understand and appreciate Volume Dive.
Weaknesses and Limitations of AutoStore
AutoStore benefits from mature technology and its reliability in terms of uptime is most likely unmatched in the warehouse automation industry. Most of its weaknesses are by design, not accidental; they are a function of the concept, not a failure of the company. And let me add that I am a fan of the system and the company for a variety of reasons (including my fondness for the west coast of Norway, where AutoStore is based). However, since I am independent and want to remain so, I take the liberty of pointing out where I see clear weaknesses and limitations of AutoStore, despite my sympathy. Also, I do quite a bit of AutoStore consulting, and so I speak with many companies that have implemented or are considering implementing AutoStore. The most common weaknesses and limitations of AutoStore are
- High demands on the floor slab (which often requires grinding the floor slab in brownfield projects)
- High sensitivity to the shape of the ABC distribution
- Strict requirements for use of AutoStore’s own storage bin and strict limitations on use of the bin outside the grid (with few exceptions, the bin never leaves the AutoStore system)
- Relatively low system height (less than 7 m), leaving plenty of empty space above in most standard warehouses
- Hive robots and gripper units have a specific orientation (north or south orientation), and depending on their orientation, they may or may not access stacks at the edge of the cube
- System performance can drop off sharply when orders contain many orderlines since there are practical limits to how many bins you can dig out in advance for picking
- Recommended order lead time of about 30 minutes (though often less is needed in practice)
- Severely limited access to your own data. Your AutoStore system is a black box.
It becomes all the more interesting when a new system is built on the same basic concept, but addresses some of the weaknesses to offer a “better version of AutoStore”.
Design Features of Volume Dive
Now that we have talked about some of AutoStore’s limitations, we can talk about the features of Dive, which happens to address quite a few of them.
First of all, Dive is vertically divided instead of having high stacks of bins (for example, AutoStore can store up to 24 bins with 220 mm height). This is because the entire grid is made up of modules of “Speed Racks“ that are attached to each other both horizontally and vertically. Each Speed Rack has a certain number of storage positions and, most importantly, – a driving level for the hive robots (called “Snappers“). Accordingly, there are no tall, uninterrupted stacks of bins from top to bottom; instead, the stacks are divided into piles of three (Dive S) or five (Dive M) bins. This means that 33% and 20% of all bins are directly accessible for Dive S and Dive M, respectively. And, of course, this setup has a big impact on the sensitivity of the system to the shape of the ABC distribution. It is much less sensitive and its performance will degrade much less with flatter distributions. Considering that the most common problem I see with AutoStore installations is poor system performance with waiting times at pick stations (“ports”, in AutoStore lingo), I think this is the most important difference and advantage of Volume Dive over AutoStore (to be clear, though, not all AutoStore installations have waiting times at pick stations. Most AutoStore customers are happy). After all, even if an AutoStore system has been perfectly planned based on all the information available during the planning phase, the system is prone to „wrong use“. „Wrong use“ usually means that the wrong inventory is brought into the system. With Dive, this is much less of a problem. Another example of AutoStore “wrong use“ is when an insufficient order pool is made available to the system too late, because then the robots may not have enough time to dig out bins from lower levels before picking, resulting in waiting times at the picking stations. Again, Dive would have much less of a problem as there is much less digging to be done due to the shorter stacks. Of course, other automated storage and retrieval systems can be used in the wrong way, too. I have seen quite useless Miniload and shuttle installations. But the point here is that conceptually certain things that frequently go wrong in AutoStore installations will not affect Dive to a similar extent.
Having intermediate driving levels for hive robots naturally reduces the storage density in the cube. To compensate, the Dive can be built higher – up to 14 m, which is more than twice the height of the AutoStore and even slightly taller than Jungheinrich’s PowerCube. In cases where the system height is fully utilized, Dive has a higher density of storage bins per square meter of storage area than AutoStore. In cases where the height is lower than 14 m, the gap between AutoStore and Dive shrinks, and in systems with the same or lower height as AutoStore, the latter has a higher storage density. In any system with a height of less than 7 m (AutoStore claims 10 m), it is impossible to exceed AutoStore’s storage density, as the bins are stacked without any spacing.
Quick anecdote. In a Zoom lecture in the midst of the Covid lockdowns one winter evening in 2020, I was explaining various cube storage systems to my students. In the context of discussing AutoStore’s ABC sensitivity, a bright young lady, Magdalena Schnaus, asked if it would be possible to include multiple levels of robot travel, rather than just one level on top of the grid. I told her that I thought that would make sense. A few days later, I contacted the patent office at our college to inquire about the process for patent applications, because I thought that maybe we should work out the concept and file an application…. Well, that would have been nice. Anyway…
The fact that storage depth Is limited to three (Dive S) or five (Dive M) bins not only makes the system less sensitive to the shape of the ABC distribution, but also reduces the need to dig out bins in advance. AutoStore recommends a 30-minute lead time for picking, Dive does not require much time. To be clear, the middleware or WMS that would be feeding Dive’s material flow controller with retrieval orders should have a pool of orders, too, as does every AS/RS. But where less digging is required, the need to look ahead is somewhat lower. Even with stacks of five bins (Dive M), 20% of all bins are in direct access. With a standard ABC distribution, this would cover 80% of orderlines. So, the system is better suited for immediate order processing than a system with greater storage depth. This is no surprise, as the system was designed with Q-Commerce requirements in mind. And since the preparation of totes in advance is not required, or not to the same extent as with AutoStore, I would not expect the system performance to decrease when multiple orders with a large number of orderlines need to be picked.
It should be mentioned that the advantages of multiple drive levels also come with a necessary disadvantage. While in AutoStore all bots are on the same level, in Dive the capacity is split, not unlike Miniload systems with multiple aisles. So if the bots on one level are very busy, it does not help that the bots on another level have spare capacity. They cannot share the workload, they cannot help each other out. AutoStore’s (almost) complete roaming on the storage grid is a clear advantage for performance predictability and utilization. Volume Dive’s performance in terms of retrievals per hour can never come as close to the system’s technical dynamic capacity as AutoStore’s. Moreover, smart slotting becomes significantly more important for Dive, and smart slotting certainly is not simple.
Another notable feature is that Dive accepts a wide range of storage totes. There are no special Dive bins, in stark contrast to AutoStore’s approach. The website claims that even beverage crates (for the international readers: these are common in Germany, and possibly only in Germany) can be stored and retrieved. In my opinion, the greater freedom in terms of bin types is nice and can save a lot of money if suitable bins already are available. On the other hand, the process safety aspect is a bit worrisome. Perhaps more than a bit. Bins will bulge or break or otherwise change their physical properties. Of course, it is the responsibility of the system operator to ensure that only bins in suitable condition enter the system. But reputation doesn’t care so much about whose responsibility is what, and any malfunction will reflect on the system and the system provider. So I expect the requirements for storage bins to become more stringent once the first systems are up and running.
Dive’s gripper units can rotate 360°. This allows any robot to reach every storage bin stack in the grid. Again, this is a weakness of AutoStore – not a major one, but a minor drawback, since AutoStore’s hive robots come with a predetermined north or south orientation and the gripper unit cannot rotate. This requires robots with different orientations on the grid and results in a division of the effective available capacity for bin stacks at the edge of the grid.
The following table summarizes the limitations and weaknesses of AutoStore that Volume Dive addresses. It is clear that Volume gets a lot of things right conceptually.
| Limitations of AutoStore | Volume Dive’s Response |
| High evenness requirements on floor slab; floor slab rework frequently needed | Totes held by rack, hence lower floor slab requirements |
| ABC sensitivity | Lower stack height due to intermediate driving levels for hive robot |
| 30 min order lead time (recommended) | Shorter lead time necessary due to lower stack height |
| Drop in retrieval performance when orders contain many orderlines | Unlikely since bin preparation not needed |
| Cube height restricted to 5.950 mm (with bin height of 425 mm), else 5.400 mm | System height 14.000 mm (but with intermediate driving levels, hence lower density at same system height as AutoStore) |
| Robots and gripper unit installed in fixed orientation | Gripper unit can rotate, hence robot orientation does not matter |
Storage Bins
Dive can handle two different footprints of bins and their maximum weight (25 kg or 35 kg) depends on whether you use Dive S or Dive M, two different variants of the “Snapper” robot. The height of the bins is not fixed, as there is some flexibility here; of course, you can only use one bin height in a given system.
The footprint of the bins is 600 mm x 400 mm or 300 mm x 400 mm. These dimensions are quite common. However, considering that many packaged products have outer dimensions of 300 mm x 200 mm or 400 mm x 300 mm, it would have made more sense to expand the bin size to accommodate these products. AutoStore (as well as Jungheinrich and Intellistore) has taken this into account and has inner horizontal bin dimensions of 603 mm x 403 mm.
Energy Concept and Management
Volume Dive is powered by lithium iron phosphate batteries. The charging stations are integrated into a “Tech Module” located on one side of the cube. This module also includes the maintenance stations. The bots automatically move to the charging station as soon as they cross the minimum battery level of 20% – or even before that to be ready for peak times. In any case, they are not available for operations for a certain period of time. That’s the same for AutoStore’s R5 robots. In contrast, AutoStore’s Black Line robot B1 can swap batteries, making it available almost continuously.
I do not have any information about Dive’s expected energy consumption. AutoStore prides itself on its high energy efficiency. To the extent that the low energy consumption is due to system design, Dive should not be much different. To the extent that low energy consumption is due to sophisticated fine-tuning, AutoStore certainly has an advantage as they have more mature technology. But as I said, I don’t have numbers for Dive and it will take a few projects before reliable numbers can be communicated.
Maintenance and Trouble Shooting
One of the most common questions that arises when robots travel under a grid (as with PowerCube), through a grid (as with Attabotics), or between storage levels (as with Dive) concerns troubleshooting: How do you get the robot out if it’s stuck? Clearly, robots will visit the “Tech Modules“ for regular maintenance. But that’s not an option when a robot is unexpectedly put out of service. We haven’t discussed this point yet, but the options are obvious and limited: Someone crawls in, somehow. Accessing robots is not a big deal in an AutoStore system since moving atop the grid is clearly more convenient than under or trough a grid.
Fire Safety Concept
When we talk about energy, we also have to talk about fire safety. Yes, that fun topic that everyone in the cube storage market gets so excited about.
Volume plans for sprinklering on all driving levels. Oxyreduct is not being considered at this time. This is a sharp contract to Jungheinrich’s PowerCube, which comes with Oxyreduct “out of the box” (literally). The sprinkler pipes will make the concept of “expansion on the go” (see below) more complicated in practice than Volume might anticipate, however.
You may be interested in my article on fire safety systems, which includes some reflections on oxygen reduction systems.
Target Market and Target System Size
In our conversation, Mikhail highlighted brownfields as target systems and emphasized Dive’s flexibility to meet brownfield requirements. One aspect is certainly the lower floor slab requirements compared to AutoStore. Another aspect, according to Mikhail, is that the system is designed for “expansion on the go” with pre-assembled modules that attach to each other both vertically and horizontally. This focus on expandability also makes clear why oxygen reduction fire protection systems are not an option. They must be closed, even sealed, and therefore do not lend themselves to easy expansion. However, quick expansion is not fun with sprinkler systems, either. It is one thing to simply “click“ in” a new module; it is another thing to connect it to the sprinkler system. It is quite another thing to adjust the capacity of the sprinkler system (pressure, tank size…) to accommodate the new system size. So, in reality, the supposedly simple expansion will be much more complicated. However, this does not limit the attractiveness of brownfields as a target market.
When we talked about system size, Mikhail made an interesting remark. He said that very large systems are unlikely to be brownfields. Therefore, he believes that the system’s selling point of high flexibility will be most attractive in the range of up to 3.000 bins/h of dynamic capacity and 15.000 – 25.000 thousand bin locations of static capacity.
Software Control
Dive is supplied only with a material flow controller. The system does not really care about what is in the bins, whether the bins are subdivided or not, or whether they need replenishment. All the system does is retrieve the bins as instructed by the superordinate warehouse management system (WMS) and then put them back into storage. There is a built-in optimization algorithm that can move the totes to a higher (= faster access) storage position based on predicted demand (they call it “AI”,“ but we did not get into the details). But that’s about it.
AutoStore, on the other hand, comes with a middleware that was implemented with a great variety of different WMS before, which makes for a more worry-free package.
Now, it is a legitimate decision to limit the scope of the software to a material flow controller; after all, you need to pick your battles. However, I believe this will be a major limitation in practice, given the target market, which consists of small to medium-sized brownfield projects. While many (though certainly not all) warehouse operators have a decent WMS, it is unlikely that in most cases this WMS will have a warehouse control layer that includes adequate logic for, say, the sequence in which bins are retrieved (e.g., in case of the existence of different crash classes) or the arrangement of products in compartmentalized bins. Expecting the customer to bring this IT scope is most likely going to be a dealbreaker on many projects, especially if the alternative is the worry-free, mature, and most importantly, complete AutoStore option. Yes, AutoStore does not provide a WMS, it provides middleware, but that middleware makes decisions such as creating an optimized retrieval sequence, after receiving the order queue from the WMS. Also, some of the AutoStore distributors have their own WMS (Swisslog, Dematic…) that they can bring into the solution. To the extent that Dive is offered through integrators with a proper warehouse control system (WCS) that interfaces with Volume’s material flow controller, this limitation is eliminated. It is primarily or exclusively an issue when Volume works directly with customers.
Conclusion
I’m honestly pretty impressed with Volume’s Dive. The concept is great, and it actually addresses several pain points of AutoStore. Unlike Intellistore’s cube storage solution, which also includes some good ideas, Volume Dive’s technical complexity seems to be much lower – only one robot is needed instead of three.
However, there are also some drawbacks, doubts and limitations. The flexibility in terms of storage bins is great, but may pose a risk to process safety. Eventually, they will have to become more restrictive and at least recommend certain tested and approved standard bins. This is not a big deal, though.
Splitting robot capacity into multiple levels is a good approach to overcoming AutoStore’s sometimes painful ABC sensitivity. At the same time, it creates a new constraint that AutoStore does not have, because some robots can be overloaded with transport jobs while others are idle, which should never happen in a properly functioning AutoStore system. This means that dynamic capacity utilization can be much higher in AutoStore, while Volume Dive must be planned with plenty of buffer capacity to avoid waiting time for operators at picking stations.
It’s a smart move to define brownfields as a target market, because there are many warehouses that aren’t exactly suitable for other types of automation or that need to have the floor slab ground down to make them fit for AutoStore. Customers accept it because there often are only few or no viable alternatives to AutoStore, but it’s certainly not appreciated. At the same time, it’s unlikely that many of these potential customers have a WMS that has the functionality to interface meaningfully with Volume’s material flow controller and doesn’t leave a lot of potential untapped without major IT efforts for the customer. I suspect that Volume will figure out very soon that they want to offer a more complete package.
There is something to be said for the simplicity of AutoStore (the system). AutoStore (the company) could address the conceptual and systemic limitations of their solution if they wanted to. And in some cases, they should (e.g., data transparency). But for most of the issues discussed in this article, any change would increase complexity – technical complexity, planning complexity, or control complexity. Despite AutoStore’s limitations, which may or may not play a role in a given project – in many cases, they don’t play a role at all – the fact that the system is simple is a major advantage and, in my opinion, one of the key reasons AutoStore became the most successful solution on the market in a very short time. Not only is it simple, but it is good enough for the vast majority of applications. So I would not say that Volume Dive is better than AutoStore, that would be an oversimplification. It’s different, it has different strengths and different weaknesses. And I think these differences can give Volume some good market opportunities.
