Print
94th General Meeting Presentation
08/14/26

94th General Meeting Presentation
“A Framework for Evaluating Unmanned Aerial Systems-Based Inspections in Critical Infrastructure”
Paul Coco

The following remarks were delivered at the General Session of the 94th General Meeting on May 11, 2026. It has been edited for content and phrasing.

INTRODUCTION: Paul Coco joined Hartford Steam Boiler in January 2014 and is a senior engineer in the Codes and Standards group, where he provides technical support for nuclear construction and inservice activities in accordance with ASME Section III and Section XI and their associated conformity assessment programs.

He also develops and delivers technical training on nuclear construction, inservice inspection, international codes, and regulatory requirements, and supports the HSB NQA Services Program. Coco serves as the technical lead for HSB’s remote inspection initiatives, third-party nuclear and ISO 19443 inspections, and emerging renewable technology efforts.

Coco served in the U.S. Navy from 2002 to 2010, including as a professor at the U.S. Naval Academy from 2007 to 2010.

His slide presentation can be found here.

MR. COCO: Thank you for letting me speak about a topic that I'm very passionate about: The use of robotic inspection and remote inspection.

What I will present to you is the path that led us to the development of MUS-1, which is basically a UAS standard for Unmanned Aerial Vehicles to do remote inspection activities while also meeting code requirements.

I am a senior engineer at Hartford Steam Boiler, the world’s largest AIA (Authorized Inspection Agency). We have a global reach of over 450 inspectors, operating for over 160 years, providing not only training services but also design services. We're a notified body and work with several other codes in addition to ASME and the National Board.

Let’s talk a little more in detail about the overview. We're going to look at the inspection deployments and how we arrived at this path. Much of this has to do with how the technology we currently have enables us to perform safe remote or virtual inspections using remote platforms or robotics. We also had to contend with the way that the code was written, how it was written to assume that you would have to have a physical presence, and how that language has changed and evolved as technology has evolved as well, and some of the activities for that.

The group I was with, MUS-1, was predominantly formed in 2017. Most of our development was during the COVID era, as I like to say, because COVID exposed gaps in the code that we had to address to make remote inspection a reality. Again, that goes back to remote inspection. The presentation will address that as well.

Then we wanted to make sure that, as we're developing a standard, we didn't have one-offs every time someone used some type of robotic inspection. Therefore, the purpose of this code was to provide a defensible framework for remote inspection while preserving the inspector's authority and maintaining the safety of the items inspected.

To give you a little lowdown, if you're not familiar with the evolution of Unmanned Aerial Systems and where they've come over the last 20 years or so, they have evolved quickly to where they are today.

So, starting in the early 2000s – I call it the DIY garage era because that's where my wife sent me every time I was working on these types of projects, since my workbench looked like the Unabomber's bench. That's what some drones looked like at this time. It was people who were participating in an open-source type of code who would basically hack video game controllers to extract the accelerometers and Gyros to create a platform that could fly and remain stable in the air. These were put together with wooden dowels and brushless motors and looked like a kind of aerial Frankenstein-type helicopter.

The biggest innovation in the industry was the advent of the smartphone around 2007. You may remember the iPhone 2G. The reason that that was such a pivotal moment within the industry was because that such the high demand for not only Apple smartphones, but other companies competing with smartphones, drove the costs of small chips, such as Gyros, accelerometers, GPS units down to a smaller size and scale of a level where it made it affordable and reasonable to go ahead and incorporate that into the design of the earlier Unmanned Aerial Systems.

In 2013, we had the first commercially available turnkey option: DGI. That drone was called the Phantom 1. People would hang a GoPro underneath it, and it was the first time you could get digital or video imagery of items you wanted to look at.

The evolutionary step came in 2015, when 3D Robotics introduced the Solo. This was widely commercially available. And it was considered a smart drone, with all the technology. They used much of the open-source technology developed in the early 2000s, and they significantly evolved that to make a stable platform.

Finally, right up to the 2017 time frame, in which we had our first industrial enterprise solutions and drones, as you would see or UASs today, are quite similar to the role that you currently have to unleash this. That last picture is the M200. A lot of police forces had it; many inspection units did, and most of the development came from improving this platform.

So, where did ASME get its tasking from this? About 2016, a task group was developed: The Unmanned Aircraft Systems Standardization Collaboration. This was an ANSI project that brought multiple standards organizations to the forefront to develop codes and standards that would apply not only to aerial systems but also to other robotics systems.

ASTM led the way in the development of standards for the construction of UASes. Whereas, ASME was assigned as part of the gap analysis for the use of Unmanned Aerial Systems in the inspection of power plant industry processes, and they found it was sufficient. Our first code meeting took place in 2017 to evolve the code development process.

To make sure we were heading in the right direction, we had to break it down to its fundamental steps.

This graphic is in our code book, which shows the development. It shows how uncrewed aircraft and UAS systems fit in the overall inspection process. The intent was to emphasize that the successful use of drones for inspection is not as technology-driven but asset and code-driven. We considered the different assets and users in stakeholder cases where such platforms would be used. From there, we started developing the requirements.

At the top level, we had different assets, such as piping, tanks, vessels, boilers, and so on. Each asset drives its own access issues, so you have a unique risk profile, regulatory requirements, and means of inspections that need to be defined. Once that's understood, we move down to the platform selection to dictate whether the inspection must take place, where the inspection must take place, and what type of platform, whether you want to use a fixed-wing or a rotary-wing type platform.

We had to take environmental considerations into account. In this case, many assets were in hazardous, wet areas, elevated electrical-safety-classification environments, or traditional access exposures that put inspectors at actual risk.

There was also a focus on sensors and on what data you would need, so whether it's visual inspection, infrared, ultrasonic, electromagnetic, or gas detection, and what was needed to ensure success. From there, we had to overlay the inspection criteria. It was critical that this code did not develop a separate set of standards and acceptance criteria from already established codes. These were meant to be complementary to which you would establish a payload that would provide the data that you would need, that would be compliant with any type of NDE method or analysis that you would see in Section V. Also, the codes establish acceptance criteria as well.

Finally, we arrived at the end results. When we further dissected Section V, it is obvious that Section V is the authoritative source for NDE and inspection methodology. And these included visual inspection, penetrant testing, magnetic particle testing, radiographic testing, ultrasonic testing, liquid penetrant testing, and Eddy testing, so you have the entire list there.

We decided that, to see what the best use case was and what was currently being looked at, we went for the low-hanging fruit. We wanted to use remote inspections with cameras because they were already used in the code to some extent. However, this was determined back in 2017, and we started developing the code based on that. And then we finally had our first real-world opportunity as global operations were significantly disrupted with the shutdown in March 2020 due to COVID-19.

The COVID era gave us unique opportunities. At this point, we were asked to look at how, based on what we were developing, we could deploy this technology to certain sites to alleviate some of the inspection backlogs. Although the robotic deployment assets weren't fully mature, this also served as a dry run of what we envisioned MUS-1 to become.

Rather than relying on robotic platforms equipped with payloads, such as cameras, we used on-site individuals with remote links to an inspector, who provided real-time direction, enabling remote inspection while closely approximating the function and intent of robotic inspection.

We also knew this was a question that had to be answered and studied prior to moving forward with the code. This gave us an opportunity to get real-world results and then solidify the process workflow in the code itself.

Further restrictions that we had imposed interrupted traditional inspection practices. Everybody lived through that, so everybody is familiar with the travel bans, lockdowns, quarantines, corporate safety policies, face masks, and the fact that our inspectors stationed on site weren't able to enter because they weren't part of the employee pool there.

Before COVID-19, the boiler pressure vessel code was written with the implicit assumption that on-site inspection was required in its presence. So key terms such as “witness,” “verify,” and “inspect” were not defined in terms of observer locations. However, it was the intent when the code was originally written, without the forethought of what the future might bring or how inspection techniques would evolve.

While ASME Section V did allow alternative indirect visual examinations using cameras and other tools, these allowances only applied to inspection techniques and did not extend to Authorized Inspection roles. Technology existed to support remote observation, but the code framework did not clearly support remote execution. The pandemic exposed the fundamental ambiguity of the code. Inspection outcomes were defined, but the inspection mechanisms were not. The original intent assumed direct human observation, while modern technology enables real-time two-way video communication. Some of the code cases you see here were efforts by ASME, NBIC, and EPRI to establish very simple requirements for properly conducting remote inspections.

Once we have the jurisdictional and the STO go-ahead to conduct this, the big question is how to conduct an eye exam to establish human equivalency to an inspector using a camera? We started tackling what the industry standard for that was, and luckily for us, in 1951, the Air Force developed it.

This is the size of a stamp. And this was deployed at different test locations, where certain aircraft could take pictures to determine the resolution level. We adopted this into MUS-1 and then we worked with our counterparts in QAI to establish minimum resolution requirements of 1/32 or 0.8 millimeters along with the light intensity of 100-foot candles to establish what the hard requirements are in order to properly qualify a camera for human equivalency based off the requirements that were set forth within the code and what the exceptions criteria was for detecting various different types of anomalies.

The Air Force wasn't the only one using similar technology. NASA has also done this for many, many years prior to this. A couple of people at NASA who worked in this department said they have a similar placard like this, where you would have that small eye chart, color chart, and then also a coin, which is something of known structure that once a camera is put online, it would calibrate to those items, and then they would send pictures back to earth. This is Voyager 1 and Voyager 2. And this is the Curiosity rover, which is currently on Mars.

At HSB, as we're doing field testing to validate what we could use to do this, we had in-field optical resolution testing for visual examination, where we developed our own stamp. The stamp basically took into consideration different types of scales. The way it worked was that it corresponded to the minimum feature sizes that needed to be resolved within the code. By capturing the image with these elements very distinctly and visibly, the inspection system demonstrated that it was reliable to detect features or equivalency for small sizes and actual points.

One of the other unintended benefits of this is that once we put the stamp in frame, it also was able to sharpen the resolution on the picture and allow the camera to focus as well, because as you're holding a camera closely to the surface of a metallic vessel, that void of any type of discernible marks creates a challenge to focus in on, but that created a focal point for the camera to focus the whole entire frame.

That gave us a scale, and this is about the size of a postage stamp as well. We deployed these to our inspectors globally as an aid for inspection in a similar process, as this was also adopted at QAI for their code cases.

As I said, Section V included language addressing remote visual inspection. We took that a little further and codified it to address targets that are normally handled in Section XI as a use case, and also invoked an ISO standard, which was in development at the time, to have that, along with the Air Force 1951 resolution charts.

Here you can see where Section XI also meets that, with its different requirements for visual examinations that meet VT-1, VT-2, or VT-3. The other side of the coin is that, to be successful, you had to understand which mobile uplink you were using. At the time, we were learning to use Zoom and Teams, and we held virtual meetings for ASME on them. I would assume that, to date, we are proficient in that, but not all of these platforms are created equal. Some of these platforms are more focus-driven, reducing resolution to preserve bandwidth, while others are more inspection-driven.

It was important to understand not only the use of these platforms but also their uplink. They could be in harsh environments, industrial sites where you might have all kinds of RF interference or process workflow interference, and limited bandwidth capacity. High-resolution videos can still be produced, so the inspector on the other side can validate the results and document them properly.

You also need to validate redundancy, so you might want to run a test before the actual inspection to make sure that all the infrastructure is in place to produce reasonable test results. This was also recorded for retention. Then, for pre-service examination data, it was used and later audited to complete documentation on the nuclear side.

I’d like to stress that the acceptance of robotic inspection has the items that we learned from remote inspection and puts them back into MUS-1. Did that robotic inspection, such as UAS (your aerial platforms), crawlers, or submersibles, alter what was being inspected or the criteria for acceptance?

Acceptance of the remote inspection came before the robotic platform could be used. Inspection programs needed to recognize that remote visual observations were as valid as witness verification and documenting inspection activities. Without this acceptance, robotic capabilities, no matter how advanced they became, had no regulatory footing. We saw this as a big hurdle that we overcame during the COVID time frame.

Remote inspection also enabled robotic deployments once remote inspection was accepted. Inspection capabilities could be evaluated based on performance, resolution, lighting, integrity, and also inspector authority. Oversight was preserved by the fact that we recorded the various engagements. And then COVID-19 accelerated this.

This is MUS-1. This standard was published in the latter half of 2024. MUS-1 defines how Unmanned Aircraft Systems may be used to support industrial inspections in safe, repeatable, and dependable manners. It focuses on the deployment and process control, not the inspection acceptance criteria. This was written more as a plan-and-risk assessment and site preparation for UAS-supported inspections, where it was performance-based on the aircraft, camera, lighting, sensors, and handling equipment.

The chart I showed at the beginning also relies on the book on how to properly assess what you're inspecting, the environment that you're inspecting with, and understanding not only the limitations of the platform, but also what the pilot can do within that inspection space in order to ensure that you have a safe inspection.

Also, we looked at the roles and responsibilities of the asset owners, UAS operators, pilot-in-command, and qualified inspectors. Then we looked at the controls that need to be in place, such as communication, documentation, and records retention, to support inspection traceability.

As I said before, this does not change the inspection criteria set in the codes. It does not define inspection limits or alter them just because you're using an MUS platform, so you still have the same rigor of meeting the inspection criteria as if this were done in traditional methods. It does not replace the inspector's judgment or authority. We have not adopted any AI detection techniques or anything like that that would override the need to keep a human out of the loop.

To give you a breakdown of the table of contents: If you were to look at the code or the standard that we have established in this case, it was planning for risk management and site preparation, equipment selection, recommendations on selecting UAS platforms sensors, roles and responsibilities, data acquisitions, protocols, and also data collection.

MUS-1 is more for your reference as notes, but well-organized to follow a logical progression of inspection from initial planning through execution and reporting. Earlier sections address the preparation for the inspection, including mission planning, risk analysis, site evaluation, and communication among the owners, inspectors, and the UAS service provider. These sections establish the foundation of safe operation and clear expectations.

Many of the groups of MUS-1 were asset owners and utilities that were using robotic inspections and that had developed robotic inspection groups within their organization, but we're looking for a set of standards or guidelines to follow to make sure that they had repeatable results and were doing inspections safely.

The central risk you would see reflected in MUS-1 is that UAS operations introduce a unique risk alongside their benefits. The standard requires a formal risk analysis to identify hazards before interacting with personnel or equipment. Whether you had confined indoor spaces, areas where you might lack GPS, or unique navigation or console systems that had to be set up inside a boiler or piping system for the crawler or aerial asset to properly navigate and fly.

UAS-1 mandates clear definitions of takeoff/landing zones, emergency procedures, and stop-work authorizations. It also has roles for visual observers and safety spotters to address risk mitigation, particularly in complex and dynamic environments.

You also need to consider battery management, safety settings, loss-of-link procedures, and emphasize preventing uncontrolled aircraft behavior. It does not assume that automation eliminates human responsibility. Again, there's still a human in the loop and a pilot operating the asset. The pilot in command retains accountability for safe operations, and a qualified inspector retains the responsibility for inspection decisions. Those are typically two different personnel.

By integrating UAS-specific standards into familiar safety management processes, such as shop safety analysis, MUS-1 organizations enable inspectors to apply established safety principles to new technologies.

To give you a breakdown of the structure today, MUS-1 was removed from Section V's control and transferred to the Board of Standardization and Testing. Underneath that, you have a MAM Standard that covers robotic arm manipulation; the B30 Standards, which deal with crane inspections; and the Mobile Unmanned Systems, which are broken down into UAS/UAV (MUS-1), which is currently published. And then we have two sister standards in development for ground crawlers and submersibles for underwater inspections.

What are the future developments, and where are we heading with this? We're looking to develop the other MUS standards as well, as I said, such as crawlers and submersibles, establish best practices for data collection and processing, considering the AI revolution and see how that would impact us.

Also, regarding regulatory alignment and safety protocols, most of the regulatory alignment currently is for extant conditions, as the original code cases were.

The Technical Oversight Management Committee for ASME had a working task group to establish a mainstay for using remote visual inspections. And I know that there was also some interest in the National Board as well. You also have integration with industrial safety systems. In this case, it's taking that data and providing it to show valid information. For instance, you now have crawlers that can perform point-contact UTs that meet the requirements. And then, from that, they can do a 100% mapping and calculate the useful life of a vessel as they inspect it.

We also have to look at the validation of new sensors and how they are incorporated into the code. We already cornered the market on visual inspections. We also need to look at THERMAL, UT, and LiDAR. And then also look at the training framework and workflows that are established to train operators properly and also end-users on how to use the code properly in a safe manner.

I'll open it up to any questions.

MEMBER: How do you validate the UAS and GSB in probable detection – close visual inspection, identifying the hairline corrosion?

MR. COCO: With the visual examination, there's technology out there that not only based off that postage stamp for the optical sensors that we have there, but most of the UAS operators are producing these technical platforms that have what's called a bumper distance of what is the max distance that the platform can be in order to properly detect any type of anomalies, would that meet the threshold for the inspection criteria?

With that, not only do they look at an angle coming on, but they can also look at angles of light to the actual thing that they're inspecting in order to develop a spatial awareness of a three-dimensional structure as you're seeing it on a two-dimensional screen.

MEMBER: You mentioned AI, and you guys really haven't dived into that portion of it.

MR. COCO: That's correct. Early on, we had some concerns about AI. When we started looking at remote inspections, smartphones were getting really, really smart. When you took a picture, it would use automatic settings, and we were concerned that it would self-correct, make the best-looking picture, and then erase any type of anomaly.

That was one of the restrictions that we had with AI. We quickly found which off-the-shelf cameras could do something similar and what countermeasures we would have to take to protect them. We’re currently in the development stage within the code, addressing how AI would fit.

We're looking at more of this perspective: For instance, if you're doing a reactor vessel or a concrete inspection containment, it can stitch those pictures together to create a three-dimensional model. As you have that three-dimensional model, it doesn't remove any type of artifacts that are, in fact, actual inclusions or defects within the structure.

MEMBER: You guys are actually looking at the AI's potential, because while it does cover up different imperfections, it can see things that the normal human eye can't, creating better consistency in the inspection process. Is there an opportunity to develop AI into a helpful tool for human inspectors to identify things they might not otherwise see?

MR. COCO: They're doing that right now. There are various companies out there, specifically those with crawlers that can establish a three-dimensional model. From that, they can do AI projections for useful-life analysis based off of the operational conditions when you integrate it with Internet of Things and you can have like real-time operational records on how this is functioning based off that current trajectory, how far down you would want to replace that or, you know, what is the rate of corrosion in real-time based off the data and then repeating that scan every six months.

Many manufacturers in this space with these UAS and crawler platforms are developing their own camera software to further detect anomalies and other targets. They’re guarding the gate, if you will, for any type of unwanted AI intrusion, which could affect the quality of the results of what you might be seeing.  

MEMBER: Are there units developed with multiple sensors that can do simultaneous thermal imaging, as well as visual inspection, and so on, all in the same pass?

MR. COCO: We haven't got there yet. It was meant to be generic for UAS operation, and the platforms were the sensors themselves. So, regardless of whether I have a contact UT probe, a thermal imaging camera, or I'm doing a visual inspection, the operations and risk assessment would be the same.

The additional aspect to that would be on how that payload would operate not only under the environments of conditions that would be established writing on that platform, but if there was any type of adverse interference by the prop wash or the vibration of the structure of the actual UAS or any type of robotic platforms, it might impair any type of valid results. That's one of the analysis points that we look at.

As we further develop with the technology and have use cases that we're able to now have further analysis, we're going to increase the appendices for specific types of considerations as guidelines if you want to use a UT or contact UT probe of how that would look like.

Thank you, everybody.