The History
PMBus Ancestry: PMBus and the Technologies Preceding It.
From the beginning, power system communications have been integrated into complex systems. Power system communication is not a new idea. Varying levels of communication between host controllers and power subsystems have existed for years. In earlier times, communication allowed the power system to be monitor and enabled. Devices like power supply supervisors monitored the power system and communicated the power state back to system devices. When the output was deemed inadequate for system operation, these supervisors would hold the system in reset or notify the system of impending loss of power.
As microcontrollers became cost effective power management devices, they were used to perform more complex control and monitoring of power subsystems. Initially, the control was simple on-and-off commands that could be used for sequencing. Later these microcontroller devices were used to control voltage outputs along with other operating parameters like current. A simple device like the “digipot†allowed the microcontroller to adjust the voltage sense signals and adjust current sense values. The digipot devices were one of many devices that take advantage of the I2C (inter-integrated circuit) bus such as memory, displays, sensors, and power supply ICs.
The I2C interface specification was created in 1982. Philips created I2C as a simple two wire interface specification suitable for passing data between electronic devices located on the same board or in the same chasis. In 1987, Philips was awarded US patent 4,689,740 for I2C. An I2C bus consists of two lines, one each for clock and data. I2C provides a means to connect multiple devices on a shared bus and have data representing commands, control, and information shared between a host and a slave device. The typical use of I2C is to have a single master device control the communication. Because of its simplicity, the I2C bus is widely adopted. The I2C specification has continued to be developed, allowing greater communication speeds and address range.
The I2C bus was identified as an attractive starting place as a physical communication means for industry standard specifications such as ACCESS.bus, SMBus, PSMI, and IPMI. The I2C interface is available on many microcontrollers; however, the simplicity also allows the bus to driven by software using general purpose I/O pins in many cases. For example, in 1991, a group of companies led the development of ACCESS.bus (or A.b), which used a version of I2C as its physical communications layer, and added two lines to power ACCESS.bus-enabled devices. ACCESS.bus was intended as an improved, simplified, uniform, versatile way to connect a computer's internal and external devices to the CPU. It could support internal devices like clocks and battery power monitors, and external devices like keyboards, mice, display monitors, and modems. The ACCESS.bus working group (ABIG) issued its last specification, version 3.0, in 1995. Several companies active in the ABIG, such as USAR Systems and Fujitsu, went on to become active in the Smart Battery System Interface Forum (SBS-IF).
Prior to 1995, battery management was accomplished through various interface methods including RS-232, one-wire, SPI, and I2C. There were no industry standards for either the physical interface or the command and data format. Intel and Duracell led development of the Smart Battery System (SBS), with the goal of implementing an industry-standard, high-level, accurate battery management specification that is independent of battery chemistry. The driving purpose was to make modern battery management available from multiple vendors while reducing the burden on the system to support multiple protocols. The physical protocol is the System Management Bus (SMBus) and the command language is SBD (Smart Battery Data).
The System Management Bus (SMBus), a version of I2C, is the physical communication layer of SBS. The upper layer of SBS issues commands and responses between SBS components: smart battery, smart charger, and smart selector. The commands and responses are transmitted using the general purpose commands of SMBus, which are mostly identical to those of I2C. These commands allow the battery capacity and condition to be monitored. As importantly, the SBS battery or SBS host can send commands to the Smart Charger to set the charger output voltage and current as well as other critical parameters. The resolution for the output voltage commands is in millivolts and the resolution for current is in milliamps in most cases. This communication interface allowed for a power subsystem to be managed and controlled so that it can perform a charger function that is chemistry-independent.
In 1996, ten promoter companies led by Intel and Duracell formed the Smart Battery System Interface Forum (SBS-IF) to maintain and advance the SBS and SMBus specifications. Several companies active in the SBS-IF, especially Texas Instruments, went on to become active in the Power Management Bus Interface Forum (PMBus-IF).
SBS and SMBus have become widely adopted standards in notebook computer hardware. SMBus software drivers by Microsoft were included in Windows starting with Windows 2000.
SBS and SMBus specification development ran in parallel with the creation of the Advanced Configuration and Power Interface (ACPI) specification (first released December 1996), in which Intel had a leading role also. ACPI was intended as the key element in Operating System-directed configuration and Power Management (OSPM). Implementations of SBS, and of SMBus with the intent to support SBS, tend to rely on ACPI-compliant systems.
In 1998, the SBS-IF introduced SBS 1.1 and SMBus 1.1. The main innovation in SMBus 1.1 is the introduction of and optional Packet Error Check (PEC) byte at the end of each SMBus communications packet. This byte is a standard 8-bit Cyclic Redundancy Check (CRC-8) checksum of the packet's contents.
In 2000, the SBS-IF introduced SMBus 2.0, also known as SMBus on PCI. SMBus 2.0 allows device addresses to be assigned dynamically. The Peripheral Component Interconnect Special Interest Group (PCI SIG) then (in October 200) allocated pins 40 and 41 on the PCI connector to SMBus clock and data respectively.
In 2000, the SBS-IF released its own SMBus driver for Windows. Unlike the Microsoft SMBus drivers, the SBS-IF SMBus driver could be used with Windows 98, and it did not rely on the presence of an embedded controller.
As another example, starting in 1998, Intel introduced IPMI the (Intelligent Platform Management Interface) specification, a set of interfaces for OS-independent computer and cross-computer monitoring. IPMI draws on parallel Intel maintainability specifications such as Metolious (Metolious 1.0 was published April 1999). IPMI 1.0 uses I2C as its physical layer. IPMI 1.5 can use SMBus 1.1, including the optional PEC.
As digitally controlled power systems are being adopted, it is apparent that there is need for an industry standard protocol for power communication. There are several attributes that must be addressed by the protocol. The protocol must be a small burden for the designer, the cost, and the host. Once again an I2C derived bus seemed to be the best compromise. SMBus has been used for years by SBS to manage batteries and power supplies such as chargers and backlight systems. This was considered to be a good place to start.
So in 2004, a group of companies led the development of the Power Management Bus (PMBus), as an industry standard for power subsystem management. PMBus uses SMBus as its physical communication layer and includes support for the SMBus Alert as well as an optional Control line. The current PMBus 1.0 specification does not include address arbitration. The PMBus specification is divided into 2 parts: Part 1 specifies the physical layer while Part 2 specifies the command layer. In much the same way as SBS defines the general means to manage portable power, the PMBus defines the means to manage power subsystems.
The PMBus initiative was endorsed by the Point-of-Load Alliance (POLA) and the Distributed-power Open Standards Alliance (DOSA).
In 2005, the Smart Battery System Interface Forum (SBS-IF), Inc., was renamed the System Management Interface Forum (SMIF), and reorganized to include two forums, the SBS forum (SBS-IF) and the PMBus forum (PMBus-IF). The organization took advantage of the symbiotic relationship of SBS and PMBus. The SBS group had been using the SMBus for nearly ten years to manage and control power supplies within notebook computers, so this knowledge would help the PMBus adopters in their development.
In March 2005, version 1.0 of the PMBus specification was published. The PMBus-IF has more than 30 adopter companies. It is through industry efforts like PMBus that new power technologies like digital power can be adopted without the need to unduly burden the host system with multiple protocols.
http://pmbus.org/ancestry.php
please download this pdf)
Generally speaking an API (Applications Programming Interface) that consists of only 31 functions is an efficient API to work with. It would not be unrealistic to make one's system compatible with this. (they seem to have gotten it right)
Even if the Smart Battery Data Specification is not something that we would necessarily implement in our own systems at the moment it's a larger API that should open our eyes to where computerized Electric Vehicles will go... even if the final "wheel" is slightly different... it won't be much different. (you can't improve much on the Smart Battery Data Specification because it's already as simple as you can make it)
