EC-Mediated BMU Communication for Runtime Battery Diagnostics
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems face challenges in efficiently and securely communicating between a host Operating System (OS) application and a Battery Management Unit (BMU) without reboot or reset, particularly when using different processor architectures such as RISC and CISC.
Innovation Solution
The system employs a kernel driver that translates messages between a host OS application and an Embedded Controller (EC) using a hardware-based security architecture, such as TRUSTZONE, to request battery data or diagnostics, without entering System Management Mode (SMM, by utilizing a Look-Up-Table (LUT) and policy-based translations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If the system uses traditional communication methods between host OS application and BMU, then compatibility with existing systems is maintained, but the system requires reboot or reset to perform battery diagnostics and cannot operate without entering System Management Mode
Solution Approach 1:
The patent introduces an Embedded Controller (EC) as an intermediary component between the host OS application and the Battery Management Unit (BMU). The EC receives messages from the host OS application, translates them into appropriate commands, and communicates with the BMU without requiring the host system to enter System Management Mode or perform reboot/reset operations. This mediator approach enables battery diagnostics to be performed while the system remains operational.
2Reliability
If the system implements platform-specific communication protocols for different processor architectures (RISC and CISC), then communication reliability is improved, but device complexity increases due to multiple protocol implementations
Solution Approach 1:
The patent implements a universal message translation mechanism within the EC that can handle multiple processor architectures (RISC and CISC) through a single interface. The EC translates messages from the host OS application into architecture-specific commands automatically, allowing the same host application to communicate with the BMU regardless of whether the underlying processor uses RISC or CISC architecture. This eliminates the need for separate protocol implementations for each architecture.
3Object-affected harmful factors
If the system uses hardware-based security architecture (TRUSTZONE) for secure communication, then security is improved, but device complexity increases due to additional security components and drivers
Solution Approach 1:
The EC serves as an intermediary that handles security operations between the host OS application and the BMU. It manages the TRUSTZONE security architecture by receiving messages from the host application, validating them through the security driver, and translating them into secure commands for the BMU. This approach consolidates security functionality in the EC rather than requiring complex security implementations at multiple layers of the system.
Data Source
AI summary
Systems and methods for handling communications between a host Operating System (OS) application and a Battery Management Unit (BMU) through an Embedded Controller (EC) are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: receive, by a kernel driver of a host OS, a message from a host OS application; and at least in part in response to a determination that the processor comprises a Reduced Instruction Set Computer (RISC) processor, send a request to an EC, wherein the EC is configured to request battery data from a BMU.