Mobile Systems Architecture
Outlines the differences between mobile systems and fixed systems in five categories: energy, connectivity, sensors, resources, and life cycle.
This chapter is from the book
This chapter is from the book
This chapter is from the book
With Yazid Hamdi and Greg Hartman
The telephone will be used to inform people that a telegram has been sent.
—Alexander Graham Bell
So, what did Alexander Graham Bell know, anyway? Mobile systems, including and especially phones, are ubiquitous in our world today. Besides phones, they include trains, planes, and automobiles; they include ships and satellites, entertainment and personal computing devices, and robotic systems (autonomous or not); they include essentially any system or device that has no permanent connection to a continuous abundant power source.
A mobile system has the ability to be in movement while continuing to deliver some or all of its functionality. This makes dealing with some of its characteristics a different matter from dealing with fixed systems. In this chapter we focus on five of those characteristics:
Energy. Mobile systems have limited sources of power and must be concerned with using power efficiently.
Network connectivity. Mobile systems tend to deliver much of their functionality by exchanging information with other devices while they are in motion. They must therefore connect to those devices, but their mobility makes these connections tricky.
Sensors and actuators. Mobile systems tend to gain more information from sensors than fixed systems do, and they often use actuators to interact with their environment.
Resources. Mobile systems tend to be more resource-constrained than fixed systems. For one thing, they are often quite small, such that physical packaging becomes a limiting factor. For another, their mobility often makes weight a factor. Mobile devices that must be small and lightweight have limits on the resources they can provide.
Life cycle. Testing mobile systems differs from the testing of other systems. Deploying new versions also introduces some special issues.
When designing a system for a mobile platform, you must deal with a large number of domain-specific requirements. Self-driving automobiles and autonomous drones must be safe; smartphones must provide an open platform for a variety of vastly different applications; entertainment systems must work with a wide range of content formats and service providers. In this chapter, we’ll focus on the characteristics shared by many (if not all) mobile systems that an architect must consider when designing a system.
18.1 Energy
In this section, we focus on the architectural concerns most relevant to managing the energy of mobile systems. For many mobile devices, their source of energy is a battery with a very finite capacity for delivering that energy. Other mobile devices, such as cars and planes, run on the power produced by generators, which in turn may be powered by engines that run on fuel—again, a finite resource.
The Architect’s Concerns
The architect must be concerned with monitoring the power source, throttling energy usage, and tolerating loss of power. We elaborate on these concerns in the next three subsections.
Monitoring the Power Source
In Chapter 6 on energy efficiency, we introduced a category of tactics called “resource monitoring” for monitoring the usage of computational resources, which are consumers of energy. In mobile systems, we need to monitor the energy source, so that we can initiate appropriate behavior when the energy available becomes low. Specifically, in a mobile device powered by a battery, we may need to inform a user that the battery level is low, put the device into battery-saving mode, alert applications to the imminent shutdown of the device so they can prepare for a restart, and determine the power usage of each application.
All of these uses depend on monitoring the current state of the battery. Most laptops or smartphones use a smart battery as a power source. A smart battery is a rechargeable battery pack with a built-in battery management system (BMS). The BMS can be queried to get the current state of the battery. Other mobile systems might use a different battery technology, but all have some equivalent capability. For the purposes of this section, we will assume that the reading identifies the percentage of capacity left.
Battery-powered mobile systems include a component, often in the kernel of the operating system, that knows how to interact with the BMS and can return the current battery capacity on request. A battery manager is responsible for periodically querying that component to retrieve the state of the battery. This enables the system to inform the user of the energy status and trigger the battery-saving mode, if necessary. To inform the applications that the device is about to shut down, the applications must register with the battery manager.
Two characteristics of batteries change as they age: the maximum battery capacity and the maximum sustained current. An architect must allow for managing consumption within the changing envelope of available power so that the device still performs at an acceptable level. Monitoring plays a role in generator-equipped systems as well, since some applications may need to be shut down or put on standby when generator output is low. The battery manager can also determine which applications are currently active and what their energy consumption is. The overall percentage of the change in battery capacity can then be estimated based on this information.
Of course, the battery manager itself utilizes resources—memory and CPU time. The amount of CPU time consumed by the battery manager can be managed by adjusting the query interval.
Throttling Energy Usage
Energy usage can be reduced by either terminating or degrading portions of the system that consume energy; this is the throttle usage tactic described in Chapter 6. The specifics of how this is done depend on the individual elements of the system, but a common example is reducing the brightness or the refresh rate of the display on a smartphone. Other techniques for throttling energy usage include reducing the number of active cores of the processor, reducing the clock rate of the cores, and reducing the frequency of sensor readings. For example, instead of asking for GPS location data every few seconds, ask for it every minute or so. Instead of relying on different location data sources such as GPS and cell towers, use just one of those.
Tolerating a Loss of Power
Mobile systems should gracefully tolerate power failures and restarts. For example, a requirement of such a system could be that following restoration of power, the system is back on and working in the nominal mode within 30 seconds. This requirement implies different requirements apply to different portions of the system, such as the following:
Example hardware requirements:
The system’s computer does not suffer permanent damage if power is cut at any time.
The system’s computer (re)starts the OS robustly whenever sufficient power is provided.
The system’s OS has the software scheduled to launch as soon as the OS is ready.
Example software requirements:
The runtime environment can be killed at any moment without affecting the integrity of the binaries, configurations, and operational data in permanent storage, and while keeping the state consistent after a restart (whether that is a reset or a resume).
Applications need a strategy to deal with data that arrives while the application is inoperative.
The runtime can start after a failure so that the startup time, from system power on to the software being in a ready state, is less than a specified period.