This chapter is from the book
This chapter is from the book
This chapter is from the book
18.4 Resources
In this section, we discuss computing resources from the perspective of their physical characteristics. For example, in devices where energy comes from batteries, we need to be concerned with battery volume, weight, and thermal properties. The same holds true for resources such as networks, processors, and sensors.
The tradeoff in the choice of resources is between the contribution of the particular resource under consideration and its volume, weight, and cost. Cost is always a factor. Costs include both the manufacturing costs and nonrecurring engineering costs. Many mobile systems are manufactured by the millions and are highly price-sensitive. Thus a small difference in the price of a processor multiplied by the millions of copies of the system in which that processor is embedded can make a significant difference to the profitability of the organization producing the system. Volume discounts and reuse of hardware across different products are techniques that device vendors use to reduce costs.
Volume, weight, and cost are constraints given both by the marketing department of an organization and by the physical considerations of its use. The marketing department is concerned with customers’ reactions. The physical considerations for the device’s use depend on both human and usage factors. Smartphone displays must be large enough for a human to read; automobiles are constrained by weight limits on roads; trains are constrained by track width; and so forth.
Other constraints on mobile system resources (and therefore on software architects) reflect the following factors:
Safety considerations. Physical resources that have safety consequences must not fail or must have backups. Backup processors, networks, or sensors add cost and weight, as well as consume space. For example, many aircraft have an emergency source of power that can be used in case of engine failure.
Thermal limits. Heat can be generated by the system itself (think of your lap on which your laptop sits), which can have a detrimental effect on the system’s performance, even to the point of inducing failure. The environment’s ambient temperature—too high or too low—can have an impact as well. There should be an understanding of the environment in which the system will be operated prior to making hardware choices.
Other environmental concerns. Other concerns include exposure to adverse conditions such as moisture or dust, or being dropped.
The Architect’s Concerns
An architect must make a number of important decisions surrounding resources and their usage:
Assigning tasks to electronic control units (ECUs). Larger mobile systems, such as cars or airplanes, have multiple ECUs of differing power and capacity. A software architect must decide which subsystems will be assigned to which ECUs. This decision can be based on a number of factors:
Fit of the ECU to the function. Functions must be allocated to ECUs with sufficient power to perform the function. Some ECUs may have specialized processors; for example, an ECU with a graphics processor is a better fit for graphics functions.
Criticality. More powerful ECUs may be reserved for critical functions. For example, engine controllers are more critical and more reliable than the comfort features subsystem.
Location in the vehicle. First-class passengers may have better Wi-Fi connectivity than second-class passengers.
Connectivity. Some functions may be split among several ECUs. If so, they must be on the same internal network and able to communicate with each other.
Locality of communication. Putting components that intensely communicate with each other on the same ECU will improve their performance and reduce network traffic.
Cost. Typically a manufacturer wants to minimize the number of ECUs deployed.
Offloading functionality to the cloud. Applications such as route determination and pattern recognition can be performed partly by the mobile system itself—where the sensors are located—and partly from portions of the application that are resident on the cloud—where more data storage and more powerful processors are available. The architect must determine whether the mobile system has sufficient power for specific functions, whether there is adequate connectivity to offload some functions, and how to satisfy performance requirements when the functions are split between the mobile system and the cloud. The architect should also take into consideration data storage available locally, data update intervals, and privacy concerns.
Shutting down functions depending on the mode of operations. Subsystems that are not being used can scale down their footprint, allowing competing subsystems to access more resources, and thereby deliver better performance. In sports cars, an example is switching on a “race mode,” which disables the processes responsible for calculating comfortable suspension parameters based on the road profile and activates calculations of torque distribution, braking power, suspension hardening, and centrifugal forces.
Strategy for displaying information. This issue is tied to available display resolution. It’s possible to do GPS style mapping on a 320 × 320 pixel display, but a lot of effort has to go into minimizing the information on the display. At a resolution of 1,280 × 720, there are more pixels, so the information display can be richer. (Having the ability to change the information on the display is a strong motivator for a pattern such as MVC [see Chapter 13] so that the view can be swapped out based on the specific display characteristics.)