EPISODE 10: CONCURRENT ENGINEERING

Transcript

Torsten Bieler: Sharing of information is the key factor of concurrent engineering.

Whenever you have a multidisciplinary problem and you have a team to solve that, and the team is working towards a solution, then you can apply this concurrent principle.

You can learn a lot, especially when you’re a young engineer, like it was in my case when I started there. This was fantastic. You have all these domain experts, and if you have a question or when you have a question, you just go to this person and he or she will explain to you, and he or she will be the expert in the field.

Deana Nunley (Host): You’re listening to Small Steps, Giant Leaps – a NASA APPEL Knowledge Services podcast featuring interviews and stories, tapping into project experiences in order to unravel lessons learned, identify best practices and discover novel ideas. I’m Deana Nunley.

Concurrent engineering, also known as simultaneous engineering, has been adopted by companies and government agencies as a method to improve productivity and reduce costs. Several teams within an organization engage concurrently in multiple aspects of design and development.

Our guest today, Torsten Bieler, has been with the European Space Agency for almost 20 years, and has spent much of that time as a systems and concurrent engineer. He’s the ESA presenter and faculty representative to the APPEL Knowledge Services International Project Management course.

Torsten, we appreciate you joining us. And we’re eager to hear your thoughts on concurrent engineering.

Bieler: Well, I could talk for hours and hours about concurrent engineering. I really love it. It gave me a lot, me personally. I think it also has given the agency — the European Space Agency — a lot. It’s fun. It’s one of the best places you can work when you like the system engineering, when you like to stick your nose in different fields, talk to different people, understand the different programs, projects, systems, subsystems, equipment, then this is the place to be. This is very rewarding.

Host: What are some of the factors in ESA’s decision to implement concurrent engineering?

Bieler: In fact, this whole idea comes from the States. It was in the times of better, faster, cheaper, and maybe even before that. So, one was thinking of how to do projects, how to design, how to make studies in a more efficient way. In my opinion, it boils down all to communications. You can imagine in the old, old days, when you had a project, whatever it would be – it doesn’t have to be a space project – but you have one person who has an idea that’s his or her part of the project, passes it on to the next responsible person. That one then does his or her part.

For spacecraft, you could think you have mission operations, so mission analysis. So, you have mission analysis and they see how you go to whatever, a Jupiter moon. Then they come up with a delta-v and they give it to propulsion. Then the propulsion person does his or her design of the system, and so it continues. Then it goes to structure, goes all the way around, and when it comes back to the guy who had the idea, suddenly you go to the Moon and you have a rover there, and it’s like, “This has nothing to do with what I asked for.”

Now I’ll come back to the communications. It is all about communications. This is all about having people being aware of what is going on. Because what does concurrent engineering mean? Concurrent engineering means to bring every domain, everyone who has something to do and has some say in the design of whatever system it is, let’s say a space mission design. So, you bring them all together in the same room at the same time, and you design the space mission. So, everyone is always aware of the current status, and you can influence each other.

So, it’s not just over-the-fence communication, where you do something and you give it to the next one, you do something and give it to the next one, and at the end something weird comes out. No. Everyone is always aware. When Domain A says something or comes up with an idea or with a result, which might have an impact not only on Domain B, but also on E and Zed, so these E and Zed persons can say something. “Look, if you do it like this and like that, it might be creating some problems for my own domain in a different way.” So, this sharing of information is the key factor of concurrent engineering.

Host: How widespread is ESA’s adoption of concurrent engineering?

Bieler: The way we are using it in ESA is that we use it mainly in the early phases of a project’s life cycle. So, phase zero or pre-phase A, phase A, sometimes still in phase B1. This has to do with the amount of parameter that you have to juggle. There are a lot of activities going on to improve this and to go further into the project life cycle, but in ESA, we use it mainly in the early phases, where you design new future space missions. There, all program directorates come to us, to the CDF, the Concurrent Design Facility, to have their missions studied, so observations, science, human spaceflight, so on and so forth.

Host: And then what happens once the studies are brought to the facility?

Bieler: The way it works is let’s say there is this science group that has this idea to check and test a radar for a Jupiter moon. Then the representative of the science directorate for future space missions would then contact the Concurrent Design Facility. We sit together. We discuss what is the envelope. What do we want to get out of this study? What is the manpower that we have available? What is the frame that we want to understand?

Then we sit down in the Concurrent Design Facility to invite the different domain experts. So, you have different, let’s say, subsystem experts from structure, propulsion, data handling, attitude and orbit control, and so on and so forth. You also have system-level people like simulations, for example, programmatic people that look at the testing perspective. Technology readiness level will be a parameter to be looked at, a risk expert to see what will be the potential threats to the program or the project. There is a cost engineer, who looks from the cost perspective and tries to identify the envelope in which this project will maneuver from the cost perspective, and what can be included and what can’t. So, these are the domain experts.

You have the system-level people. You have a system engineer. You have a system assistant normally, and you have a team leader. The team leader you can consider is like a conductor of an orchestra. So, all these domain experts and all the system experts are playing an instrument, and the conductor is the team leader, who has the task to get something harmonic out of this.

Once in a while, you bring a domain expert in the front, who plays then a solo, while the rest of the orchestra is still playing in the background, listening, working on their domain. Then you change and somebody else comes in the front. And like this, you try to have a nice song, a nice concert there.

The last element that I have not mentioned yet, what is also in the room, is the customer, so the representative of that science community, let’s say, so the study manager. So, whenever there is a question with regards to this project, there should be somebody in the room who can answer right away or maybe with a slight delay, because he or she can call somebody or check with a model or whatever. So, the communication waits are rather short.

Host: What do you see as other advantages of concurrent engineering?

Bieler: The advantages of concurrent engineering, apart from the fact that you bring everyone in the same time at the same place, and that you can learn a lot, especially when you’re a young engineer, like it was in my case when I started there. This was fantastic. You have all these domain experts, and if you have a question or when you have a question, you just go to this person and he or she will explain to you, and he or she will be the expert in the field. So, it’s almost – almost – better than in university, because you get really the thing that you need to know for that specific moment, for this specific project. So that’s quite nice.

So, there is this cross-fertilization aspect in between the different domains. So, when you are, let’s say, a structural engineer, you will learn automatically something about attitude orbit control because you hear it. You can listen. You might have a clue, but then you can really dive into it. You will not become the expert-expert, but this will help you to better design your system.

It is also that there are different program directorates. Let’s say science and Earth observation. When we do these studies in the more traditional way, either somebody who is a systems engineer somewhere in his or her office does a study by himself or herself or we give it out to industry. So, when you do this in Earth observation and science, they might not necessarily talk to each other all the time and exchange lessons learned, for example. But in the CDF, you have experts. Two months ago, they had worked on an Earth observation mission. Today, they’re working on a science mission, and there might be something that is interesting to take into account for science, which they would not have done if this expert wouldn’t have worked on something else before. You can also exchange that – it was just an example. So, this cross-fertilization effect is a good one.

Then when you do these studies in a traditional way, it takes six to nine months, let’s say, half a year, three-quarters of a year. When you do it in the CDF, it’s maybe, max, two months, everything from setup to having the report written. So, it’s like eight weeks or something like that, plus or minus. Of course, it depends on the complexity and how long and blah, blah. But the time factor is clearly an advantage. Since we know time is money, then there’s also a good factor that these studies are cheaper, so you can do more studies if you wanted to or you can do it for a cheaper price.

When you do more studies, then this allows you to have a better understanding of what kind of missions you want to choose. So, you become a more clever buyer, as former director Turner once put it. It’s like when you want to buy a car. At the beginning, you know some, and then you check the web and then you go test drive. And you try to understand the market. You try to understand what is out there.

This is what you do with the space missions. You want to understand for what can you put the taxpayers’ money on the table. What are the risks involved? What is the potential learning effect? What brings us further? So, this is the third big advantage. So cross-fertilization, time and money.

Host: Are you familiar with other concurrent design facilities outside of ESA?

Bieler: Yes. There are many. They are also in the States. At NASA, you have these mission design offices, I think. In Europe, we had to establish many a) in industry, and b) in academia. So, you need to know that you don’t have to have only a nice room with screens and computers, but you also have to have a computer model behind it. You have to have a methodology behind it. Of course, you need to have the team and all this to set up.

We helped academia in the main space primes in Europe, like Airbus, Thales Alenia Space, OHB. All those have concurrent design facilities, but also in academia, so universities, for example. Even in the International Space University, they had to have one.

We went all the way down to Melbourne. There’s an education center, so an undergraduate who somehow saw this. Massimo Bandecchi, my former boss, went down and attempted to set this up. Very interesting, because whenever you have a multidisciplinary problem and you have a team to solve that, and the team is working towards a solution, then you can apply this concurrent principle.

Host: What advice would you offer to someone who wants to start using concurrent engineering or stand up a concurrent design facility?

Bieler: Of course, you want to understand where you are, where this person is, or you want to understand where you are and where you want to go, what you want to have. How would you need it? It’s going to be about information, so I would try to gain a bit of knowledge. Of course, there will be articles and books and stuff.

You might want to go to conferences. So, go there. Talk to people. You can contact the ESA office and I’m sure in NASA you can also find out who does it there and try to exchange, and find a) companies, and b) conferences, and c) literature to educate yourself.

Host: Torsten, thanks for joining us and sharing your thoughts on concurrent engineering.

Bieler: I’m the one to thank you. Good luck.

Host: For more information, including links to topics mentioned on the show, Torsten’s bio, and a transcript of today’s episode, please visit APPEL.NASA.gov/podcast.

If you have interview topic suggestions, please let us know on Twitter at NASA APPEL, and use the hashtag SmallStepsGiantLeaps.

We encourage you to subscribe to the podcast, and tell your friends and colleagues about it.

Thanks for listening.

Angelo Conner, Millennium Engineering and Integration Company, contributed to the development of this episode.