Michelle Salyer:                Welcome to Outside the Box with BRPH, where we discuss the most innovative, interesting, and outside-the-box solutions to some of the most exciting and challenging projects in the world of architecture, engineering, design, construction, and mission solutions. You’ll hear directly from the problem solvers at BRPH as we dive deep into the latest news, trends and topics in aerospace, defense, manufacturing, and industrial commercial, education, entertainment and hospitality. I’m your host, Michelle Salyer, and I’ll be your guide as we open the lid on these topics and more, and invite you for an insider’s look at one of the most successful, fastest-growing, employee-owned AEC firms in the United States. Welcome to Outside the Box with BRPH.

When it comes to designing an aerospace vehicle, testing and verification are critical parts of the process. Understanding where testing fits into the entire program lifecycle, what components need to be tested, when and how they’ll be tested, and what elements can be verified versus tested, are all crucial to ensuring that the facility requirements meet those comprehensive needs, and are all crucial to mission success. Having an AEC partner who truly understands the nuances of testing and knows the right questions to ask can make a world of difference when you’re working against the clock.

With me today to discuss the ins and outs of testing facilities and everything in between, is Derek Nolek, National Practice Leader for Ground Support Equipment Engineering at BRPH. Welcome, Derek.

Derek Nolek:                     Thanks, Michelle. Good to be here.

Michelle Salyer:                Good, glad to have you. So Derek, before we jump in, tell me a little bit about your background and how you found your way into systems engineering.

Derek Nolek:                     Well, I’ve been designing launch pads for aerospace components and flying launch pads and other unique aircraft, and I had the opportunity to learn something new. And I didn’t know enough about what system engineering was, and I couldn’t figure it out. So I decided, well, yeah, let me go learn about that, and I went for it.

Michelle Salyer:                So you got a master’s in systems engineering?

Derek Nolek:                     Yes, I did, yeah.

Michelle Salyer:                Okay. Okay, and explain for our listeners what you do for BRPH now.

Derek Nolek:                     Yeah, I lead the GSE engineering team. We help our clients with their tooling, equipment needs, as well as test fixtures.

Michelle Salyer:                Okay, so this is obviously a very complex topic, but it all boils down to one question, to test or not to test.

Derek Nolek:                     Yeah, so testing is a subset of verification.

Michelle Salyer:                And what do you mean by that?

Derek Nolek:                     So, every vehicle component facility is a system, and you want that system to perform. You want the aircraft to fly well, you want the launch vehicle to deliver the payload. We want the test facility perform testing representatively. There’s many ways that the system can fail, and that’s what we’re trying to avoid. So when we talk about ways the system can fail, we want to quantify that risk of failure, and that gets into the engineering design process of identifying the modes of failure, estimating their likelihood, quantifying the effect, and the consequence. It’s all about buying down technical risk.

Michelle Salyer:                Okay, and so where does the testing come in?

Derek Nolek:                     Well, so every system is put together as this collection of subsystems, right? And further down into the collection of components, we have their individual functions and purpose and what they’re supposed to do for their job. We want to quantify all that stuff with a thorough documentation of requirements.

Michelle Salyer:                So by the documentation of requirements, you mean the verification, right?

Derek Nolek:                     Yeah, so just because you have a requirement doesn’t mean that the thing magically does that. We want to actually verify that yes, the component does that functional thing, right? The bearings turn, the screw jack goes up and down, right? You want to verify that it actually does what you intended it to do, and so that’s when you would test.

Michelle Salyer:                Okay, so let’s put this in an example of, say, something we would do for our clients. Let’s say a test stand, for example.

Derek Nolek:                     Yeah. Well, normally we’ll have like a kickoff meeting and go through the scope, and if it says we need a test stand to perform A, B, C, and D on this vehicle or component, I’m that person asking the question to the systems engineer and the customer, “Which requirements are you verifying with these tests? And is this development testing, is it production acceptance testing, or design qualification testing?”

Michelle Salyer:                Okay, so explain how those different types would affect the design.

Derek Nolek:                     So for example, if it’s development testing, this is when the team is just trying to make things work, they’re trying to gain knowledge of what is and isn’t important, or they’re trying to tune how the system or rocket engine works. We know that the test article from that would probably live on the test stand for a number of weeks and need lots of good access and may have a higher likelihood of an anomaly. So, we might add some protection for their run equipment.

Michelle Salyer:                Okay, by an anomaly?

Derek Nolek:                     Well, yeah. I mean, rocket engines, sometimes they spectacularly come apart rapidly, so.

Michelle Salyer:                A good way to put it.

Derek Nolek:                     You have to plan for those events because if that doesn’t happen, you’re probably not testing the full limits. And destructive testing is a part of it, it’s a part of everything that these companies do. So on the other hand, if this was a test stand that was going to support production test, production acceptance testing, they’ll have an expected test cycle duration, maybe run the engine for 30 seconds. Probably need to rapidly load and unload the test article. Their technology is likely a bit more mature, and then the likelihood of something going wrong or having an anomaly might be a little bit lower. So, those are all considerations that go into the ultimate design of a test stand.

Michelle Salyer:                Okay. So when you talk about production acceptance testing, they would be testing a number of components in succession, so that’s why you need that in and out, or load and unload access?

Derek Nolek:                     Yeah, correct. It would be for every, production testing, that’s you’re testing every single ship set, right? So every single engine, every single launch vehicle, what have you.

Michelle Salyer:                Okay, and what about the third one, that design qualification testing?

Derek Nolek:                     So in that instance, you’re trying to validate that the design meets the requirements of the system, so you’re going to try to test everything you can. You’re verifying that the design actually meets the requirements as planned. So there might be some risk of something coming apart, but you’re trying to go through and be as thorough and probably do testing that you wouldn’t normally do during production testing. It’d be the largest expanse of testing.

Michelle Salyer:                Okay. So, how do you know which systems or parts should be tested versus verified? So say, sticking to our rocket engine example, does every part and subsystem need to be tested individually?

Derek Nolek:                     Well, I mean, yes and no. I mean, the need really comes from the need to verify the system requirements. And it’s, testing is only one way to verify those requirements. Testing was one of those things where it could be very expensive, right? Your test article is seeing cycles now, you may not be able to sell it/ your development testing, it might have taken you three weeks or three months to make this thing that you’re putting on test, and if something goes wrong and you don’t know what happened immediately, now you’re three months behind. So, there’s some risks to it, right?

There’s other ways to verify things, and usually you’ve done that beforehand as much as you can. So there’s really five ways that you would verify a requirement. Testing is one of them. The other ways are inspection, analysis, demonstration, and similarity. And sometimes multiple methods are used and sometimes all of the methods are used if you can, but it really depends on the risk that you’re trying to buy down from the program.

Michelle Salyer:                Okay, so you’re ultimately trying to balance cost versus risk. So, give me an example of, say, a high risk requirement that you would want to test.

Derek Nolek:                     Sure. So like a rocket engine may need to ignite for a certain amount of time and give you a certain maximum thrust. That would be a very important parameter at liftoff. And so, I would want to test those parameters because they’re very critical if it’s going to leave the launchpad on time and get there without hitting things on the way up, we’ve got to make sure that all those things work. And the other end of that is if it doesn’t perform the thrust needed and doesn’t ignite on time, it may not put the payload into the right orbit, so that would be a mission failure, and that consequence would definitely justify the test.

Michelle Salyer:                Okay, so tell me a little bit more about the other verification methods and when those would be used.

Derek Nolek:                     Sure. So, inspection is a good one that you could use that for if designing a building and there’s a requirement, like the building shall be designed with AISC steel columns for cost and schedule. You can verify that by inspection of the design drawings. Analysis is another helpful one. A lot of times you use analysis during design development to just verify that you’re heading in the right direction with your design. There’s a lot of analytical tools. There’s a lot of different simple analyses you can do to verify performance under different loading conditions, thermal conditions, acoustic environments. And it’s a good first step to verify that your design is going to meet the performance requirements before you go to test. So, it could be a first step. There’s a subset of analysis too, that when you get into really advanced CFD, where even today-

Michelle Salyer:                Sorry, what is CFD?

Derek Nolek:                     Oh, computational fluid dynamics.

Michelle Salyer:                Okay.

Derek Nolek:                     So if you’re looking at some highly exotic aerodynamic aspect of an aircraft or launch vehicle, it may actually be cheaper to test, or faster. So, that’s just an interesting balance that is still in existence today.

The verify through demonstration could be something simple like the tool shall provide adjustment in height from one to 18 inches. We had that tool we just delivered recently, and a customer and I ran the tool through the required range, and they signed off on it, so-

Michelle Salyer:                Okay, did what it was supposed to do.

Derek Nolek:                     Yeah. And of course, we looked at that during the design and did our-

Michelle Salyer:                Before you brought it to the customer.

Derek Nolek:                     Did analysis before we brought it to the customer, but, yeah. And then similarity is a really good one where you can save a lot of verification system engineering time. You just have to make sure that what you’re comparing, and the idea with similarity is, well, this thing is the same as the last one that tested good, but we made these few changes to it. And so you’d do a kind of an analysis by similarity and say all of these aspects of this thing are the same, so they’re good. These are the things that are different, they don’t affect these quantities of these requirements.

There’s also the argument that, well, maybe there’s an effect that those changes affect all those requirements. You see a lot of this in aerospace where you have an electronic box that does something for the aircraft, and there’s a slight, maybe they took the old chip off and replaced it with a new generation chip that doesn’t have lead. And they say, “well, do we have to do acceleration of vibration and shock testing of the new box all over again?” You can make a very good argument to say no. So, that’s a great thorough method where you can use some… Instead of just testing for the sake of testing, you can make a good argument and say, “Well, no, we don’t do that.”

Michelle Salyer:                That wouldn’t affect anything.

Derek Nolek:                     Right, that wouldn’t affect anything.

Michelle Salyer:                Okay. So, it sounds like you need all of these various methods to test for different reasons, for different things. I guess, why is it important to have this whole suite of tools?

Derek Nolek:                     Well, it’s good because you can select the right tools to balance the risk and the cost. Obviously for some very critical things, you want to test absolutely everything you can, but that would be very expensive. A lot of analysis time and development time, and maybe you don’t have the schedule or maybe you don’t have the trained people to put at it.

The other part of it too, is there are some quantities, I mean, that you can’t test. You don’t want to test a production engine, you don’t want to burst test a flight tank, right? You want to test it to a subset of that. So there’s a good balance between risk and cost. If you look at, for example, back when the Apollo capsules, they put them in a full vacuum chamber. They built a facility to put those in that was the world’s largest vacuum chamber. They put the whole capsule in there, they test fired it, powered it up, ran as many tests as they could on it. It’s still not necessarily going to simulate everything and represent the full environment of space and the mission. But then again, that’s what some of the early Apollo missions were after, right? You’re testing those systems in space so that you know when you get to Apollo 11 that you’re going to have some good reliability with that.

Michelle Salyer:                Well, that was before and after Apollo one, then, correct?

Derek Nolek:                     Yeah.

Michelle Salyer:                Yeah. Wouldn’t all spacecraft need that rigorous amount of testing then?

Derek Nolek:                     Yeah. I mean, if you’ve already proven out your first spacecraft through testing, then if you make a modification or an upgrade or if you want to fix something that didn’t turn out the best the first time around, then you can use that first set of testing as your validation, and then it’s applicable to only test the changes. So that can save months of testing on your second and third and subsequent spacecraft.

Michelle Salyer:                So again, balancing the cost versus risk. Going back to test stands for a moment, or test fixtures also, is there a way to make these features adaptable to accommodate a program’s future needs and the testing that might come along with that?

Derek Nolek:                     Yeah, absolutely. I mean, we try to work with all of our clients. If we’re doing an engine test stand, for instance, we want to make sure that there’s expansion area for a larger engine or a higher thrust. A lot of times, if there’s run tanks for propellants, we can add a blind flange on the line and that can have future additional run tank capacity. There’s many small things that we can do to kind of protect the design for future upgrades that make it way easier to do later on.

Michelle Salyer:                Okay, with much less cost.

Derek Nolek:                     Yes, yeah. I’ve been in programs where it’s been the other way around, where you’re already painted into the corner and you have to expand the design to accommodate the new thing and that makes it very difficult, and sometimes it ends up being very costly.

Michelle Salyer:                Okay. So this future proofing is built into everything you’re doing?

Derek Nolek:                     I try to make it, yeah. I try as much as I can, yeah.

Michelle Salyer:                Okay.

Derek Nolek:                     And we definitely work with our clients to make sure that they understand the reasons behind that.

Michelle Salyer:                It sounds to me like you really know your stuff, but how does this intimate knowledge of testing and verification help BRPH design a test stand or fixture? And I guess, why does it matter to a client that you have these skills when they are also, I imagine their teams are bringing these skills to the table as well?

Derek Nolek:                     It’s more of a, for both sides of the team to understand what’s driving the design of the test stand. Our customers are always under tremendous pressure for schedule, and that goes for their test facilities, their test programs as well. We know the right questions to ask so that they get all the capabilities they need without getting anything excessive. And just understanding that we can give them everything they need, plus try to future-proof it in the same regard. It’s a nuanced, speaking the right lingo, seeing eye to eye with some of the people driving the requirements for the test stand in the beginning.

Michelle Salyer:                Okay. So, rather than just accepting the statement of work and designing to exactly what it might say, are you in some cases kind of pushing back or I guess certainly asking a lot of questions, I imagine?

Derek Nolek:                     We’re trying to look beyond that statement of work and give them everything that they need. Right? So that’s kind of what we’re trying to achieve with it, and see how their testing fits into their overall mission. I think because of that, BRPH is better able to tailor the design of each test stand or fixture to their individual needs for use. Sometimes we bridge a gap between their client’s facilities team and their systems team. And they may not always be speaking the same language, but when we get involved, we can line up the right personnel so that everybody’s on the same page.

Michelle Salyer:                Okay. Everybody speaking the same language on the same page, ultimately improving the design.

Do you have any examples you can share of a time when you were able to influence a design based on your testing knowledge?

Derek Nolek:                     Yeah, so we had a small thruster test stand we helped design. We knew it was early in development and that they would have some challenges. And they even asked us specifically like, “What happens if this blows up? What kind of features?” And so we helped design a frangible roof architecture so that it saves the walls and the foundation and hopefully protects the cell next to it. They can iterate on their design and feel confident that if there is something that goes wrong, the repairs should be pretty minimal. And actually, the roof that we designed for them, it was not an expensive one at all. I mean, it was actually, it fit within their original budget, so it was success all the way around.

Michelle Salyer:                Wow. So you literally blew the roof off that design.

Derek Nolek:                     Well, I hope not. I hope it stays on, but.

Michelle Salyer:                Gotcha. Well, thank you so much, Derek. This has been really informative. I feel like I’m ready to head out into the field and run some tests now.

Derek Nolek:                     Okay. Yeah, I’d hold off on that, but we barely scratched the surface of all there is to know about testing.

Michelle Salyer:                Yes. I’m sure I’m no expert, but we’ll leave that in your capable hands. So, thank you so much for being on the podcast and sharing some of your knowledge and insight on why it’s so important for a knowledgeable AEC firm to be partnering with the client and working on these test facilities. Thanks so much.

Derek Nolek:                     Yeah, thank you.

Michelle Salyer:                Thanks for joining us today for Outside the Box with BRPH. We hope you’ve enjoyed today’s episode, as we explored some of the most innovative and challenging projects, and the most pressing issues and trends in the AEC world. Learn more about us at BRPH.com. Email us at [email protected], and follow us on LinkedIn, Facebook, Instagram, and X. You’ll find this podcast on Apple, Spotify, or wherever you find your favorite podcasts. Be sure to subscribe so you’ll be notified when new episodes are posted. See you next time on Outside the Box with BRPH.