If the COVID-19 pandemic has taught us anything about the workplace, it is how vulnerable we are to factors beyond our control. It has also shown us how lucky many of us are to have at our disposal myriad technologies that allow us to work remotely from the safety of our homes.
Software engineers are certainly fortunate in that they can continue working and contributing to the economy through lockdown and shelter-in-place orders. In fact, a recent Deloitte paper states that, “In contrast to the parts shortage and unpredictability of supply chains dragging down the industry, software is a growth catalyst.”
As reassuring as this evaluation may be, it should not blind us to the challenges we face developing and delivering software for the duration of the pandemic and beyond. We must assume that for the foreseeable future our work will involve a great deal less personal contact, hence a great deal more remote work and a new definition of what it means to work in the lab.
In short, the lessons we learn and the measures we implement to get through the pandemic will also stand us in good stead after the pandemic is, thankfully, behind us.
Software development is indeed insulated, but the work we do eventually does require hardware. This is particularly true of embedded systems, where sooner rather than later, we must prove our work on specific target boards. To compound the problem, we often work with pre-production boards, which are usually rare commodities—sometimes only a handful exist, worth far more than their weight in gold, and only parsimoniously shared by the manufacturers, even inside their own organizations.
Plan to Share
Given that software engineers must work remotely, and that the boards with which they must work are likely to be even more difficult to obtain than in the past, the first order of business should be to plan to share. That is, set the boards up in secure locations with reliable and secure Internet connections so that they can be readily accessed by multiple users.
Unless other constraints, such as security, require it, these locations don’t have to be a formal lab; someone’s home may do perfectly for a board or two, as long as they aren’t accessible to the two-year-old, the parrot or the dog. If necessary, consider scheduling times slots for different users. When making schedules, remember that different people prefer different times of the day; ask for preferences, and if your organization spans multiple time zones, leverage this to minimize any inconvenience to your teams.
Connect, and Connect Securely
Wherever you locate a board, you’ll need to connect with it. Your board set up and your connection should ensure that:
- You can easily contact the board from your remote host system
- You have a secure tunnel through firewalls to the board
- You can easily reset or, if necessary, cold boot the board
Assuming it has an appropriate port—and most boards do—establishing contact with a remote board is quite simple with protocols such as Telnet or Echo. These protocols are useful to confirm that you have made contact with the board you need, but they aren’t secure.
For testing and debugging, you should probably use another port with Secure Shell (SSH) or some other technology that can provide a secure channel. This requires a bit more work than Telnet. You need to query your subnet to get the IP addresses you’ll need, and work with your router to set up port forwarding to your reserved IP address.
The brief webinar “How to Keep Your Projects on Track While Working Remotely, Part 1” offers an example of how to set up an SSH connection to an embedded target. Once you have established a secure connection, you can work with your preferred tools to test and debug your software on the hardware on which it will need to run.
Finally, plan your connection strategy for failure; specifically, plan for things going wrong with the software—after all, this is development. You will need to reset your boards remotely. Set up relays to the board reset switches, and consider connecting your boards to remote power IP switches, so that when software fails you can initiate a cold boot remotely. You can always purchase a remote relay board, but since you do embedded development, you can also build one yourself.
The commands below illustrate how easy it is to control a reset power switch remotely. This setup uses a secondary control board that can control a set of isolating relays. You can use a general purpose I/O (GPIO) driver to manage some output pins on the target like this:
# echo 2 > /dev/outs; sleep 1; echo 0 > /dev/outs
# echo 1 > /dev/outs; sleep 3; echo 0 > /dev/outs
The first command above is for a reset, while the second is for a cold reboot, so it has a three second sleep to give all the hardware time to shut down before power is applied again. To complete the setup, connect relay control on the associated GPIO pins to the relays controlling the reset pin, and the power supply of the controlled target. This simple configuration ensures that you are always able to remotely push the target’s reset button or pull the plug.
Keep Your Data
You can use stored data to advance your project without the need for field trials. For example, if you are developing a subsystem that controls high-speed trains or LRTs and are far along enough to have run some trials, you should have the live sensor data from these trials stored in a database. You can feed this data into your system as though it were coming from the sensors in real time, so you can advance development of the algorithms you use to integrate the data from diverse sensors in order to provide everything behind the sensors: position, acceleration, etc., they need to learn how to control your vehicles.
The figure below presents a vehicle control system that stores raw sensor data for use in the lab: