DE19950249C1 - Elektronisches Gerät mit Softwareschutz - Google Patents

Abstract

Die Erfindung betrifft ein elektronisches Gerät mit Softwareschutz für Runtime-Software. Zumindest ein Funktionsbaustein (4...11) der Runtime-Software wird mit einer Wertigkeit versehen. In einer Einrichtung (12) ist eine maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt. Durch eine Recheneinheit (1) wird die Summenwertigkeit der Funktionsbausteine der Runtime-Software bestimmt und ein Anzeigesignal (14) ausgegeben, wenn die Summenwertigkeit die maximal zulässige Wertigkeit übersteigt. Funktionsbausteine und Wertigkeitsbausteine können mit einer OEM-Kennung versehen werden, so daß Systemhersteller und OEM unabhängig voneinander einen Softwareschutz gestalten können.

Description

Die Erfindung betrifft ein elektronisches Gerät mit Soft­ wareschutz. Das elektronische Gerät weist eine Recheneinheit zur Abarbeitung eines Progranms und einen Speicher auf, in dem eine Betriebssystem-Software und Runtime-Software für die Recheneinheit geladen ist.

Voraussetzung für eine gewinnbringende Vermarktung von Soft­ ware ist ein entsprechender Schutz, der verhindert, daß die Software von Anwendern mehrfach eingesetzt wird, obwohl kein entsprechendes Nutzungsrecht erworben wurde. Deshalb ist ein technisches Mittel zum Schutz der Software vor unerlaubter Nutzung erforderlich. Insbesondere bei Automatisierungs­ geräten, bei denen durch Zusammenschalten verschiedener Funk­ tionsbausteine ein Steuerungsprogramm gebildet wird, ist ein Schutz notwendig, der eine unerlaubte Mehrfachverwendung der Funktionsbausteine verhindert. Dabei soll es sich nicht um einen Kopierschutz handeln, wie er bei vielen Software­ produkten für Personal Computer üblich ist. Schutz vor un­ erlaubter Mehrfachverwendung bedeutet, daß eine Software auf einem Automatisierungsgerät nur dann abläuft, wenn der An­ wende das Recht dazu erworben hat, d. h., wenn vom Her­ steller eine Lizenz erteilt wurde.

Ein Schutz vor einer unerlaubten Mehrfachverwendung von Software könnte an eine eindeutige Kennung des elektronischen Geräts, beispielsweise eine Seriennummer, gekoppelt werden. Die Software könnte so ausgeführt werden, daß sie nur auf dem Zielsystem ablauffähig wäre, für das sie freigegeben wurde. Das hätte jedoch den Nachteil, daß der Schutz nicht überall anwendbar wäre, da derzeit nicht in allen Zielsystemen Seriennummern vorhanden sind, und daß wegen der Kopplung an ein einzelnes Zielsystem ein Wechsel auf ein anderes, bau­ gleiches Zielsystem bei Ausfall des ursprünglichen Ziel­ systems schwer möglich wäre.

Eine weitere Möglichkeit zum Schutz vor unerlaubter Mehrfach­ verwendung wäre es, im Engineering-System das Laden von ge­ schützter Software auf ein Zielsystem anhand einer eindeuti­ gen Kennung des Zielsystems, z. B. einer Seriennummer, zu überwachen. Auch diese Möglichkeit wird verworfen, da Ziel­ systeme meist nicht über eine Seriennummer verfügen und ein Wechsel auf ein anderes, baugleiches Zielsystem bei Ausfall eines Zielsystems nur schwer möglich wäre. Die Wirksamkeit des Schutzmechanismus wäre in diesem Fall nur auf ein Engi­ neering-System beschränkt. Deshalb wären beim Engineering- System zusätzliche Maßnahmen für einen Softwarekopierschutz erforderlich.

Alternativ könnte die geschützte Software mit Namensdekla­ rationen, z. B. einem Projektnamen, verknüpft werden. Das Engineering-System müßte dann überprüfen, ob die geschützte Software bei unterschiedlichen Projekten eingesetzt werden soll, und dies gegebenenfalls unterbinden. Diese Maßnahme wäre ohne weitere Ergänzungen allerdings nicht ausreichend, da Software prinzipiell auch außerhalb des Engineering- Systems dupliziert werden kann. Eine sichere Schutzfunktion würde damit nicht erfüllt.

Eine weitere Möglichkeit könnte darin gesehen werden, die Vervielfältigung von geschützter Runtime-Software durch ein Kopierschutzprogramm ähnlich dem Programm "StopCopy" zu unterbinden. Dieser Kopierschutz müßte sowohl im Bereich der Engineering-Systeme als auch der Zielsysteme wirken. Hin­ sichtlich eines solchen Kopierschutzes bestehen jedoch Ak­ zeptanzprobleme beim Systemhersteller und beim Anwender wegen des schwierigen Handlings, insbesondere bei verlorenen Nut­ zungsrechten. Zudem müßte der Schutzmechanismus in der Soft­ ware des Engineering-Systems und auf allen Komponenten des Zielsystems implementiert werden.

Aus der US-PS 5 870 726 ist ein elektronisches Gerät mit einer Recheneinheit bekannt, bei welchem eine Chipkarte zum Schutz der Software verwendet wird. Die Software kann aus mehreren Teilen bestehen, in denen jeweils ein Betriebssys­ temaufruf zum Zugriff auf die Chipkarte enthalten ist. Bei diesem Zugriff wird geprüft, ob ein ausreichendes Guthaben für die Benutzung der Software vorhanden ist.

Aus der US-PS 5 671 412 ist ein Verfahren zur Verwaltung von Software-Lizenzen bekannt. Dabei wird ein Softwarepaket mit verschiedenen, genau aufgelisteten Einzelkomponenten betrach­ tet und sichergestellt, dass nur diejenigen Einzelkomponenten benutzt werden, auf die sich die Paketlizenz eines Benutzers erstreckt.

Der Erfindung liegt die Aufgabe zugrunde, ein elektronisches Gerät zu schaffen, das mit einem wirkungsvollen Schutz gegen unerlaubte Mehrfachverwendung von Software ausgestattet ist und sich durch eine gute Handhabbarkeit der Software bei Her­ steller und Anwender auszeichnet.

Zur Lösung dieser Aufgabe weist das neue elektronische Gerät der eingangs genannten Art die in Anspruch 1 angegebenen Merkmale auf. In den Ansprüchen 6 und 7 sind eine Einrichtung bzw. ein Funktionsbaustein beschrieben, die zur Verwendung in dem neuen elektronischen Gerät geeignet sind. Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.

In vorteilhafter Weise wird durch die Erfindung ein Schutz von Runtime-Software ermöglicht, die auf ein Zielsystem ge­ laden wird und auf dem Zielsystem abläuft. Unter dem Begriff "Funktionsbausteine der Runtime-Software" werden System­ funktionsbausteine, Standardfunktionsbausteine, Anwender­ funktionsbausteine, mit Hilfe eines grafischen Projektie­ rungswerkzeugs, das auch als Continuous-Function-Chart be­ zeichnet wird, erzeugte Funktionsbausteine, ladbare Treiber, Betriebssystem-Add-Ons oder andere, auf eine Recheneinheit ladbare, optionale Softwaremodule verstanden.

Generell können beim Softwareschutz zwei Ausprägungen unter­ schieden werden. Das ist zum einen der technologische Schutz und zum anderen der Schutz vor einer unerlaubten Mehrfach­ verwendung. Durch den technologischen Schutz wird verhindert, daß Anwender den Source-Code der Software lesen oder auf ihn zugreifen können. Durch diese Maßnahme wird das technologi­ sche oder softwaretechnische Know-how des Herstellers ge­ schützt. Der technologische Schutz ist beispielsweise bei SIMATIC S7-Automatisierungssystemen der Siemens AG durch das Attribut KNOWHOW-Protect gewährleistet. Die durch Software- Funktionsbausteine realisierten technologischen Funktionen sind damit für den Anwender nicht zugänglich. Mit dem Begriff "Runtime-Software" wird in diesem Zusammenhang jegliche Art von ladbaren und auf einem Zielsystem ablauffähigen Program­ men bezeichnet. Dies können beispielsweise Systemfunktions­ bausteine, Funktionsbausteine für technologische Funktionen und Betriebssystemfunktionsbausteine sein.

Ein Nutzungsrecht erlaubt dem Anwender die Nutzung der Soft­ ware auf einem Zielsystem, beispielsweise einem Automatisie­ rungsgerät. Innerhalb des Zielsystems kann die Software be­ liebig oft verwendet werden. Das Nutzungsrecht bezieht sich somit auf die Verwendung des Bausteintyps und nicht auf die mit diesem Baustein jeweils realisierte Bausteininstanz innerhalb der Runtime-Software. Die Software wird entspre­ chend der für sie festgelegten Wertigkeit geschützt. Es wird überprüft, ob die auf einem Zielsystem verwendete geschützte Software in Summe durch die in einer Einrichtung hinterlegte maximale Wertigkeit gedeckt ist. Die Runtime-Software kann nur im Rahmen der erlaubten Nutzungsrechte auf dem Zielsystem verwendet werden. Eine Nutzung ist nur möglich, wenn für ge­ schützte Software ein entsprechender Gegenwert in der Ein­ richtung hinterlegt ist. Der Mehraufwand beim Systemherstel­ ler für das Handling von geschützter Software ist im Ver­ gleich zum Handling von ungeschützter Software in bezug auf Vertrieb und Support minimal. Dabei kann geschützte Software über verschiedene Wege, wie z. B. Diskette, CD, Memory Card oder Internet, vermarktet werden. Für einen Anwender ergeben sich beim Handling von geschützter Software allenfalls ge­ ringfügige Änderungen gegenüber dem Handling ungeschützter Software. Zudem ist ein Handling und gemeinsamer Betrieb von geschützter und nicht geschützter Software möglich. Auf den Aufwand für Support durch den Softwarehersteller wirkt es sich günstig aus, daß im störungsfreien Betrieb keine Inter­ aktionen über eine Hotline zwischen Anwender und Hersteller erforderlich sind. Es müssen z. B. keine Registrierungs- oder Autorisierungsnummern zum Betrieb der Software angefordert werden. Ist die hinterlegte Wertigkeit im elektronischen Gerät zum Betrieb der Runtime-Software nicht ausreichend, so sind eindeutige Hinweise durch das System an den Anwender möglich. Unterschiedliche Versionen des Betriebssystems des elektronischen Geräts, z. B. bei Updates oder Upgrades, be­ einflussen nicht die Verwendung von geschützter Software. Beim Handling neuer Versionen kommen keine neuen Schutz­ mechanismen hinzu.

Der Schutz ist nicht an die einzelne Softwarekomponente, sondern an ihre Wertigkeit gekoppelt. Dadurch ergibt sich eine wesentlich einfachere und flexiblere Handhabung beim Systemhersteller wie beim Anwender. Z. B. ist ein Austausch oder eine Ergänzung von geschützten Softwarekomponenten ohne weiteres möglich, solange der Wert des Nutzungsrechts aus­ reichend ist.

In vorteilhafter Weise erfordert der Softwareschutz keine feste Zuordnung zwischen einer Hardwarekomponente, die häufig als Dongle bezeichnet wird, und einer bestimmten geschützten Software. Dies vereinfacht die Handhabung beim Anwender er­ heblich, da keine unterschiedlichen Dongles für verschiedene Softwarekomponenten verwendet werden müssen und die geschütz­ te Software nicht nur auf einem einzigen Zielsystem ablaufen kann.

Darüber hinaus wirkt der Schutzmechanismus nur zur Laufzeit der geschützten Software. Sie kann daher vor dem Einsatz auf einem Zielsystem wie ungeschützte Software gehandhabt und beispielsweise beliebig oft kopiert werden. Mit Kopierschutz­ programmen verbundene Probleme werden somit vermieden. Der Wertigkeit kann direkt und flexibel ein Preis zugeordnet werden.

Die Einrichtung, in welcher die maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, als ein in das elektronische Gerät einsetzbares oder an das elektroni­ sche Gerät anschließbares Hardwaremodul auszubilden, hat den Vorteil, daß eine leichte Anpaßbarkeit der Wertigkeit bei Softwareänderungen erreicht wird. Zudem ist der Schutz der Software ohne einen aufwendigen Eingriff in die Hardware des elektronischen Geräts realisierbar. Wenn der Anwender ge­ schützte Software einsetzt, benötigt er - abgesehen von dem leicht austauschbaren Hardwaremodul - keine zusätzlichen Komponenten zu den vorhandenen Systemkomponenten. Bezüglich eines Austauschs einzelner Baugruppen des elektronischen Geräts gibt es keinen Unterschied im Verhalten von geschütz­ ter und nicht geschützter Software. Die bisherige Software kann ohne Änderungen bei Austausch einzelner Baugruppen weiterverwendet werden.

Die Verwendung einer Memory Card als Hardwaremodul hat ins­ besondere bei Automatisierungsgeräten den Vorteil, daß keine zusätzliche Hardwarekomponente erforderlich ist, da eine Memory Card ohnehin meist eingesetzt wird. Ein komplizierter Hardwareeingriff ist überflüssig, da die Memory Card in ein­ facher Weise in den dafür vorgesehenen Schacht eingeschoben werden kann. Die Sicherheit einer Memory Card ist für die Schutzfunktion ausreichend. Ein Erstellen einer Kopie mit ebenfalls gültiger Wertigkeit ist nicht ohne weiteres mög­ lich.

Vorteilhaft kann die Einrichtung, in welcher die maximal zu­ lässige Wertigkeit für die Runtime-Software auslesbar hinter­ legt ist, eine eindeutige Identifikation, insbesondere eine Seriennummer, aufweisen und die hinterlegte Wertigkeit als ladbarer Wertigkeitsbaustein ausgebildet werden, der nur für die Einrichtung mit der jeweiligen Identifikation Gültigkeit besitzt. Dadurch ist der Wert von Nutzungsrechten leicht zu erhöhen, indem ein anderer Wertigkeitsbaustein mit dem be­ nötigten Wert in die Einrichtung geladen wird. Die Vermark­ tung von Wertigkeitsbausteinen ist beispielsweise über Inter­ net automatisierbar. Ein Handling von Hardwarekomponenten ist dazu nicht erforderlich. Damit werden sogenannte Wertigkeits­ leichen vermieden. Mit dem Begriff "Wertigkeitsleiche" wird eine Einrichtung bezeichnet, in der eine maximal zulässige Wertigkeit fest hinterlegt ist, die für den konkreten An­ wendungsfall nicht mehr ausreichend ist, z. B. weil die Anwendung zwischenzeitlich um weitere geschützte Software­ komponenten ergänzt wurde. Da eine Erhöhung der Wertigkeit ohne nachladbare Wertigkeitsbausteine entweder gänzlich un­ möglich wäre oder nur vom Hersteller der Einrichtung vor­ genommen werden könnte, wäre eine derartige Einrichtung für den Anwender wertlos geworden. Wertigkeitsbausteine integrie­ ren sich nahtlos in die bestehende Softwarelandschaft von Automatisierungsgeräten, da es sich prinzipiell um Funktions­ bausteine handelt.

Wenn die Funktionsbausteine in Gruppen, insbesondere nach Herstellern, mit jeweils zugeordneten Wertigkeitsbausteinen untergliedert werden, hat dies den Vorteil, daß Funktions­ bausteine verschiedener Hersteller über eine einzige Ein­ richtung, auf welcher jeweils die maximal zulässigen Wertig­ keiten hinterlegt sind, geschützt werden können. Bei nach­ ladbaren Wertigkeitsbausteinen können sogenannte Original Equipment Manufacturer (OEM), d. h. Anwender, die selbst Software erstellen und vermarkten, ihre Software eigenständig und ohne direkte Unterstützung durch den Hersteller des elek­ tronischen Geräts schützen. Eine Wertigkeitsvergabe oder Er­ höhung beim Anwender ist unmittelbar, lokal und hardware­ unabhängig vom Systemhersteller oder OEM möglich. Ein Ver­ senden beispielsweise einer neuen Memory Card, auf welcher die neue, maximal zulässige Wertigkeit hinterlegt ist, ist nicht erforderlich, da eine datentechnische Kopplung zur Hinterlegung einer neuen Wertigkeit ausreicht.

Anhand der Zeichnungen, in denen ein Ausführungsbeispiel der Erfindung dargestellt ist, werden im folgenden die Erfindung sowie Ausgestaltungen und Vorteile näher erläutert.

Es zeigen:

Fig. 1 ein Blockschaltbild eines elektronischen Geräts mit Softwareschutz,

Fig. 2 ein Blockschaltbild einer Einrichtung, in welcher Wertigkeiten hinterlegt sind,

Fig. 3 eine Einrichtung zur Hinterlegung von Wertigkeiten und Funktionsbausteinen zur Verdeutlichung des Wirkungsprinzips,

Fig. 4 eine Eingabemaske zur Erstellung von Wertigkeits­ bausteinen,

Fig. 5 und Fig. 6 jeweils ein Ablaufschema zur Überprüfung ausreichender Nutzungsrechte.

Gemäß Fig. 1 ist ein elektronisches Gerät mit einer Rechen­ einheit 1 ausgestattet, die mit Hilfe einer Betriebssystem- Software in einem Speicher 2 eine Runtime-Software in einem Speicher 3 abarbeitet, die applikationsspezifisch ausgeführt und beispielsweise bei Automatisierungsgeräten an die je­ weilige Steuerungsaufgabe angepaßt ist. In dem gezeigten Aus­ führungsbeispiel enthält die Runtime-Software insgesamt acht Funktionsbausteine 4. . . 11. Die Funktionsbausteine 4, 5 und 6 sind ungeschützt und weisen daher keine Wertigkeit auf. Da­ gegen sind die Funktionsbausteine 7. . . 11 jeweils mit einer Wertigkeit versehen, die prinzipiell den Wert des Nutzungs­ rechts darstellt. Jedem geschützten Funktionsbaustein ist somit eine Wertigkeit zugeordnet. Ein Anwender, der die ge­ schützten Funktionsbausteine einsetzen möchte, erwirbt ein Nutzungsrecht mit einem bestimmten Wert. Dieses Nutzungsrecht wird durch eine maximal zulässige Wertigkeit für die Runtime- Software wiedergegeben, die in einer Einrichtung 12 auslesbar hinterlegt ist. Der Anwender kann geschützte Software ein­ setzen, solange die Summenwertigkeit der geschützten Software durch den Wert des Nutzungsrechts gedeckt ist. Die maximal zulässige Wertigkeit ist gemeinsam mit der Runtime-Software auf einer Memory Card 13 abgespeichert. Alternativ zum dar­ gestellten Ausführungsbeispiel kann auch der Speicher für die Betriebssystem-Software auf demselben Speichermedium angeord­ net werden. Die Recheneinheit 1 überprüft anhand der Be­ triebssystem-Software im Speicher 2, ob die Summenwertigkeit aller geschützten Funktionsbausteine, d. h. der Funktions­ bausteine 7. . . 11, die in der Einrichtung 12 hinterlegte, maximal zulässige Wertigkeit überschreitet. Ist dies der Fall, so liegt eine Schutzverletzung vor und es wird ein Anzeigesignal 14 ausgegeben, das eine vorbestimmte Reaktion zur Folge haben kann.

Fig. 2 zeigt eine Memory Card 13 zur Realisierung der Ein­ richtung 12 mit nachladbaren Wertigkeitsbausteinen. In einem Kennbitspeicher 20 der Memory Card 13 ist eine Seriennummer 21 in einer Speicherzelle hinterlegt, die nur durch den Her­ steller der Memory Card 13 und nicht durch den Anwender be­ schrieben werden kann. Diese Seriennummer 21 ermöglicht eine eindeutige Identifizierung der Memory Card 13. Wertigkeits­ bausteine 22, 23 und 24 sind herstellerspezifisch und in einem freien Speicherbereich 25 der Memory Card 13 hinter­ legt. Der Wertigkeitsbaustein 22 ist für den Hersteller des elektronischen Geräts, die Wertigkeitsbausteine 23 und 24 sind für einen ersten OEM bzw. einen zweiten OEM vorgesehen. Der Hersteller und die OEM können somit ihre eigenen Wertig­ keitsbausteine herstellen und eigene Nutzungsrechte an den Anwender vergeben. Im freien Bereich 25 der Memory Card 13 ist weiterhin die Runtime-Software abgelegt, die in Fig. 2 der Übersichtlichkeit wegen nicht dargestellt ist. Wertig­ keitsbausteine sind hinsichtlich der Softwarestruktur mit Funktionsbausteinen identisch und somit wie Funktionsbau­ steine handhabbar. Sie haben allerdings keinen ablauffähigen Programmcode. Gültigkeit besitzen die Wertigkeitsbausteine 22, 23 und 24 nur in Verbindung mit einer bestimmten Serien­ nummer 21.

Die Abhängigkeiten zwischen Seriennummer, Wertigkeitsbaustein und geschütztem Funktionsbaustein sind in Fig. 3 darge­ stellt. Beispielsweise enthält ein geschützter Funktionsbau­ stein 30 eine Herstellerkennung 31, die aus einem lesbaren Herstellernamen und einem dem Anwender versteckten Password besteht. Dieselbe Herstellerkennung muß auch als Hersteller­ kennung 38 in einem Wertigkeitsbaustein 32 vorhanden sein, damit dieser eindeutig dem Hersteller des Funktionsbausteins 30 zugeordnet werden kann. Für den Anwender wiederum un­ zugänglich sind im Wertigkeitsbaustein 32 eine Seriennummer 33 und eine maximal zulässige Wertigkeit 34 abgelegt. Über die Seriennummer 33 wird die Einmaligkeit des Wertigkeits­ bausteins 32 sichergestellt und gewährleistet, daß er nur für die Einrichtung Gültigkeit besitzt, deren in einem Kennbit­ speicher 35 abgelegte Seriennummer 37 mit der Seriennummer 33 des Wertigkeitsbausteins 32 übereinstimmt. Durch die Über­ prüfung der Seriennummern 33 und 37 auf Übereinstimmung wird eine mehrfache Verwendung von Wertigkeitsbausteinen ver­ hindert. Weiterhin ist im Funktionsbaustein 30 eine Wertig­ keit 36, d. h. ein Wert des Funktionsbausteins 30, für den Anwender nicht beschreibbar abgelegt. Die Summenwertigkeit aller geschützten Funktionsbausteine eines Herstellers muß durch die Wertigkeit 34 auf dem Wertigkeitsbaustein 32 des entsprechenden Herstellers gedeckt werden, damit ausreichende Nutzungsrechte vorliegen.

Eine Verschlüsselung der Daten ist nicht notwendig, wenn der Inhalt von Wertigkeitsbausteinen und geschützten Funktions­ bausteinen nicht vom Anwender ausgelesen werden kann. Bei SIMATIC S7 wird dies durch ein Setzen des Attributs KNOWHOW- Protect mit ausreichender Sicherheit gewährleistet. Sollte der Schutz vor unerlaubten Zugriffen nicht ausreichen, müssen die Daten verschlüsselt werden.

Fig. 4 zeigt die Bedienoberfläche eines Tools zur Erstellung von Wertigkeitsbausteinen. Die Herstellerkennung, die in Fig. 4 als OEM-Kennung bezeichnet wird, kann der OEM frei wählen. Sie besteht aus zwei Teilen. Der sichtbare Teil ist der OEM-Name, hier Fa. Softy, der für Anwender jederzeit les­ bar ist, um zu identifizieren, von welchem Hersteller ein Wertigkeitsbaustein oder eine geschützte Software stammt. Der zweite Teil ist ein OEM-Password, das nur dem jeweiligen OEM bekannt ist und Anwendern verborgen bleibt. Damit wird ein Mißbrauch verhindert, weil nur der OEM, der das Password kennt, in der Lage ist, Wertigkeitsbausteine zu erzeugen. Weiterhin kann in der in Fig. 4 dargestellten Eingabemaske eine Seriennummer der Memory Card, hier als MC-Seriennummer bezeichnet, und eine Wertigkeit des Wertigkeitsbausteins ein­ getragen werden.

Entsprechend Fig. 5 kann immer im Anlauf eines elektroni­ schen Geräts, beim Nachladen von Software oder in geeigneten Abständen während des Betriebs das ausreichende Vorhandensein von Nutzungsrechten überprüft werden. Auf einer Memory Card 50 sind Funktionsbausteine FB und eine Wertigkeit 51 hinter­ legt. Zur Überprüfung der Nutzungsrechte werden durch die Recheneinheit mit Hilfe einer geeigneten Betriebssystem-Soft­ ware in einem Schritt 52 das Steuerprogramm nach Funktions­ bausteinen FB durchsucht, die Einzelwertigkeiten ausgelesen und die Summenwertigkeit berechnet. In einem Schritt 53 wird die maximal zulässige Wertigkeit 51 für die Runtime-Software ausgelesen. Danach findet ein Vergleich 54 zwischen der im Schritt 52 ermittelten Summenwertigkeit und der maximal zu­ lässigen Wertigkeit 51 statt. Übersteigt die Summenwertigkeit die maximal zulässige Wertigkeit 51, wird in einem Schritt 55 ein Anzeigesignal ausgegeben und es erfolgen eventuell wei­ tere Fehlerreaktionen. Andernfalls wird in einem Schritt 56 in den normalen Betrieb übergegangen. Dabei können alle ge­ schützten Funktionsbausteine, die sich auf der Memory Card 50 befinden, erfaßt werden. Die Prüfung erfolgt dann unabhängig davon, ob eine Instanz eines Funktionsbausteintyps in einen Ablaufzyklus eingebaut ist oder nicht. Die jeweilige Ver­ schaltung der Funktionsbausteine ist in Fig. 5 durch einen Programmblock 57 dargestellt. Die beschriebene Überprüfung wird für jeden Hersteller gesondert durchgeführt.

Im folgenden wird eine alternative Möglichkeit zur Über­ prüfung der Wertigkeiten beschrieben, deren Ablauf in Fig. 6 dargestellt ist. Die Funktionsbausteine FB schreiben jeweils beim ersten Aufruf einer durch den Funktionsbaustein reali­ sierten Instanz ihre Wertigkeit und Herstellerkennung in eine Liste des Betriebssystems. Dieser Vorgang entspricht einem Schritt 60 des Ablaufs. Wurde das komplette Applikations­ programm einmal durchlaufen, so kann davon ausgegangen wer­ den, daß in der Liste die Wertigkeiten und Herstellerkennun­ gen aller beteiligten Funktionsbausteine enthalten sind. In einem Schritt 61 wird die Liste ausgewertet, indem die Wertigkeiten zu einer Summenwertigkeit nach den jeweiligen Herstellerkennungen getrennt aufaddiert werden. In einem Schritt 62 werden die Wertigkeiten 63 aus den Wertigkeits­ bausteinen ausgelesen und wiederum in einem Vergleich 64 mit den berechneten Summenwertigkeiten verglichen. Liegen aus­ reichende Nutzungsrechte vor, wird in einen normalen Betrieb 65 übergegangen, falls nicht, wird in einem Schritt 66 ein Anzeigesignal ausgegeben und eine Reaktion eingeleitet. Bei dieser Art der Überprüfung werden nur die Funktionsbausteine FB erfaßt, die entsprechend einer Verschaltung 67 in den Ab­ lauf der Runtime-Software eingebaut sind.

Für die anhand der Fig. 5 und 6 beschriebenen Varianten gilt, daß die Überprüfung vorzugsweise im Anlauf der Rechen­ einheit des elektronischen Geräts durchgeführt werden muß. Bei Recheneinheiten, die ein Entfernen der Einrichtung mit den hinterlegten, maximal zulässigen Wertigkeiten während des laufenden Betriebs ohne Störung zulassen, sollte die Über­ prüfung zusätzlich in angemessenen Zeitabständen erfolgen.

Je nach Anwendung sind verschiedene Reaktionen bei fehlenden Nutzungsrechten möglich. Beispielsweise kann zusätzlich zur Ausgabe eines Anzeigesignals die Recheneinheit mit verminder­ ter Leistungsfähigkeit weiterarbeiten. Eine schwerwiegendere Konsequenz könnte darin bestehen, daß die Recheneinheit bei fehlenden Nutzungsrechten in einen Stoppzustand übergeht und somit das elektronische Gerät nicht funktionsfähig ist.

Um die Handhabung des Softwareschutzes bei Projektierung, Test, Inbetriebsetzung oder Hardwareausfall zu vereinfachen, können dem Anwender des elektronischen Geräts zwei Hilfen angeboten werden. Die eine besteht darin, daß dem Anwender eine allgemein gültige Memory Card zur Verfügung gestellt wird, deren Wertigkeitsbausteine den Wert ~ enthalten. Mit dieser Memory Card sind alle geschützten Bausteine unein­ geschränkt ablauffähig. Die andere Hilfe besteht darin, über Parametrierung an einem Engineering-System die Recheneinheit des elektronischen Geräts in eine Betriebsart "Probebetrieb" zu schalten. In dieser Betriebsart wird keine Überprüfung der Wertigkeit vorgenommen. Wiederum sind alle geschützten Funk­ tionsbausteine uneingeschränkt ablauffähig. Nach einer be­ stimmten Zeit, z. B. nach 200 Stunden, läuft der Probebetrieb ab und die beschriebenen Schutzmechanismen werden wieder wirksam.

Die Vermarktung von Wertigkeitsbausteinen kann beispielsweise über Versand erfolgen. Der Anwender bestellt dazu schriftlich oder telefonisch unter Nennung der Seriennummer der Memory Card einen Wertigkeitsbaustein mit einer bestimmten Wertig­ keit beim Hersteller, dessen Funktionsbausteinbibliothek er verwendet. Der Hersteller kann beispielsweise der Hersteller des elektronischen Geräts oder ein OEM sein. Bei diesem wird der Wertigkeitsbaustein erzeugt, auf Diskette gespielt und an den Besteller gegen Rechnung verschickt.

Eine andere, völlig automatisch abwickelbare Möglichkeit zur Vermarktung bietet das Internet. Der Anwender wählt sich in die Service-Homepage des Herstellers ein und findet dort einen Menüpunkt "Wertigkeitsbausteine bestellen". Hier gibt er seinen Namen, seine E-mail-Adresse, die Seriennummer der Memory Card, die gewünschte Wertigkeit und die bevorzugte Zahlungsart, z. B. Rechnung oder Kreditkarte, ein und schickt die Bestellung ab. Ein Server kann beim Hersteller automa­ tisch anhand dieser Angaben einen Wertigkeitsbaustein er­ stellen und den Baustein per E-mail an den Besteller ab­ schicken.

Alternativ zu dem gezeigten Ausführungsbeispiel kann ein Dongle, der hier als Memory Card ausgebildet ist, als ein Hardwareschlüssel implementiert werden, der im Stecker eines MPI-Verbindungskabels untergebracht oder, wenn keine MPI- Verbindung zum Einsatz kommt, als Blindstecker auf die MPI- Schnittstelle aufgesteckt wird. Diese Realisierungsvariante hat allerdings den Nachteil, daß ein neuer Dongle entwickelt werden müßte, der eine neue, zusätzliche Hardwarekomponente darstellt. Der Dongle müßte zudem an zukünftige Weiter­ entwicklungen der MPI-Schnittstelle angepaßt werden.

Alternativ zu den nachladbaren Wertigkeitsbausteinen kann eine Gesamtwertigkeit im Kennbitspeicher der Memory Card hinterlegt werden, die somit nicht durch Software änderbar ist. Diese Gesamtwertigkeit deckt den Wert sämtlicher ge­ schützter Software von Systemhersteller und von OEM ab. Die Memory Cards werden mit unterschiedlichen Wertigkeiten pro­ duziert und erhalten als jeweils verschiedene Produkte auch unterschiedliche Bestellnummern. D. h., bei n verschiedenen Wertigkeiten müssen n verschiedene Typen von Memory Cards als Produkte gehalten und bevorratet werden. Bei dieser Variante ist keine Unterscheidung zwischen Systemhersteller und OEM möglich, da lediglich eine Gesamtwertigkeit für beide gemein­ sam hinterlegt wird. Da die Wertigkeit nicht nachträglich ge­ ändert werden kann, entstehen die oben beschriebenen "Wertig­ keitsleichen".

Eine weitere Variante entsteht, wenn im Kennbitspeicher der Memory Card feste Summenwertigkeiten jeweils für System­ hersteller und OEM getrennt hinterlegt werden. Somit kann beim Softwareschutz zwischen der Software des System­ herstellers und des OEM unterschieden werden. Die Memory Cards werden mit unterschiedlichen Wertigkeiten produziert, wobei jede Wertigkeitskombination einem eigenständigen Pro­ dukt mit Bestellnummer entspricht. Demgemäß vervielfacht sich die Anzahl der Produkte, die bevorratet werden müssen. Zu­ sätzlich kann die OEM-Kennung den jeweiligen Wertigkeiten zugeordnet werden.

Als weitere Alternative kann eine Memory Card geschaffen wer­ den, deren Kennbitspeicher über einen Bereich verfügt, in welchen Anwenderdaten geschrieben werden können. Dieser Be­ reich sollte allerdings nur zugänglich sein, wenn der zu­ gehörige Programmiermechanismus bekannt ist. Dort werden die Wertigkeit und die OEM-Kennung hinterlegt. Ein OEM benötigt in diesem Fall ein spezielles Programmiertool mit dem Pro­ grammiermechanismus, um auf diesen Bereich des Kennbit­ speichers zugreifen zu können. Dieses Programmiertool kann als Erweiterung eines vom Hersteller der Memory Card zur Verfügung gestellten Engineering-Systems realisiert werden. Bei dieser Variante können OEMs die Wertigkeit und ihre Kennung selbst ändern. Somit müssen weniger Produkte bevor­ ratet werden und der Schutz ist mit einem geringeren Aufwand verbunden.

Abweichend von dem beschriebenen Ausführungsbeispiel können Wertigkeitsbausteine in den Speicher 2 oder 3 des elektroni­ schen Geräts geladen werden, so daß der Speicherbereich der Einrichtung 12, in welchem eine maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, durch einen Teil des Speichers 2 bzw. 3 ersetzt wird. In diesem Fall trägt die Einrichtung 12 eine eindeutige Identifikation, beispielsweise eine Seriennummer, und wird vorzugsweise als austauschbares Hardwaremodul ausgebildet.

Claims (7)

1. Elektronisches Gerät mit Softwareschutz

• - mit einer Recheneinheit (1) zur Abarbeitung eines Pro­ gramms,
• - mit einem Speicher (2), in den eine Betriebssystem- Software für die Recheneinheit (1) geladen ist,
• - mit einem Speicher (3), in den Runtime-Software geladen ist, die zumindest einen Funktionsbaustein (7. . . 11) enthält, der mit einer Wertigkeit versehen ist,
• - mit einer Einrichtung (2, 3, 12), in welcher eine maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist,
• - wobei Mittel vorhanden sind zur Bestimmung der Summen­ wertigkeit der Funktionsbausteine (4. . . 11) der Runtime-Software und zur Ausgabe eines Anzeigesignals (14), wenn die Summenwertigkeit die maximal zulässige Wertigkeit übersteigt.

2. Elektronisches Gerät nach Anspruch 1, dadurch gekenn­ zeichnet,

• - daß die Einrichtung (12), in welcher die maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, als ein in das elektronische Gerät einsetzbares oder an das elektronische Gerät anschließbares Hardwaremodul ausgebildet ist.

3. Elektronisches Gerät nach Anspruch 2, dadurch gekenn­ zeichnet,

• - daß das Hardwaremodul eine Memory Card ist.

4. Elektronisches Gerät nach einem der vorhergehenden An­ sprüche, dadurch gekennzeichnet,

• - daß eine Einrichtung (12) vorgesehen ist, die eine ein­ deutige Identifikation, insbesondere eine Seriennummer (21), aufweist, und
• - daß die hinterlegte Wertigkeit als ladbarer Wertigkeits­ baustein (22, 23, 24) ausgebildet ist, der nur für die Einrichtung (13) mit der jeweiligen Identifikation Gültig­ keit besitzt.

5. Elektronisches Gerät nach Anspruch 4, dadurch gekenn­ zeichnet,

• - daß die Funktionsbausteine in Gruppen, insbesondere nach Herstellern, untergliedert sind,
• - daß jeder Gruppe ein Wertigkeitsbaustein (22, 23, 24) zu­ geordnet ist und
• - daß Mittel vorhanden sind zur Bestimmung der Summen­ wertigkeit der Funktionsbausteine einer Gruppe und zur Ausgabe eines Anzeigesignals, wenn die Summenwertigkeit die maximal zulässige Wertigkeit des jeweiligen Wertig­ keitsbausteins übersteigt.

6. Einrichtung, die als ein in ein elektronisches Gerät nach einem der vorhergehenden Ansprüche einsetzbares oder an das elektronische Gerät anschließbares Hardwaremodul, insbeson­ dere als Memory Card, ausgebildet ist, dadurch gekenn­ zeichnet,

• - daß in der Einrichtung eine maximal zulässige Wertigkeit für eine Runtime-Software und/oder eine eindeutige Identi­ fikation, insbesondere eine Seriennummer, durch das elek­ tronische Gerät auslesbar hinterlegt ist.

7. Funktionsbaustein zur Verwendung in der Runtime-Software eines elektronischen Geräts nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet,

• - daß der Funktionsbaustein mit einer Wertigkeit versehen ist.