Custom system integration
Embedded Redesign
Board Support Package for System Houses
You're familiar with power management from your everyday life
The display turns off, a device switches to standby mode, or certain functions are scaled back during periods of inactivity. In embedded systems, however, such a general approach to energy conservation is usually insufficient, as these systems often require long runtime, defined responses to power dips, and technically sound system behavior.
Power management is an architectural task in embedded systems
Many subsequent energy-saving and power-down strategies require the hardware to have been properly designed for this purpose from the outset. Particularly in the case of customised embedded systems, it is therefore important to clarify at an early stage which voltage ranges, switching paths and system states are to be supported.
Power management in embedded systems goes far beyond simply switching off individual loads. The key lies in the coordinated interaction between the power supply, hardware design, operating system, drivers and application. Whether a device is designed for long battery life or to cope safely with voltage dips, the key decisions are made early on in the system design phase.
Missing power management could cause problems
In many projects, power management only becomes a concrete issue once battery life, stability or shutdown behaviour have already started to cause problems. By this stage, however, key areas of flexibility at the hardware and system levels are often already limited. Particularly in the case of customised embedded devices, this leads to greater integration effort, technical compromises and avoidable risks in the field.
Missing signal paths
Not enough flexibility in hardware design
Inappropriate response to undervoltage
Correcting things at a late stage will be costlyWhere power management actually takes place within the system
In embedded systems, power management does not occur at a single point, but spans several technical levels. Only when the power supply, hardware, SoC, operating system and application work together effectively can energy consumption, runtime and response to critical conditions be reliably controlled.
This is where the basic requirements are established: power supply, buffering, voltage monitoring and switchable loads. This level determines which measures will actually be technically feasible at a later stage.
PMICs and switching logic control voltages, sequencing and individual power supply paths. Separately switchable sections, for example via GPIO or MOSFET, also fall within this scope.
Depending on the platform, the SoC features its own power domains, sleep states and options for adjusting the clock speed and voltage. These functions must be selected and integrated in a way that suits the device’s behaviour.
At this level, state transitions, interrupts and events such as undervoltage or wake-up are processed. This is where it is determined whether power modes and response chains function stably during operation.
The application determines when certain actions are triggered, configured or linked to user interaction. These include, for example, dimming times, switching thresholds or product-specific response sequences.
Key prerequisites are established during the hardware design phase
Many subsequent energy-saving and power-down strategies require the hardware to have been properly designed for this purpose from the outset. Particularly in the case of customised embedded systems, it is therefore important to clarify at an early stage which voltage ranges, switching paths and system states are to be supported.
- Which power domains does the SoC provide?
- Is a suitable PMIC included?
- Can individual voltages be switched off separately as required?
- Can the display, backlight or peripherals be deactivated selectively?
- What specifications or restrictions arise from the SoC or SoM?
- Which shutdown paths and wake-up sources should be supported?
- Which loads must be given priority in the event of a critical situation?
This behaviour is implemented in practice at the operating system and application levels
Once the hardware requirements have been met, the desired power management must be reliably implemented whilst the system is running. The mechanisms vary depending on the platform – such as Embedded Linux, Windows-based embedded systems or Android – but the underlying system logic remains similar.
Two typical scenarios in embedded projecs
Power management requirements vary significantly depending on the class of device. In practice, two basic scenarios occur particularly frequently: the controlled management of voltage dips in devices that are predominantly mains-powered, and ongoing energy optimisation in battery-powered systems.
Even mains-powered devices require robust power management when a voltage dip leaves little time for an orderly response. In such cases, the priority is not maximum operating time, but a controlled transition to a safe state.
Typical requirements:
- early detection of a drop in line voltage
- rapid shutdown or dimming of energy-intensive loads
- prioritised response to prevent data loss
- orderly termination of relevant processes
- clean shutdown of the system, as far as technically possible
For devices that are regularly charged or used on the move, the focus is on continuously optimising energy consumption. The aim is to increase the available runtime without unnecessarily restricting the desired device behaviour.
Typical requirements:
- Continuously monitor battery voltage and capacity
- Adjust switching thresholds and power-saving modes
- Dim or disable the display
- Reduce the SoC or lower voltages
- Limit unnecessary processes, apps or peripherals
Typical technical measures in power management
Which measures are appropriate for a specific device depends on its architecture, power supply concept and application profile. However, certain technical levers recur time and again in embedded projects and should be assessed at an early stage.
Dim or switch off the backlight
Selectively disable peripherals
Handling undervoltage on a per-event basis
Integrate DVFS
Tailor power modes to specific products
Ensuring data consistency
Defining wake-up sources
Take load profiles into accountDepending on the device, other factors may also be relevant
In addition to traditional measures such as switching off, dimming or pulsing, there are device designs in which additional factors are incorporated into power management. Whilst these issues are not the main focus of every project, it may be worthwhile to take them into account depending on the application profile.
Why hardware and software must be considered together in power management
In embedded systems, effective power management can rarely be achieved at a single level. The key factor is how the hardware, system software and application recognise and evaluate states, and respond accordingly.
Hardware defines the possibilities
Switchability, voltage domains and monitoring paths determine which measures will actually be technically feasible at a later stage.
The operating system and drivers implement the system’s response
Interrupts, state changes, power modes and shutdown paths must be handled correctly and implemented reliably at system level.
The application combines technology with product behaviour
User interaction, time profiles and product-specific logic help determine when certain actions take effect and how the device responds to events.
Where power management is particularly important
Power management plays an important role in all sectors where energy availability, security of supply or defined state changes influence the behaviour of a device. This applies not only to traditional battery-powered devices, but also to mains-powered systems with a buffer time or specific requirements for controlled shutdown.
Ideally, this should be done as early as the design and hardware phase. Many subsequent measures depend on whether power domains, signal paths, monitoring and appropriate response options have been taken into account from the outset.
In many cases, yes. However, the extent to which optimisations are possible depends on the existing hardware design, power supply and system architecture.
Not in every case. Software can control a great deal, but only within the limits of the technical capabilities dictated by the hardware, the power supply design and the SoC.
They lay the groundwork for supplying power to specific circuits, isolating individual sections and implementing various operating states in a technically sound manner.
With PowerFail, the focus is on a controlled transition to a safe state. With battery-powered devices, on the other hand, the main priority is to strike a sensible balance between energy consumption and operating time during normal use.
No. Power management is fundamentally a cross-platform issue and can be just as relevant for Windows-based embedded systems or Android.
Backlit displays, wireless modules, high-performance SoCs, active peripherals, and processes that run continuously are often among the biggest power consumers. However, which of these factors are significant in a specific device depends heavily on its architecture and usage.
In such cases, there may not be enough time to shut down devices in a controlled manner, back up data, or safely bring the system to a stable state. This can lead to data loss or unstable behavior.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
