Recently Auriga launched a new R&D lab for medical devices software testing. This is our thirteenth engineering laboratory – and the eighth medical one. In addition to medical labs we also operate labs for embedded software development, an electrotechnical lab to work with high-voltage devices, labs to develop intelligent telecom board controllers, worker safety devices, and others.
In R&D labs, we interact with real-life equipment, usually presented in several pieces, which should be shipped, installed, calibrated and monitored on a regular basis, and stored somewhere. No need to mention that some devices are very expensive and sophisticated. What if something breaks down?! And why on earth do we need real devices in the era of digital transformation? Isn’t it easier to create digital twins that fully emulate real devices, develop virtual environments to test a variety of scenarios and get the same results faster, cheaper and, in a way, more reliably? Let’s answer these questions but keep in mind that, based on our experience, when choosing digitalization over good old methods, you risk toss the baby out with the bath water.
What is an R&D lab?
An R&D lab is a site deployed in accordance with the customer’s requirements to troubleshoot their specific issues and perform research tasks. Thus, we have a medical lab with the regular supply of water with the required quality level, a “wet” lab with blood-emulating liquids, and a lab that allows working with gases. The labs are provided with all necessary equipment, including the devices under development. Except the specific hardware, the lab accommodates two types of workplaces: one for a software developer and another for an engineer that acts as a “business user”. These workplaces are usually combined in blocks that allow several team members working on a single project to collaborate simultaneously. This work process organization helps engineers to conduct research and participate in prototyping, bringing the most successful products into production.
Why do customers deploy R&D labs on the vendor’s site?
Many manufacturing companies at some point may encounter difficulties in performing technical tasks. The reasons vary from the absence or loss of the necessary competencies, the lack of specialists in the market or a “hire freeze” to the occurrence of routine activities, etc. Sometimes, the deployment and operation of an R&D lab on the customer’s premises requires expensive training and certification of authorized employees, and it takes a lot of time to arrange and obtain approvals for the specialized equipment and safety measures in place. When this happens one of the healthy choices companies can make is to look for a vendor to step in. Among the important selection criteria are the availability of infrastructure, the ability to quickly build a lab and provide the related services (testing, refactoring, etc.). Naturally, approval processes, safety measures, personnel training are also essential in Eastern Europe, where our labs are located, but training and certification are much cheaper, and the legislation is more liberal with fewer bureaucratic obstacles.
What problems do R&D labs solve?
In our labs, engineers can implement new functions and check how they work, before launching the device into the market, ensure interoperability of products of different generations, assemble almost any configuration of equipment and emulate external systems, services or applications. Labs can play a vital role in porting the product to a new platform, hardware and/or operating system, or preparation for certification.
How customers benefit from Auriga’s R&D labs?
R&D labs allow us to cut software development, debugging and testing time significantly. The customer does not need to allocate time and resources on hiring engineers and setup activities; the client’s own staff workload decreases, including support, developers and experts. Our premises already have a basis to build up necessary infrastructure, which means we can deploy a lab in a matter of weeks, ensure a smooth and streamlined shipment process, and provide regular calibration of equipment and third-party simulators. Having a real device (or the entire product line) in place greatly simplifies and shortens the communication chain. We know how to handle complex life- and safety-critical equipment, and we comply to international standards and use best practices in our work. In other words, our customers get access to equally knowledgeable personnel, hands-on experience in various domains, time-proven practices, geared-up infrastructure and lower costs of a nearshore or offshore location.
Why have R&D labs in the digital age?
Virtual is part of the game. Our motto here is: get the best of two worlds, meaning our engineers perform part of the tasks using simulation, HIL platforms and all kinds of test stands and debugging devices. However, a great deal of the tasks can only be done on real devices. Particularly, when we are talking about life- or safety-critical device there are scenarios that demand testing it “the good old–fashioned way”.
To name the few, almost all scenarios involving device preproduction phase, or resolving issues/adding functionality for already produced products largely depend upon real lab work and cannot be 100% covered by simulation due to the complex physical nature of the device: it consists of different parts, that are integrated and interoperating with each other. I believe in a healthy balance between real devices and simulators; however, creating high-quality mathematical and physical models of complex devices (for example, an induction motor) takes a lot of time and may be financially unprofitable. At some point, the cost of the development of a detailed mathematical model may be close to the cost of the real device development.
Another scenario of “simulation isn’t the case” comes to my mind when the device we are working on needs to be certified to be set to production. Verification and validation of such equipment should be performed on real devices for the most regular and commonly used configurations. Without R&D labs on the vendor’s side, developers should travel onsite to the customer, which is not economically feasible.
And if this is not enough, I can give you one more argument in favor of the labs. Sometimes the device passes all tests and goes into series, and suddenly (and this is not so rare) an assembled ready-to-use device gives errors that could not be reproduced neither in simulations, nor in testing. They can be assembly errors (for example, a slightly increased tolerance) or some very rarely reproduced bugs that occur, relatively speaking, on three out of 10,000 devices. Without investigating real devices, it is impossible to say exactly what affects their functionality.
Summary
The bottom line is that if your software is designed to run on a real device not in a fully virtualized, there will come a point where you will need to test it thoroughly on that device. Yes, digital twins and simulation model save a ton of time shifting your production schedule left (and we will talk about it really soon), but, simply put, there is no emulator of even digital twin yet that will precisely duplicate the functioning of real-world electronics or the physical environment in all its uniqueness or real operating activities and user experience in its full. The trick is, though as usual, to find a reliable and knowledgeable vendor you can trust. And this is a subject we have been blogging about for a long time (for example, here are the two unexpected key selection criteria for your attention).
For Auriga, every R&D lab is a new level of customer relationships, a token of trust and confidence in our reliability. Each of them is tailored to the specific needs and requirements of a particular client and becomes a knowledge hub for the customer on its own products and artifacts collected which importance could not be overstated. New product development, porting to new platforms, interoperability support – labs are playing an essential role in SDLC. While, definitely not every project and every customer need a lab to be deployed, it is still a valuable and resources saving asset to their business.
