ArgonDigital - enterprise automation experts

Share This Post

When a system is modified, does its TRL change?

I was recently asked the question. “When a project begins with a existing device that has a TRL of 9, with the goal to develop a miniaturized version of the device, is the TRL of miniaturized version of the device still 9?  Your point of view will be very helpful.

The short answer is “no”.  The miniaturized version is really a new device and you would have to do an assessment of the TRL for the new, miniaturized version of the device per the definitions of TRLs and then mature the device through the TRLs until it meets the criteria for TRL 9.

Technology Readiness Levels (TRLs) are a risk identification and mitigation tool.  TRLs are based on a system being used for a specific purpose in a specific operational environment.  A common false assumption is that legacy systems (systems at TRL 9) can be used for different purposes in different operational environments and still be rated at TRL 9.

It is also important to understand that TRLs apply to the complete system, not just one specific technology used within that system.  The TRL of a system is a roll-up of the TRLs of the parts that make up the system.  A miniaturized version of an existing device, is still a new device.

Any changes to the mechanical, hardware, or software parts of a system, lowers the technical TRL of the system to at least 5 or 6 until you can prove differently.  In the case of miniaturization of a device, most if not all of these parts will be changed. In order to miniaturize a device, there would be multiple parts and technologies involved: means of inputting data, processing that data, storing the data, display of the data, communications, processors, power supply, cyber security, etc.

From a systems engineering perspective, this miniature version of the existing device is really a new device.  You would develop a new set of design-to requirements as well as new build/code to requirements. You would probably be able to re-use many of the design-to requirements such as functional/performance requirements, operational requirements, quality requirements, standards, and regulations.  The physical requirements would be different.   If you wanted to improve the performance, add new functionality, improve quality, address issues with the existing version, those requirements would be added or updated in the new requirement set.  Most likely the build/code-to requirements would all be new.

These new sets of requirements would mean that you would have to go through system verification to prove the new system meets these requirements and supply the customer proof that the new system meets all the requirements including any applicable regulations and standards.

Once system verification is done successfully, then system validation activities would have to be completed to prove the new miniature version of the device meets it intended purpose in its operational environment.  From a TRL perspective, the new device TRL would increase as you meet the criteria for each TRL.

If the device is a medical device, you would perform system validation and TRL maturation per FDA  standards and regulations. The focus of TRLs for medical devices is system validation.  Thus, for the new, miniaturized device, you would need to do a TRL assessment of the parts that make up the device as well as the overall TRL of the integrated system per the TRL definitions for medical devices and then mature the new device through each of the TRL levels.

Comments to this blog are welcome.

If you have any other questions you would like me to address, please feel free to fill out an “Ask the Experts” form and I will reply as soon as I can.

ArgonDigital specializes in helping clients improve their requirement development and management processes.  Let us know if there is anything we can do to help you and your team.

When a system is modified, does its TRL change?

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage