BatteryMAX

BatteryMAX es un sistema de detección de inactividad utilizado para la gestión de energía de computadoras bajo el control del sistema operativo, desarrollado en el Centro Europeo de Desarrollo (EDC) de Digital Research, Inc.  en Hungerford, Reino Unido. Fue creado para abordar la nueva generación de computadoras personales portátiles ( portátiles ) que funcionaban con batería. Por ello, también fue una parte integral del sistema operativo PalmDOS 1.0 de Novell, diseñado para las primeras computadoras de mano en 1992.

Tradicionalmente, el ahorro de energía en las computadoras portátiles se basaba en temporizadores de inactividad del hardware para determinar si una computadora estaba inactiva. Por lo general, la computadora tardaba varios minutos en identificar el estado de inactividad y cambiar a un estado de menor consumo de energía. Al monitorear las aplicaciones de software desde el sistema operativo , BatteryMAX reduce el tiempo de detección del estado de inactividad de minutos a microsegundos. Además, puede cambiar los estados de energía aproximadamente 18 veces por segundo entre las pulsaciones de teclas del usuario. Esta técnica, denominada Detección Dinámica de Inactividad , consiste en detener la CPU durante períodos de tan solo unos microsegundos hasta que se produce un evento de hardware que la reinicia.

DR DOS 5.0, lanzado en 1990, fue el primer sistema operativo para computadoras personales en incorporar un sistema de detección de inactividad para la administración de energía. ^{[ 1 ] [ 2 ]} Fue inventado por los ingenieros británicos Roger Alan Gross y John P. Constant en agosto de 1989. ^{[ 3 ]} El 9 de marzo de 1990 se presentó una patente estadounidense que describía el sistema de detección de inactividad, la cual fue concedida el 11 de octubre de 1994. ^{[ 4 ]}

A pesar de haber tomado la delantera desde el principio y contar con la protección de una patente, BatteryMAX no tuvo un éxito comercial significativo, ya que quedó relegada tras el caos que siguió a la integración de Digital Research en Novell, Inc. en 1991. No fue hasta 1992, unos tres años después de la invención, que la administración de energía por software bajo el control del sistema operativo se generalizó tras el lanzamiento de Advanced Power Management (APM) por parte de Microsoft e Intel .

BatteryMAX utiliza la técnica de detección dinámica de inactividad para ahorrar energía, detectando la actividad de la aplicación (si está inactiva) y cambiando los estados de energía (entrando en modo de bajo consumo), lo que prolonga la duración de la batería del producto.

BatteryMAX emplea un modelo de software de detección por capas encapsulado en un controlador de dispositivo de caracteres DOS llamado $IDLE$que contiene todo el código dependiente del hardware para admitir la detección dinámica de inactividad. ^{[ 5 ]} Puede vincularse al BIOS del sistema operativo DR-DOS o cargarse dinámicamente usando la directiva CONFIG.SYS DEVICE , sobrecargando el controlador predeterminado integrado. Todas las versiones de DR-DOS desde la versión 5.0 han incluido soporte para detección dinámica de inactividad dentro del núcleo del sistema operativo . Cuando el sistema operativo cree que una aplicación está inactiva, llama a la $IDLE$capa BIOS/controlador, que ejecuta código personalizado escrito por el fabricante de la computadora o terceros para verificar la solicitud y cambiar los estados de energía. Usando el concepto de controlador de dispositivo, BatteryMAX puede integrarse con las funciones de administración de energía relacionadas con el hardware, que pueden ser proporcionadas por el hardware subyacente, incluida la interfaz con los BIOS del sistema APM o ACPI .

Los estados de energía dependen del ordenador y varían según el fabricante. Se puede ahorrar energía de varias maneras, como reduciendo o deteniendo la velocidad del procesador o apagando subsistemas completos.

Antes de cambiar el estado de energía, el $IDLE$controlador utiliza la asistencia de hardware disponible para detectar si la aplicación ha estado accediendo a otros componentes del sistema. Por ejemplo, la aplicación podría estar consultando un puerto serie o actualizando una pantalla gráfica. En ese caso, el controlador del dispositivo determina que la aplicación no está inactiva y anula la llamada del kernel para cambiar el estado de energía, transmitiendo información a las capas superiores y permitiendo que la ejecución de la aplicación se reanude.

COMMAND.COM en DR  DOS 5.0 y versiones posteriores implementa un comando interno IDLEque toma ON|OFFparámetros para habilitar o deshabilitar la detección dinámica de inactividad. ^{[ 6 ]}

Una aplicación está inactiva si está esperando algún evento externo, como una pulsación de tecla o un movimiento del ratón, o que transcurra un tiempo determinado. El núcleo de DR-DOS monitoriza todas las llamadas a la API de DOS , creando un perfil del comportamiento de la aplicación. Ciertas combinaciones de llamadas a la API indican que la aplicación está inactiva.

El $IDLE$controlador es capaz de distinguir sutilmente entre un programa que está realmente inactivo, por ejemplo, uno que está sondeando el teclado en un bucle cerrado, y uno que está activo pero que también sondea el teclado para comprobar si se ha pulsado una tecla de cancelación. El controlador realiza esta distinción monitorizando el tiempo que tarda en entrar en estado de inactividad. Si el tiempo se encuentra dentro de un período especificado, el controlador asume que el programa está inactivo, por ejemplo, sondeando en un bucle cerrado para comprobar si se ha pulsado una tecla. Si el tiempo está fuera del límite especificado, el controlador asume que se ha producido algún procesamiento entre los sondeos del teclado y permite que la ejecución de la aplicación se reanude sin cambiar el estado de energía. Una variable local, IDLE_CNTDN, especifica el tiempo con el que se compara el tiempo real que tarda en entrar en estado de inactividad. El valor de esta variable se calcula dinámicamente durante la inicialización y se recalcula periódicamente.

La técnica de detección de inactividad se utilizó por primera vez para mejorar la multitarea de aplicaciones DOS de una sola tarea en el sistema operativo multitarea/multiusuario Concurrent DOS 386 (CDOS386) de Digital Research.

Los programas escritos para sistemas operativos monotarea como MS-DOS/PC  DOS pueden entrar en bucles infinitos hasta que se interrumpan; por ejemplo, cuando esperan a que el usuario pulse una tecla. Si bien esto no supone un problema cuando no hay ningún otro proceso en espera, desperdicia un valioso tiempo de procesador que podría ser utilizado por otros programas en un entorno multitarea/multiusuario como CDOS386. Las aplicaciones diseñadas para un entorno multitarea utilizan llamadas a la API para "suspender" cuando están inactivas durante un período de tiempo, pero las aplicaciones DOS normales no hacen esto, por lo que es necesario utilizar la detección de inactividad.

La versión Concurrent DOS 386 incluía una función de detección de inactividad en el núcleo del sistema operativo que supervisaba las llamadas a la API de DOS para determinar si la aplicación estaba realizando alguna tarea útil o, por el contrario, inactiva. Si estaba inactiva, el proceso se suspendía, lo que permitía al despachador programar la ejecución de otro proceso.

BatteryMAX y la patente de "detección de inactividad" desempeñaron un papel importante en una supuesta infracción de patente relacionada con la gestión de energía del software bajo el control del sistema operativo.

El 15 de mayo de 2009, St. Clair Intellectual Property Consultants presentó la demanda civil n.° 09-354 ante el Tribunal de Distrito de los Estados Unidos para el Distrito 1 de Delaware contra los demandados Acer , Dell , Gateway y Lenovo , y el 18 de septiembre de 2009 presentó la demanda civil n.° 09-704 contra Apple y Toshiba. Las demandas alegaban la infracción de varias patentes estadounidenses de su propiedad relacionadas con la gestión de energía del software bajo el control del sistema operativo.

St. Clair afirmó que Henry Fung había inventado la gestión de energía por software bajo el control del sistema operativo y alegó que estas empresas habían infringido las patentes de St. Clair y, por lo tanto, le debían el pago de regalías . Microsoft intervino en nombre de los demandados y presentó una sentencia declaratoria contra St. Clair el 7 de abril de 2010, solicitando sentencias de no infracción e invalidez de las patentes de Fung (DI 1, CA n.° 10-282). Intel interpuso una demanda en nombre de los demandados, la cual fue admitida el 4 de junio de 2010 (DI 178, CA n.° 09-354).

El bufete de abogados Perkins Coie , con sede en Seattle y que representaba a los demandados, descubrió BatteryMAX y la patente de detección de inactividad de Gross durante una búsqueda de antecedentes . La patente de Gross tenía una fecha de prioridad anterior a las patentes de Fung, lo que, de comprobarse, debilitaría el caso de St. Clair. El 28 de febrero de 2011, Intel contrató a Gross como experto en la materia para que prestara testimonio pericial en defensa de los demandados. En su informe pericial, Gross aportó pruebas de que él, y no Fung, había inventado la gestión de energía por software bajo el control del sistema operativo, y citó la patente de detección de inactividad y la existencia de BatteryMAX como prueba de ello.

St. Clair presentó una moción para excluir las opiniones relativas a BatteryMAX, en un intento de que se desestimara el informe pericial de Gross, pero el 29 de marzo de 2013, el tribunal de distrito denegó la moción de St. Clair, declarando admisible el testimonio de Gross para los demandados, ^{[ 7 ]} afirmando que "El Tribunal está de acuerdo con los demandados en que hay pruebas suficientes que corroboran que BatteryMAX estaba disponible para el público antes de la fecha de prioridad de las patentes de Fung. Además, el Tribunal concluye que incluso si BatteryMAX no fuera anterior a las patentes de Fung, el testimonio del Sr. Gross [...] sería relevante y útil para el juzgador de los hechos en una investigación sobre obviedad ".

• Gestión avanzada de energía (APM)
• Interfaz avanzada de configuración y alimentación (ACPI)

• "Implementación de la administración de energía (BatteryMAX) en DR-DOS" . Caldera, Inc. 1997. Archivado del original el 8 de enero de 2017. Recuperado el 8 de enero de 2017 .