The global coronavirus outbreak forced people to stay at home and companies to switch their employees into remote working mode. The proportion of the workforce working remotely during the crisis varied, according to different estimates, from one-third to almost 80% in some companies. A Gartner, Inc. survey of 229 HR leaders in April 2020 revealed that nearly 50% of organizations reported that 81% or more of their employees were working remotely during the coronavirus pandemic. The CNBC All America Survey released in April 2020 showed that 42% of U.S. workers who had not telecommuted previously were doing so.
Luckily, we at Auriga mastered remote working long before it became a necessity, with our offshore and nearshore distributed teams located across the globe over the years. We recently discussed the psychological aspects of home office efficiency and offered ten life hacks on how to maintain productivity and motivation while working from home. This article touches on a somewhat tricky question: how can teams work with hardware remotely?
Why Teams Need to Work with Hardware Remotely
First, the reasons teams face the necessity of working with hardware remotely vary from project to project. It may be more convenient to establish processes for remote access instead of shipping the hardware itself when the equipment is:
- non-transportable (i.e., too bulky or heavy);
- very expensive or unique and the customer does not want to take risks shipping it;
- available in limited quantity (i.e., not enough for the whole team);
- or in need of constant updates available only at the customer’s side;
- or when the hardware the team is working on is a part of a larger system not to be disassembled.
In a recent project for an optical imaging solutions manufacturer, we worked remotely with equipment because it was necessary to constantly test and configure it in the customer’s optical laboratory. Another customer, a semiconductor company, was the first in the world to create a device with a new architecture. It was a completely new piece of equipment with very few test units, which is why we had to work with it remotely.
The gains for customers are pretty obvious: potential equipment shipping and IP security risks are mitigated. The customer is free to build up a team of qualified engineers regardless of location and encouraged to take advantage of different time zones and pricing options to speed up time to market within the designated budget. But this seemingly easy and beneficial opportunity is not without problems. To really thrive, a customer needs to partner with a trusting and reliable service provider who knows not only the ins and outs of hardware management and embedded systems development and testing but also how to make communications work (remote work requires extensive productive communication), how to establish processes and procedures and how to mitigate risk in case something is not working as expected.
Remote Hardware Challenges and Solutions
You might think that the biggest barrier to remote work with equipment is its accessibility, but this is not actually true. The main challenge arises when there are far fewer accessible pieces of hardware than engineers on the team. Whether it is remote or local equipment, the problem of time sharing comes into the picture. The real challenge for engineering teams is not the remote access itself but the way this access is organized when the number of devices is limited. Solving it quickly and efficiently is a matter of experience. With 30 years in the industry, we at Auriga are highly aware of this issue, and we plan balanced and smooth time sharing among team members at the launch of any project. We also reveal the plan to our customer’s team as early as possible and align it with the practices and procedures in place.
Another challenge emerges when, for whatever reason, it is important to physically view the device. When engineers test, debug, or develop software for unique equipment, it is sometimes necessary to see the screen reads, lights lighting up (or not), or signals the device returns or to hear what sound is playing and at what volume level. Or what if the equipment is smoking and about to light up? To be on the safe side, we usually set up a webcam and/or other tools to obtain a picture or sound remotely.
After we have resolved the issues of the accessibility and visibility of the remote hardware, the time comes for the next challenge to reveal itself. What if engineers need to physically interact with the device (press buttons, modify hardware configurations, etc.)? A one-size-fits-all solution is highly unlikely here, but we have tried and tested several possibilities and found them efficient. Here are some for your consideration. You can create a custom system (e.g., an Arduino with push–pull solenoids to press the buttons). Some of the off-the-shelf products, like tools by National Instruments, perform particularly accurate measurements or loads. In the worst-case scenario, you may require an on-call colleague on-site to perform needed actions upon your request. It sounds somewhat complicated, but in fact, such cases make up few test scenarios, and at the initial stage, they are usually limited to the need to press the reset button or activate the reed switch. So the majority of tasks can be performed remotely, and only a few of them require physical action and it’s better to have a plan for them.
We also cannot underestimate the importance of the internet channel speed and reliability when we talk about working remotely. In theory, if the equipment is far away, it will most likely not be as responsive to our actions as it would be if it were nearby due to the speed of the connection. It could be a critical problem 30 years ago, when the connection speed was slower and we had to debug drivers remotely for some RTOS development projects (but we managed—thanks for asking). Today, it is the least of our worries, as the connection speed skyrocketed in the last decade and many efficient debugging tools became available. Frankly speaking, about 90% of an engineer’s working time is spent thinking and only 10% is actually spent testing and debugging. Thus, the vast majority of the work can be done locally in batch mode, so the internet speed and stability do not have a significant impact on the project result.
Finally, we may encounter a situation in which the remote equipment issue cannot be solved simply with a webcam or a special tool. This is the case for the fully functional emulators that have come on the scene. Our experience proves emulators to be the technical investment that always pays off. They significantly improve test automation, assisting in complex scenario implementation. In projects where hardware and/or firmware are also undergoing a development phase, simulation is a solution. Hardware simulators allow the hardware and firmware teams to work in parallel to reduce the number of steps (hardware prototype release iterations) required before entering the market. In addition, simulation helps you to integrate with the OS kernel, test firmware, prototype the hardware itself, and build hybrid hardware/software simulators. It allows hardware components to be tested as they are ready before reaching MVP in the hardware team. If you feel confused about the whole emulation vs. simulation issue, please refer to our recent article, which will instantly shed light on the subject.
Conclusion: Creativity and Cooperation
Apparently, there is no silver bullet for successfully starting a project with remote equipment. It all depends on the equipment itself and, more precisely, on how it is going to be used. So when setting up a project with remote hardware, we must always be alert and creative. In one of our healthcare projects, for instance, we needed to turn medical devices on and off and tap the console. Our team connected the devices using the Web Power Switch to control and reboot the hardware remotely. To reach the console, we took advantage of the SSH protocol technology and configured the SSH tunnel through several intermediate servers. The traffic was directed to the SSH tunnel, which allowed us to work with the equipment as if it were connected to a local network. Only one trip a year to the customer’s premises was required to perform “physical” tests, although they made up only about 5% of the total number of tests.
Elena Baranova, Director of Engineering at Auriga, says the following regarding the COVID-19 pandemic:
As we navigate the unprecedented events the world is facing due to the COVID-19 pandemic, we want to reassure our customers that we are continuing to provide our services at the highest quality standards while remaining efficient and transparent. By introducing new, reliable, and secure tools and technology solutions, we are creating a shareable environment where both Auriga’s customers and teams have access to the same infrastructure and can perform their project tasks regardless of their physical location.
Would you like to discuss your project with our experts? Please get in touch with us.
