The unique structure and purpose of embedded devices presents special challenges for IT development firms. Issuing a device to an end user during the Beta stage and working the bugs out once it’s already firmly embedded in its final location is often impossible. Even today’s Web-enabled embedded systems – which permit remote maintenance, patching, and updating – still have to hit the ground running in good working order. The whole point of embedded tech is reliability. If you don’t feel confident that the device will perform to meet minimum requirements, it’s not ready for deployment.
Here are five areas that deserve special attention when you are developing an embedded system. Not all of these tips will apply to every project, so just pick and choose based on what type of device you are working with:
Define what’s really needed
An embedded device is only as useful as its target device allows it to be. When you are documenting the software requirements for your project, pay special attention to how the client will actually be using the target device that houses the embedded system. This will allow you to select (or build) and configure the components that will prove most useful. Since many smaller embedded devices have very limited memory, pinpointing the features that are most important will allow you to make the most of available resources. This approach will enhance the end user’s experience with the device in terms of reliability and functionality.
Evaluate vendors carefully
Using off-the-shelf hardware and third party software drivers or apps can save you a huge amount of time and effort when you are developing an embedded system. Instead of reinventing the wheel, you can focus on adapting and customizing your device. However, your end product will only be as reliable as the individual components you choose. Will out-of-the-box hardware and software be your salvation, or will they be the weakest link?
Look beyond whether hardware simply meets the requirements of the target system. You need to have confidence in the vendor’s quality control standards. Ask whether the hardware has been independently tested. For example, the vendor’s product might be certified through a widely recognized industry program (like Microsoft's Windows Hardware Quality Lab). Obtain written guarantees from your software vendors and investigate their track record for responding to customer requests for tech support.
Are you developing an embedded application that is microprocessor based (e.g. with an 8051 or ARM processor)? Engineers from the embedded systems laboratory at the University of Leicester recommend using PORT WRAPPER coding patterns. These patterns are designed to increase system reliability when multiple team members are involved in the development or maintenance of an embedded system. The purpose of the wrappers is
- To appropriately manage the allocation and initialization of port pins
- To avoid unintended alterations to the code
- To make it easier to port code to a new system (or port a system to a new hardware platform)
This is especially important for systems that are embedded in high-powered machinery. An unintended change in port pin initialization could mean the emergency cut-off switch for the equipment will no longer operate.
Never neglect unit testing
Breaking embedded device code up into its smallest testable units and testing each one individually is arguably the most time consuming and flat out boring part of the development process. However, it is the piece of the puzzle that delivers the highest value from a reliability standpoint. This is especially critical in complex, real time systems where debuggers and loggers are more difficult to use. Sift bugs out at the unit level so you don’t have to track down what’s going wrong later.
Taking the time to write those drivers and stubs for unit testing pays off by allowing you to create extensive automated testing programs that run over the weekend when you are (hopefully) getting to take a break and rest your brain. Automation is also very useful for integration testing and testing in the target environment. If you can afford to set this up, do it. Build up a “library” of codes you can use in future test programs to help control costs.
Be aware of the constraints of PC testing
Running unit tests for an embedded device on a PC can create problems if you don’t pay attention to the differences between these two systems. For example, if you are writing in C code, the algorithms may seem fine in the desktop testing environment. But they could be buggy in the final embedded environment if you aren’t being completely clear about what integer types you are using.
More advanced embedded systems might contain specialized hardware that is not present in a PC. Simulating the actual capabilities of the embedded hardware in a PC environment may require significant resources. You might consider building a real-world testing environment with the customized hardware rather than trying to emulate the process virtually on a PC.