Lessons from the software industry on requirements and design iterations that could radically improve hardware development over the next 10 years
Why is it that in just over a decade, companies in the software industry were able to serve much more users with a higher quality product by using less engineers & employees (think WhatsApp vs AIM)? Of course technological advances contribute significantly, but at Space Tech Expo 2021 in Bremen, Valispace CEO Marco Witzmann shared reflections on the systemic changes in processes, design and iteration that software developers underwent to become more agile and develop products faster.
There is no reason why today’s hardware teams shouldn’t learn lessons from software, ditch yesterday’s tools, and start working smarter. Listen to Marco discuss 5 key areas of hardware design that will allow teams to embrace Agile Hardware Development and build better products without constant (and expensive) rework.
Transcription:
[00:10] How to develop Hardware faster, cheaper and more agile
Hello, everyone. Thanks so much for joining. My name is Marco Witzmann, I’m one of the cofounders of Valispace and happy to talk with you today about a topic that I think we all want to get better at: which is developing hardware, faster, cheaper, and hopefully a bit more agile.
So let me walk you through this. You have the slideshow parts next to us and if you want to ask any questions, feel free to write them in the app. And in the end, we’re going to do a short Q&A, where I’m going to try to answer your questions.
So the question is, can digitization save you from the typical requirements, verification, and test nightmare, and how to basically do Agile Hardware Development. Let’s look at the overall engineering process – when you develop something you will see that the cost of making any change to your product changes. It goes up over time and goes up exponentially. And actually, the flexibility of making those kinds of changes goes down. So when we talk about industry 4.0, a lot of times we talk about the right part of this graph. But the reality is, the left part is where you have the biggest ROI.
When you do Data Driven Engineering, what you’re actually able to do is you’re able to capture that value early on every mistake that you didn’t make during the design, and capture every part that is actually coherent in your design at the very beginning and not at the end, will save you so much money and time.
So let’s talk about a few things today. Why we have the experience to share the key concepts of modern software, software development, and then the key question: How can we learn from modern software development and transfer that to hardware development? And then probably talk a bit about a few use cases.
Why do we actually have the experience to share? Why am I standing here today? Well, actually, the most innovative companies, especially in the space industry, use Valispace for agile hardware development, right? All of these kinds of companies, they have started where everyone is on a document based basis, they have their servers with share points, and they made a transition to taking a step forward and being more efficient. And I brought you a small video which is going to explain roughly what this is all about.
[02:27] Valispace Video
If your company develops complex hardware, you know, these projects are constantly facing budget overruns and schedule slips. The reason: engineering data, which describes the design of your product and evolves dynamically during the development process doesn’t, have a digital home. This means all your engineers work from inconsistent requirements and values siloed across 1000s of disconnected documents. This causes expensive rework, wastes engineering hours, increases risk and creates project drag. Enter Valispace, a digital productivity tool that helps your engineering team share up to date dynamic data quickly and easily.
Designed by engineers for engineers, Valispace is an intuitive browser based software that integrates seamlessly into your existing tool landscape, enabling lean collaboration across departments. Thanks to automatic data exchange across tools and documentation, engineers have the right information at their fingertips when they need it, making it easier to get your projects right the first time. That means your team’s waste less time chasing design statuses, digging through documents and cross referencing data and gain more time driving your innovation projects forward.
The result? Increased productivity, fewer data inconsistencies, happier engineers, and more projects delivered on time and budget. Are you ready to take hardware development to the next level? Get in touch with our experts today.
[03:56] So now that we all know that you’re ready for it, let’s see how we can actually take those ideas from software development into hardware development. “Could you send me the SharePoint link to version four of your parameter function? I’d like to compile my software today” said no software engineer ever. You will not find a single person who develops software this way but anyone who has touched hardware design will recognise that sentence, because that’s how we build hardware today.
end of video
[04:22] Single Source of Truth
So let’s look at what software gets right. First, a single source of truth. Think about GitHub or other things. It’s one data repository where all the engineers can collaborate. Second, that is not a document management system, by the way. It’s all about data. It’s not about that the files being stored somewhere. It’s about the content (in this case, the code) is stored in a single place.
[04:45] Realtime Collaboration for Hardware Teams
Real time collaboration. That means commenting, discussions, and notifications happen in the same place where that data is. You’ve never seen a code review happen over email. You’ve never seen an Excel spreadsheet which is sent to another developer telling them what’s wrong with their code.
[05:05] Continuous Integration Throughout the Development Chain
Third one, continuous integration. When you talk about software development, continuous integration means that you do automated checks of design against requirements. In software development, we call that automated testing, or whatever you want to call it, but it’s part of the development chain. You constantly get feedback. People compile several times a day, their software, people look, let the test suite run constantly to know whether they’re still on track or not. So that means not waiting for milestones to find out that you do have a problem.
[05:35] Agile Development for Hardware Engineering
Agile development. So actually having a real time overview over your progress. Where are we? How many things have we implemented already? Is there a problem I should take care of? That’s not waterfall planning. Waterfall planning, what we do so often, is when we think we know exactly what’s going to happen and then we’re surprised that our project takes three times the time and double the budget than we thought.
[05:58] Automatically Updated Documentation
And then automatic documentation. Documentation is generated from the code in the good companies, you actually comment in the code and in the end, once you get this documentation out. You don’t have to write a dedicated part as it’s automatically up to date. And it’s definitely not called version_final.3.
Okay, so now we have five key concepts of how software gets it right. But hardware is not software. So how do we take those concepts, these ideas and transfer them into hardware development? Let’s see how we do that.
[06:35] How to Have a Single Source of Truth
First one, single source of truth: A single data repository to collaborate and put your engineering data in a single place. That is not spreadsheets on SharePoint. That means data, because we have spreadsheets on SharePoint two spreadsheets say different things and that’s not a single source of truth. Have inputs of multiple disciplines combined automatically, if people collaborate on that data, they should be able to work on the same data and make it browser based access from all of your devices. Don’t think that you have to install something and then in the cleanroom, and you have a different machine, which runs Linux, and you cannot install that software. So obviously, make sure that with modern tools, you actually have that kind of access dynamically.
[07:30] How to do Real Time Collaboration
Second, real time collaboration, how can we make sure that all that happens in the same place? Well, make sure that you have granular access rights for customers and suppliers. You do want to collaborate! Space is the typical collaboration place. We all work together in this industry, one way or another. You’re the supplier one day, you’re the prime the other day, you work together but you don’t want to share all of your trade secrets. So what do we do today? We just send things back and forth of what we think is fine and that takes a lot of time. Just give granular access rights and say, well customer, here’s my mass budget. This is one you can always look at, I’m not going to send you any progress reports, because you can look it up at any point. Full traceability of decisions that you take on the way you have to store them in the place where they happen. Nobody wants to wake up and wonder ‘why did we make that choice three years ago?’ and go again through that same process trying to answer the same question. And have API’s to connect multiple engineering tools. Don’t have engineers highly paid to copy and pasting things from place A to place B as your integration layer. tools should be talking to each other. Engineers should focus on engineering work, not on copy pasting.
[08:30] What is Continuous Integration?
What does continuous integration look like? Well, actually, you can have requirements which are with rule sets being automatically verified at all stages. That means whenever someone runs a simulation, and it turns out that the orbital velocity got 5% shorter, that should ring a bell in some requirement document telling you to be careful as now you’re outside of spec. You shouldn’t have to wait for the expert to look at it. And that’s what basically automatic and continuous verification looks like. Simulations should also be triggered automatically if you change one part the other recalculations should not be dependent on if you decide there is another simulation loop going on. They should be triggered. You should know what depends on what, and therefore verification is already partially completed, before you’ve touched the first thing. You don’t have to have an engineer go through a lot of documentation, check numbers. If you have that view all the time. Now you can focus on actually doing tests, doing the things that you cannot verify by review or simulation.
[09:40] How to do Agile Development for Hardware
Agile development? Well, first of all, have a place where you can actually look at the status. Who as a project manager wouldn’t like to pull up a dashboard and actually see how many requirements of the 250 that we have, we’ve verified as of today. How many tests do I still have to run? Whether the mass of my spacecraft has been going up or going down over the last few months. Make sure that when you do planning, when you actually collaborate, you don’t put up Microsoft Project, make a perfect plan, and then expect everything to happen and then you call up people and ask ‘Did you do that?’ ‘Oh, no, it’s late. Oh, no, it’s late.’ Make bottom up planning. Ask people,’ what do you need for your task? Great. These are your inputs, what are you producing? Great. These are your outputs.’ and then put the planning together from these things. Now in real time, when someone says I’m done with this task, the other person will get a notification and the time shifts automatically. If one task lasts longer, you will immediately see what that does to your critical path. But you don’t need to be the person updating that it should be a software doing that. That allows you to find problems really, really early on in the process.
[10:53] Making Your Documentation Automatic
The last one is automatic documentation. Make sure that the data is your source and documents are just the output. You can optimise technical change management, therefore things that change automatically get reflected in your user manual and your ICD and whatever it is. Have traceability for every data entry. You do want to know where that data came from. Why are we having this change? You want to look at the mass increase on spacecraft level and immediately know that it is because a supplier agreed on a different kind of mass on one of the pieces of equipment that you have.
[11:53] Summary
So basically, the answer to the question of ‘How do we do hardware development in a more agile way?’ is digital continuity. It means having a digital threat that goes from requirements engineering through concurrent design, detailed design, simulations, reviews, all the way up to test and documentation. And that needs to come from at least a tool chain that is integrated if it’s not a single tool.
Requirements, design, verification and test, when they’re interconnected, Agile Hardware Development becomes a reality. And now the question is this: ‘Where are you in this process? How many of your parts have you integrated? How many of these things are real for you?’ Here’s the secret of how to do it. Now, it’s just about implementation. Thank you very much.
This video was kindly made available by the organizers of Space Tech Expo. If you’d like to see all of the talks presented by space industry leaders at Space Tech Expo 2021, you can purchase the whole programme from them here.