Scalable Data Management in Integrated Factory Design: A Northvolt Gigafactory Adventure

AXEL SAVE: All right. Welcome to this session. My name is Axel Save. With me I have Fredrik Englund. We are from Northvolt, the makers of world's greenest batteries. We have gathered here today to talk about scalable data management. And this is a continuation from our AU talk last year, when we talk about our principles in integrated factory design. And this year we go one step deeper and we talk about the way we have used conventional tools in an unconventional way to make the design process more integrated and one step further towards actual collaboration.

FREDRIK ENGLUND: So for anyone who has missed this before, we will give you a brief, very brief introduction to us as a company. So we are Northvolt, and our mission is to build the greenest battery in the world, basically. And a bit of a motto is enabling the future of energy. We have European leadership. We have a unique vertical integration company and industry-leading technology. I think those are the big things.

We have an inspirational quote here, which we use to point out how important the battery will be for this green change. A bit about the numbers here. We were founded in 2016. We're about eight years now, so I would still call us pretty young. We have $15 billion raised to date. We have 50 billion in our order book. And we have grown to 6,500 plus employees. And I think the big thing as well is that we are 150 plus nationalities, making us a very diverse company.

So what are we trying to do? So if you look at the objectives we need to achieve for 2030, you can see that the cell manufacturing target capacity here would be 150 gigawatt hours. And our goal is to have a minimum recycled material in all new cells to be 50%. And for that, we want 10 kilograms of CO2 emissions per kilowatt hour cell produced, and that is a fraction of what right now is the current standard.

So to achieve those goals, you can see here our expansion so far. We have our North America facilities, Northvolt Six, our gigafactory, we have a few of them in Europe. You can see a substantial amount of factories here. We have established our big production facility up in Skelleftea called Ett We have our main office in Stockholm, Volthouse, and the Polish factory, Dwa, the German gigafactory Drei, and so on. So we have a lot of facilities here.

And on the scale here, we can see how we're going to ramp up to 250 gigawatt hours. And to reach that high capacity goal, scalability is key to success. And we think that integrated factory design is the key to scalability here.

AXEL SAVE: So this is a continuation from last year's session, as I mentioned at the beginning. So for those of you who have seen it, this will be sort of a recap. But fundamentally, we want to establish some principles that we have been using for everything we do in our department in terms of factory design globally at Northvolt. And this is important because you can talk as much as about the tools and the software and the hardware, but it's fundamentally a mindset question, and an organizational question that we need to establish that everyone thinks and works in the same way.

We generally talk about three guiding principles: standardization, modularization, and productization of everything we do within our design toolbox. We really need to think puzzle pieces, and that as in a normal toolbox, not every tool does everything. But you need to make sure that they work together to make the best job as an output.

Now we generally talk about three layers in our design onion when we talk about this. We talk about design generation, design collaboration, and design management. And fundamentally, generation is where the engineering happens. This is where you literally draw your pipes, sketch up your walls, design your machines, whatever you do. It's actually generation of content.

But then all of these disciplines, and all of these engineers, need to collaborate. You need to haggle. You need to see how your pieces comes together. This is where you collaborate. You need platforms that make everyone see each other and talk and align and work together. And obviously this goes back and forth, and you go home, you draw a bit more, go back, you collaborate.

And then once you agree on what you want, you need to have a management. You need to document, you need to ensure that everyone has the same picture of the truth, that the project knows what has changed from one iteration to another. And for all of these three layers, we need different tools, different platforms, different procedures. And we all need to agree on how we do this. All of this is based on a scaling mentality, where we need to be very, very smart of how we do something little, and do it so efficiently so we can scale it rapidly to enable that graph that Fredrik showed earlier.

And we-- a bit catchy-- talk about keep, tweak, and leap. Where we want to keep what is great or what we are doing today from one iteration to another. But we also need to identify what can be improved and tweak it. So we always moving forward. And the nature of battery manufacturing is that technology moves very, very rapidly. The toolbox changes and everything. This means that occasionally we need to be able to leap and do fundamental retakes and entire platform, the entire toolbox, and everything we do needs to enable all three of this very, very efficiently.

FREDRIK ENGLUND: So moving on from those or what we call the design onion here, we have the first layer, which is the design generation. This is where the groundwork is done. We have decided to give one toolbox per discipline. So we carefully curated and standardize the tools that we're working with. We create templates and guidelines so that everything is compliant with each other and we have good data integrity.

We put a lot of effort into our infrastructure and framework on how we are managing and getting that data across those different fields, because as we said, it's one tool per discipline, but it means that you can have the best tool for each job, but it also means that we still need that data transfer to happen between those tools. We centralize our asset management. And then to make this all happen, we have to create scripts, automation and centralized data mesh in order to make it fast and scalable enough to be able to do this at the rate we need.

The second layer is design collaboration. So here we're talking about true collaboration. We want the designers to work together, live, within the modeling environment and be able to both see the geometrical, but also the information data shared live between the different people, stakeholders. And you have an integrated design process. We put a lot of effort into data exchange between those data is the most important piece of the puzzle with the information needed for each step and each person. And we try to keep it to a single source of truth where everyone should always know where to look and what is the plan of record that we're working towards.

The last piece of the onion here is the design management. What's very important for us is change management, and we want to have a high grade of visibility and acceptance for those changes and why things are happening in certain rate. Battery technology is changing, meaning the factory design will change with it. We always keep track of and record to know what we came from and where we're going. And then in our PMM system, we package and deliver it as it is a factory designed product that we're giving to the programs.

And now we move into the most important piece of getting all of this puzzle together, scalable data management. It's a bit of a bumpy ride. So this big cornerstone here that we call scalable data management it's about we have identified the fundamental pieces for the IFM data categories is geometric data-- so the size, shape, the different interfaces of design-- and then the metadata. So all of the associated information the data to the design components.

And to make this work, we have a few requirements for scalability and the structure. So we have very few factory designers who are in the malls doing the designs, working with the data in there. But we have a lot of stakeholders who wants to be part of that information, and want to put that information into the model to be able to collaborate with others.

A data owner isn't always the same thing as a factory designer, meaning that we want people who own data to be able to be accountable and be able to put in the data or communicate it to the factory designer. But they don't have to be the actual ones who are working in the design itself, in the tools. And then to make this all scalable, we are working very heavy with standardization, parallelization, and automatic ability. So creating automatic scripts and systems, creating the templates, making everything be able to work parallel with each other here.

So the current state is that the geometric data exchange, it works pretty well through the IFM structure. I mean, we can get the geometry between our different tools. Looks pretty good. We can see our machine in one place, put it into the construction part and see it. The problem is that the metadata flow, we would say that it's currently a bit underdeveloped and really limits the efficiency of the cross-disciplinary design here.

AXEL SAVE: So how do we make this work? As Fredrik explained, fundamentally, we have two streams of information that is both needed in a design effort. And they fundamentally share the same stream, the same flow. So in the beginning, we have metadata on one side and geometry data on another side, and they both need a source. This can be a supplier, it can be an internal engineer, it can be a napkin drawing, whatever. You need a source for the information that is needed to be started.

This needs to be ingested somewhere. It needs to be an interface that needs to be standardized and access controls So not anyone should be able to add whatever data they want. It needs to be controlled and easy to use. This then needs to be stored and managed in a standardized storage solution. It can be a PLM system, a PDM system, whatever you want for it. And of course, this can be the same structures, but it's two different information streams that then need to be combined into what we call an asset.

The asset is the component of the factory design. It can be a wall, it can be a machine, it can be a pathway, it can be all of the things that goes into the factory design. And it has a geometry and it has data associated to it. This assets that gets into a factory design generation environment for it where it's actually generated content that then need to be collaborated and we need to manage it as per our design onion.

Fundamentally, this can be streamlined. And if we are looking at how a proper BIM implementation in construction is doing, it is fundamentally a single consistent flow where metadata and geometry data is just two sides of the same coin that is stored together. It comes together. It is inputted together, it is stored together. It's generated, it's collaborated and it's managed all the way for it. They are never separated. And this makes it very, very efficient and consistent and it's easy to work with.

So what's the catch here, if BIM has done this already? Well, when it comes to process and production in an integrated factory modeling environment, this is a trickier nut to crack. So conventional IFM practices have it like this, and it looks fairly similar. You have the two flows, and then you have an asset that generates a design. But there's a catch.

There is a gap in the chain. So we can move geometry data through the sources in that production and process environment. It works for it. We can move something from a vault, inventor-based and machine environment into a building Revit environment or so. That works. But due to conventional industry standards and old limiting data carriers and file formats, there is no way to easily move metadata together with the geometry data. This simply do not work efficiently. And what we have been forced to do is to do fairly janky workarounds, to be honest, to move the data in a way that is needed for us to really do an integrated factory model and design.

So what does this mean? It means that we have a long way to go. So if we take these two starting points, we have the conventional practices as they are today when we have this break in the metadata chain. And then we look at our colleagues in the construction environment. And say, hey, BIM already has this Utopian, perfect, streamlined flow.

What would this require? It would require broad industry standards such as the IFC standards used in BIM. And it also requires a mindset. And this is frankly, a long-term vision as of today. It's currently utopian to make this happen as of today. So what can we do?

Well, we could have a potential improvement where we go back to this principal flow, where we just try to connect. We have two separate flows that is connected in an asset, and then shipped. And it would be an improvement, but it is severely limited by the way, the different data carriers today are not talking together. And as it is today, we are, frankly, losing unacceptable amounts of metadata when we try to force it through this flow.

So what we at Northvolt has been doing as part of our own development trying to improve this, is a huge leap, but in an compromised fashion. So what we have been doing is that the geometry data doesn't change, and we have found a way to move the metadata not associated to the asset, but to connect it in a collaboration environment. So that means that the data can be used in collaboration, but it's still a separate flow. So it is accessible and it's feasible, but it's very cumbersome and it's complex. And frankly, not a very stable way, but it's doable.

What does it mean in practice? So let's take an example. Let's talk about a machine and its metadata weights and loads. So a machine has geometry, it has a size. But the box doesn't tell you anything of how heavy it is. Now it is a property of the machine to tell how heavy it is. So it should belong with the machine data.

However, who needs to know how heavy it is? It is architects and structural engineer who need to design the building that this machine goes into. So the consumption of the data is in one place, and the home of the data is in another. So how do we move metadata from source to collaboration consumption?

And if we look then at this workflow that we have tried to sort out as our janky compromise way to make this work as is today, we start with the metadata source. And we use teamcenter PLM system as a way to input and manage a digital representation of every machine. And therefore you can add metadata to it, and you can control it and change management and all the way as a standard PLM system.

We then have a geometry data source that is also teamcenter as a portal for our suppliers to feed us geometries. We then use Inventor and the FDU toolbox to manage it. We store the representation in vault, which is having an asset of this machine. Now come the secret sauce, where we have built custom plug-ins that basically takes the information from our PLM system, and extracts it, puts it in a third party storage environment, moves the assets, in geometry only then, through the desired environments, and then feed it back to data using a tagging system.

So what this allows is the architect and the structural engineers to receive the data of the machine in Revit or wherever they wanted, but it's actually hosted in a PLM system. This is not great. Or it is great for we have found a way to actually keep the data integrity safe. We have the data where it is supposed to be, and we can move it from home to consumption point. But it's very cumbersome, it is sensitive, it requires quite a bit of fragile infrastructure, and it's not streamlined.

But it's doable end to end. And that is how we have made it possible for our cross-disciplinary design team to actually take this step where they reliably can get the information they need, where they need it, and how they need it, no matter where the data actually is housed.

FREDRIK ENGLUND: So what have you achieved so far? We have a pretty good interface for input management. We have standardized process, how we manage the change through this entire chain. And we have worked a lot with, I think, especially expectation management here, so people are aware of what the data that is coming in, maturity, what it should be used for, what it shouldn't be used for, and what is the plan of record of that information.

We have managed to improve quality of life a bit for our designers and users by minimizing uncertainty here, basically. And we want the designers to actually be able to focus on the work they should be doing, which is design. And with all of this, our own improvements in the tooling here, we have connected the two different main tools we're using, and the two different worlds of the construction and the manufacturing side.

So what would we see as the next steps here? I mean, the main thing is that incompatibility between the data carriers. So if we're looking at our main two tools here, which would be Inventor and Revit, the data doesn't transfer without all of this extra massaging we have to do. Basically, the building our own plugins and making sure that the data can come from via one step to the other. We can't go directly as we would. We have used them as a good example here of information management and information exchange. I think in that sense we're quite used to having the data directly available from one user to another within the tool itself. That doesn't happen right now.

AXEL SAVE: So fundamentally, where does this lead us? And I'm a production engineer, and Fredrik is the construction guy in this crew. And I am genuinely jealous about the openness that the BIM community, especially in Sweden, but also broadly internationally, has shown, where everyone agrees that we need to collaborate and the way we treat data needs to reflect that mindset.

We as production engineers and manufacturing experts and partners, no matter if it is the manufacturers themselves, or equipment vendors, or construction partners, or whoever is, we need to get our shit together. We need to really understand that this is a partnership. And in partnership, you need to collaborate. And like geometric data, it's not good enough any more. It doesn't matter if you send me how big your boxes if you don't give me the data associated with it. That's the only way to really can start bridging the gaps between our disciplines.

And as our disciplines gets more and more specialized, their tools need to be more and more advanced, the more important it is for them to start talking together. And I think the way that the BIM community has shown the way, and it is doable. And hell, if the traditionally conservative construction business can make this very modern approach, then we as manufacturing society needs to follow suit and do something similar.

Now where this leads-- and fundamentally, this means that scalable data management, and therefore truly cross-functional collaboration, and therefore the future of factor design, is frankly but a few leaps away. And it's all in our power if we just decide to do something about it. And with that, we thank you for attending this session. We are hoping to see you at AU and have a good day.