-
Diese
Offenbarung bezieht sich allgemein auf ein Protokollieren von Daten
hinsichtlich einer Verwendung eines Computersystems und genauer
gesagt auf Systeme und Verfahren zum Protokollieren von Daten hinsichtlich
einer Verwendung von Hardwarekomponenten eines Computersystems und
ein Verwenden der protokollierten Daten, um z. B. Verwendungsprofile
zu erzeugen.
-
Computersysteme
wurden entwickelt, um verschiedene Informationen zu protokollieren.
Zum Beispiel wurden bestimmte Systeme, wie beispielsweise dasselbe
von US-Patent Nr. 6,085,244 mit dem Titel „Dynamic Test Update in a
Remote Computer Monitoring System" zum Überwachen von Computersystemen
und Speichern von Systemdiagnose-Informationen entwickelt, die aus
einer Ausführung
von Diagnoseprogrammen resultieren. Dieser Typ einer Überwachungstechnik
verwendet somit Diagnoseprogramme, die periodisch ausführen, um
derartige Diagnose-Informationen zu sammeln, wie beispielsweise
Fehlernachrichten aus Protokolldateien, Systemabsturzdaten, eine
Liste von installierten Patches und Revisionen, eine Hardwarekonfiguration
(RAM, Plattenraum, SCSI-Vorrichtungen)
und Verwaltungsprobleme (volle Plattenpartitionen, ein geringer
Auslagerungsraum).
-
Ferner
wurden bestimmte Computersysteme entwickelt, um eine integrierte
Selbstüberwachungskomponente
zum Überwachen
eines bestimmten Aspekts der Computervorrichtung zu umfassen. Zum
Beispiel das US-Patent Nr. 5,961,215 mit dem Titel „Temperature
Sensor Integral with Microprocessor and Methods of Using Same" sieht einen Temperatursensor
vor, der mit einem Mikroprozessor integriert ist, wobei der Tempera tursensor
verwendet werden kann, um die Taktgeschwindigkeit des Mikroprozessors
zu reduzieren, wenn die Mikroprozessortemperatur eine vorbestimmte
Temperatur überschreitet,
oder um Temperaturangabedaten in einem nichtflüchtigen Speicher des Mikroprozessors
zu speichern, um eine Wärmehistorie
des Mikroprozessors bereitzustellen.
-
Einige
Systeme umfassen Techniken zum Protokollieren von Informationen über eine
Eingabe eines Benutzers (z. B. Tastenanschläge) zu dem Computersystem.
Derartige Techniken können
zu Sicherheits- oder anderen Überwachungszwecken
enthalten sein. Zum Beispiel umfassen bestimmte Systeme Techniken
zum Protokollieren einer Verwendung eines gegebenen Software-Anwendungsprogramms
durch einen Benutzer, um dem Benutzer eine zeit-/verwendungsbasierte
Abrechnung bereitzustellen, wie beispielsweise in dem US-Patent
Nr. 5,155,680 mit dem Titel „Billing
System for Computing Software".
Als ein anderes Beispiel offenbart das US-Patent Nr. 6,622,116 mit
dem Titel „Time
and Activity Tracker" ein
Zeitverfolgungssystem, um zu dokumentieren, wie lange ein Benutzer
an einer spezifischen Aufgabe gearbeitet hat, durch ein Protokollieren
von Informationen hinsichtlich der Computeraktivität des Benutzers,
wie beispielsweise einer Tastatur- und Mausaktivität, einer
Dateizugriffsaktivität
etc., um eine chronologische Zusammenfassung der Aktivitäten des Benutzers
zu tabulieren, was ermöglicht,
dass derartige Informationen zum Nachweisen der Menge an Arbeit verwendet
werden können,
die der Benutzer an einem gegebenen Projekt durchgeführt hat.
Die obigen Techniken protokollieren jedoch eine Verwendung von Hardwarekomponenten
eines Computersystems durch einen Benutzer nicht angemessen. Ferner
haben die obigen Techniken keine wirksame Verwendung der protokollierten
Informationen durch einen Computerhersteller zum Treffen von Entwurfsentscheidungen
hinsichtlich des geeigneten Computersystems für die Kunden desselben geliefert.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein System, ein Verfahren
und einen computerausführbaren
Software-Code mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein System gemäß Anspruch 1 und Anspruch 28,
ein Verfahren gemäß Anspruch
17 und Anspruch 39 und einen computerausführbaren Software-Code gemäß Anspruch
34 gelöst.
-
Gemäß zumindest
einem Ausführungsbeispiel
weist ein System zumindest ein Computersystem auf, das ein Basiseingabe-Ausgabe-System („BIOS" =Basic Input/Output
System) aufweist. Das System weist ferner eine Einrichtung zum Sammeln
von Daten über
eine Verwendung zumindest einer Hardwarekomponente des zumindest
einen Computersystems über
das BIOS auf.
-
Gemäß zumindest
einem Ausführungsbeispiel
weist ein Verfahren ein Sammeln von Daten über eine Verwendung zumindest
einer Hardwarekomponente zumindest eines Computersystems über ein
BIOS des zumindest einen Computersystems auf. Das Verfahren weist
ferner ein Protokollieren der Hardwareverwendungsdaten zu einem
nichtflüchtigen
Speicher des zumindest einen Computersystems auf.
-
Gemäß zumindest
einem Ausführungsbeispiel
ist ein computerausführbarer
Software-Code vorgesehen, der zu einem computerlesbaren Medium gespeichert
ist. Der computerausführbare
Software-Code weist einen Code zum Empfangen protokollierter Daten
hinsichtlich einer Verwendung von Hardwarekomponenten einer Mehrzahl
von Computersystemen und einen Code zum Erzeugen eines Verwendungsprofils
für die Mehrzahl
von Computersystemen zumindest teilweise basierend auf die empfangenen
protokollierten Daten auf.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
exemplarisches Laptop-Computersystem, das ein Ausführungsbeispiel
eines Protokollierens von Hardwareverwendungsdaten implementiert;
-
2 einen
Betriebsfluss gemäß einem
Ausführungsbeispiel
zum Protokollieren von Hardwareverwendungsdaten in einem Computersystem,
wie beispielsweise durch den Protokolliermechanismus des beispielhaften
Systems von 1;
-
3 zeigt
ein detaillierteres Betriebsflussdiagramm für ein exemplarisches Ausführungsbeispiel
zum Protokollieren einer Hardwareverwendung;
-
4 zeigt
ein beispielhaftes Computersystem, das gemäß einem Ausführungsbeispiel
zum Empfangen (oder „Ernten" bzw. Einsammeln)
von Hardwareverwendungsinformationen von einem oder mehreren Computersystemen
(wie beispielsweise dem beispielhaften Computersystem von 1)
und Erzeugen eines Verwendungsprofils für (ein) derartiges) Computersystem(e)
angepasst ist;
-
5 einen
Betriebsfluss gemäß einem
Ausführungsbeispiel
zum Empfangen von protokollierten Hardwareverwendungsdaten für überwachte
Computersysteme und Erzeugen eines Verwendungsprofils für diese
Computersysteme, wie beispielsweise durch den Verwendungsprofilgenerator
des beispielhaften Systems von 4;
-
6 ein
detaillierteres Betriebsflussdiagramm für ein exemplarisches Ausführungsbeispiel
zum Empfangen protokollierter Hardwareverwendungsdaten und Erzeugen
eines Verwendungsprofils; und
-
7 ein
beispielhaftes Betriebsflussdiagramm zum Protokollieren einer Hardwareverwendung
und Er zeugen eines Verwendungsprofils gemäß einem Ausführungsbeispiel.
-
Computerhersteller
haben herkömmlicherweise
Computerentwürfe
für Kunden
mit relativ geringen Informationen hinsichtlich dessen entwickelt,
wie die Kunden derselben die Hardwarekomponenten der Computer tatsächlich verwenden.
Eine Verwendung von Hardwarekomponenten kann von Kunde zu Kunde
sehr stark variieren. Zum Beispiel lassen bestimmte Kunden die Laptop-Computer
derselben viel häufiger
als andere Kunden auf einer Batterieleistung laufen. Als ein anderes
Beispiel öffnen
und schließen
bestimmte Kunden eventuell die Deckel der Laptop-Computer derselben
viel häufiger
als andere Kunden. Als noch ein anderes Beispiel schalten bestimmte
Kunden eventuell die Computer derselben viel häufiger als andere Kunden ein/aus.
Bei einem Entwerfen eines Computersystems für einen gegebenen Kunden, bei
einem Bestimmen des optimalen von einer Mehrzahl von unterschiedlichen
Computersystemen, die einem gegebenen Kunden empfohlen werden sollen,
oder bei einem Versuchen, Ursachen von Problemen zu diagnostizieren,
die bei einem Computersystem eines gegebenen Kunden auftreten, waren
relativ wenige Informationen hinsichtlich dessen verfügbar, wie
der gegebene Kunde die Hardwarekomponenten des Computersystems desselben
verwendet.
-
Unten
beschriebene Ausführungsbeispiele
sehen Systeme und Verfahren zum Protokollieren von Verwendungsinformationen
für ein
Computersystem vor. Bei bestimmten Ausführungsbeispielen geben die
Verwendungsinformationen insbesondere detailliert an, wie ein Benutzer
Hardwarekomponenten des Computersystems verwendet. Zum Beispiel
kann ein Laptop-Computersystem
Daten protokollieren, die die Anzahl von Malen detailliert angeben,
die der Benutzer den Deckel desselben geöffnet und geschlossen hat,
wie oft der Benutzer eine Batterieleistung verwendet hat, wie viele
Male der Benutzer dem System zyklisch Leistung bereitgestellt hat
etc. Gemäß zumindest
einem Ausführungsbeispiel
ist ein neuartiger Protokollierungsmechanismus in dem BIOS (Basic
Input/Output System = Basiseingabe-Ausgabe-System) des Computersystems
zum Protokollieren verschiedener Daten hinsichtlich einer Verwendung
der Hardware des Computersystems implementiert.
-
Ferner
werden bei bestimmten Ausführungsbeispielen
die protokollierten Verwendungsinformationen (die entweder über den
neuartigen Protokollierungsmechanismus, der hierin offenbart ist,
und/oder über
andere Protokollierungsmechanismen, die jetzt bekannt sind oder
später
entwickelt werden, protokolliert werden können) eingebracht und verwendet,
um ein Verwendungsprofil für
den Benutzer des Computersystems zu erzeugen. Derartige Verwendungs-Informationen können für eine Mehrzahl
von Computern (z. B. alle Computer von einem gegebenen Hersteller
oder eine bestimmte Gemeinschaft von Computern, wie beispielsweise
die Computer einer gegebenen Geschäftsorganisation) protokolliert
werden und die protokollierten Verwendungs-Informationen für die Mehrzahl von Computern
können
eingebracht werden, um Verwendungsprofile für die Benutzer dieser Computer
zu erzeugen. Derartige Verwendungsprofile können dann analysiert werden,
um zu bestimmen, wie der Computerentwurf modifiziert/optimiert werden
kann, um der Verwendung derartiger Computer durch die Benutzer zu
entsprechen. Zum Beispiel für
Kunden mit einem Verwendungsprofil, das ein hohes Auftreten einer
Batterieverwendung angibt, kann ein Computersystem mit einer verbesserten
Batterielebensdauer für
diese Kunden entworfen werden. Ferner kann eine Batteriegarantie
diese Kunden empfohlen werden, die stark von einer Batterieverwendung
abhängen.
Als ein anderes Beispiel kann für
Kunden mit einem Verwendungsprofil, das ein hohes Auftreten eines Öffnens und
Schließens
des Deckels des Laptop-Computers derselben angibt, ein Computersystem
mit einem verbesserten Deckel-Öffnungs-/Schließsystem
(z. B. einem verbesserten Scharnier etc.) für diese Kunden entworfen werden.
Das heißt,
der Hersteller kann das Verwendungsprofil verwenden, um zu bestimmen,
wie die Bemühungen
desselben am besten auf ein Verbessern des Computersystems (oder
eine zukünftige
Entwicklung) gemäß der Verwendung
des Kunden zu konzentrieren ist.
-
Gemäß bestimmten
hierin vorgesehenen Ausführungsbeispielen
kann eine Mehrzahl von unterschiedlichen Computersystemen jeweils
einen Hardwareverwendungsmechanismus zum Protokollieren von Daten über die
jeweiligen Hardwareverwendungen derselben umfassen und derartige
protokollierte Daten können zum
Ableiten eines Verwendungsprofils für die Mehrzahl von Computersystemen
verwendet werden. Somit kann z. B. ein Hardwareverwendungsprofil
für alle
Computer eines gegebenen Herstellers, alle Computer einer bestimmten
Geschäftsorganisation
abgeleitet werden. Es ist klar, dass, wie dasselbe hierin verwendet
wird, Geschäftsorganisation
sich auf irgendeine Organisation (z. B. Firma, Bildungsentität, Regierungsentität etc.), irgendeine
Abteilung einer Organisation oder irgendeinen anderen Teilsatz einer
Organisation bezieht.
-
Gemäß bestimmten
Ausführungsbeispielen
werden die protokollierten Hardwareverwendungsinformationen verwendet,
um eine Benutzerprofildatenbank beizubehalten, um einem Computerhersteller
zu helfen, Produktverbesserungen durch ein Ermöglichen einer statistischen
Analyse von Kundenumgebungen anzutreiben, und zusätzlich eine
Unterstützung
auf dritter Ebene bei Fehlersuchbemühungen hinsichtlich Problemen
zu unterstützen,
die durch einen Kunden angetroffen werden. Somit werden bei bestimmten
Ausführungsbeispielen
Hardwareverwendungsdaten gesammelt, um (1) ein Benutzerverwendungsprofil
aufzubauen, um eine statistische Datenbank zu erzeugen, um einen
Hersteller bei einem Systemvalidierungstestplan-Testen zu unterstützen, und
(2) eine Systemausfalldatenbank aufzubauen, um dem Hersteller zu
helfen, die zukünftigen
Entwürfe
desselben zu verbessern. Natürlich
werden verschiedene andere Verwendungen für die protokollierten Hardwareverwendungsdaten
ersichtlich.
-
Ein
Beispiel einer Verwendung der protokollierten Hardwareverwendungsdaten
bestünde
in Batteriegarantiekosteneinsparungen. Die Batteriegarantie beträgt typischerweise
ein Jahr und da eine Batterielebensdauer eine Funktion von Lade-/Entladezyklen
ist, kann ein Hersteller zu Garantiezwecken einen Batterielaufzeitspielraum
bestimmen. Die Wirkung bestünde
darin, Garantiekosten zu senken und eine Garantiedauer zu erhöhen. Diese
Daten könnten
ferner durch den Hersteller verwendet werden, um den Systemvalidierungstestplan
fein einzustellen, um zu der Umgebung des Kunden desselben zu passen.
-
Wie
es oben beschrieben ist, wurden Techniken zum Protokollieren derartiger
Informationen wie einer Benutzereingabe (z. B. Tastenanschläge) zu einem
Computersystem, Protokollieren einer Verwendung einer gegebenen
Softwareanwendung durch einen Benutzer (z. B. zu zeit-/verwendungsbasierten
Abrechnungszwecken), Protokollieren von Ergebnissen aus Diagnoseprogrammen,
die auf einem Computersystem laufen, und Protokollieren einer Temperatur
eines Mikroprozessors in einem Computersystem bereitgestellt. Diese Techniken
protokollieren jedoch eine Verwendung von Hardwarekomponenten eines
Computersystems durch einen Benutzer nicht ausreichend. Außerdem verwendeten
diese Techniken die protokollierten Informationen nicht, um Verwendungsprofile
zu einer Verwendung durch einen Computerhersteller bei einem Treffen
von Entwurfsentscheidungen zu entwickeln.
-
Bei
bestimmten hierin vorgesehenen Ausführungsbeispielen wird eine „direkte" Hardwareverwendung durch
einen Benutzer protokolliert. Eine direkte Hardwareverwendung bezieht
sich auf eine Verwendung von Hardware, die direkt durch einen Benutzer
eingeleitet wird, wie beispielsweise einen Benutzer, der den Deckel eines
Laptop-Computers öffnet
oder schließt,
den Benutzer, der einen Laptop-Computer auf einer Batterieleistung
laufen lässt,
den Benutzer, der den Computer ein- oder ausschaltet, den Benutzer,
der einen Laptop-Computer
an eine Andockstation andockt oder von derselben abdockt, und den
Benutzer, der ein Peripheriegerät verbindet
oder abtrennt (z. B. der Benutzer, der ein Eingabegerät verbindet
oder abtrennt, wie beispielsweise eine Maus, eine Tastatur, einen
Scanner etc. oder ein Ausgabegerät,
wie beispielsweise eine Anzeige, einen Drucker, eine externe Speicherungsvorrichtung
etc.) als Beispiele. Bei derartigen direkten Hardwareverwendungen
soll die Handlung des Benutzers die resultierende Wirkung auf die
Hardware des Computers aufweisen, wie beispielsweise ein Öffnen/Schließen des
Deckels, ein Laufen auf Batterieleistung, ein Ein-/Ausschalten des
Computers, ein Andocken/Abdocken des Computers, ein Verbinden/Trennen
von Peripheriegeräten etc.
Natürlich
kann in einigen Fällen
der Benutzer einen bestimmten Zwischenprozess verwenden, um die
erwünschte
direkte Hardwareverwendung zu erreichen, wie beispielsweise ein
in Wechselwirkung treten mit einer Benutzerschnittstelle, um den
Computer herunterzufahren im Gegensatz zu einem physisch in Wechselwirkung
treten mit der Hardware (z. B. durch ein Drücken eines Leistungsknopfs).
Weil jedoch die Verwendung des Benutzers direkt die beabsichtigte
Wirkung an der Hardware erzielt (z. B. den Computer herunterfahren), wird
eine derartige Verwendung eines Vermittlers in dieser Hinsicht als
eine direkte Hardwareverwendung betrachtet.
-
Bei
bestimmten Ausführungsbeispielen
wird auch eine „indirekte" Hardwareverwendung
durch einen Benutzer protokolliert. Eine indirekte Hardwareverwendung
bezieht sich auf eine Verwendung einer Hardware, die indirekt aus
der Benutzerverwendung des Computers resultieren kann, wie beispielsweise
ein Mikroprozessor, der eine größere Last
und/oder eine erhöhte
Temperatur als eine Folge davon auf sich lädt, dass ein Benutzer beispielsweise
eine bestimmte Anwendung auf dem Computer ausführt. Falls ein Benutzer eine
Ausführung
einer bestimmten Anwendung auf einem Computer auslöst, was
wiederum eine erhöhte
Rechenlast und somit eine erhöhte
Temperatur des Mikroprozessors des Computers als eine Folge der
Mikroprozessor-Verarbeitungsanweisungen der Anwendung bewirkt, ist
in diesem Fall die Folge, die ein Ausführen einer derartigen Anwendung
hinsichtlich eines Erhöhens
der Temperatur des Mikroprozessors hat, eine Wirkung, die indirekt
ist und durch den Benutzer oft nicht bemerkt wird. Während der
Benutzer beabsichtigt, die Anwendung auszuführen, beabsichtigt der Benutzer
im Allgemeinen nicht, die Temperatur des Mikroprozessors zu erhöhen.
-
1 zeigt
ein beispielhaftes Laptop-Computersystem 100, das ein Ausführungsbeispiel
zum Protokollieren von Hardwareverwendungsdaten implementiert. Während ein
spezifisches beispielhaftes Ausführungsbeispiel
gezeigt ist, wie es für
einen Laptop-Computer implementiert ist, können natürlich ähnliche Ausführungsbeispiele
auf irgendeinem anderen prozessorbasierten System zum Protokollieren
einer Hardwareverwendung implementiert werden, wie beispielsweise
auf einem Personalcomputer (PC), einem Arbeitsplatzrechner, einem
Personaldigitalassistenten (PDA), einem Mobiltelefon etc. Zum Beispiel
kann ein ähnliches Ausführungsbeispiel
ohne weiteres angepasst sein, um auf einem Mobiltelefon implementiert
zu sein, um z. B. die Anzahl von Malen zu protokollieren, die der
Benutzer den Deckel eines „Klapptelefons" öffnet/schließt, wie häufig der
Benutzer eine Antenne an dem Telefon erhöht/absenkt, wie häufig der
Benutzer das Telefon mit einem Ladegerät zum Wiederaufladen der Batterie
des Telefons verbindet etc. Folglich wird, wenn es nicht anderweitig
spezifiziert ist, der Ausdruck „Computersystem" hierin breit verwendet
und soll irgendein prozessorbasiertes System umschließen.
-
Bei
dem beispielhaften Ausführungsbeispiel
von 1 umfasst das Laptop-Computersystem 100 einen
Protokolliermechanismus 101, der implementiert ist, um
Hardwareverwendungsdaten zu protokollieren, wie es weiter unten
beschrieben ist. Bei diesem beispielhaften Ausführungsbeispiel ist der Protokolliermechanismuscode 101 innerhalb
des BIOS des Systemspeichers positioniert, der bei diesem Beispiel
ein Flash-ROM 123 ist.
-
Das
beispielhafte Laptop-Computersystem 100 umfasst eine zentrale
Verarbeitungseinheit (CPU = central processing unit) 102,
eine Nordbrücke 103,
eine Südbrücke 104,
eine Graphiksteuerung 105, ein Doppelreihenspeichermodul
(DIMM = dual in-line memory modul) 106, eine Universalserienbus-Steuerung (USB-Steuerung;
USB = Universal Serial Bus) 107, eine Integriert-Treiberelektronik-Steuerung
(IDE-Steuerung; IDE = integrated drive electronics) 108,
eine Systemverwaltungsbus-Steuerung ("SMBus"-Steuerung; SMBus – system management bus) 109,
eine Wärme-
und Lüftersteuerung 110,
eine Peripheriekomponentenverbindungssteuerung (PCI-Steuerung; PCI – peripheral
component interconnect) 111, eine Super-Eingang/Ausgang-Steuerung
(Super-I/O-Steuerung) 112, einen Deckelschalter 113,
eine SMBus-Steuerung 114, eine Batterie 115, eine
Ladeschaltung 116, ein Diskettenlaufwerk 117,
einen seriellen Port bzw. ein serielles Tor 118, einen
parallelen Port 119, eine Tastatursteuerung (KBC = keyboard
controller) 120, eine Tastatur (KB) 121, eine
Maus 122, einen Flash-Nur-Lesespeicher (Flash-ROM; ROM – read only
memory) 123, einen Komplementärmetalloxid-Halbleiterspeicher (CMOS-Speicher; CMOS
= complementary metal-oxide semiconductor) 124 und einen
Infrarotstrahlungsport (IR-Port; IR = infrared radiation) 126.
Bei dem Beispiel von 1 ist das beispielhafte System
ein IBMkompatibles mobiles Computersystem (z. B. ein Laptop), das
ein INTEL-Architektursystem und ein ACPI-basiertes (ACPI = Advanced
Configuration and Power Interface) WindowsTM-Betriebssystem (OS
= operating system) aufweist.
-
Das
beispielhafte System 100 implementiert einen neuartigen
Protokolliermechanismus 101 innerhalb des System-BIOS.
Wie es weiter unten beschrieben ist, können jedoch bei bestimmten
Ausführungsbeispielen Hardwareverwendungsdaten über andere
Protokolliermechanismen gesammelt werden. Bei bestimmten Ausführungsbeispielen
können
Hardwareverwendungsdaten beispielsweise über das Betriebssystem (OS)
unter Verwendung bekannter Techniken gesammelt werden, die durch
Windows Management Instrumentation (WMI), Self-Monitoring, Analysis
und Reporting Technology (SMART) und/oder ACPI verfügbar sind,
anstelle von oder zusätzlich
zu einem Sammeln von Hardwareverwendungsdaten auf der BIOS-Ebene.
-
Während 1 eine
beispielhafte Laptop-Systemarchitektur zeigt, an der ein Ausführungsbeispiel
eines Hardwareverwendungsprotokollierens implementiert sein kann,
wie es hierin weiter beschrieben ist, sind die hierin beschriebenen
Ausführungsbeispiele
natürlich
nicht auf diese beispielhafte Architektur begrenzt. Anstelle dessen
können
andere Systemarchitekturen, die nun bekannt sind oder später entwickelt
werden, verwendet werden und/oder verschiedene Elemente können zu
der beispielhaften Architektur von 1 hinzugefügt werden
und/oder von derselben entfernt werden. Zum Beispiel können hierin
beschriebene Ausführungsbeispiele
ohne weiteres für
eine Verwendung bei einer Systemarchitektur angepasst werden, die
nicht IBMkompatibel ist, kein INTEL-Architektursystem aufweist und/oder
kein ACPI-basiertes WindowsTM-OS verwendet.
Die spezifischen Elemente, die bei dem exemplarischen Laptop 100 von 1 gezeigt
sind, sind weiter unten beschrieben, aber wiederum soll diese Architektur
lediglich ein Beispiel sein und die Ausführungsbeispiele zum Protokollieren
einer Hardwareverwendung, die hierin beschrieben sind, können ohne
weiteres für eine
Verwendung bei anderen Architekturen angepasst werden.
-
Die
CPU 102 umfasst allgemein einen oder mehrere Prozessoren
(z. B. Mikroprozessoren), die eine Einheit bilden, die eine Logikschaltungsanordnung
enthält,
die die Anweisungen der Programme des Computers ausführt, wie
es auf dem Gebiet gut bekannt ist. Die Nordbrücke 103 und die Südbrücke 104 sind
zwei Hauptkomponenten, die viele Prozessorarchitekturen zu umfassen
entworfen sind, wie beispielsweise bei vielen der Prozessoren, die
von INTEL-Corporation erhältlich
sind. Bei vielen Systementwürfen
ist die Nordbrücke 103 im
Wesentlichen die Hauptkomponente der Hauptplatine und ist typischerweise
die einzige Hauptplatinenschaltung neben dem Prozessor, die normalerweise
mit einer vollen Hauptplatinengeschwindigkeit (Prozessorbusgeschwindigkeit)
läuft.
Die Nordbrücke 103 stellt
eine Verbindung zu derartigen Hochgeschwindigkeitskomponenten her,
wie beispielsweise der Graphiksteuerung 105 und dem DIMM 106.
-
Bei
vielen Systementwürfen
ist die Südbrücke 104 die
Komponente mit niedrigerer Geschwindigkeit in dem Chipsatz. Zum
Beispiel stellt die Südbrücke 104 im
Allgemeinen eine Verbindung mit dem PCI-Bus (über die PCI-Steuerung 111)
her und enthält
normalerweise die Dual-IDE-Festplattensteuerungsschnittstellen 108 und
die USB-Schnittstelle 107. Ferner stellt bei diesem Beispiel
die Südbrücke 104 eine
Verbindung mit der SMBus-Steuerung 109 her, die (unter
anderem) eine Temperatur über
die Wärme-
und Lüftersteuerung 110 überwacht.
Die Südbrücke 104 ist
ferner kommunikativ mit der Super-I/O-Steuerung 112 gekoppelt.
Im Allgemeinen ist die Super-I/O-Steuerung 112 ein Chip,
der zum Steuern von Peripheriegeräten mit niedriger Geschwindigkeit
verantwortlich ist, die in vielen Computersystemen zu finden sind,
wie beispielsweise das Diskettenlaufwerk 117, der serielle
Port 118, der parallele Port 119, der Flash-ROM 123 und
der IR-Port 126. Da diese I/O-Vorrichtungen meistens standardisiert
wurden, sind dieselben bei den meisten Computerarchitekturen praktisch
die gleichen und somit kann ein Implementieren der Super-I/O-Steuerung 112,
die die Steuerung dieser verschiedenen Vorrichtungen integriert,
die Gesamtarchitektur vereinfachen. Natürlich kann eine derartige Super-I/O-Steuerung
bei alternativen Architekturen mit getrennten I/O-Steuerungen ersetzt
sein. Die Super-I/O-Steuerung 112 ist bei dem Beispiel
von 1 ferner kommunikativ mit dem Deckelschalter 113,
der SMBus-Steuerung 114 und
der KBC 120 gekoppelt.
-
Gemäß diesem
beispielhaften Ausführungsbeispiel
sammelt der Flash-ROM 123 Daten basierend auf Unterbrechungsrufen,
einer Systemverwaltungsunterbrechung (SMI = System Management Interrupt),
ASL, Smbios, ACPI und/oder SMART. Bei bestimmten Ausführungsbeispielen
wird z. B. eine Systemverwaltungsmodus-Programmierung (SMM-Programmierung;
SMM = System Management Mode) (hierin auch als „SMBIOS" bezeichnet) durch den Protokolliermechanismus 101 in
dem System-BIOS
des Flash-ROM 123 zum Sammeln bestimmter Hardwareverwendungsinformationen
verwendet. Ein derartiger BIOSbasierter Mechanismus zum Protokollieren
einer Hardwareverwendung ist eine neuartige Technik, die hierin
unten vollständiger
beschrieben ist. Zusätzlich
oder alternativ können
bei bestimmten Ausführungsbeispielen
andere Protokolliertechniken eingesetzt werden, wie beispielsweise
Techniken, die Hardwareverwendungsdaten durch OS-Rufe sammeln. Ungeachtet
der eingesetzten Hardwareverwendungs-Sammeltechniken sind neuartige Verwendungen
für derartige
gesammelte Daten hierin weiter beschrieben, wie beispielsweise ein
Erzeugen von Kundenverwendungsprofilen.
-
Gemäß einer
beispielhaften Implementierung zeigt Tabelle 1 unten Typen von Daten,
die protokolliert werden, sowie wo derartige Daten gespeichert sind
und den zum Sammeln der Daten verwendeten Mechanismus. Natürlich können andere
Speicherungspositionen und/oder Protokolliermechanismen bei alternativen
Implementierungen verwendet werden und unterschiedliche Daten können bei
alternativen Implementierungen protokolliert werden.
-
-
-
-
Bei
dem beispielhaften System von 1 werden
der CMOS 124 und der Flash-ROM 123 für eine temporäre Datenspeicherung
der gesammelten Hardwareverwendungsdaten verwendet. Bei einem Ausführungsbeispiel
sind Daten, die mehr als 1000 Mal aktualisiert werden sollen, temporär in dem
CMOS 124 gespeichert, während
Daten, die weniger als 1000 Mal aktualisiert werden sollen, temporär in dem
Flash-ROM 123 ge speichert sind. Bei der beispielhaften
Architektur von 1 erfolgt ein CMOS-Zugriff durch
I/O-Ports 70h (Index) und 71h (Daten).
-
Eine
Flash-Speichervorrichtung, wie beispielsweise der Flash-ROM 123 ist
spezifiziert, um eine finite Zeitdauer zuverlässig programmiert zu werden
(typischerweise näherungsweise
8000 Mal). Um den Flash-ROM 123 zu verwenden, ist es deshalb
erwünscht,
irgendwelche veränderten
Daten in einer temporären Speicherung
(reservierter Systemspeicherbereich) bei Laufzeit zu speichern,
bis das System heruntergefahren wird. Dies würde ermöglichen, dass der Flash-ROM 123 weniger
Male programmiert wird, um das Flash-Zuverlässigkeitsproblem zu vermeiden.
Mit anderen Worten werden, wenn Hardwareverwendungsdaten während einer
Laufzeit des Systems (ansprechend auf ein Auftreten einer gegebenen
Hardwareverwendung, die protokolliert wird) aktualisiert werden,
die aktualisierten Daten in einer temporären Speicherung, wie beispielsweise
CMOS 124 protokolliert und derartige Daten werden auf eine
Systemherunterfahrung hin zu dem System-ROM, d. h. Flash-ROM 123 geschrieben.
Während
diese Datenspeicherungsstrategie für bestimmte Ausführungsbeispiele
eingesetzt wird, können
andere Datenspeicherungsstrategien ähnlich zum Protokollieren der
gesammelten Hardwareverwendungsdaten in einer erwünschten
Weise eingesetzt werden.
-
Gemäß bestimmten
Ausführungsbeispielen
können
die gesammelten Hardwareverwendungsdaten von dem überwachten
System geerntet bzw. eingesammelt werden und einem Benutzer präsentiert
werden. Gemäß einem
Ausführungsbeispiel
schreibt der Flash-ROM 123 z. B. die gesammelten Daten
zu einer WMI-Datei
(WMI = Windows Management Instrumentation). Ein Anwendungsprogramm,
das eventuell auf einem getrennten Computersystem (wie beispielsweise
auf einem Computersystem des Herstellers) ausgeführt wird, empfängt die
WMI-Datendatei,
verarbeitet dieselbe und zeigt dieselbe einem Benutzer für eine Analyse an.
Beispiele der resultierenden verarbeiteten Informationen (z. B.
Verwendungsprofile für
eines oder mehrere Computersysteme), die einem Benutzer präsentiert
werden können
und durch denselben für
eines oder mehrere Computersysteme analysiert werden können, sind
weiter unten beschrieben. Durch ein Spezifizieren von WMI kann auf
die Systemverwaltungs-Informationen in einer Unternehmensrechenumgebung
zugegriffen werden. WMI ist eine Komponente des Microsoft® Windows® Betriebssystems
und ist die Microsoft-Implementierung von WBEM (Web-Based Enterprise
Management = Web-basierte Unternehmensverwaltung), was eine Industrieinitiative
ist, um eine Standardtechnologie zum Zugreifen auf Verwaltungsinformationen
in einer Unternehmensumgebung zu entwickeln. WMI verwendet den CIM-Industriestandard
(CIM = Common Information Model = gemeinsames Informationsmodell),
um Systeme, Anwendungen, Netzwerke, Vorrichtungen und andere verwaltete
Komponenten darzustellen. WMI kann verwendet werden, um Verwaltungsaufgaben
in einer Unternehmensumgebung zu automatisieren. Die gesammelten
Daten können
natürlich
bei alternativen Ausführungsbeispielen
zu anderen Typen von Dateien (anderen als WMI) geschrieben werden,
falls es so erwünscht
ist.
-
Wie
es bei der beispielhaften Implementierung von 1 gezeigt
ist, können
verschiedene Typen einer Hardwareverwendung durch den Protokolliermechanismus 101 erfasst
und protokolliert werden. Zum Beispiel kann der Deckelschalter 113 überwacht
werden, um die Anzahl von Malen, die ein derartiger Deckelschalter 113 geöffnet und
geschlossen wird, über
GPIO und SMM zu zählen.
GPIO ist ein Universal-Digital-Eingang/Ausgang-Signal
(General Purpose Digital Input/Output). Dasselbe kann als ein Eingangssignal
oder ein Ausgangssignal programmiert sein. In dem Fall des Deckelschließungszählwerts
ist das GPIO als ein Eingangssignal programmiert und SMM wird durch
den Protokolliermechanismus 101 verwendet, um die Anzahl von
Malen zu zählen,
die der Deckelschalter 113 geöffnet und geschlossen wird.
-
Ferner
kann die Anzahl von Warmbootvorgängen
zu dem System durch die KBC 120 über SMM gezählt werden. Bei diesem beispielhaften
Ausführungsbeispiel
soll SMM für
fortgeschrittene Leistungsverwaltungsmerkmale und andere betriebssystemunabhängige Funktionen
verwendet werden. Der Chipsatz ist programmiert, um viele Typen
von Ereignissen und Zeitabläufen
zu erkennen. Wenn ein derartiges Ereignis auftritt, aktiviert der
Chipsatz den SMI#-Eingangsanschlussstift. Bei der nächsten Anweisungsgrenze
sichert der Mikroprozessor den gesamten Zustand desselben und tritt
in SMM ein.
-
Wenn
der Mikroprozessor in SMM eintritt, aktiviert derselbe einen Ausgangsanschlussstift,
SMIACT#. Dieser Anschlussstift dient dazu, den Chipsatz zu benachrichtigen,
dass der Mikroprozessor in SMM eintritt. SMI# kann zu irgendeiner
Zeit während
irgendeines Betriebsmodus außer
innerhalb von SMM selbst aktiviert werden. Der Chipsatz erkennt
SMIACT# und richtet alle nachfolgenden Speicherzyklen zu einem geschützten Speicherbereich
um, der spezifisch für
SMM reserviert ist. Sofort nach einem Empfangen des SMI#-Eingangssignals und
einem Aktivieren des SMIACT#-Ausgangssignals
beginnt der Mikroprozessor, den gesamten inneren Zustand desselben
zu diesem geschützten
Speicherbereich zu sichern.
-
Nachdem
der Mikroprozessorzustand zu einem Speicher gespeichert wurde, beginnt
die spezielle SMM-Handhabungseinrichtung auszuführen. Bei einer beispielhaften
Implementierung befindet sich der Prozessor in einem realen Modus,
weisen alle Segmente 4-GB-Grenzen auf und sind alle Segmente les-/beschreibbar.
Nachdem der SMM-Code ausgeführt
hat, kehrt derselbe zu der vorhergehenden Betriebsumgebung zurück. Das
Programm führt
die RSM-Anweisung aus, um aus SMM auszutreten. RSM liest die Mikroprozessorzustandsdaten
aus der Zustandssicherungsabbildung und stellt den gesamten Mikroprozessorzustand
wieder her bzw. speichert denselben zurück. Wie LOADALL führt RSM
praktisch keine Überprüfungen an
den Daten in der Zustandssicherungsabbildung durch. Auf einen Abschluss
von RSM hin wurde der gesamte Mikroprozessorzustand neu definiert
und das vorhergehende Programm nimmt eine Ausführung genau da wieder auf,
wo dasselbe aufgehört
hat.
-
Verschiedene
andere Typen von „direkten" Hardwareverwendungen
können
bei diesem System ähnlich
erfasst werden, wie beispielsweise ein Betreiben des Systems auf
einer Batterieleistung, dass der Benutzer den Laptop-Computer an
eine Andockstation andockt oder von derselben abdockt, der Benutzer
ein Peripheriegerät
verbindet oder abtrennt etc. (wie beispielsweise die verschiedenen
Typen von „direkten" Hardwareverwendungen
von Tabelle 1 oben). Somit können
verschiedene direkte Hardwareverwendungen durch einen Benutzer des
Systems 100 durch den Protokolliermechanismus 101 erfasst
und protokolliert werden.
-
Ferner
können
bestimmte indirekte Hardwareverwendungen durch den Protokolliermechanismus 101 erfasst
und protokolliert werden. Zum Beispiel kann eine Systemtemperatur über die
Wärmesteuerung 110 überwacht
werden. Verschiedene Beispiele anderer Typen von „indirekten" Hardwareverwendungen,
die bei diesem System erfasst werden können, sind in Tabelle 1 oben
enthalten.
-
Ein
beispielhaftes Protokoll von Hardwareverwendungsdaten, die durch
den Protokolliermechanismus 101 gemäß einem Ausführungsbeispiel
gesammelt werden können,
ist in Tabelle 2 unten gezeigt.
-
-
-
Jedes
der obigen beispielhaften Felder von Tabelle 2 kann beispielsweise
durch ein Computersystem auf der oben in Verbindung mit 1 beschriebenen
Weise gesammelt/protokolliert werden. Die in Tabelle 2 oben enthaltenen
Werte sind lediglich Beispiele von Daten, die für ein gegebenes System protokolliert
werden können.
Ferner sind die in Tabelle 2 enthaltenen Felder lediglich als Beispiele
beabsichtigt und zusätzliche oder
alternative Daten können
bei alternativen Ausführungsbeispielen
in dem Protokoll enthalten sein. Zum Beispiel kann die Anzahl von
Malen, die ein Laptop auf einer Batterieleistung laufen gelassen
wird, protokolliert werden, ein Zeitnehmer (Timer) kann verwendet
werden, um die Gesamtzeitdauer zu protokollieren, die der Laptop
auf einer Batterieleistung laufen gelassen wird, und/oder die Zeitdauer
zu protokollieren, die der Laptop auf einer Batterieleistung jedes
Mal laufen gelassen wird, wenn derselbe von einer AC-Leistung entfernt
wird (somit können
die protokollierten Informationen angeben, wie lange der Benutzer
den Laptop typischerweise auf einer Batterieleistung laufen lässt, um
beispielsweise zu bestimmen, ob bei der Batterie typischerweise eine
Leistung im Wesentlichen aufgebraucht wird, bevor dieselbe durch
den Benutzer wieder aufgeladen wird). Gleichermaßen kann anstelle oder zusätzlich zu
einem Sammeln der Anzahl von Malen, die ein Laptop an/von einer
Andockstation angedockt/abgedockt wird, ein Zeitnehmer verwendet
werden, um die Menge an Zeit zu protokollieren, die der Laptop angedockt
gegenüber
abgedockt ist.
-
2 zeigt
einen Betriebsfluss gemäß einem
Ausführungsbeispiel
zum Protokollieren von Hardwareverwendungsdaten bei einem Computersystem,
wie beispielsweise durch den Protokolliermechanismus 101 des
Systems 100 von 1. Bei einem Betriebsblock 201 werden
für zumindest
ein Computersystem Daten über
eine Verwendung zumindest einer Hardwarekomponente eines derartigen
Computersystems (derartiger Computersysteme) über ein BIOS des Computersystems
(der Computersysteme) gesammelt. Zum Beispiel ist der Deckel schalter 113 das
beispielhafte System von 1 und erfasst das Öffnen/Schließen des
Deckels. Das BIOS verfolgt die Anzahl von Offen/Geschlossen-Zyklen
durch SMM. Das heißt,
der Protokolliermechanismus 101 des Systems 100 sammelt
Daten über
die Anzahl von Malen, die der Deckel des Systems 100 geöffnet und
geschlossen wird. Bei einem Betriebsblock 202 werden die
Hardwareverwendungsdaten zu einem nichtflüchtigen Speicher des entsprechenden
Computersystems (der entsprechenden Computersysteme) protokolliert.
Zum Beispiel kann durch den Protokolliermechanismus 101 die
Anzahl von Malen, die der Deckel des Systems 100 geöffnet und
geschlossen wird, zu dem Flash-ROM 123 protokolliert werden.
-
3 zeigt
ein detaillierteres Betriebsflussdiagramm 300 für ein exemplarisches
Ausführungsbeispiel zum
Protokollieren einer Hardwareverwendung. Meistens kann eine jegliche
Art von Daten durch ein Verwenden der Datenprotokollstruktur, die
eingerichtet wurde, gesichert und wiedererlangt werden. Beispielsweise können die
Anzahl und der Typ von Abschaltungen, Deckelschalteröffnungen
und -schließungen
und unterschiedliche Typen von Flash-Schreibvorgängen einschließlich des
FBDA (Flash BIOS Data Area) und der Mikrosteuerung bei bestimmten
Ausführungsbeispielen
gesammelt werden. Daten werden bei unterschiedlichen Orten gehalten,
wenn das System aktiv ist, und in dem FLASH-FBDA und dem CMOS gehalten,
wenn das System inaktiv ist. Bei einem Block 301 ist ein
Datenprotokollieren (z. B. der Protokolliermechanismus 101)
in dem BIOS des Computersystems resident. Bei einem Block 302 ruft
der Protokolliermechanismus 101 ansprechend auf eine Systemrücksetzung
eine InitDataLog-Prozedur in einem SMM-Modus auf. Bei einem Block 303 liest die
InitDataLog-Prozedur ein Datenprotokoll aus einer Flash-ROM-Vorrichtung
(z. B. dem Flash-ROM 123 des Systems 100) (das
Datenprotokoll wird von dem vorhergehenden System Herunterfahren
zu dem Flash-ROM geschrieben) und speichert dasselbe in einem Puffer.
INITDATALOG liest die Signatur (auch Prüfsumme genannt), um sicherzustellen, dass
keine Datenverfälschung
auftrat und das Datenprotokoll gültig
ist. Falls die bekannte Signatur nicht mit der gelesenen Signatur übereinstimmt,
wird das Datenprotokoll als ungültig
betrachtet oder gelöscht
und die Datenprotokollvariablen werden zu Null gelöscht.
-
Bei
einem Block 304 werden, falls die Daten als gut betrachtet
werden, Laufzeitvariablen zu einem Variablenraum in einer SMM-Struktur
bewegt. In einigen Fällen,
in denen Informationen in einem CMOS aktualisiert werden, werden
Daten (KBC-Steuerungsaktualisierung, FBDA) aktualisiert, bevor dieselben
zu der SMM-Struktur bewegt werden. Ein CMOS wird lediglich verwendet,
um Daten temporär
zwischen Bootvorgängen
zu halten, bei denen das System eventuell nicht die Fähigkeit
aufweist, dieselben zu dem FBDA aufzuzeichnen, bevor eine Abschaltung
auftritt. Bei einem Block 305 ruft der Protokolliermechanismus 101 eine
InitDataLog-DMI-Prozedur
auf, um Daten zu einer DMI-Struktur zu bewegen. Eine Struktur ist
ebenfalls als ein Datenfeld bekannt. DMI ist eine Desktop-Management-Interface-Softwarespezifikation.
DMI erzeugt ein Standardrahmenwerk zum Verwalten und Verfolgen von
Komponenten in einem Desktop-PC, Notebook oder Server. Der nächste Schritt
in dem Prozess ist eine Prozedur namens InitDataLogDMI (POSTDMI.ASM),
die die Daten zu der DMI-Struktur bewegt. Abhängig von den Daten werden dieselben
entweder von dem Laufzeit-SMM-Variablenraum (eine für eine SMM-Programmierung
reservierte Speicherregion) oder direkt von einem FBDA bewegt. Es
ist zu beachten, dass ungeachtet dessen, wann die DMI-Daten gelesen
werden, die Zählwerte
lediglich zu der Zeit eines Systembootvorgangs aktuell sind. Dies
ist so, weil die DMI-Struktur während
POST in dem F000-Laufzeit-Segment platziert ist. Falls die aktuellen
Daten zu irgendeiner speziellen Zeit erwünscht sind, dann kann das System
heruntergefahren und wieder gebootet werden, um das Datenprotokoll zu
aktualisieren.
-
Bei
einem Block 306 werden Laufzeitdaten in einem CMOS (z.
B. dem CMOS 124 des Systems 100) oder einem SMM- Variablenraum gespeichert.
Bei einem Block 307 wird vor einer Systemabschaltung SaveDataLog
ausgeführt,
um alle gesammelten Daten zu lesen und dieselben zurück in FBDA
zu speichern. Die in FBDA gesammelten Daten umfassen bei einer beispielhaften
Implementierung die folgenden Daten:
- 1. Zählwert der
Anzahl von tastaturgesteuerten Aktualisierungen (KBC-Aktualisierungen;
KBC = keyboard controlled);
- 2. Zählwert
der Anzahl von Deckelschaltereignissen;
- 3. Zählwert
der Anzahl von Warmbootvorgängen;
- 4. Anzahl von (S5) Leistungsübergängen (Ausschalten)
sichern;
- 5. Zählwert
der Anzahl von Bereitschaftsabschaltungen;
- 6. Zählwert
der Anzahl von FBDA-Aktualisierungen; und
- 7. Zählwert
der Anzahl von Flash-BIOS-Aktualisierungen.
-
Natürlich können, wie
es oben beschrieben ist, bei anderen Implementierungen verschiedene
andere Daten zusätzlich
oder anstelle der obigen Daten durch den BIOS-Protokolliermechanismus protokolliert
werden.
-
Gemäß bestimmten
hierin vorgesehenen Ausführungsbeispielen
werden protokollierte Hardwareverwendungsinformationen, die für eines
oder mehrere Computersysteme (wie beispielsweise dieses, das durch den
BIOS-Protokolliermechanismus 101 des Systems 100 und/oder
irgendeinen anderen Protokolliermechanismus, der nun bekannt ist
oder später
entdeckt wird, protokolliert wird) protokolliert werden, durch ein
anderes Computersystem (z. B. ein Computersystem eines Herstellers)
eingesammelt und verwendet, um ein Verwendungsprofil zu erzeugen.
Ferner können
bei bestimmten Ausführungsbeispie len
protokollierte Hardwareverwendungsinformationen, die zu jedem einer
Mehrzahl unterschiedlicher Computersysteme protokolliert werden,
durch ein anderes Computersystem eingesammelt werden und verwendet
werden, um ein Verwendungsprofil für die Mehrzahl von unterschiedlichen
Computersystemen zu erzeugen. Zum Beispiel kann jedes Computersystem
eines gegebenen Kunden (z. B. eine gegebene Geschäftsorganisation)
den Protokolliermechanismus umfassen, um die jeweiligen Hardwareverwendungsdaten
desselben zu protokollieren, und die Hardwareverwendungsdaten von
allen derartigen Kundencomputersystemen können durch ein Computersystem
eines Herstellers periodisch gesammelt werden, um ein Verwendungsprofil
für diesen
Kunden zu erzeugen. Tabelle 3 unten zeigt ein Beispiel von Verwendungsprofilen,
die für
einen Satz von überwachten
Computersystemen (d. h. Computersysteme, die jeweils einen Hardwareverwendungsprotokolliermechanismus
umfassen) gesammelt werden können.
-
-
Wie
es in dem Beispiel von Tabelle 3 gezeigt ist, können Verwendungsprofilinformationen,
wie beispielsweise diese von Tabelle 2 oben eingesammelt und einem
Kunden zugeordnet werden. Zum Beispiel können die Verwendungsprofile
einem entsprechenden Benutzer, einer entsprechenden Firma und/oder
einer entsprechenden Abteilung der Firma zugeordnet werden. Bei
dem Beispiel von Tabelle 3 identifiziert die erste Zeile einer derartigen
Tabelle, dass die gesam melten Hardwareverwendungsinformationen einem
gegebenen Benutzer, Benutzer A, entsprechen, der anstelle dessen
ein gegebener Computer des Benutzers sein kann, wie beispielsweise
ein Computer ID 123456. Die erste Zeile umfasst ferner ein Feld,
das identifiziert, dass dieser Benutzer/dieses Computersystem einer „Firma
X" gehört, und
es ist ein Feld enthalten, das identifiziert, dass dieser Benutzer/dieses
Computersystem in der „Buchhaltungsabteilung" einer derartigen
Firma X verwendet wird. Das letzte Feld der ersten Zeile umfasst
die entsprechenden Hardwareverwendungsdaten, die für diesen Benutzer/Computer
protokolliert wurden, wie beispielsweise die beispielhaften Verwendungsinformationen von
Tabelle 2 oben. Die folgenden Zeilen von Tabelle 3 umfassen gleichermaßen ein
Feld, das einen gegebenen Benutzer/ein gegebenes Computersystem,
eine entsprechende Firma, eine entsprechende Abteilung der Firma
und die entsprechenden protokollierten Hardwareverwendungsdaten
für einen
derartigen Benutzer/ein derartiges Computersystem identifiziert.
-
Somit
können
die Verwendungsprofile verwendet werden, um ordnungsgemäße Entwurfserwägungen für einen
gegebenen Benutzer, eine gegebene Firma (basierend auf einer Mehrzahl
von Benutzern derselben, wie beispielsweise Benutzer A und B der
Firma X in Tabelle 3) und/oder eine gegebene Abteilung einer Firma (z.
B. alle Benutzer der Buchhaltungsabteilung von Firma X in Tabelle
3) zu bestimmen. Mit anderen Worten können die eingesammelten Daten
von Tabelle 3 verwendet werden, um ein Verwendungsprofil für alle Benutzer
der Firma X oder alle Benutzer der Buchhaltungsabteilung der Firma
X oder alle Benutzer aller Buchhaltungsabteilungen über verschiedene
unterschiedliche Firmen beispielsweise zu erzeugen. Somit können die eingesammelten
Informationen zum Bestimmen der ordnungsgemäßen Entwurfserwägungen für einzelne
Benutzer eines Kunden, spezifische Abteilungen des Kunden etc. verwendet
werden. Der Hersteller kann diese Informationen beispielsweise verwenden,
um einen geeigneten Computersystementwurf für eine Verwendung in einer
Buchhal tungsabteilung einer Firma basierend auf dem Verwendungsprofil
der Buchhaltungsabteilung dieser Firma und/oder basierend auf Verwendungsprofilen
von Benutzern über
Buchhaltungsabteilungen verschiedener unterschiedlicher Firmen vorzuschlagen.
Als ein Beispiel kann die durchschnittliche Menge an Zeit, die ein
Laptop-Computersystem durch Benutzer in der Buchhaltungsabteilung
der Firma X auf einer Batterieleistung laufen gelassen wird, aus
den entsprechenden protokollierten Hardwareverwendungsinformationen bestimmt
werden und derartige Informationen können verwendet werden, um ein
gegebenes Computersystem zu entwerfen und/oder vorzuschlagen, das
zum Bedienen der Batterieverwendungsbedürfnisse der Buchhaltungsabteilung
der Firma X am besten geeignet ist. Dies stellt somit ein Beispiel
zum Erzeugen eines Verwendungsprofils für eine Geschäftsorganisation
(z. B. eine Firma, eine Abteilung etc.) bereit, die von Interesse
ist.
-
4 stellt
ein beispielhaftes Computersystem 400 dar, das gemäß einem
Ausführungsbeispiel
zum Empfangen (oder „Ernten" bzw. einsammeln)
von Hardwareverwendungsinformationen von dem Protokolliermechanismus
eines oder mehrerer überwachter
Computersysteme (wie beispielsweise des Computersystems 100 von 1)
und Erzeugen eines Verwendungsprofils für ein derartiges Computersystem
(derartige Computersysteme) angepasst ist. Das Computersystem 400 kann
beispielsweise an einem Ort eines Herstellers zum Empfangen protokollierter
Hardwareverwendungsinformationen von Computersystemen implementiert sein,
die durch einen derartigen Hersteller hergestellt werden (z. B.
das Computersystem 100 von 1). Während ein
beispielhaftes Computersystem 400 in 4 gezeigt
und weiter unten beschrieben ist, sind hierin beschriebene Ausführungsbeispiele
zum Empfangen protokollierter Hardwareverwendungsinformationen und Erzeugen
von Verwendungsprofilen nicht auf diese beispielhafte Architektur
begrenzt, sondern anstelle dessen kann irgendeine geeignete Computersystemarchitektur
verwendet werden, die nun bekannt ist oder später entdeckt wird und die zum Unterstützen der
hierin beschriebenen Operationen in der Lage ist.
-
Bei
dem beispielhaften System 400 von 4 ist eine
zentrale Verarbeitungseinheit (CPU = central processing unit) 401 mit
einem Systembus 402 gekoppelt. Die CPU 401 kann
irgendeine allgemeine CPU sein. Die CPU 401 kann die verschiedenen
logischen Anweisungen zum Empfangen („Ernten") protokollierter Hardwareverwendungsdaten
von einem oder mehreren Computern und Erzeugen eines Verwendungsprofils
für einen
derartigen Computer (derartige Computer) ausführen, wie es weiter hierin
beschrieben ist. Die CPU 401 kann beispielsweise Anweisungen
auf Maschinenebene gemäß den exemplarischen
Betriebsflüssen
ausführen,
die unten in Verbindung mit 5 und 6 beschrieben
sind.
-
Das
Computersystem 400 umfasst ferner vorzugsweise einen Direktzugriffsspeicher
(RAM – random access
memory) 403, der ein SRAM, ein DRAM, ein SDRAM oder dergleichen
sein kann. Das Computersystem 400 umfasst vorzugsweise
einen Nur-Lesespeicher (ROM = read-only memory) 404, der
ein PROM, EPROM, EEPROM oder dergleichen sein kann. Der RAM 403 und
der ROM 404 halten Benutzer- und Systemdaten und Programme,
wie beispielsweise einen Verwendungsprofilgenerator 416,
der unten beschrieben ist, wie es auf dem Gebiet gut bekannt ist.
-
Das
Computersystem 400 umfasst ferner vorzugsweise einen Eingang/Ausgang-Adapter
(I/O-Adapter; I/O = input/output) 405, einen Kommunikationsadapter 411,
einen Benutzerschnittstellenadapter 408 und einen Anzeigeadapter 409.
Der I/O-Adapter 405, der Benutzerschnittstellenadapter 408 und/oder
der Kommunikationsadapter 411 können bei bestimmten Ausführungsbeispielen
ermöglichen,
dass ein Benutzer mit dem Computersystem 400 in Wechselwirkung
tritt, um Informationen zu demselben einzugeben. Zum Beispiel können protokollierte
Hardwareverwendungsinformationen von dem entsprechenden Computer
(den entsprechenden Computern) auf irgendeine geeignete Weise empfangen
werden. Bei einem Ausführungsbeispiel können z.
B. derartige protokollierte Hardwareverwendungsinformationen, die
zu einem gegebenen Computersystem (z. B. dem Computersystem 100 von 1)
gespeichert sind, durch das System 400 durch ein kommunikatives
Koppeln der Hauptplatine eines derartigen gegebenen Computersystems
mit dem System 400 (z. B. über einen USB-Port des Systems 400 (in 4 nicht
gezeigt)) wiedererlangt werden. Als ein anderes Beispiel können protokollierte
Hardwareverwendungsinformationen, die zu einem gegebenen Computersystem (z.
B. dem Computersystem 100 von 1) gespeichert
sind, durch das System 400 durch ein kommunikatives Koppeln
des Systems 400 (zumindest temporär) mit einem derartigen gegebenen
Computersystem über ein
Netzwerk 412 wiedererlangt werden.
-
Der
I/O-Adapter 405 verbindet vorzugsweise eine Speicherungsvorrichtung
(Speicherungsvorrichtungen) 406, wie beispielsweise eines
oder mehrere von einem Festplattenlaufwerk, einem CD-Laufwerk (CD
= compact disc), einem Diskettenlaufwerk, einem Bandlaufwerk etc.
mit dem Computersystem 400. Die Speicherungsvorrichtungen
können
verwendet werden, wenn der RAM 403 für die Speichererfordernisse
unzureichend ist, die einem Speichern von Daten für Anwendungsprogramme
zugeordnet sind. Der RAM 403, der ROM 404 und/oder
andere Speicherungsvorrichtungen 406 können zum Speichern eines computerausführbaren
Codes zum Empfangen von Hardwareverwendungsinformationen von einem
Computersystem (von Computersystemen) und Erzeugen von Verendungsprofilen
für ein
derartiges Computersystem (derartige Computersysteme) gemäß den hierin
beschriebenen Ausführungsbeispielen
verwendet werden. Der Kommunikationsadapter 411 ist vorzugsweise
angepasst, um das Computersystem 400 mit dem Netzwerk 412 zu
koppeln, wie beispielsweise dem Internet, einem Intranet, dem World
Wide Web (dem „Web"), anderen weiten
und/oder lokalen Netzen (WANs und LANs; WAN = Wide Area Network;
LAN = Local Area Network), einem drahtlosen Netzwerk und Kombinationen
derselben.
-
Der
Benutzerschnittstellenadapter 408 koppelt Benutzereingabegeräte, wie
beispielsweise eine Tastatur 413, eine Zeigevorrichtung 407 und
ein Mikrophon 414 und/oder Ausgabevorrichtungen, wie beispielsweise
(einen) Lautsprecher 415 mit dem Computersystem 400.
Der Anzeigeadapter 409 ist durch die CPU 401 getrieben,
um die Anzeige an einer Anzeigevorrichtung 410 zu steuern.
-
Das
System 400 umfasst einen Verwendungsprofilgenerator 416,
der ein Softwareanwendungsprogramm ist, das durch die CPU 401 ausführbar ist
und betreibbar ist, um protokollierte Hardwareverwendungsdaten 417 von
einem oder mehreren „überwachten" Computersystemen
(z. B. die Hardwareverwendungsdaten, die durch das System 100 von 1 protokolliert
werden) zu empfangen und ein Verwendungsprofil 418 für ein derartiges überwachtes
Computersystem (derartige überwachte
Computersysteme) zu erzeugen. Wie es oben beschrieben ist, kann
oder können
das eine oder die mehreren Computersysteme (wie beispielsweise das
Computersystem 100) selbstüberwacht sein dahingehend,
dass dieselben einen Hardwareverwendungsprotokolliermechanismus
zum Protokollieren der eigenen Hardwareverwendung derselben umfassen.
Wie es ebenfalls oben beschrieben ist, können die protokollierten Hardwareverwendungsdaten 417 über ein
Netzwerk 412 empfangen werden oder anderweitig zu dem Computersystem 400 eingegeben
werden. Ferner kann das erzeugte Verwendungsprofil 418 zu
dem RAM 403, dem ROM 404, der Speicherungsvorrichtung
(Speicherungsvorrichtungen) 406 und/oder einem anderen
Computersystem gespeichert werden, mit dem das System 400 (zumindest
temporär)
kommunikativ über
das Netzwerk 412 gekoppelt ist.
-
5 zeigt
einen Betriebsfluss gemäß einem
Ausführungsbeispiel
zum Empfangen protokollierter Hardwareverwendungsdaten für überwachte
Computersysteme und Erzeugen eines Verwendungsprofils für diese
Computersysteme, wie beispielsweise durch den Verwendungsprofilgenerator 416 des
Systems 400 von 4. Bei einem Betriebsblock 401 emp fängt der
Verwendungsprofilgenerator 416 protokollierte Daten hinsichtlich
einer Verwendung von Hardwarekomponenten einer Mehrzahl von Computersystemen
(z. B. einer Mehrzahl von Laptop-Computersystemen 100 einer
gegebenen Geschäftsorganisation).
Der Verwendungsprofilgenerator 416 kann beispielsweise
protokollierte Daten hinsichtlich einer Verwendung von Hardwarekomponenten
für jedes
einer Mehrzahl unterschiedlicher Computersysteme eines gegebenen
Kunden (z. B. einer gegebenen Firma, einer gegebenen Abteilung einer
gegebenen Firma oder einer anderen interessierenden Geschäftsorganisation)
empfangen. Bei einem Betriebsblock 402 erzeugt der Verwendungsprofilgenerator 416 ein
Verwendungsprofil für
die Mehrzahl von Computersystemen zumindest teilweise basierend
auf den empfangenen protokollierten Daten. Somit legt ein derartiges
Verwendungsprofil für
die Mehrzahl von Computersystemen die Hardwareverwendung des Kunden
detailliert dar, die durch den Hersteller bei einem Entwerfen eines
optimalen Computersystems für
den Kunden, einer Fehlersuche von Problemen, die durch die Computersysteme
des Kunden angetroffen werden, Empfehlen eines geeigneten Computersystems
für den
Kunden etc. vorteilhaft verwendet werden kann.
-
6 zeigt
ein detaillierteres Betriebsflussdiagramm für ein beispielhaftes Ausführungsbeispiel
zum Empfangen protokollierter Hardwareverwendungsdaten und Erzeugen
eines Verwendungsprofils. Bei einem Betriebsblock 601 werden
eingesammelte Daten aus dem Flash-ROM (z. B. dem Flash-ROM 123 des
Systems 100) eines überwachten
Computersystems durch den Verwendungsprofilgenerator 416 wiedererlangt
(der beispielsweise ein WINDOWS® Anwendungsprogramm
sein kann). Dabei liest der Verwendungsprofilgenerator 416 DMI/SMBIOS-OEM-Aufzeichnungen
(Datentyp 90H), was ein Datenfeld in der DMI-Software-Spezifikation ist.
Bei einem Betriebsblock 602 werden die eingesammelten Daten
zu einer Datei geschrieben. Bei einem Betriebsblock 603 wird
die eingesammelte Datendatei zu einer Datenbank (z. B. über das
Netzwerk 412, wie beispielsweise das Internet) für eine statistische
Analyse heruntergeladen. Bei einem Betriebsblock 604 können die
eingesammelten Daten für
eine Verwendung bei derartigen Aufgaben analysiert werden wie: 1)
einer Fehlerratenreduzierung, 2) einer Garantiekostenreduzierung,
3) einer Rückkopplung
zu Entwicklungsteams hinsichtlich einer Zuverlässigkeit und zukünftigen
Entwürfen
und/oder 4) Fehlerbeseitigungsbemühungen.
-
7 zeigt
ein beispielhaftes Betriebsflussdiagramm zum Protokollieren einer
Hardwareverwendung und Erzeugen eines Verwendungsprofils gemäß einem
Ausführungsbeispiel.
Bei einem Betriebsblock 701 werden Daten hinsichtlich einer
Verwendung zumindest einer Hardwarekomponente zumindest eines überwachten
Computersystems (z. B. Computersystem 100 von 1) über ein
BIOS des zumindest einen überwachten
Computersystems gesammelt. Bei einem Betriebsblock 702 werden
die gesammelten Daten zu einer nichtflüchtigen Datenspeicherung des
zumindest einen überwachten
Computersystems protokolliert. Bei einem Betriebsblock 703 werden
die protokollierten Daten von der nichtflüchtigen Speicherung zu einem
zweiten Computersystem (z. B. dem Computersystem 400 von 4)
empfangen und bei einem Betriebsblock 704 erzeugt das zweite
Computersystem ein Verwendungsprofil für das zumindest eine überwachte
Computersystem zumindest teilweise basierend auf den empfangenen
protokollierten Daten.
