There are advantages and disadvantages when using embedded systems. In this video, you’ll learn about the limitations associated with power, networking, upgradability, patching, and more.
<< Previous Video: Embedded Systems Communication Next: Physical Security Controls >>
One of the challenges you have with embedded systems is they’re usually running on a device that is not a fully capable computer. This is often a low cost device sometimes it has been purpose built or maybe using off the shelf like this Raspberry Pi. And so there are a number of constraints associated with this design. As you can see from this example, there may be limited number of features available.
There may be interfaces on this device that you might have on your home computer that simply won’t appear on this embedded device. This is also very difficult to upgrade there may be operating system limitations on the size of the storage of this device. And as you can tell it would be very difficult to upgrade the hardware of this embedded device.
There might also be a limitation in the type of communication. This device has wired interfaces but the embedded device used somewhere else may only be able to communicate over wireless and over specific wireless technologies. But that’s usually the trade you have with embedded devices because they’ve been built to perform a specific function. There’s no need to put additional memory or additional communications capabilities in these devices if they’re never going to use that functionality. We can keep our costs down because we built this device to perform that single function but of course, this comes at the trade of having this additional functionality.
A common constraint for these embedded devices is power. We’re often putting these devices out in the field and there may not be a direct power source for this embedded device. Often we’re plugging into a battery connection or we’re recharging the batteries with solar power throughout the day. There may also be times where you have to physically service the embedded device just to change the batteries out because there’s no other option for powering that unit.
These embedded devices are low cost devices they’re often purchased off the shelf. And that means we might have limitations over the CPU and computing power of the embedded device. This may not necessarily be a bad thing lower speed CPUs tend to create less heat and that may be an advantage especially for these smaller devices.
The location of these embedded devices can also limit what we’re able to boot from a networking perspective. If this is a sensor that’s on an oil pump in the middle of a field we may not have the ability to run an ethernet connection or be able to connect it to a tornado 2.11 wireless network. The geographical location of the embedded device may determine what type of networking can be used by this device. So there may be trade off as to the type of network and the speeds we may have available to communicate to that embedded device.
These low cost embedded devices also don’t have a lot of additional cryptographic capabilities. There is a CPU but of course, that CPU is limited. And there’s usually no additional cryptography hardware on that device unless it’s been designed that way from the very beginning. If we need to add or change cryptography functionality you’re probably not going to be able to do that using the hardware on that device.
Many of these purpose built devices have no physical keyboard or mouse there may not even be a video connection and that complicates the upgradability of these devices. You may not be able to connect to this device over the network to perform a firmware upgrade. And you may have to visit the device directly to plug-in a USB drive or some other type of firmware upgrade process.
If there is any type of security on these embedded devices, it’s often an afterthought. It may be that there’s no authentication required to gain access to the firmware on the system or it may be a very limited type of authentication. We’re used to using things like multi-factor authentication and connecting to directory services with our mobile devices and our laptop computers. But these are functions you may not find on an embedded device.
These embedded devices also have a very specific function and it’s unusual for that device to have any additional capabilities beyond that. This is not usually a device that allows you to add on additional functionality after the fact because it has been specifically engineered and designed to perform that single function. And additional capabilities was not in the original plan.
Being able to have an embedded device that performs one particular function means that we can design it very specifically just for that function and nothing else. By designing this way we can keep costs low, which is especially important if we’re creating a lot of these embedded devices. We also have to think about how using lower cost components may affect the quality of that device. By using the lower cost components we may be limiting the lifespan of that particular embedded device.
And with many of these embedded devices you don’t have direct access to the operating system or the software that’s running on that device. And it may be very difficult to gain access to the operating system on that device. From a security perspective, we’d like to be able to audit that device, make sure the operating system is up to date, make sure there’s no security issues. But if you don’t have access to the hardware software makes it very difficult to perform that task.