Instant-On is often touted as an ease-of-use feature. Consumers, as we know, are extremely impatient and want their gadgets to be available immediately. For many applications, however, Instant-On can be a critical system requirement that impacts functional safety.

Instant-On capabilities ensure that devices are available for use as quickly as possible. This usually includes some sort of fast internal non-volatile memory and memory bus so that firmware and application software can be up and running with minimal delay. An Instant-On processor may also reach an operational power level faster when paired with the right external components.

For Instant-On to be effective, however, firmware and application software must be designed with Instant-On in mind. For example, the entire program doesn’t have to be loaded into memory or be available for a system to start up.

This is where embedded developers come in. Your choices during start up processes can significantly impact a system’s time-to-wake. By identifying the critical and essential blocks of code to load first, your system can already be operational before the rest of the program is loaded. The question is, what needs to be loaded first?

The answer may not be what you initially think.

Mitigating User Failure

It might seem obvious which systems need to be brought up first in a car. However, there are some ease of use dependencies associated with potential hazards you might want to take into account. For example, how critical is booting the radio and connecting to a phone via Bluetooth?

Drivers get in the car and it starts immediately. Within seconds, the car is backing down the driveway and about to enter traffic. Now the radio finally boots. Because the phone hasn’t been connected in yet, the radio blasts the last FM station played at a high volume. This might surprise, or annoy, the driver. Worse, since the driver always listens to Spotify or other music app via smartphone, the driver might start fiddling with the infotainment system to get the right music to play. Did we forgot we were backing out of a driveway?

This is no longer about ease of use, it’s about understanding your user. This isn’t an isolated use case. While they back up, drivers adjust their seats, fiddle with the A/C settings, open the navigation system, flip to the menu setting that shows gas, tire pressure, and tripometer. Put up all the warning screens you want, people are going to do what they do. Instead, by accepting their nature, you can build a more resilient system.

One approach for making the infotainment system more resilient would be to enable Instant-On for the radio. Instead of booting the radio after the car has started, the radio could boot in parallel. Even better, start booting the radio when the car door is opened. The few seconds it takes for the driver to get situated is all that’s needed to have the radio going before the car is moving. Now the driver can select music safely. Again, the driver starts driving before selecting music only because the radio isn’t ready before the engine. Then again, why not start booting the infotainment system as the driver (and keys) approaches the vehicle. Then everything can be ready for drivers before they have even sat down.

Know Your User

Another Instant-On approach to application software that would enhance safety is to give drivers what they did last time or what they tend to do most often. If a driver knows that the Spotify playlist will automatically start up on its own, then the driver won’t need to fiddle with the infotainment system at all.

Tracking user startup behaviors can be a key part of an effective and resilient Instant-On protocol. For example, with the entertainment system, some drivers want the radio, others a playlist, and still others want their book on tape to resume. Anticipate what users what, give it to them, and you can make them safer.

Instant-On as a safety consideration doesn’t apply just to cars. Industrial systems, for example, have to recover from either power or system failure. Faster time-to-wake means less time down and potentially less damage to materials or injury to users as the system resumes operation in “safe mode.”

Connectivity of all sorts benefits from Instant-On as well. For example, when a router goes down, typically it can take a minute or two for connectivity to be restored. In an industrial setting, this delay could translate to lost productivity. In a medical center, those extras seconds to wake could mean delaying an alert from a patient who needs help. Certainly, the self-diagnostics routine is important for a router to complete, but the router can run these routines after the router is already transferring data.

Effective Instant-On does improve the user experience. By considering how people are going to use your systems, you not only enhance the user experience but potentially increase user and functional safety as well.