The following transcript is from Interference Technology’s EMC Live: Mil/Aero event that took place March 2nd, 2021 and covered topics like MIL-STD-461 and RTCA/DO-160 updates, design and testing for harsh environments, and IoT applications in military systems.
Good morning, this is Steve Ferguson. I want to say welcome to all the attendees. I’m pleased to speak with this group and all of you that have signed in. I appreciate the opportunity to do my little live event.
The EMC LIVE events give us such an opportunity to gain information and keep our education going through the various tutorials that come up through, not only as MIL/AERO event but other events that are sponsored and placed every year.
These technology updates that we see keep us at the forefront of what’s going on and what’s coming in our lives. I do appreciate our sponsors. They make this all happen here, so let’s all participate by contacting our sponsors, looking at what they do and supporting them.
I look forward to hearing from our array of speakers today. A lot of people will be dealing with planning and solutions. Seems to be the major theme today and some product demos are coming into being.
I definitely look forward to being with us today as we go through the various events and I even get an opportunity to go this afternoon with one of my little tutorial things that I’ve gotten several questions about. So welcome to the event and let’s get right into it.
Well, exactly, what is our purpose in doing the planning phase? A lot of times, it’s contractually obligated. Various integrators of systems and system level things like platforms, aircraft, vehicles et cetera issue a requirement to put together all of the various pieces that fit into that system integration. And with that, they want to be assured that they have compatibility in the design phase. So when it comes time to go into operation, this is a no-brainer. When it goes into the test, things have already been taken care of to do that.
MIL-STD-461, for devices, and MIL-STD-464, for systems, cite requirements for plans and procedures, typically, putting on a timeline to deliver those things. The contract establishes that the obligation for these are there and they need to be approved by the purchasing authority, whoever’s doing the file integration and et cetera. These contracts really call out the delivery schedules et cetera but in general, there is some very early end of the phases of that. The content is prescribed. They layout an outline in the various data item descriptions for the various plans and procedures and it tells us what we’re trying to address.
The guidance that is derived from the planning phase or the procedure development, really confirms that we understand what we’re trying to do. That we understand there is an EMC requirement, we understand what the requirements are, how much the emissions control needs to be, how much the susceptibility management needs to be to where we are immune to various things. It provides direction to the team, anywhere from system guidance to design jobs, to the testing phase, to you name it. These plans and procedures guide all this activity. And it also communicates the understanding to the customers. It tells them that we have a grip on the situation.
We understand the requirements and where they need to go and we have an approach to incorporate things, so at the end of the day, we have a successful program that doesn’t end up in their hands with not being able to complete the system integration because a piece or two has failed the testing phase. These things are very important to keep programs running on schedule and today, the planning phase is very early into the work. So we need to really provide a good thorough understanding of the planning phase.
As I mentioned, the MIL-STD do have requirements for these and they call them DIDs, Data Item Descriptions. They list several of them and these are the groups associated with MIL-STD-464 where the system’s document the 81450B Integration and Analysis Report.
Even though the title says report, it’s really a review of the analysis. What are we going to be putting into our system? What’s required? When I get a piece of equipment, what does it have to do to meet the EMC when I integrate it into the system? Do I have something that’s going to be a sensitive device that happens to be adjacent to a noisy pump? And do I need to look at other control measures?
This integration analysis is really deriving a plan that tells us that we need to plan for other events. It might be the basis for a limit conversion, something different than the normal standard calls out because of requirements. A lot of 464 doesn’t really specify a numeric value for many of the requirements listed there but it gives us, we need to be compatible and so this analysis tells us what it’s going to take to be compatible.
The 81541B, Effects Verification Procedure, is a plan to tell us how we’re going to evaluate it. How are we going to go board an aircraft or board a ship or enter a vehicle and see that all systems are compatible, they work together harmoniously without a radio being keyed causing the autonomous vehicle to run off the road or whatever?
These procedures tell us how we’re going to evaluate that integration that we talked about here. The 51242 is a Verification Report. It tells us the results of that. So is it a planning item? Not really a plan but it feeds for device planning because it tells us if we do have issues that surface during the verification, that we need to adjust our integration.
We go back and look at that and it could involve changing requirements to the equipment level. In other words, the contract says well, you’ve got to meet 461 requirements for your whatever device but it may also say, but there are some amendments to that.
The limit in this frequency range has to be more stringent and et cetera. For instance, if we interfere with the emergency radio band, we may have to limit the emissions in that area much more stringently than we would otherwise. There’s also this 81827, Spectrum Certification and this is a plan that spans from the concept to operation for wireless devices.
It basically is giving us our allowed usage, shall we say, through various phases throughout the development program, including placing it into operation. So what are we going to consume as the spectrum goes? So these things are important. Now, this is a kind of a form that’s completed with the supporting evidence and with today’s integration of wireless devices everywhere, this becomes an extremely important element.
We’re going to integrate something that may already have a commercial MCC approval or something of that nature and we’re going to integrate it into a military system. So we’re going to be talking to the theaters of operation, the spectrum managers for various facilities and locations and et cetera. Are we going to deploy to Europe? Then a part of that will be what’s allowed to be used there.
The spectrum certifications are becoming a little bit more usage, the more wireless things that come about and believe me, we have wireless coming about all the time. It continues with everything growing and the associated sensors and things that we have for wireless events. This becomes a very important issue to be very thorough in.
Well, the MIL-STD-461, the equipment level EMC standard also has a few DIDs called out and most of those deal with these elements here versus the 464 system elements that we just reviewed. So I’m going to spend a little bit more effort on the 461 area.
This 80199C, and the C edition came out, I think it was before 461F, when it was released, so if there are elements that change the letter here for revision when I knew 461 comes out, these DIDs are looked at to see if they’re still usable or not. And the C version, I believe, came out with 461F. This is a control procedure. Fundamentally, its goal is to provide guidance for the design team and confirm the understanding of the requirements back to the customer. The customers and usually the contracts say they want to see this control plan within 60 to 90 days after awarded contract. That seems like there’s not very much time to put together a cohesive control procedure and it wasn’t intended to be.
It’s to provide a general concept to say we understand that we’ve got to meet RS103 requirements at 200 volts per meter. And here are some things we are going to do to incorporate in our design to help us gain that susceptibility control where we’re not overwhelmed.
The control procedure really is telling the design team to do these things. Little things come into being here and it gets the complete design team to be working on the same venue, the same requirements. They understand this. So that’s an extremely important element of doing this.
The 80201C, the EMI Test Procedure, directs the qualification testing and it also gets agreement with the customer on acceptability. And I’m not going to spend a lot more time on that one because as I mentioned, Dean is going to talk about that pretty in-depth.
So I’m going to leave that into his venue to talk about the details and things like that. As a matter of fact, all these details are not going to go in. This is a reminder of what we’re trying to do here. The 80200 is a test report. It documents results and can planning deviations be a part of that?
Well, it’s almost a necessity to get deviations to the plan. Sometimes plans get amended to take care of integrating that but let’s assume that we make minor deviations, get approval.
Something came up during the test that says the plan didn’t understand this and we had to add the deviation into here, or we had to do a modification or we had to do something that justifies putting a planned deviation in and how we incorporated that into our overall qualification testing.
One of the things that we see in all the various DIDs, there’s a very common thread that goes on here, where we’re asked to address each of the requirements. The integration and analysis report discusses every MIL-STD-464 requirement and there are many, many requirements listed and not very many specified or specific limits. It’s generic, you need to be compatible, you need to do this, you need to prevent ESD from harming us et cetera.
And the discussion here looks at how each requirement is going to be met. For instance, the ESD element of it, what are we going to do to make ESD a non-issue? Analysis could establish modifications to the standardized test levels and limits that flow down to the device so tailored tests come about.
It could be that we had system control measures. The design may call for using unshielded cables and we realize that prior application, we’re kind of stuck with that.
I do remember a job a few years back, where I was asked to put in shield terminations via pigtail and instead of the 360-degree turn, they wanted a pigtail. And so I put together a thing using the pigtails and the analysis and the pigtail inductance tends to be a little bit higher than a good 360 termination. So I calculated that into it and realized that in order to meet what I needed to do, I needed about five to six centimeters max pigtail length. And so I put that in the control procedure that we were going to have the pigtail arrangements and we need to manage that to the five, six centimeter ranges.
Well, the customer disagreed with that because he said in our manufacturing phase, our pigtails come out to be 10 to 18 inches in order to run them the way we have to. And I went back and forth and et cetera and I said I can’t do it. You’re going to have to improve your process on installation to get those pigtails shorter and there’s too much inductive reactance to get my shield terminated and meet the limits you’re asking for.
So there has to be a give here. So that’s the kind of an example of why these requirements have to be addressed. We need to take care of that so in that arena, every cable coming to that particular device, the pigtails had to be better controlled than what they first established for building the entire platform.
And this content and that I’m sure Dean will reiterate this, that the communication and understanding are built to convey the message in terms appropriate for the reader. I’m talking to the design team of a control procedure, I’m talking to the test engineers and technicians with a test procedure. I’m talking to the managerial level. So we need to communicate in terms that each of these disciplines is going to fully understand.
And remember, the approval of most of these things indicates an agreement. And now we’ve arrived and agreed what we’re going to do, what our limits are and these requirements should be met and they should work with everybody. So we’ve basically overpowered the generic documents with some detail plans and procedures that give us the guidance we need.
Where does this planning event fit? As I mentioned previously, that control plan, we write that within a few days of getting the contract. That was one of the first things the EMC team needs to do because they’ve got to get this information into the design team. So they can put together their targets, their goals, making things fit and things like that.
What happens is a lot of information comes in for the EMC analysis phase? We bring it into the arena where the analyst takes in the information for the EMI control requirements. What has the thing got to do with the performance issues? And that includes the physical size of the fit and environment concerns that come into this thing.
And we look at this and think, wait a minute, this is an EMI control plan, so what are we doing with all of this information? Well, the environmental thing could give us clues of what we’re allowed to do for EMC and like, for example, selecting a simple power line filter. We look at this and say okay, we need to have this. It’s going to draw three amps of current and et cetera and I need to be able to control this frequency range. So I’m going to select an X, Y, Z filter.
But environmental conditions tell us, well, wait a minute this seems you got to operate in an environment of 50 degrees C and we realize that suddenly that power filter is rated for a 40 C environment. So we have to derate the functionality of the power filter. So we need that information to select, well, we can’t afford to derate it because we’re right on the edge of what it’s allowed to do. So we’re going to have to select a better filter, something that’s destined to operate in that environment. Things like that.
All of the data feeds into this planning phase and control plan development. We feed that over to the design team and they come back and reject it and say well, we can’t do that. So we circle back and do that. So we go through this iteration, feeding back information over and over again. And it could happen very quickly here.
So we’re working with the design team, we’re getting their inputs, we’re discussing. Team meetings help us build a control plan so when it’s documented, we got a starting point. So this control plan may be a series of meetings with some conceptual discussions and the discussions tell us how do we build the document to feedback to the customer to say this is how we’re going to approach it?
And we’ve got the consensus of the design team to say, yeah, I can make that fit. So we’ve got an early element going on here that tends to cycle a few times and we develop that and come onto it. And then what also comes out of that planning phase, some test procedures things that we might want to do some pretest work and the procedures will say, I want you to evaluate a particular model or a purchased part. I can buy something at CE Mart but that’s not going to meet my requirements here.
I need to look at what do I need to do in that module to integrate it into my device to get compliance. So when I integrate the device into the system, we meet our ultimate goal of compatibility at the system level. So these things come about and the test plans feed that. We also have a qualification test plan or procedure, whatever you want to call it, that feeds into this and we also need a plan for what happens afterward.
We get into production and things come up; obsolescence of parts. We can’t suddenly buy particular models of one chip or another. Is that going to affect things? Well, if our planning was thorough, our EMC control plan is going to tell us what we consider to be an important aspect of EMI control. It could be the artwork on a circuit board, it could be a particular chipset, it could be a particular whatever.
And so we need to feed that information back into it. So even during production, as we fix things, we come back to a planning phase but more so if the initial design is documented well, in other words, we put together a control plan and feed it out here and so we’re established. We know what is doing what, that’s important to EMC or EMI.
Don’t let us forget that we’ve got to fit this thing in. A lot of things come into being here. So we pull these requirements together into a good control plan and test plan. And like I said, we’ve got to do this in a seemingly never-ending loop. And it really is never-ending. We’re constantly being beaten up by we’ve quit building those things five years ago and suddenly because of an event, there’s a demand for us to reconstruct those things.
And five years before, we could do these things, what are we going to do? We see events where they ask for a reverse engineering in order to do the same thing again. And we may not be able to buy the same parts and our technologies may have improved where we can buy better solutions and incorporate better things, better artwork into our circuit boards that do better EMC control.
Those evolve all the time. New technologies come about. So planning fits forever. So it’s not just something that starts out, you write it and in 60 days, you’re done with it. It’s a continuing event. So keeping up with it really demands that we pay attention as we go through.
Let us continue to look at the last cycle of the EMI control procedure. From memory, started it out by drafting something and putting together a design team, having some meetings et cetera and arriving at something the design team says we’ve got something we can go forward with. And the design team says, well instead of saying no, we don’t have a design ready, we tell them, okay, let’s push it over the test, build a prototype, build modules, things like that and look at what the test team does with it. Feeds it information of the testing back to us and if it works compliantly, we press it forward so it can be released to production in the test arena. And if not, we come back to the design team and keep running this cycle back through the test group and the control procedure group until we’ve arrived at something that’s ready to release into production. We might build a test article from the production level requirements. I’d be building a production floor, but it’s something that is destined to go to production as is. The procedures for building et cetera are there. So we’ve fed all this information back and if there are changes required, things happen, then we push those back in, keep updating the control procedure and et cetera.
Keep feeding this circle until we’re there. And these events can happen in the long term. So we have these things where no changes were made and we keep going on and on and everything works as it should. I do remember an incident several years ago that suddenly we got a complaint about some pieces providing noise into a radio and we looked at what was going on with it, got the information about the frequency and what was happening and what the unit was doing.
And we looked at that and said, well, when we go back to our control procedure, we experienced that problem in the test phase and it incorporated a modification to put a capacitor on a particular circuit board to solve that potential issue. Well, when we opened the unit up and looked at the circuit board, the capacitor wasn’t there. And looking at this, it seems as though the manufacturing pick and place machine had not been loaded with the component.
It had a flaw when doing that picked item and they built a couple of hundred units, a short production run, where the serial line was reproduced that didn’t have the capacitor put in place. And so we said that’s an easy solution. We put the cap on and we’re ready to go. Solved the problem. It took us three hours to take care of that.
Now because the control procedure clearly documented exactly that problem and exactly what we did to fix it. So we were there. If we had been trying to figure out how to solve this, we might have been a few days in the test area looking to see that the small surface mount capacitor wasn’t physically… in the midst of a very dense circuit board. So keeping the documentation at the end is very important in making this thing realistic.
What happens when we don’t do a good planning phase, when we omit that? We see it over and over again where customers show up at a laboratory without a plan, the details are not there for them. They just said we’re just going to follow MIL-STD-461 for testing a device and so the laboratories are going to try to support that event if they’ve got a lot of things to fill into, to get documentation going on here.
Number one, if I’ve got a contract requirement, I didn’t meet the obligations of the requirement. So we’re going to need to get those procedures et cetera. I have seen many times where people have said I need to write out a test procedure, but it’s not subject to approval because I’m doing my own funding. That’s a myth. If they are going to do a procedure and submit it, even though approval isn’t required, if that thing is found to be less than adequate, the customers are going to be reluctant to buy the product in the end. Believe me, you just can’t walk away from the obligation on the contract requirement things. But under self-development, we see many people try to avoid the added cost of preparation. They see it as an added cost and say that they’re not going to be preparing those procedures.
So without control procedures, the design team is not singing the same song. No focus point for EMC, risk of non-compliance and self-compatibility issues become much more prevalent.
Without test procedures, direction to the test configuration lacks management, requirement specifications are often undefined delaying the test phase. We don’t know what limit applies. So help me, I had a customer show up at a laboratory many years ago and I ask him, well, what limits are we following? Is it army, navy, what? “I don’t know.” So he calls back to the office, “The person who has the answer is in a meeting,” so by noon that day, we got a callback and says that this is what we’re going to do.
And by that time, we had 10 or 12 more questions. Well, even that person didn’t come up with the answers. They had to go back to the customer to get clarification. So a test procedure in that case would’ve saved two days of dead time in the laboratory.
It took two days to get everything configured, set up cable properly et cetera. The test procedure, as Dean will tell you, tells us all of those things. How we’re going to configure it, how we’re going to do things and it was just a major delay.
And long-term support becomes more difficult with that and having knowledge of compliance, how it was attained. I’ve seen this over and over again and I’m discussing reverse engineering phases where they don’t know why people did what they did. And it is kind of a tough thing to try to figure out well, do I need to do that, or is that obsolete? Why is it there?
And we don’t really understand that. So the idea is there. This puts a lot of things in these omissions because we start looking at delays, time-to-market happens and they’re costly as can be.
Design changes that are late in the development are costly. We didn’t plan for an event, so we find out that there’s a problem in the test phase instead of realizing the risk and coming up with a solution before it ever got built. Now we’re into this, well, we’ve already got it built, that’s going to cost me X to fix this.
And believe me, this happens more and more commonly than you can imagine. So using this process, benefits everybody and by the way, everybody gets the team involved, okay? It’s very important to do that.
I’m seeing that my time is running out so I need to bring this thing to a conclusion here. The importance of planning is imminent for many, many pioneers in the electronics industry: Edison, “Planning is the key to success,” Franklin, “Failing to plan is planning to fail.”
These guys knew what they were talking about and this really comes into the EMC world. Planning for EMC is a very important step. We hear people talking about the black magic of EMC, nobody understands it. We don’t know what we’re doing. Believe me, planning is an important element. I went to work at a company a few years ago to find that they were going to the laboratory and failing 75% of the time.
So they went to the laboratory to find out what was wrong with it. I started implementing changes to how we approached the design and getting people involved with the design, building control plans during self-development, making this an important step and educating the team about it, calling meetings, getting people involved, pulling the team together and to do that, resulted in the next three years at that company, the laboratory pass rate was 95% instead of 25%.
Tell me that wasn’t an important step forward in the design team’s attitude. Now they have a realistic plan to go forward. People are not placing the emphasis on planning for these things and I brought that into being with my team at that company. We gave them a focal point in support. They weren’t trying to be EMC people but they needed support. And the digital design or the power of people, you name it, the RF people et cetera may have heard about EMC but they weren’t looking at control. That wasn’t their big event.
So having support made that whole program of development a much more seamless operation. And I involved the entire team. Successful programs require everybody to deal with it. And I mean the entire team. Procurement. Now the purchasing people needed to know not to buy a part without approval. Don’t change this. This is the approved supplier and until you get approval, nobody else does it. The quality control people got part of signing off the plan.
Production. The engineers that support the manufacturing phase, the people that operated the plant, understood that EMC was not something unimportant, that their changes affected the role and we went very thorough on documenting these things with enough listings to where people could actually find the information.
We communicated to those people. So it made this very important step a very fluid operation. So I challenge each of you to bring planning into your requirements. Be thorough, be adequate, look at things realistically. What can we do and make it a party to do that? With that, I’m going to open the floor for questions.
Please visit the EMC LIVE website to view this webinar and other webinars from the 2021 Mil/Aero event.
