| Introduction | Perhaps you are considering (or in the process of) bringing a robot to market using open source software. This robot is built on linux . Maybe you're using Robot Operating System (ROS) or Mission Oriented Operations Suite (MOOS), or another open source middleware that can help streamline your development process. As development approaches production, expectations of return start to put some pressure on you. You may be asked, "When will our product be available for sale?" At this time, you will be faced with an important decision. |
You can do one of two things:
- Start shipping existing products
- Go back and treat productization as a completely new problem to solve and deal with new problems
You don’t have to look far to find examples of approach (1). In fact, the IoT device market is full of such devices. In the rush to get devices to market, it's not uncommon for these products to be found with hardcoded certificates, development keys, various security holes, and no way to update them.
Consider the Mirai botnet, which caused distributed denial-of-service (DDos) attacks with over 1Tbps of traffic, taking some of the largest websites on the Internet out of service. This botnet is mainly composed of IoT devices. Was this bot developed to defeat a device's defense mechanisms and then take control of it, developed in a windowless lab (or underground base) using super cool black magic? No, just the default (usually hardcoded) certificate. Do the manufacturers of these devices respond quickly and release updates for all these devices to ensure the security of the devices? No, many manufacturers have no update method at all. They recall devices instead of releasing updates.
Instead of rushing to get your product to market, take a step back. With just a few extra thoughts, you can save yourself and your company some pain.
For example, how is your software updated? You must be able to answer this question. Your software isn't perfect. It only takes a few weeks to notice that when you use an autonomous High Mobility Multipurpose Wheeled Vehicle (HMMWV) in California, it recognizes a small shrub as an oak tree. Or you accidentally included your SSH key in the software.
How to update the base operating system? Maybe this is still part of your product and your answer to the previous question. But maybe the operating system you're using is from another vendor. How do you get updates from suppliers and provide them to customers? This is where security vulnerabilities can really cause you headaches: a kernel that is never updated, or a severely outdated openssl.
Once you have solved the update problem, how does the robot recover if something goes wrong during the update process? My example is a common solution to the previous problem: automatic security updates. This is good practice for servers and desktops and obviously computer stuff because most people realize there is an acceptable way to turn it off other than holding the power button for 5 seconds . One problem with robotic systems (and most IoT systems) is that sometimes they aren't considered computers at all. If your bot behaves strangely, it may be forced to shut down. If your bot is behaving strangely because it's quickly installing a kernel update, well, now you have a bot paperweight with half a kernel installed. You need to be able to handle this situation.
Finally, what is your factory process? How do you install Linux, ROS (or the middleware you use), and your own stuff that you want to install on the device? Small factories may do it manually, but this method is scale-prone and error-prone. Other vendors may create a customized initial release ISO, but this is no small task and not easy to maintain when updating the software. Others use Chef or automation tools that have a steep learning curve, and soon you realize that you're putting a lot of engineering effort into what should be a simple job.