0:01 Okie do, hi everyone, I’m Kiera, it’s great to be here with you all today. So just a quick intro to me and Ocado before we get in, because I think we had maybe three people earlier who had heard of us before. So for me, I’m a software engineer by trade, a background in physics but went straight into software, I joined Ocado in 2021 in the supply chain simulation team based in London, so what we were doing in that team was creating a digital twin of the Ocado warehouses, so all of the processes that go in, stock levels, and kind of using that for optimization and planning the next set of warehouses. At the start of last year I moved to the team I’m currently in, and the team that are working on what I’m doing, going to be talking about today, industrial devops. So we’re based in stockhome in Sweden, and what we do is we’re optimizing Hardware development using software practices.

0:55 So a little bit about Ocado before we get into that and why we’re talking about both software and hardware at the same time, so aado has a deep expertise in both of these areas. Aado is founded as an online only grocery company based in the UK, so we don’t have any brick and mortar stores, none of that. Quickly found out that online grocery requires new technology that wasn’t available on the market at the time, for reasons like the average Shopper will order about maybe 40 things in one particular order, we’ve got to think about, got a range of maybe 58,000 products in Ocado in the UK, all these have shelf lives because they’re groceries, some of them are fragile, they all need to be delivered perfectly on time so the customers can plan to be home at the right times, because no one wants ice cream that’s already melted by the time it gets to you. So all of this means that the grocery problem specifically is a lot more complicated than General merchandising, where you just be kind of moving boxes around, so we had to build this software and the hardware inh housee, which led to us transitioning from a grocery company to a tech company.

2:01 So these are the Bots, these are not the current, the version of the Bots, these are the previous ones, I’ll talk about the current ones in just a little second, because you may notice these are not additively manufactured. So these are known as The Hive, so that contains the large grid that you can see the Bots running around on, as well as the Bots themselves and the kind of AI machine learning that Essen creates, the hive mind for them all to optimize where they’re going and what they’re doing at once. So from the start in the UK, as just a grocery company, at the moment we’re providing this technology around the world to other retailers, so for example in UK, in the US we have a long-standing partnership with Kroger for their e-commerce operations, so if you order something from Kroger it might have been packed by one of these Bots. There we go.

2:57 So the bot themselves, when I talk about Hardware development I’m going to specifically be talking about the bot and the next generation of the bot, so the 600 series is what we call it. So the Bots have travel around 4 MERS per second with only a 5 millimeter clearance between them when they do so, so this means they’ve got a tough but very important job, which is fetching those containers of product that you could see in the video earlier, for the, and then taking those to picking and packing stations that then put it, put that product into the bags that arrived to your door. In order to transport a tote, which what the we call the containers, the bot will stop over the relevant cell, it lowers kind of a grabbing apparatus which attaches to the top tote in the stack, however far down that might be, and it then pulls that tote up inside the bot.

3:46 So a few stats before we get into things, so this is all from 2023, so last year. The Bots all have a fairly tough life in our warehouses, last year we have a fleet over of over 10,000 Bots around the world, and between them they traveled 114 million kilom, which for those of you used to miles is just over 70 million miles. They also lifted between them about 80 million tons of product, I think 83 million, which is in our wonderful standard metric of African elephants, about 400,000 of them, lifted 44 times over. So all of this means that the Bots themselves need to be very robust, very reliable, and super super efficient, which is why we’re always looking, look at ways to make them even better than they are.

4:32 So that takes us to today’s topic, for our most recent round of innovation on the bot, for the 600 series, we decided to experiment with our design process, drawing inspiration from the software world, and enabling, well, using additive manufacturing to enable this. This is the 600 series bot, you might see it looks very very different from the previous ones, part of this is because the main, main goal with this one is to shave off weight. Lightweighting, as I’m sure many of you are aware, creates a virtuous cycle of benefits, so it means we can use smaller Motors, smaller batteries, and then all of that then needs to, further weight reductions. The lightweight bot also reduces cost of construction, which means we need the, the grid we were talking about earlier, it has fewer steel and concrete support structures to support the weight of it.

5:20 So all of this comes from the fact that we are able to use additive Manufacturing in the bot, me, we can use a totally different approach, we can kind of really speed up that prototyping time. So at the moment we can go from designing a particular part for the bot on a Monday to having a printed, built and bought in test on the Friday, which is wild when you think about it compared to traditional manufacturing where that would take months. So what this means is we can make tweaks and reprints quite easily, so we’ve got printers inhouse, we’ve also got kind of specialist tooling that mean we can get the best out of this additive first process. So by designing Hardware like we do software, it means we can quickly experiment and merge the best features from different models into the brand new one, so using continuous Improvement and automated test methods inspired by the software development.

6:16 So the next question is, how do we design software. One of the main Concepts, and the subject I’m really going to be focusing on today, is known as cicd, which I think someone mentioned earlier, I forget who, so continuous integration, and then continuous delivery, deployment, it varies, but they kind of focus on the same thing. Cicd is an alternative to traditional project structures where you’d have very specific design phases, and then once that’s done you move on to the build phase, but you can’t, you can never go back to the design phase. So instead of that, we’re going to throw that out the window, what we do is we do very short Loops of feedback, so we’re delivering incremental value all the time.

6:54 The CI part of this, The Continuous integration, means we’re merging our changes in often, which means that all the other devs looking at the current version of the bot are all using the newest changes, everyone is working on the most up toate version of the bot at all times. The Continuous delivery part of this means we’re regularly releasing features to users, including feedback, to then inform that next Loop of design. So for a software example, from when I was in the simulation team, we were looking at adding a new process that existed in our physical warehouses into our digital twin of the warehouses. First, in order to be able to do that, we needed to understand what that process actually was, so we’re speaking to a lot of people who actually worked in the warehouses and things like that, so we then understood the process enough to add into the simulation. That team we would also obviously build it and then run the simulations ourselves so we could see the outputs before we then kind of release that to users, so we can kind of had the own feedback loop before we even involved users.

7:57 So what I’m going to do today is talk about some of the specific ways that we’ve put this into action in the 600 series bort development. First up is the work that we’ve done to create and automate tests for our B designs. In the software World everyone has different opinions about everything, but test automation is assumed for pretty much every project you do, so what this means is it ensures that our new feature does what we think it does, as well as making sure it hasn’t broken anything else. So, and for anyone who’s not famili with kind of branching and how that works, where, this is how we think of feature branches, so we have the main branch, which is kind of the the version of our code that everyone refers to, and then when we want to make a change to develop a specific feature we take a copy of it, we can call it a branch, have a few changes in that, until we’re ready for that to be merged back into the main version. So feature branches are intended to be lightweight and shortlived, and merging back into main quite often.

8:56 So a feature that we might see in something like a cad design for the bot would be, maybe we’ve added a new part in for to adding some like structural Integrity, maybe we decided we don’t need one and we’ve removed it, or maybe we’ve redesigned something entirely. If we didn’t have any test automated, it’ll be very very easy to miss when things break, it does happen, people are human, without automated tests we wouldn’t be aware that anything had broken until one of the users tries to use the new feature. So this one right here, here is what the tests would show if we had them, but because we didn’t have them we weren’t aware that something had been broken, and then we merged that into the main version of the code, which breaks it for everyone.

9:39 Obviously we want to avoid that, so if we had the automat tests we’d be able to see very clearly not only which functionality is broken, from the specific test which failed, but also the specific change that broke it, because we’re running these tests for every single change. So knowing which change that broke it enables us to fix that change earlier and more easily, assuming test coverage is Happ enough. What we’ve done for the 600 series bot is to Define these test cases and kind of best practice definitions for CAD Engineers for our department, and give those CAD Engineers the ability to run these tests against any version of the code or the cad document, and then be presented with a report that details any errors or any test failures.

10:25 I just want to take a note that the reason we’re able to do this with our CAD documents is because we use onshape, onshape has a bunch of fantastic apis that allow us to kind of interface, read and write data about all of our documents. So this report generation has become a required part of the departmental workflow for any changes to the cad, and it’s reduced errors found at release time, it’s reduced the amount of merge issues, as well as the errors reported by our manufacturer, so it might not be the cad itself that just kind of the impact on us, it’s also that later impct on the manufacturer themselves.

11:02 So to recap, software has automated tests to ensure each set of changes don’t break anything, and it means that we can trust every single version of the code implicitly. What we’ve done is we’ve created a department wide tool that does exactly that for every set of CAD changes, which means any potential errors are C earlier.

11:21 The next thing we’ve done is to create release artifacts, and what I’m talking about when I say release artifacts is product defining data, manufacturing pack data, kind of all of the the files that you would need to release a hardware product, and we’ve done this programmatically. So this relates to the the release stage of that cicd Loop that we were talking about earlier, so again, in software a commonly held opinion is that you should be able to release your code at any time, whether you actually do, want not, what this means is that the main version of the code, so our main branch, is always in a good state.

12:00 How do we do this in Hardware. If we take a look here, at this is going to be a very very very simplified model of our document structure for the 600 series bot, there’s lots of data that needs to be collected for releasing something as complicated as a bot that has thousands of parts in it. Some of that means it’s just kind of like a Bild of materials, a list of every single part in the bot, we do that once per release, some of it’s more involved. So what we’ve been able to do is, again, because we’re using on shape and we have this data available to us, is Trace the document structure. I just want to be very clear, we’re not talking about the component structure, we’re talking about the documents themselves.

12:39 So one of the best practices that we’ve defined in Nardo is that when we have a definition of a part in CAD, in the same document it also contains the engineering drawing for that part, so that we know we’ve got engineering drawings for everything we need. So what we’ve got in my team is we’ve developed multiple individual scripts that can be run at release time that generate a vast majority of the artifacts that are required. So one example of something that’s required for our release is three MF files, so we have, we have three MF files for every single additively manufactured part in the bot. Previously, to be able to do this we need to go through the bill of materials manually, check to see which parts of adely manufactured, open those documents in on shape, and then export it from them, there, for every single part.

13:32 Now we have a single script that makes use of the metadata for each part to work out automatically whether it needs to be exported, and then does the export, and all of that is generated by running a few simple scripts. So what we’re able to do is create the release artifacts required for every release in a, I’m calling it a semi-automated way. What this does is it saves massive amounts of manual effort and time for each release, which feeds back into to the CCD loop we’re aiming for, it reduces the error rate as we know these artifacts are created the exact same way for every single release, and we even had one piece of feedback from our manufacturer recently that the data we sent them was the best that they’ve ever seen from us, as a result of things like the scripts.

14:17 So where do we go from here, these release Scripts still need to be run manually, but what if they didn’t, what if we could automate that. And we’re trying, the ideal in software is to be able to release everything you need for a release with a single click of a button, to make it so painless you almost don’t notice the release is happening, and be able to do that for every change made, and there is no reason at all to think that we couldn’t do the same in hardware, and be so confident in our release process that we could take any version of the bot live at any point, without worrying about the manual effort involved in that release. Like I mentioned before, there is a lot of data involved in this, so it’s not, not just the bill of materials, every sing, Single part has an engineering drawing and geometry file, sometimes multiple geometry files, as well as a whole host of other data.

15:05 So what we’re doing right now, my team is currently working on this, they might have gone, I think the day is over for them by now, the automation of not only the scripts that we’re already using, but what we’re doing is creating a platform to manage Hardware releases and the associated data. So for any of our main branch changes, if we decide we want to release a specific one, we already know from our tests that the the tests are green, so we’re not worried about anything breaking the production build, we have that confidence, we generate the artifacts for our release version, we know we’re able to download everything required for the manufacturing pack in one place, and then we continue development the same day.

15:42 So like everything I’ve mentioned so far, we can also create tests for these generated artifacts, because if you can test it, why not test it, so that means that we know we’re going to be creating the right thing, and the thing that we expect to be creating, for everything we do. So to recap, tests are not the only part of the cicd pipeline that benefits from automation, the release process itself does as well, the goal for our current work is to not only automate all of the release artifact generation required for our manufacturing pack, but also to verify those artifacts against our standards and keep improving from there.

16:23 So to summarize everything I’ve talked about today, testing of CAD is not only possible but hugely valuable, release artifact generation can be scripted, and not only scripted but fully automated. If there is anything that I’ve mentioned today that you kind of want to talk about, if you any questions please do catch me afterwards. Thank you very much.