This will be a shorter post, as the message I try to get across is rather simple:
Be aware of all systems your device has to interact with.
Easy right? You’ve probably thought about this before. However have you thought about:
- Buildsystems – these can take a lot of forms and shapes
- (Software) Testsystems (we’ve talked about this before)
- Productionsystems (During Hardwareproduction!)
- Testsystems (During Hardwareproduction, these might be in-circuit testers, systems designed to flash the firmware and/or bootloader)
- Foreign systems you or your company don’t control
Buildsystems
As engineers, our usual approach to buildsystems is: “Checkin Code, build binary, deploy binary to target”. However this might fall short if we want a truly integrated environment that creates a maximum of productivity. Think about the following aspects:
- How do you intend to deploy binaries from your buildsystem to test targets?
- How do you intend to deploy binaries from your buildsystem to production devices of your customers?
- Are there aspects involved that make deployment non trivial, such as:
- Your binaries need to be in a special format (you might want to include some kind of metadata)
- Your binaries might need to be signed using different keys, depending on the devices they’re intended for (we’ll talk about this in the chapter on security)
- Your binaries might acutally consist of several subbinaries, that need to be packaged in some fashion
- Your devices are usually not directly connected to ethernet and need to be flashed using specialised tools and/or hardware
(Software) Testsystems
As noted in the last section, your device will probably have to interact with a testharness of some sort. While it is good practice to not write software that has special operationmodes for testing, as these modes will almost certainly alter the behavior of your software and you can’t be sure, that the software will behave the same when not in testmode, you might want to consider that:
- A test needs to stimulate the device in some form
- A test will usually need to be able to reset the device to a known state (factory reset)
- A test will have to configure the device
- A test needs to be able to sense what the device is doings
If you think about these points you will probably design the software slightly different. As an example: I once worked at a company where we had a device that had it’s service functions only exposed via a web ui. While this worked fine for most cases, it always caused problems, when we wanted to interact with the device in an automatic way. In the end we spent a lot of time writing tools that somehow pretended to be a webbrowser. A better design would have exposed the service functions using a well defined API (e.g. SOAP or REST) which would’ve been used by the web ui. However, when the software was initially designed nobody thought, that anything else than the web ui would ever be needed to access the service functions (this was more than a decade ago, when testautomation wasn’t much of a topic in embedded development).
(Hardware) Productionsystmes
At some point your device will actually be built on an actual production line, and while it won’t be able to do much in this phase, some of the designchoices you made until this point will have a severe impact and have the potential to make live miserable to the people that build the device for you. Think about topics such as:
- How should the software be deployed to the device in production? Keep in mind that efficiency is paramount here, people will usually not want to use some graphical UI to deploy the software.
- How are things like crypto keys handled/deployed to the device?
(Production) Testsystems
In a lot of productionenvironments some sort of final assembly test is made, to make sure the product is in working order when it leaves the assembly line. These may include in-circuit tests and other more specialized tests. The system running these tests might need to interact with your software in a non-standard way. You are well advised to clarify the needs of your productionteam ahead of time and to make sure you can give them the kind of access they need.
Foreign systems
The impact of the point is hugely dependant on the kind of product you’re building. Some products are designed to be used with a specific controlsystem in mind (e.g.: In access control systems, most vendors will sell systemsoftware along with the controllerhardware and the controllers are only expected to work with these systems), however most of the devices we build will have to interact with some sort of other system in one way or another. These systems will have their own quirks that need to be taken into account, here are a couple of examples:
- The implementation of a communication protocol might have its own flavour to it.
- The system in question might have limited resources and could be overwhelmed if your device sends to much data.
- The system in question might not be aware of your devices’ limited resources and might overwhelm it.
- The system might only be sporadically available to communicate with
Summary
While you cannot design for all eventualities, you should try to take as many as possible into account and make an informed decision about the cases you want to cover. The aspects noted in this article may sound like they only apply to softwaredesign, however some of these aspects should already been thought of during hardware design.
Image by Nicolas Thomas (upsplash)