Electrical Systems podcast (Ep. #4): “Addressing Electrical Design Compliance and Certification”

By Scott Salzwedel

As we experience higher levels of complexity throughout the industry, the traditional approach to electrical design compliance and certification needs to evolve.

Not only are we dealing with more complexity – we’re also in the early stages of widespread innovation.

One approach that’s helped A&D teams is model-based design. But what if we could go further? What if teams introduced the comprehensive digital twin and digital thread into electrical systems compliance and certification?

In this episode “Addressing Electrical Design Compliance and Certification” we’ll be looking at ways to achieve compliance and product certification in today’s competitive marketplace.

Listen to this episode now.

This is episode four in a five-part series.

With increased complexity throughout the industry, the traditional spreadsheet-based approach to compliance is no longer an option. New innovations along with the increased use of electrification are forcing OEMs and their suppliers to consider new ways to achieve electrical design compliance and certification.

Welcome to Talking Aerospace Today – a podcast for the Aerospace & Defense industry. The place that brings the promise of tomorrow’s technology to the ears of our listeners today.

In this episode “Addressing Electrical Design Compliance and Certification” we’ll be looking at new ways to achieve compliance through a model-based approach as well as how to best utilize the comprehensive digital twin and digital thread. We know this is a time of great innovation and transformation for the industry – and when it comes to electrical system compliance and certification, there’s a lot to cover.

Today, two industry experts from Siemens Digital Industries Software join the podcast. Anthony Nicoli is the Aerospace & Defense Director of Integrated Electrical Systems. And Steve Caravella is a Solutions Architect from the Capital Team. Both love to talk about how the digital transformation is altering the electrical system design and development landscape – for the good of teams everywhere. 

My name is Scott Salzwedel and I’m the host of Talking Aerospace Today. I invite to take a listen to our latest episode on electrical system design compliance and certification.

I hope you’ll tune into this extremely informative podcast.

In this episode, you will learn:

  • The reason why electrical regulations today are far stricter than in the past (01:45)
  • Methods to address increased complexity when it comes to compliance (04:33)
  • The approach used for connecting the separate environments in the manufacturing process (06:19)
  • How the electrical digital twin helps with the certification process (07:32)
  • Why there’s an increasing need for a “digital wingman” to help identify errors (09:00)
  • How the type certification process works (11:00)
  • How the digital twin and digital thread can help standardize the compliance process (14:04)
  • A customer had to learn the hard way to use model-based techniques (14:52)
  • Platform differentiation through increased electrification – new compliance challenges (18:22)

Connect with Tony:

 Connect with Steve:




Scott Salzwedel: Hello and welcome. This is Talking Aerospace Today – the podcast for the Aerospace & Defense industry and the trends that drive the digital enterprise – a place that brings the promise of tomorrow’s technology to the ears of our listeners today.

I’m your host, Scott Salzwedel. Welcome to episode four of our five-part series.

In this episode “Addressing Electrical Design Compliance and Certification” we’ll be looking at how the traditional approach to compliance is no longer an option, especially with increased complexity everywhere you look. We know this is a time of great innovation and transformation for the industry. When it comes to electrical system design and development, there’s a lot to talk about.

Before we begin, a reminder that our previous episode touched on change management. I urge you to give that episode a listen. You’ll find Talking Aerospace Today podcasts on iTunes, Spotify, Stitcher, Google, or wherever you go and listen to your favorite podcast. I’m excited to get started.

In this episode, I’ll be talking to Steve Caravella – a Solutions Architect from the Capital Team at Siemens Digital Industries Software – and Tony Nicoli, the Aerospace & Defense Director of Integrated Electrical Systems for Siemens Digital Industries Software. Tony and Steve love to carry on about how the digital transformation is affecting the industry. It should be a great conversation. Let’s talk compliance. Steve, I’ll start with you. The one thing we can say about compliance today is that the regulations are far stricter than, say, 20 years ago. In the mid-1990s, we experienced a major turning point. There were a bunch of mishaps that caused the FAA to tighten things up.

Steve Caravella: There were really a couple of events that were catalysts for that. There was the TWA out of the east coast that the conclusion was it was some ignition source that ignited the fuel tank and blew the airplane apart. There was that, there was a Swissair MD-11 that had a fire in the overhead due to inflight entertainment wiring. Unfortunately, there was a combination of things, there was the wiring shorted, created the spark, they had capped-on insulation there which wasn’t fire-resistant enough.

Tony Nicoli: If you look at the TWA 800 that was in 1996. It wasn’t long after that the EU’s regulations became much more stringent, and people doing new projects had to comply with them.

Steve: I remember distinctly after those events when they traced them to wiring, the level of scrutiny and expectation for the design and the design data really started going up.

Scott: Steve, with these tighter restrictions, how did it change your job?

Steve: What that led to was really the level of detail and integrity of the engineering data had to go way up. At this time – and again, we were doing this project and it was the first one where the scrutiny was coming into play. I remember that we wrestled quite a bit with how to do that. When you get into the physical routing, that’s more of a mechanical design aspect. Of course, you need to know what’s in the wiring from an electrical design standpoint, but we debated do we use a 2D CAD system and make drawings? Do we do it in 3D space? And again, keep in mind too, that this was before model-based design really was established. It was a tough challenge because you’re looking at literally hundreds of engineering hours now to draw the wire routing and clamping positions and whatnot. Whereas before, the installers on the airplane would just follow general good practices, guides to do it. You can imagine the cost impact of doing that. Of course, now we’ve got model-based design, so people are more accustomed to the modeling, we’ve got better electrical design tools.

Scott: Yes, the model-based design approach in Capital has made life easier for electrical engineers throughout the industry, no doubt about it. But before we talk about Capital and Xcelerator, I want to focus on aircraft complexity and how that affects certification. Tony, what are the methods used today to address increased complexity when it comes to compliance?

Tony: When we actually started to interview a number of customers before we started to address this problem in the context of the electrical systems development flow, what we discovered was that most of the methods that people were using to analyze compliance to the regulations and then report them out were disconnected from the development process. People would do the design in one environment, but then they had completely different environments, often old, old environments or Excel-based environments – you know Excel-based kinds of analysis tools to actually ensure that they were meeting some of the analytical needs like electrical load analysis and that sort of thing in their companies.

And then, they had yet another environment, a third environment, where they take all that analytical data and reduce it and produce reports that could be consumed by the DERs and the AERs who were actually providing the oversight and the approval at the end of the process to check off at least that aspect of moving towards type certification. This was a very long process, it was like weeks and weeks. What we were told would happen is that people would be doing a design, they put a line in the sand on a rev, they’d send it off for compliance or evidence analysis. Meanwhile, they go off and continue to evolve the design. This analysis took six weeks and discovered it was a problem, they’d come back and the design just diverged to the point where there was substantial iteration required in order to address the problem that was found during the certification analysis.

Scott: All those separated and disconnected environments. So, what did you tell your customers?

Tony: The approach we took was actually to work towards allowing people to exploit the electrical digital twin, or essentially the model that is derived or developed and enriched of the electrical system, as design goes forward and integrate the analytical tools associated with doing design and analysis such that those analytical tools would directly access that digital twin as the designer modifies it. So that the certification analysis would be done contemporaneously, nearly instantaneously – they could go make a change and they could then as part of their own verification of that change, run the certification analysis and see the result. I call it exploiting the configuration control digital twin because as the designer makes these changes they can save different versions and actually keep track of those versions and then have the analytical results that correlate to those versions on hand.

Scott: So, what we’re talking about here is how the electrical digital twin can help with the certification process, how teams can run a certification analysis, and then keep in share different versions?

Tony: Yeah. And there’s another aspect of doing this in a model-based environment that has built-in automation is that you can use design constraints and design rules to get the big things. Let’s say you have an obvious separation requirement between two signals, two different types of signals, that you can actually have the tool continuously monitor the distance between those signals. And when you inadvertently violate that it can tell you so that you catch that before you have to run any verification at all. So, other things like that can actually be programmed in. Your design environment becomes your coach. The computer is looking over your shoulder to make sure that you don’t make the wrong play, as you actually start doing some of these innovative changes.

Steve: I think that’s a huge capability. Because as much as you try to educate your design teams, get them following the rules, you’ve got to put yourselves in the shoes of the design engineer for a second.

Tony: And that process makes total sense because frankly, humans just aren’t good at that detail checking. We’re not built for that. We’re good at doing things that come out of our evolution: seeing threats and running away or capturing prey, one of the two. You can think of innovation like that – coming up with new ideas and applying them. But doing routine tasks over and over again is just something that we’re error-prone at. And so if you can have a digital wingman to actually help you not miss those tiny things that you might forget at the 11th hour when you’re trying to make that change that just came in. I think it’s a huge boon and it reduces the cost and the risk associated with the overall program. In these days, the risk of missing a certification issue has really gone up. There’s been an increasing number of incidents and it’s on people’s minds. I think that people’s attention to regulatory compliance is only increasing as we go into 2021 here.

Steve: So, your design team, they’re smart people, they’re somewhat versed in the regulatory requirements, and there are practices and methods that companies adopt to. Think of it as there’s a process they follow and some rules in their design approach to really address and prevent problems with the certification piece, the compliance piece. You get your engineers to follow this, and they will find things and they fix them and you have your DERs review it before it gets released. So, again, they find things and you can fix them while it’s still on paper or while it’s still a model in a computer.

The trouble is that’s only so effective. Inevitably, and hopefully, it’s not the major things. You find these things once you have things built, or as you’re building, or even worse, as you’re testing. And let me talk about that process a little bit. When you’re going for type certification, you’re really having to do the test three times. So, what you’re going to do is you release the design, you’re going to build your hardware, and then you’re going to do development testing. Does this work how I want it to work? Does it function the way the customer wants it to function? And then you’re also going to look at, is this going to meet the regulations? So, you do that and usually, you’re iterating your design and you’re maturing it. At some point, you’re going to get a mature design and you’re going to update your test articles. At that point, the FAA is expecting you to fully run the certification test as a company and pass it before they’re going to come and spend their time to watch it.

Scott: The FAA, we haven’t talked too much about these guys. Tony, what’s been your experience with the FAA?

Tony: I never did the work with the FAA but I used to do it with the Defense Acceptance Authorities. The guys that I would work with for acceptance testing and then sign off and selling of our systems, they always wanted information in a particular format. If you were outside of the regular format that they used or they were used to, maybe they wouldn’t reject what you discussed but it was a lot harder, it took a lot more time, a lot more effort to convince them that what you were saying was correct. It stands to reason they know their format, they can assimilate it in their environment. The thing about that is that you have to take all this analytical information that constitutes the evidence of compliance and cast it into the reporting point, and that can take four to six weeks to do that on a manual basis on its own. One of the things that we went after was to actually, I mean, we’re in a digital environment. You have a digital twin. You’ve got a digital thread, use it!

So, we created this ability to put these templates together so that you could actually sit down with the person that’s going to come in and look at your evidence and say, “Well, what’s the best way for you to understand it?” Not from the perspective of you’re going to influence this guy to make a wrong decision. It’s really to provide him with the easiest way to make a good decision about whether this thing complies or not. And once you get that codified, you save that as a template. And you can run that analysis over and over again and just automatically populate that template and put it out there. And everybody can then standardize on a format that is easily generated, consistent with what the regulatory representative is going to use to make a decision, and something that you can all use over and over again, very quickly. And when I say quickly, I mean, like in minutes, you get a report, not weeks.

Scott: It’s so important to standardize. That’s one way to meet compliance as complexity grows. I think we’ve talked about how the digital twin and digital thread can help standardize operations.

Steve: Right, and that’s something that I think doesn’t come to the front of our mind when we’re thinking about this and even talking about compliance. But achieving a level of standardization that leverages pulling information straight from the system, uses information straight from the system. Once you standardize something that is found to be acceptable, then it’s available and it’s easy for people to use and you have a high degree of confidence that the method you’re using, the analytical method you’re using, the way you’re presenting it in the templates is going to be good.

Tony: There are a couple of other things and points I want to make. One is that there is a case of a customer of ours that had to learn the hard way to use model-based techniques. It actually motivated them to move entirely to a digitalized process for electrical development. In that case, this customer was doing a very time- and cost-sensitive variant on a commercial aircraft, customizing it for a defense application. And they were under the gun to their DOD customer. They ended up doing the development, they ended up designing the whole ecosystem and they designed a lot of the mods. And they tried to get a jump on the production phase of the program. So, they built six aircraft. By the time they got the sixth one done, they discovered a critical compliance issue with signal separation problem that could not be easily retrofit. So, they had to go back and we designed the electrical system for that whole production run. And then they had to retrofit every one of those aircraft and it ended up costing them literally billions of dollars, to not just go find the problem, redesign it, but then to do all of the certification work again, all the testing work again, and then all the retrofit work on those six aircraft. The whole point of that story is that not being able to do this kind of virtual integration and virtual compliance testing – think of advanced analysis on the entire electrical system as a way of doing virtual testing. It’s very high stakes, especially when you’re doing programs that are just major variants to what you do to a significant platform. I know I’m being a little cryptic because I’m not allowed to say who that is, but it’s a serious issue and it can have serious implications for the company.

Scott: A really good example, Tony. I think our listeners get the idea without you having to name names.

Tony: The other thing I wanted to mention is that this work is really in its infancy. It’s really only in the last, I’d say, three to five years that the Aerospace & Defense industry has really prioritized moving to model-based approaches for electrical system development overall. In our work, it’s only in the last three years that we’ve gotten to the maturity of integrating analysis seamlessly into the digital twin and accessing the digital twin this way. I think there’s a LOT of room to grow here and a lot of productivity and improvement to be had. Right now, we’re focused on things like electrical load analysis, wire derating, and signal separation checking. But I think there’s a lot of headroom. These are just three aspects of electrical system certification and there are many that we haven’t even touched yet.

Scott: Tony, we’ve been talking about compliance and how the digital enterprise, which includes Siemens Xcelerator Portfolio can alter the landscape for our customers. The one thing we haven’t touched on is platform differentiation through electrification and how that affects compliance.

Tony: Electrical is increasing in importance in platform development and in platform differentiation. The missions that people need to accomplish with their platform are getting much more complicated and much more ambitious, and the capabilities that OEMs are putting into the platform necessitate electrical systems, more software, more communication networks. All these things are adding to electrical system complexity and it’s driving the difficulty of the electrical portion of the compliance activity. Even if it’s not a brilliant function like fly by wire or new communications capabilities, even if it’s simply, “I want to improve the reliability of my aircraft”, moving to electrical, really reduces the amount of issues that come up in hydraulic, pneumatic, and mechanical systems. The hybrid systems are much more reliable, they’re also lower weight because you don’t carry around all that extra tubing, mechanical linkages, you do that with a much lighter wire. There’s a lot of advantages just in the base functionality of transporting things and the base efficiency of the aircraft going into these electromechanical hybrid systems.

Scott: Good point, Tony. All right guys, really good stuff today, but I’m afraid we’ve run out of time. My sincere thanks to both of you.

And of course, I’d like to extend my deepest thanks to our listeners. Thank you, listeners. I’m glad you tuned into this podcast.

At the top of the show, I mentioned we’ll be doing a five-part series on “The Evolution of Electrical System Design in Aerospace.” If you enjoyed this episode and you want to check out previous shows, please take a look at the links in this podcast description. Be sure to subscribe to Talking Aerospace Today on Apple Podcasts, Spotify, or wherever you go to listen to your favorite podcast. Subscribe now and you won’t miss a single upcoming episode. Our next episode will be our final episode. Already? The topic will be on wire harness manufacturing and profitability. It’s going to be a great conversation.

My name is Scott Salzwedel, and this is Siemens’ Talking Aerospace Today. I hope you’ll join us again for our next podcast. Until then, bye for now…


Connect with Tony:

Connect with Steve:


Talking Aerospace Today Podcast Podcast

Talking Aerospace Today Podcast

The A&D Industry is at a serious inflection point. Transformation to the digital enterprise has opened up a new era in innovation and technological breakthroughs. However, complexity and compliance continue to hamper the best of efforts.

Join us as we explore how Siemens is turning complexity into a competitive advantage for many of our customers – today and well into tomorrow.

Listen on:

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/podcasts/talking-aerospace-today/electrical-systems-podcast-series-ep-4-addressing-electrical-design-compliance-and-certification/