Is digital thread doomed without open architecture? The secret sauce of open source — PI DX Spotlight, May 2021 Rob Ferrone, Founding Director — Quick Release_ (compère) Willem van den Corput — Lightyear Bas van Goch — Lightyear Samuel Fletcher — Quick Release_ This is a machine-generated transcript, lightly tidied for readability. Speaker attributions and paragraph breaks have been added; the substance of the talk is preserved. --- ROB FERRONE: Hi everyone, very nice to be here again. As you can see, we're going to be talking to you today about the secret sauce of open source. With me right now we've got Willem van den Corput from Lightyear, Bas van Goch as well from Lightyear, myself, and Samuel Fletcher. Willem's all about engineering, Bas is all about PLM, and Samuel is product manager for QRonos. So without further ado, I'm going to hand over to Willem, who's going to tell us a little bit about Lightyear. --- WILLEM VAN DEN CORPUT: OK, thank you Rob. Lightyear's origins actually come from the solar teams we've seen in Australia. The first one, bottom right, is the Stella, created in 2013. Over those years they were four-times world champion — Stella, Stella Lux, Stella Vie, and Stella Era. On the next page: we've shown already that you can drive on the sun. It's already possible — they showed it four times. With a full battery at the end (not a big battery), they have five persons in there. At 70 kph you're still charged by sun, and you'd have the ability to drive 1,500 kilometres on that. So that's in solar range. The reason for it: you need to serve as many people as possible. Currently, the issue is: can you drive on the sun, and can you drive on electrification? The EVs in the market are being pushed — you see them everywhere — but the biggest challenge is to get enough energy into the car itself. It's a challenge for the next 20-odd years probably, to get everything up and running and to replace one billion cars from a petrol or diesel engine into electrical or alternative sources. Our solution would be skipping the grid and making sure that you could be a fully independent, go-free car. You'll have a car and still need some energy if you need to charge in wintertime, but in general you'll have up to 30% of your over-year energy from the sun. And if you leave it in the sun, you'll get it. For example, in Barcelona, where it's nice and sunny, you'd be able to charge 20,000 kilometres a year with our car. On the next: there is no challenge because the sun is there. It will be there forever and it is there already for a long time — it will be there as well. The energy is our source of life, and it remains. And we only use 10% of it. Next to that, everybody in the world — almost 82% — has a normal power socket in their house, in their homes, or available in the near surroundings. That makes our vehicle really efficient and makes it possible to charge not on a high-power electrical load, but from just a normal power socket to charge your Lightyear. Next: how are we going to manage the energy efficiency? Because if we can use less energy, you can drive further. Our main drivers are stated here. The aerodynamics of a car is already half of the energy you're using, so we're going to use lightweight components to have a lightweight car, and rolling-resistance and in-wheel motors — that's the baseline of less mechanical losses than you'd have in a normal car with its ICE engine. In total it leads to less batteries and less value — less electricity. So the car is going to be more powerful, and the more power you have, you're going to be more efficient. That counts down as a circle to an efficient car. Our focus for this vehicle — the Lightyear One — is an exclusive one: we're going to build 1,000 vehicles as a first run into the market. It's all-round longest range (small battery in that sense, same as we settled on previously), with the highest charge-per-kilometre and lowest cost-per-mile. That's our main goal with the car — being different than all the other EV start-ups and EV companies, in order to make the most use and the most efficiency on the vehicle and driving from A to B. You can see here our first prototypes — multiple products being built to test and make sure the car is as efficient as it is. We're closing the current development, as we'll deliver by the end of the year the first one to our first customer. That's in a nutshell the technology where we are, and the baseline and the origins of Lightyear. I think that was it — that was my introduction. Over to Bas. --- BAS VAN GOCH: Yeah, thanks Willem. I'll take over and explain a bit more about our transition from a start-up into a mature automotive company, and the challenges we face with regards to systems and data — also in relation to the topic of today's Spotlight. As Willem mentioned, Lightyear was founded four-and-a-half years ago by a couple of students who had some experience from the solar challenge. At that time we were a real typical start-up — only a few people, focused on early development, and we worked CAD-centric, so everything more or less originated from CATIA. Of course we had low process maturity, and we weren't so structured and organised. Now, as Willem also mentioned, at the end of this year we plan to deliver our first car to a customer — and that really demands us to become a mature automotive company. Of course we are already a couple of years underway. So we're not with a couple of people anymore — at the moment I believe we're with 170, but we're growing fast and probably we'll even double at the end of this year or early next year. So instead of a few people, we are moving to hundreds of people, and instead of being focused on early development, we're now focused on bringing an electric vehicle to mass production. Another thing we're seeing in this transition is that we're moving from CAD-centric to more item-centric, with a focus on data — so data-driven. Of course, we need to define our processes and conform to certain regulations. This transition comes with a lot of challenges. There are many, and I'll only list a couple more or less related to today's topic and also the relation we have with Quick Release_. As Lightyear, we want to be independent and do things differently — and especially when you grow and become more mature as a company, and involve more established mainstream systems in areas of PLM and ERP, you notice that it's difficult to stay independent and be able to do things differently than the mainstream. We also need to ensure a high level of data quality. Especially for Lightyear, we're doing a lot of things at the same time, we're moving really fast, people are joining — and that's really a challenge to keep that quality at the right level. Another challenge is that, especially with the PLM tool landscape growing, and us implementing new functionality and deploying new systems, it becomes really difficult to ensure that each user sees information that is relevant to him or her, and to his discipline — not confronted with too much complex information, but only sees what he needs to see at that moment in time. The bottom one, especially related to seeing the right information at the right time, is to have a solid understanding of where we are and what's on the critical path — especially with everything that is happening. So, how do we tackle this approach — the transition from start-up to mature automotive company? Like I said, we're transitioning from CAD-centric to item-centric with a real focus on data. We've also, in consultation with Quick Release_, recently changed our data model through all the phases of development into production. If we look into systems: for example, in my domain, which is PLM, we have one core PLM system, which is 3DEXPERIENCE for us. But around that we make use of a lot of smaller applications, which for us means they're really focused on doing one thing really well. It helps us to stay a bit more independent, and they're more adaptable to our needs. Some of those applications we've developed in-house — so we've developed an order-request tool, for example, and also a bill-of-material viewer that takes the bill of material out of 3DEXPERIENCE and enriches it with information from that order-request tool. We also make use of applications of other parties, like, for example, QRonos from Quick Release_. That takes me to the next slide, which is the example of plan-for-every-part. As I mentioned with the challenges, it's really a challenge to have a good overview of what is happening and what is on the critical path — relating of course to items — because at the end of this year, we want to deliver our first vehicle to a customer. So it's really vital that we're sure every item is available on time to build that car. As I said as well, a lot is happening at the same time and we're moving fast. That's really a challenge: to know of each single individual item where we are, and which items are on the critical path. To deliver this, you can of course think of multiple options. For example, spreadsheets, or develop an application in-house, or maybe use the functionality available in your core PLM system or ERP. But we chose QRonos from Quick Release_, because like I said with the applications, it's focused on one thing and it does it really well. It takes the bill of material out of 3DEXPERIENCE, and we can enrich that data with data coming from our order-request tool — and in the future also probably ERP — and we can add additional data to it, to make sure that for each item we have a proper view of where we are, and if it's still on the right track to be available on time for our build. That was my part. I can take it over to Samuel for some more information on QRonos and open source. --- SAMUEL FLETCHER: Thanks Bas, and hi everyone. I'm Samuel Fletcher, one of the product managers here at Quick Release_. I'm just focusing on QRonos, which is our BTRS offering, but QRonos is just one part of our Gaia platform: lightweight solutions that fill the gaps between enterprise systems and provide actionable understanding for teams that would otherwise fall between the cracks. Our vision is a suite of products that seamlessly integrate and address those critical issues throughout the PDM journey that aren't addressed by traditional PLM/ERP solutions. At their heart, the approach of all of them is the same — it's about pulling the right information together and putting it in front of the right people at the right time, to drive those real-time informed decisions. With BTRS specifically, we kept coming across the same graph again and again. You start with what looks like a brilliant plan that perfectly hits the deadline, and it's a classic piece of optimism bias — it's achievable, but it relies on everything working perfectly, which means that as soon as one small element fails, the whole plan comes down like a house of cards and you end up with the dreaded "hockey stick" graph. I'm sure many of you have seen it, and it's become an almost-accepted failure in many places. So with QRonos we try and break that plan down into the stages required to meet our delivery date, and work right-to-left using the lead time for each stage and the ultimate delivery date to calculate the required-by date for each stage, for each part. That right-to-left plan is then used to track when the specific events actually happen for a part, which gives us a measure of the lateness — and also recalculates the timing plan at a part level. So then, by committing to actions earlier than the plan dates, any hiccups or deviations can be brought back on track. This is run for the entire programme BOM, vehicle builds, or whatever it is we might be tracking. QRonos itself is a web application that can be integrated into whatever systems you might be using, and it works with — rather than in parallel to, or instead of — existing processes, to be that single point of truth about the timing for your project. With that in mind, what sort of open-source content goes into some of our tools, and why do we do it? If we take one of our products as an example and start looking at its makeup — these are just the A and B modules that went into one of them. These are just the top level, because these open-source packages link to others which link to others which link to others — and in this example we ended up with 660 links in that final map. This illustrates what we see as the main benefit of working in an open-source way. It's the scale of the community you get with open-source software, that is like nothing else we've seen. At QR_, we need to be solving the business problem, not writing the boilerplate. Writing that boilerplate, for us, is not value-add, but it is absolutely necessary — and the benefit of open-source material is the gargantuan scale of the community that's working on exactly this part for us. Open-source solutions have those thriving communities behind them, bound by a common drive to support and improve a particular solution the community benefits from and believes in. The global community unites around it. This means we can work with a broader community around improving these specific solutions, and introduce new concepts and capabilities probably faster, better, and more effectively than we, or our internal teams working on our own solution, probably could. This in turn means you get a higher quality of open-source code. You've got those thousands of developers from all over the world, with experience in different technologies, industries and projects. It's more reliable because there are more eyes on it with that worldwide community. The code is developed in online forums, guided by experts, and the output tends to be extremely robust, tried and tested code. And we get transparency into it as well. Open-source means just that — it's not only visibility into the code base, but discussions about how the community develops features, addresses bugs. We're protected against lock-in risks because we can see exactly what we're getting. Like the reliability, we get improved security too — it's much more thoroughly reviewed and vetted. It's also just nice that it's time- and cost-effective, which means we can pass on the saving into our products as well. Options are openly available, free to be explored, and it makes it a bazillion times faster to get something off the ground — meaning we can stand up pop-up software in days, not months. And it's not just a theoretical exercise. It genuinely works in the real world. Last year we were asked to stand up an MRP system that did everything from looking after the BOM data to handling MRP, but also the supply-chain collaboration and issue management too. Using this open-source model, we could achieve that rapid development we needed — use the latest approaches and develop it in an agile way, in the very midst of an evolving project, alongside the people using it right then and there. QR MRP evolved from zero to 35,000 lines of code in just ten weeks. New functionality could go from concept to first use normally in a matter of hours, because of the open-source packages we were using to support it. These applications just wouldn't be possible without that open-source nature that underpins most of the work we do. --- ROB FERRONE: Thanks Samuel. I was thinking about a way to close this session. We often look to nature as an inspiration for design and engineering, and I've got no doubt that some of Lightyear's technologies have been inspired by nature. It came to me that open-source is actually not a human invention. Nature's all about efficiency — much like the efficiency that Willem talked about earlier on — and whilst most organisms are single-minded about survival and reproduction, we inevitably share the same open-source resources. Lightyear's mission is to provide us with green mobility, and it's a pleasure to be supporting such a noble endeavour. Thank you very much for listening — and if you're interested in joining, then reach out to Lightyear, who, as Bas mentioned earlier on, are growing and would love to have you in their talent pool.