Time constant of engineering research
Ever since I embarked on a journey of learning in the area of engineering, one feature has attracted my attention more than any other. On the one hand, all outcomes of any engineering practice are expected to be reliable and predictable. This is the crux of engineering practice - reliability, repeatability and predictability. It is not too much to conclude that Engineering is a science of reliability.
Engineering Research on the other hand is a creative endeavor where something that was not known clearly comes to the surface. While the methods of research in engineering may be based on well established first principles, the outcome is very much uncertain, and in some sense, unpredictable - something that does not sit well with engineering practice!
To me, this gives rise to a natural question:
How do we go from a good research outcome to a reliable engineering solution?
I will attempt to share my understanding of how to go about answering this question. In a way, this blog was inspired by writings of Professor Dennis Bernstein.
From a lab to the production floor
Let us assume we have a research outcome which we feel is reasonably mature (the said research output can be reproduced by other similar teams). The immediate next step is to prepare a list:
- Define the end use clearly. Who is the intended user?
- Define TRL level required by the ultimate application. Usually this is 9 on a scale of 1 to 9 for an industry ready product.
- Break down the new result/product into unit subsystems.
- Which hardware and software components were used? Are these available off-the-shelf?
- Are the TRL levels of the tools and components at the same or better than that of the final product?
- Identify domain expertise.
Let us look at an example of this process. Let us say we derived a novel OCR algorithm for identifying variable prints on food packages in a continuous production line. The answers to the above questions may be as follows:
- End user: Operator of the machine/station where OCR will be deployed.
- TRL of final solution: 9
- Breakdown into subsystems: Camera & Lens, Processor (computer system), OCR algorithm (software), Lights, Communication protocols, Power supply, Display.
- Off-the-Shelf: Available but do not allow custom AI software.
- The TRL of software component is 7 (prototype in intended environment) while TRL of all hardware components is 9.
- Domain expertise: Partnership with a research organization and an industry leading organization.
Audits
The above exercise usually gives a good idea of where the effort will be needed to convert the lab outcome to the deployment environment. The effort can then be estimated from the following project engineering yardsticks.
Technology Readiness Level (TRL) Audit
This is a nice way of measuring the readiness of a product when being taken from a lab prototype to a 'always-ON' functioning entity. For the industrial automation projects and machine building, a more relevant definition can be found at the YUKTI-National Innovation Repository which is an initiative by the Ministry of Education, Government of India.
The product being developed needs to be scanned through the lens of TRL with level 9 being the most mature and deployment ready stage. One needs to identify where the lab outcome belongs at Research (TRL 1-3), Development (TRL 4-6) or Deployment (TRL 7-9) stages.
Continuing with the same OCR example mentioned above, the algorithm is somewhere between TRL 1-3 if information on deployment hardware, speed, environmental conditions have not been taken into effect but the algorithm does work as specified in the lab apparatus. It is perhaps at 7 if all conditions match with operational environment but information on reliability of the whole solution is not known.
Time Audit
It's an interesting exercise to study how much time does it take for a concept presented in a research paper to be utilized in a reliable deployment. Doing this for existing success or failure stories gives an insight into estimating time required. For example, a completely new OCR algorithm may take a few months to get developed from scratch, a functioning stand-alone product in a humid and dusty environment can take longer (up to a couple of years).
Generally speaking, it takes relatively short time for algorithms and software to be deployed reliably. Certainly, for areas requiring physical build other than software, it takes longer.
Material Audit
Estimating resources required to go from the current TRL to a deployment ready stage is crucial. This includes equipment, test specimens, tools and conditions of operation. Typical input or conditions for a solution may be difficult to recreate in a lab set-up. At times, even a TRL 9 product may not enjoy the benefit of being tested in a favorable space. A huge machine with typical environment found at ultimate place of installation, for example, can only be tested satisfactorily at the installation site. This needs to be factored in while taking the lab concept to TRL 9 level.
Continuing with the example of stand-alone OCR solution, resources required may be as follows:
- Enclosure design and development
- Camera sensor and lens ruggedness
- Fine tuning algorithm for noisy images
- Resistance to humidity and dust
- Funding and knowhow for setting up the required manufacturing processes and equipment if above items are to be manufactured in-house.
Tools Audit
The tools audit is the most crucial for agility. The most trivial yet important aspect is that all the identified tools should generally be at a better TRL level than the current stage of the product.
For our OCR example, the tools can take many forms:
- Equipment (e.g. a machine tool)
- Software (e.g. PCB design and printing, lens selection)
- Mathematical (e.g. CAD or optimization centric simulation)
- Prototyping (Software and hardware or hybrid)
An important aspect is to identify early whether a tool exists at all for the intended journey. In the case when a suitable tool is missing from the current state of the technology supply, it amounts to a micro-research effort to build one. This inadvertently starts at around TRL 1-3 and usually this space provides the best opportunity for academia and industry to come together. The simple reason is that the intrinsic motivations of all parties involved are satisfied.
Concluding Remarks
Engineering is a science of reliability which has repeatability embedded in it. This ties ultimately with the quality of the product or solution. That which is repeatable is not new, and hence opposite to novel or creative, at least in the beginning. It takes time for the novel to become boringly repeatable. It takes a systematic effort to go from a novel idea to a deployable solution via identification of TRL as well as various audits.
In keeping with the electronic circuit design parlance of Time Constants, it might be apt to name the time taken by the various audits and their implementation the time constant of engineering research.