AT513861B1 - Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung - Google Patents

Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung Download PDF

Info

Publication number
AT513861B1
AT513861B1 ATA50150/2013A AT501502013A AT513861B1 AT 513861 B1 AT513861 B1 AT 513861B1 AT 501502013 A AT501502013 A AT 501502013A AT 513861 B1 AT513861 B1 AT 513861B1
Authority
AT
Austria
Prior art keywords
fpga
identification information
configuration data
information
hardware
Prior art date
Application number
ATA50150/2013A
Other languages
English (en)
Other versions
AT513861A4 (de
Inventor
Christian Dipl Ing Berger
Karl Ing Divisch
Kurt Dipl Ing Krizek
Daniel Dr Prostrednik
Original Assignee
Siemens Ag Oesterreich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Ag Oesterreich filed Critical Siemens Ag Oesterreich
Priority to ATA50150/2013A priority Critical patent/AT513861B1/de
Application granted granted Critical
Publication of AT513861A4 publication Critical patent/AT513861A4/de
Publication of AT513861B1 publication Critical patent/AT513861B1/de

Links

Landscapes

  • Logic Circuits (AREA)

Abstract

Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung (10), wobei die Logikvorrichtung (10) aufweist:-ein oder mehrere FPGAs (3), die jeweils einer oder mehreren Baugruppen (7) örtlich zugeordnet sind,-eine Programmiereinrichtung (1), welche über eine Datenverbindung (2) mit jedem FPGA (3) verbunden ist, um an diese zum Zwecke der Konfiguration Konfigurations-Daten zu übermitteln, gekennzeichnet durch die Verfahrensschritte:a)die Programmiereinrichtung (1) erstellt Konfigurations-Daten, die bestimmungsgemäß einem FPGA zugeordnet sind und übermittelt diese über die Datenverbindung(2)an einen FPGA, für den diese Konfigurations-Daten bestimmt sind;der die Konfigurations-Daten empfangende FPGA (3) prüft die bestimmungsgemäße Zuordnung und verwendet bei dieser Prüfung eine Hardware-Kennungsinformation (4), die in der ihm zugeordneten Baugruppe (7) bereitgehalten wird.

Description

österreichisches Patentamt AT 513 861 B1 2014-08-15
Beschreibung
VERFAHREN ZUM SCHUTZ GEGEN FEHLPROGRAMMIERUNG EINER FELDPROGRAMMIERBAREN LOGIKVORRICHTUNG
TECHNISCHES GEBIET
[0001] Die vorliegende Erfindung betrifft ein Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung, wobei die Logikvorrichtung mehrere feldprogrammierbare Logikbausteine (FPGAs) aufweist, und wobei mittels einer Programmiereinrichtung, welche über eine Datenverbindung mit jedem Logikbaustein verbunden ist, die einzelnen FPGAs durch Übermittlung von Konfigurations-Daten konfiguriert werden können.
STAND DER TECHNIK
[0002] Eine feldprogrammierbare Logikvorrichtung besteht häufig aus einer Vielzahl von feldprogrammierbaren Logikbausteinen, so genannte Field Programmable Gate Array, kurz FPGA, die jeweils auf örtlich voneinander getrennt angeordneten Baugruppen untergebracht sind. Eine solche Baugruppe beinhaltet meist einen Mikrocomputer. Eine Baugruppe kann beispielsweise Bestandteil eines Gerätes oder ein Gerät selbst sein.
[0003] Zusammen mit Mikroprozessoren lassen sich mit FPGAs logische Grundfunktionen und komplexe Funktionen sowie einfache mathematische Funktionen realisieren. Von Vorteil ist dabei, dass die Funktionsstruktur eines FPGAs auch nach der Herstellung des Bausteins vom Benutzer selbst vorgegeben werden kann. Um eine benutzerabhängige Funktion in einem FPGA-Baustein zu realisieren, muss dieser mit einem speziellen Anwender- beziehungsweise Benutzerprogramm programmiert, genauer gesagt, konfiguriert werden, indem Konfigurations-Daten an diesen Baustein übermittelt werden. Eine solche Konfiguration eines FPGA, bei der die interne Schaltungsstruktur des integrierten Schaltkreises (FPGA) vor dem eigentlichen Betrieb im Feld festgelegt wird, erfolgt üblicherweise mittels einer Programmiereinrichtung. Eine solche Programmiereinrichtung kann beispielsweise ein einzelner Personalcomputer sein. Die Erstellung der Konfigurations-Daten können mittels einer Hardware-Beschreibungssprache, z.B. VHDL oder einem Programm zur Erstellung eines Schaltplans erfolgen. Die auf diese Weise mittels des PC erstellten Konfigurations-Daten werden dann über eine Datenverbindung in den Konfigurations-Datenspeicher des jeweiligen FPGA-Bausteins geladen. Diese Daten können auch in einem Festwertspeicher (PROM oder FLASH- Memory) fix abgelegt sein, und werden dann üblicherweise vom FPGA selbst eingelesen (in diesem Fall spricht man von einem „Master Mode” des FPGAs); alternativ dazu ist es auch möglich, diese Daten direkt über eine Datenverbindung von einem Host in das FPGA einzuspielen (in diesem Fall spricht man von einem „Slave Mode” des FPGAs).
[0004] In einen FPGA-Konfigurations-Daten-Speicher kann auch nach einer bereits erfolgten Konfiguration ein geändertes Benutzerprogramm (repräsentiert durch einen geänderten Datensatz von Konfigurations-Daten) nachgeladen werden. Dadurch ist es dem Anwender möglich, eine in einer feldprogrammierbaren Logikvorrichtung bereits implementierte Funktionsstruktur zu ändern, beziehungsweise zu verbessern, ohne dass die physische Hardware im Anwendungsfeld geändert werden muss.
[0005] Oftmals ist es also so, dass von einer einzigen, örtlich entfernten Programmiereinrichtung mehrere FPGAs konfiguriert werden sollen. Diese FPGAs haben dabei in der Regel unterschiedliche Programminhalte, die an unterschiedlichen Orten in einer Baueinheit zur Anwendung gebracht werden sollen.
[0006] Die Übertragung der Konfigurations-Information an diese FPGAs kann beispielsweise über eine serielle (z.B. RS-232) oder parallele Datenverbindung erfolgen. Dabei ist nicht auszuschließen, dass Konfigurations-Dateien vertauscht werden. Wird ein FPGA mit falschen Daten konfiguriert, verhält sich das System nicht mehr richtig. Es kann dazu kommen, dass ein FPGA- 1 /13 österreichisches Patentamt AT 513 861 B1 2014-08-15
Baustein durch die fehlerhafte Konfiguration beschädigt wird. Bei einem sicherheitskritischen System, bei dem die zugeordnete Funktionalität der einzelnen FPGA-Bausteine vor der Inbetriebnahme nicht verifiziert werden kann, kann es zu schwer wiegenden Sicherheitsproblemen kommen.
[0007] Das Nachladen von FPGAs in sicherheitskritischen Systemen ist bis heute nicht zufrieden stellend gelöst.
[0008] Bislang hat man das Problem der fehlerhaften Konfiguration bei Steuerungssystemen durch eine Codierung des Einbauplatzes zu lösen versucht, indem über einen für die eigentliche Programmierung zuständigen Mikroprozessor diese Kennung abgefragt wird und mit einer Referenzadresse verglichen wird. Die fehlerhafte Konfiguration wird also durch die Software des Mikroprozessors verhindert. Diese Lösung funktioniert aber dann nicht, wenn der zu prüfende FPGA-Baustein für die Herstellung der Kommunikationsfunktion mit dem Mikroprozessor selbst verantwortlich ist, und dieser bei einer Systeminitialisierung nicht feststellen kann, ob das System korrekt konfiguriert und funktionsfähig ist, weil dessen Funktion erst mithilfe der programmierbaren Logik möglich ist.
[0009] Bei sicherheitskritischen Systemen, bei denen der FPGA- Baustein unter anderem für die Kommunikationsfunktion (u.U. incl. Systemadressierung) mit dem Mikroprozessor verantwortlich ist, ist es bislang nicht erlaubt, den FPGA- Baustein nachzuladen, weil eine potenzielle Verwechslungsgefahr besteht.
[0010] Aus der DE 10 2010 016 257 A1 ist ein Verfahren und eine Vorrichtung zum Aktualisieren einer Firmware eines Systems mit wenigstens einem programmierbaren Baustein bekannt. Dabei wird eine Vergleichskennung verwendet, die außerhalb eines FPGA-Bausteins in einem nichtflüchtigen Speicher gespeichert wird.
DARSTELLUNG DER ERFINDUNG
[0011] Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Schutz gegen Fehlprogrammierung, (insbesondere ein Schutz gegen eine fehlerhafte Vertauschung von Konfigurations-Daten) einer feldprogrammierbaren Logikvorrichtung anzugeben, bei dem Schutz gegen Fehlfunktion gegeben ist, und zwar auch dann, wenn ein einem FPGA-Baustein zugeordnetes Mikrocomputer-System nicht funktionsfähig ist.
[0012] Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen des Verfahrens sind in den abhängigen Ansprüchen definiert.
[0013] Gemäß einem Grundgedanken der Erfindung wird auf der elektronischen Baugruppe, auf der der zu schützende FPGA- Baustein angeordnet ist, für jedes FPGA eine durch Hardware vorgegebene Kennungsinformation vorgesehen. Diese externe Hardware-Kennungsinformation verwendet der FPGA-Baustein in Verbindung mit den geladenen Konfigurations-Daten um festzustellen, ob diese auch tatsächlich für ihn vorgesehen sind. Mit anderen Worten, der in das FPGA geladene Code ist in der Lage, eine dort vorhandene Hardware-Kennungsinformation auszuwerten. Durch diese Prüfung wird verhindert, dass ein FPGA-Baustein mit einem bei der Programmierung vertauschen Inhalt im Anwendungsfeld aktiv wird. Die Hardware-Kennungsinformation ist durch Software nicht änderbar und auch von einer Energieversorgung unabhängig. Es ist von Vorteil, dass der Schutz vor Fehlprogrammierung auch dann gegeben ist, wenn ein dem FPGA-Baustein zugeordnetes Mikrocomputer System nicht funktionsfähig ist.
[0014] In einer besonderen Ausführung des Verfahrens, ist vorgesehen, dass bei der Prüfung ein Vergleich zwischen der Hardware-Kennungsinformation und einer Überwachungs-Kennungsinformation, die Bestandteil der Konfigurations-Daten ist, durchgeführt wird. Dadurch eröffnen sich differenzierte Eingriffsmöglichkeiten für den Fall der Nichtübereinstimmung. Wird bei dieser Prüfung eine (abhängig von der vorgesehenen Prüfmethode - vollständige oder teilweise, jedenfalls nach den Prüfkriterien ausreichende) Übereinstimmung dieser beiden Kennungsinformationen festgestellt, so sorgt eine im FPGA- Programm vorgesehene logische 2/13 österreichisches Patentamt AT 513 861 B1 2014-08-15
Funktion dafür, dass die im FPGA-Programm vorhandene Flauptfunktion aktiv zur Anwendung gelangt. Stimmt hingegen die Hardware-Kennungsinformation nicht ausreichend mit der Überwachungs-Kennungsinformation überein, so bewirkt die logische Funktion im FPGA, dass die im FPGA-Programm vorgesehene Hauptfunktion deaktiviert wird. In diesem Fall wird das System in einen sicheren Systemzustand gezwungen.
[0015] Im Ergebnis wird also erreicht, dass im Falle einer Vertauschung der Konfigurationsinformation die Hauptfunktion des falschen Anwenderprogramms im FPGA nie aktiv zur Ausführung kommt. Hervorzuheben ist dabei, dass das erfindungsgemäße Verfahren kein Zutun eines zugeordneten Mikrocomputers erfordert. Mit anderen Worten, die Schutzfunktion für den FPGA-Baustein ist bereits in der Initialisierungsphase eines Systems gegeben, das heißt auch dann, wenn der dem FPGA funktionell zugeordnete Microcontroller sich noch nicht in einem definierten (hochgefahren) Programmzustand befindet. Man könnte auch sagen, der Schutz des FPGA-Bausteins ist bereits bei einem "halbfertigen Systemzustand" vorhanden. Für die Schutzfunktion sind keine weiteren Bauelemente auf der Baugruppe erforderlich. Dadurch ist die Realisierung des Verfahrens mit vergleichsweise geringem Aufwand möglich. Von besonderem Vorteil ist also, dass mit hoher Wahrscheinlichkeit davon ausgegangen werden kann, dass bei Betrieb der Baugruppe im Feld insgesamt nur das gewünschte Systemverhalten zu Tage tritt. Von besonderem Vorteil ist der FPGA Schutz bei einem sicherheitsrelevanten System. Es ist nunmehr mit vertretbarem Risiko möglich, ein sicherheitsrelevantes System auch im Feld nachzuladen.
[0016] Es kann von besonderem Vorteil sein, wenn bei der Prüfung der Vergleich zwischen der Hardware-Kennungsinformation und der Überwachungs-Kennungsinformation nicht eins zu eins, sondern unscharf, das heißt, mit einer Mehrfach (n zu m-) Zuordnung erfolgt. Es können somit alle logischen Verknüpfungen zwischen allen Aufteilungen der Bits der Hardware-Kennungsinformation und der Überwachungs-Kennungsinformation gebildet und zur Entscheidung herangezogen werden Es kann beispielsweise eine gültige Zuordnung mehrerer Varianten Hardware zu einem bestimmten FPGA-Inhalt geben, oder mehrere Varianten FPGA-Programme zu einer bestimmten Hardware. So ein Verhalten kann man erreichen, indem man die Kennungsinformation in Teilbereiche aufteilt, und jeden Bereich getrennt voneinander vergleicht.
[0017] Beispiel 1: Angenommen es existiert eine 8 Bit Kennungsinformation, dabei haben die ersten 3 Bits die Bedeutung „Baugruppenart" und die weiteren 5 Bits die Bedeutung „Modifikationsstand".
[0018] Es könnte nun folgende Zuordnung geben: [0019] Bedeutung der Bits 0...2: 000 = > Analogausgabebaugruppe 001 => Binärausgabebaugruppe; 010, 011, 100, 101, 110, 111 seien frei, also derzeit noch nicht in Verwendung [0020] Kriterium 1: Es ist nun im FPGA Code in der Vergleichsfunktion z.B. festgelegt, dass diese 3 Bits genau übereinstimmen müssen, damit die Hauptfunktion ausgeführt werden darf.
[0021] Kriterium 2: Es ist weiter im FPGA Code festgelegt, dass die Funktion ausgeführt werden darf, wenn die Kennungsbits 3...7 größer oder gleich der Kennungsinformation der Hardwarekennung seien.
[0022] D.h. Die Funktion wird nur ausgeführt wenn Kriterium 1 UND Kriterium 2 erfüllt sind, also wenn: [0023] Bit(O) der HW-Kennung == Bit(O) des FPGA Vergleichswertes [0024] UND Bit(1) der HW-Kennung == Bit(1) des FPGA Vergleichswertes [0025] UND Bit(2) der HW-Kennung == Bit (2) des FPGA Vergleichswertes [0026] UND (Zahl (bestehend aus HW-Kennungsbits 3...7) ist größer oder gleich Zahl (bestehend aus Bits 3...7 des FPGA Vergleichswertes)).
[0027] In einer anderen Ausführungsform des Verfahrens kann vorgesehen sein, dass ein 3/13 österreichisches Patentamt AT 513 861 B1 2014-08-15
Mehrheitsentscheid getroffen wird. Dies bedeutet, dass es auch ausreicht, wenn von n Kennungsbits nur (n-m) Kennungsbits übereinstimmen müssen, damit die Funktion gewährleistet ist.
[0028] Beispiel 2: Wenn die Regel: Es müssen 4 von 5 Kennungsbits übereinstimmen im FPGA Code implementiert ist, so wäre bei einer FIW-Kennung von 00110 beim Vergleich mit der internen FPGA Kennung 00110 die Funktion genauso gegeben, wie bei einer Kennung 00111 oder 10110, da jeweils auch bei nur 4 übereinstimmenden Bits die Haupt-Funktion ausgeführt werden würde.
[0029] Der Mehrheitsentscheid kann so realisiert werden, indem man also eine Teilinformation der Hardware-Kennungsinformation zum Vergleich mit einer Teilinformation der Überwachungs-Kennungsinformation (Ü1, Ü2..., Ün) heranzieht und der Vergleich immer dann ein gültiges Ergebnis liefert, wenn mindestens eine gewisse Anzahl von gleichen Teilinformationen übereinstimmt. Die Realisierung des Vergleichs muss nicht eine zeitliche Abfolge sein, sondern der Vergleich ist bevorzugt eine Logikfunktion, die parallel abgearbeitet werden kann. Er kann aber auch als sequenzieller Zustandsautomat, als sogenannte „state-machine" realisiert sein.
[0030] Beispiel 3: Mehrfachzuordnung ÜW Kennung HW- Kennung Ergebnis 0 0 wahr 0 1 falsch 0 2 wahr 1 0 wahr 1 1 wahr 1 2 falsch 2 0 falsch 2 1 falsch 2 2 wahr [0031] Tabelle 1 - Beispiel für Mehrfachzuordnung LEGENDE: „wahr” in obiger Wahrheits-Tabelle bedeutet „ENABLE" d.h. Signal 14 („ENABLE” bedeutet, Aktivierungssignal 14 in Figur 2 und Figur 3 ist vorhanden); „falsch” in obiger Wahrheits-Tabelle bedeutet „DISABLE”.
[0032] Aus oben stehender Tabelle 1 ist ersichtlich, dass der Überwachungskennung 0 die HW-Kennung 0 ODER 2 zugeordnet ist, der Überwachungskennung 1 die HW-Kennung 0 ODER 1 und der Überwachungskennung 2 die HW Kennung 2.
[0033] Die Vergleichsfunktion über Wahrheitstabelle kann als „Lookup-Table" oder in Form einer logischen Funktion oder in Form eines sequenziellen Zustandsautomaten realisiert sein.
[0034] Bezüglich der schaltungstechnischen Realisierung kann es besonders vorteilhaft sein, wenn die Hardware-Kennungsinformation in Form von auf der Baugruppe vorgesehenen Hardware-Mechanismen bereitgehalten wird. Geeignete Hardware-Mechanismen sind beispielsweise Schalter, oder Widerstandsbrücken, oder Lötbrücken oder ein fest programmierbarer Speicher, insbesondere ein EEPROM, oder auch andere Möglichkeiten permanenter Informations-Speicherung.
[0035] Innerhalb einer Baugruppe kann eine Hardware-Kennungsinformation auf einfache Weise dadurch bereitgehalten werden, dass diese Information in Form von Schalter-Stellung, in Form einer Widerstandsbrücke oder einer Lötbrücke, oder durch einen fest programmierbaren Speicher, insbesondere ein EEPROM, realisiert ist. 4/13 österreichisches Patentamt AT 513 861 B1 2014-08-15 [0036] Um bei einer fehlerhaften Konfiguration einen Schaden möglichst gering zu halten, kann es angeraten sein, dass im Falle der Nichtübereinstimmung zwischen Hardware- und der Überwachungs-Kennungsinformation alle Ausgänge des FPGAs auf einen passiven Signalzustand gebracht werden.
[0037] Ein passiver Signalzustand wird dabei so vorgegeben, dass die beteiligten Baueinheiten und Schaltkreise nicht zu Schaden kommen. Es kann also sein, dass ein passiver Signalzustand ein logisches "high" oder "low" ist, je nach den Gegebenheiten im Feld.
[0038] Um das Risiko einer Beschädigung möglichst gering zu halten, kann es günstig sein, wenn der passive Signalzustand solange beibehalten wird, bis die Entscheidungs-Logik im FPGA feststellt, dass eine Übereinstimmung (teilweise oder vollständig) der Zuordnung zwischen empfangenen Konfigurations-Daten und zugeordnetem FPGA gegeben ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
[0039] Zur weiteren Erläuterung der Erfindung wird im nachfolgenden Teil der Beschreibung auf die Zeichnungen Bezug genommen, aus denen weitere vorteilhafte Ausgestaltungen, Einzelheiten und Weiterbildungen der Erfindung zu entnehmen sind.
[0040] Es zeigen: [0041] Figur 1 eine schematische Blockdarstellung, welche die für das Verfahren erforderli chen Funktionsbaugruppen zeigt; [0042] Figur 2 ein Blockdiagramm, welches die für das erfindungsgemäße Verfahren nötige
Logik-Struktur darstellt; [0043] Figur 3 ein Flussdiagramm, welches den Ablauf des erfindungsgemäßen Verfahrens veranschaulicht.
AUSFÜHRUNG DER ERFINDUNG
[0044] In der Figur 1 ist eine feldprogrammierbare Logikvorrichtung 10 zu sehen, die aus einer Anordnung von mehreren Baugruppen 7, von denen drei mit dem Bezugszeichen B1, B2 und Bn gekennzeichnet sind, gebildet wird. Jede dieser Baugruppen B1, B2 bis Bn ist über eine Datenverbindung 2 in Form einer Programmierkette mit einer einzelnen Programmiereinrichtung 1 verbunden. Jede dieser Baugruppen 7 beinhaltet einen FPGA Baustein 3.
[0045] Wie eingangs bereits gesagt, ist der Begriff Baugruppe breit zu verstehen und kann beispielsweise ein Gerät, einen elektronischen Einschub in einem Gerät, eine einzelne Platine in einem Einschub oder eine andere örtlich zusammenhängende Gruppe von elektronischen Bauelementen bezeichnen.
[0046] Die Programmiereinrichtung 1 wird im gezeigten Beispiel durch einen einzigen Pro-grammier-Master P1 gebildet, der aus der Ferne die im Anwendungsfeld auf jeder Baugruppe B1, B2 bis Bn befindlichen logischen Bauelemente 3 (FPGAs L1, L2 bis Ln) programmiert beziehungsweise konfiguriert. Bei dieser Programmierung werden die in der Programmiereinrichtung 1 erzeugten Konfigurations-Informationen 8 auf einer Datenverbindung 2, beispielsweise in einem seriellen oder parallelen Übertragungsverfahren, zu den einzelnen FPGAs 3 bzw. deren Konfigurations-Daten-Speicher 9 übermittelt.
[0047] Das Beispiel der Figur 1 zeigt eine einzige Programmiervorrichtung 1. Zur Konfiguration einer Logikvorrichtung 10 können aber auch mehrere Programmiereinrichtungen vorgesehen sein.
[0048] In Figur 1 ist mit dem Bezugszeichen 9 ein Konfigurations- Daten-Speicher eines FPGAs L2 bezeichnet, der Konfigurations-Daten 8 enthält, die über die Datenleitung 2 an ihn übermittelt wurden.
[0049] Auf jeder der Baugruppen B1, B2 bis Bn ist jeweils eine den FPGAs L1, L2 bis Ln zugeordnete Hardware-Kennungsinformation K1, K2 bis Kn permanent vorgesehen. Diese Hard- 5/13 österreichisches Patentamt AT 513 861 B1 2014-08-15 ware-Kennungsinformation ist auf der jeweiligen Baugruppe fix vorgegeben und nicht durch Software änderbar. Sie ist innerhalb einer Baugruppe 3 üblicherweise in der örtlichen Nähe zu einem FPGA angeordnet, kann aber auch örtlich entfernt gespeichert sein. Im vorliegenden Beispiel ist die Hardware-Kennung eine Lötverbindung auf einer gedruckten Schaltung. Sie können aber auch durch eine Widerstandzeile, oder durch einen Festwertspeicher (ROM, EPROM oder EEPROM) oder auch anders realisiert sein. Die Hardware-Kennungsinformation steht an einem Eingangs-Port des zugeordneten FPGAs 3 ständig an (siehe Pfeil 6 in Figur 1). Damit ist sie für diesen FPGA zum Zweck der Prüfung der empfangenen Konfigurations-Daten 8 ständig verfügbar.
[0050] In der Figur 1 ist mit dem Bezugszeichen 5 eine Überwachungs-Kennungsinformation bezeichnet, die Bestandteil der an einen FPGA 3 übermittelten Konfigurations-Daten 8 ist. In Figur 1 ist ein Szenario gezeichnet, bei dem der in der Baugruppe B2 befindliche FPGA L2 mit einem Konfigurations-Programm 8 geladen ist, welches auch die zugehörige Überwachungs-Kennungsinformation 5 (das heißt hier Ü2) beinhaltet. In den anderen beiden FPGAs L1, Ln ist der Konfigurations-Datenspeicher 9 in der Zeichnung strichliert angedeutet.
[0051] Jede FPGA 3 besitzt eine auf dem Substrat des FPGAs implementierte logische Funktion, in Figur 1 f 1, f2 bis fn. Unter dieser logischen Funktion f 1, f2 bis fn ist allgemein eine Bool-sche Funktion zu verstehen, die teilweise durch den in das FPGA geladenen Code und durch die Hardware des FPGAs selbst gebildet ist und dazu eingerichtet ist, das FPGA 3 in einen aktiven oder in einen passiven Zustand zu bringen.
[0052] Diese spezifische Entscheidungs-Logik f1, f2 bis fn ist zudem so ausgebildet, dass sie die zugeordnete Hardware-Kennungsinformation K1, K2 beziehungsweise Kn erfasst (in Figur 1 durch Pfeil 6 angedeutet) und mit der internen (übermittelten) Überwachungs-Kennungsinformation 5 (in Figur 1 auch mit Ü1, Ü2 und Ün bezeichnet) verglichen werden kann. Bei einem falschen, also nicht zusammenpassenden Inhalt (Hardware- und Überwachungs- Information stimmen nicht oder zumindest nicht ausreichend überein, zwingt diese Funktionalität f1, f2 bis fn den jeweiligen FPGA-Baustein (L1, L2 beziehungsweise Ln) in einen unkritischen, das heißt sicheren Systemzustand. Mit einem sicheren Systemzustand ist gemeint, dass durch diese Maßnahme weder direkt noch indirekt Personen- oder Sachschaden entstehen kann. Nur wenn das FPGA bei der Prüfung eine ausreichende Übereinstimmung zwischen der Hardware-Kennungsinformation 5 und der Überwachungs-Information festgestellt wird, kommt die in den FPGA-Speicher 9 geladene Konfigurations-Information 8 vollständig zur Ausführung.
[0053] Die Prüfung auf Übereinstimmung kann auch unscharf erfolgen, z.B. über einen Mehrheitsentscheid oder eine Mehrheitszuordnung. Dies bringt den Vorteil, dass man je nach Grad der Übereinstimmung differenziert eingreifen kann. Dadurch kann man eventuelle Modifikationen eines FPGA-Codes oder der Hardware bei dem Vergleich mitberücksichtigen. Dies ist insbesondere dann von Vorteil, wenn die Konfiguration von der Ferne (zum Beispiel über einen Bus oder über das Internet) erfolgt, da auch selbst bei durch Softwarefehler verursachten Vertauschungen beim Programmieren kein gefährlicher Zustand entstehen kann.
[0054] Voraussetzung für das Funktionieren dieses Verfahrens ist, dass sämtliche, zur Auswahl kommenden Programme, die für das Einlesen der Hardwarekennung und den Vergleich mit der Überwachungskennung nötige Funktionalität beinhalten und dass in der Systemarchitektur von Anfang an dafür gesorgt wurde, dass jedes FPGA die gleichen Eingänge bzw. die gleiche Schnittstelle für das Einlesen der HW-Codierung reserviert hat.
[0055] Ergänzend sei hier angemerkt, dass Fehler, die beim Generieren des Codes des FPGAs entstehen, üblicherweise durch einen systematischen Test erkannt werden, Übertragungsfehler (z.B. durch eine gestörte Datenverbindung entstehende Fehlinformationen) sind normalenweise durch die Checksummenprüfung beim Konfigurieren des FPGAs abgefangen; gegen die bei einer Vertauschung von verschiedenen unterschiedlich konfigurierten FPGA Codes entstehenden Fehlfunktionen besteht - außer bei Anwendung der gegenständlichen Erfindung - keine Sicherheit. 6/13 österreichisches Patentamt AT 513 861 B1 2014-08-15 [0056] Figur 2 zeigt anhand eines Blockdiagramms die Logikstruktur des erfindungsgemäßen Verfahrens. Der in Figur 1 beschriebene Verfahrensablauf lässt sich anhand der Figur 2 so beschreiben: Eine Hardware-Kennungsinformation 4 (K 2), die auf einen Baugruppenträger fix gespeichert und diesem zugeordnet ist, wird von einer logischen Funktion f2 ausgewertet. Dazu wird zunächst ein Block aktiv, der die Hardware-Kennungsinformation 4 einliest. Ein Kennungs-Vergleichs-Funktionsblock zieht zum Vergleich eine Uberwachungs-Kennungsinformation 5 (Ü2) heran. Ist dieser Vergleich positiv, wird von der Vergleichs-Funktionalität ein Aktivierungssignal 14 (in Figur 2 auch mit „ENABLE" bezeichnet) generiert. Diese Aktivierungsinformation 14 wird der zu schützenden Hauptfunktionalität 11 zugeleitet. Nur dann, wenn diese Aktivierungsinformation 14 positiv vorhanden ist, gelangt die Hauptfunktion 11 zur Anwendung, das heißt, vom Funktionsblock 11 werden Eingabedaten 12 empfangen, verarbeitet und Ausgabedaten 13 erzeugt.
[0057] Die Figur 3 veranschaulicht in einem Flussdiagramm den Ablauf des erfindungsgemäßen Verfahrens. Aus einem Reset-Zustand (sicheren Systemzustand) wird in einem Funktions-Block 16 zunächst die Hardware-Kennungsinformation eingelesen. Anschließend daran erfolgt in einem Block 17 der Vergleich von Hardware-Kennungsinformation 4 und Überwachungs-Kennungsinformation Ü2. Wird in einem Vergleicher-Funktionsblock 18 eine vollständige oder zumindest teilweise Übereinstimmung dieser beiden Informationsinhalte erkannt, so wird das Aktivierungssignal 14 erzeugt. Dieses Aktivierungssignal 14 aktiviert die Haupt-Funktionalität 11. Wenn der Vergleich 18 negativ ist, springt der Algorithmus zurück in den sicheren Systemzustand (Reset). Die Funktionen 16, 17 und 18 entsprechen dabei der logischen Funktion f2 in Figur 2 und in Figur 1; f2 stellt also einen Code dar, der teilweise durch den in das FPGA geladene Programm und teilweise durch die Hardware des FPGAs selbst gebildet ist.
[0058] Die Erfindung hat den Vorteil, dass selbst bei hoher Komplexität von digitalen Schaltungen Bauteile im Feld nachgeladen werden können. Auch dann wenn die Programmierung nur über eine Schnittstelle (z.B. eine Datenverbindung zu einem einzelnen PC) erfolgt können verschiedene Hardware-Orte innerhalb eines Gerätes sicher nachgeladen werden.
[0059] Von besonderem Vorteil ist dabei, dass selbst dann, wenn sich ein Mikroprozessorsystem noch nicht in einem funktionierenden Zustand befindet, weil dessen Funktion erst mithilfe der programmierbaren Logik (FPGA) möglich ist, ein Schutz des FPGA-Bausteins bereits gegeben ist.
[0060] Der erfindungsgemäße Schutz kann beispielsweise darin bestehen, dass der integrierte Baustein FPGA ausgangsseitig auf einen definierten Zustand gebracht wird, der je nach Anwendungsfall unterschiedliche Signalpegel kann, je nachdem welcher Aktuator an einem Ausgang angeschlossen ist. Es kann vorteilhaft sein, einen bestimmten Signalzustand solange beizubehalten, bis eine Übereinstimmung der Hardware-Kennungsinformation und der Überwachungs-Kennungsinformation vollständig oder zumindest teilweise gegeben ist.
[0061] Wie bereits oben erwähnt, ist das erfindungsgemäße Verfahren insbesondere bei sicherheitskritischen Systemen mit Vorteil anwendbar. 7/13 österreichisches Patentamt AT 513 861 B1 2014-08-15
ZUSAMMENSTELLUNG DER VERWENDETEN BEZUGSZEICHEN 1. Programmiereinrichtung (PC) oder kommunikationsfähige Speichereinrichtung, in der Programmierdaten für FPGAs abgelegt sind oder Interface zu einer solchen Einrichtung 2. Datenverbindung zur Übermittlung der Konfigurations-Daten 3. FPGA-Baustein 4. Hardware-Kennungsinformation 5. Überwachungs-Kennungsinformation 6. Eingabeports oder Datenverbindung von Hardwarekennung zur Vergleichsfunktion 7. Baugruppe, Baueinheit 8. Konfigurations-Daten 9. Konfigurations-Daten-Speicher des FPGA L2 10. feldprogrammierbare Logikvorrichtung 11. Hauptfunktionalität 12. Eingangsinformation 13. Ausgangsinformation 14. Aktivierungssignal für Hauptfunktion 15. Reset / Sicherer Systemzustand 16. Funktionalität zum Einlesen der Hardware-Kennungsinformation 17. Funktionalität zum Vergleich von Hardware-Kennungsinformation und Überwachungs-Kennungsinformation 18. Abfrage P1 Programmiereinrichtung, Programmier-Master B1, B2, ...,Bn System bestehend aus n Baugruppen L1,L2. ...,Ln FPGA-Bausteine
f1, f2,... ,fn logische Funktionen auf einem FPGA K1, K2,... ,Kn Hardware-Kennungsinformation Ü1, Ü2,..., Ün Überwachungs-Kennungsinformation 8/13

Claims (11)

  1. österreichisches Patentamt AT 513 861 B1 2014-08-15 Patentansprüche 1. Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung (10), wobei die Logikvorrichtung (10) aufweist: - ein oder mehrere FPGAs (3), die jeweils einer oder mehreren Baugruppen (7) örtlich zugeordnet sind, eine Programmiereinrichtung (1) oder eine Speichereinrichtung, in der Programmierdaten abgelegt sind (1), welche über eine Datenverbindung (2) mit jedem FPGA (3) verbunden ist, um an diese zum Zwecke der Konfiguration Konfigurations-Daten (8) zu übermitteln, gekennzeichnet durch die Verfahrensschritte: a) die Programmiereinrichtung (1) erstellt oder beinhaltet zuvor anderswo erstellte Konfigurations-Daten, die bestimmungsgemäß einem FPGA zugeordnet sind und übermittelt diese über die Datenverbindung (2) an das FPGA (3), für den diese Konfigurations-Daten (8) bestimmt sind; b) der die Konfigurations-Daten (8) empfangende FPGA (3) prüft die bestimmungsgemäße Zuordnung und verwendet bei dieser Prüfung eine Hardware-Kennungsinformation (4), die in der ihm zugeordneten Baugruppe (7) bereitgehalten wird.
  2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Prüfung durch einen Vergleich der Hardware-Kennungsinformation (4) und einer Überwachungs-Kennungsinformation (5), die Bestandteil der empfangenen Konfigurations-Daten (8) ist, hergestellt wird.
  3. 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass nach erfolgter Prüfung von diesem prüfenden FPGA (3) entschieden wird, ob er die empfangenen Konfigurations-Daten (8) vollständig oder teilweise zu seiner Konfiguration verwendet.
  4. 4. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass nach erfolgter Prüfung durch die Logikfunktion im FPGA (3) entschieden wird, ob die in den empfangenen Konfigurations-Daten (8) enthaltene Hauptfunktion ausgeführt wird, oder nicht ausgeführt wird.
  5. 5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass bei der Prüfung eine Einfach- oder Mehrfachzuordnung oder ein Mehrheitsentscheid durchgeführt wird.
  6. 6. Verfahren nach Anspruch 5 dadurch gekennzeichnet, dass der Mehrheitsentscheid hergestellt wird, indem man eine Teilinformation der Hardware-Kennungsinformation (4) zum Vergleich mit einer Teilinformation der Überwachungs-Kennungsinformation (Ü1, Ü2..., Ün) heranzieht, und der Vergleich immer dann ein gültiges Ergebnis liefert, wenn mindestens eine gewisse Anzahl von gleichen Teilinformationen übereinstimmt.
  7. 7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Mehrfachzuordnung hergestellt wird, indem man eine vordefinierte Wahrheitstabelle, welche alle möglichen Überwachungs-Kennungsinformationen (Ü1, Ü2,..., Ün) , Hardware-Kennungsinformationen (K1, K2, ...,Kn) und Vergleichsergebnisse enthält, verwendet.
  8. 8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Hardware-Kennungsinformation (4) in Form von auf der Baugruppe (7) vorgesehenen Hardware-Mechanismen bereitgehalten wird.
  9. 9. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass für den Fall, dass das FPGA (3) feststellt, dass die empfangenen Konfigurations-Daten (8) nicht für ihn bestimmt sind, alle seine Ausgänge auf einen passiven Signalzustand bringt.
  10. 10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass der passive Signalzustand solange aufrechterhalten bleibt, solange keine Übereinstimmung zwischen der Hardware-Kennungsinformation (4) und der Überwachungs-Kennungsinformation (5) gegeben ist. 9/13 österreichisches Patentamt AT 513 861 B1 2014-08-15
  11. 11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der passive Signalzustand so vorgegeben wird, dass auf der Baugruppe (7) vorhandene Baukomponenten nicht aktiviert werden. Hierzu 3 Blatt Zeichnungen 10/13
ATA50150/2013A 2013-03-06 2013-03-06 Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung AT513861B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ATA50150/2013A AT513861B1 (de) 2013-03-06 2013-03-06 Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ATA50150/2013A AT513861B1 (de) 2013-03-06 2013-03-06 Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung

Publications (2)

Publication Number Publication Date
AT513861A4 AT513861A4 (de) 2014-08-15
AT513861B1 true AT513861B1 (de) 2014-08-15

Family

ID=51300417

Family Applications (1)

Application Number Title Priority Date Filing Date
ATA50150/2013A AT513861B1 (de) 2013-03-06 2013-03-06 Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung

Country Status (1)

Country Link
AT (1) AT513861B1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050014559A1 (en) * 2003-07-16 2005-01-20 Igt Secured verification of configuration data for field programmable gate array devices
DE102010016257A1 (de) * 2010-03-31 2011-10-06 Softing Ag Generisches Firmware-Fileformat

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050014559A1 (en) * 2003-07-16 2005-01-20 Igt Secured verification of configuration data for field programmable gate array devices
DE102010016257A1 (de) * 2010-03-31 2011-10-06 Softing Ag Generisches Firmware-Fileformat

Also Published As

Publication number Publication date
AT513861A4 (de) 2014-08-15

Similar Documents

Publication Publication Date Title
EP3173884B1 (de) Verfahren zum programmieren einer sicherheitssteuerung
EP4235323A2 (de) Verfahren und vorrichtung zur automatischen validierung von sicherheitsfunktionen an einem modular aufgebauten sicherheitssystem
EP1262856A2 (de) Programmgesteuerte Einheit
DE102010039021B4 (de) Verfahren zur Rekonfiguration von Softwareparametern in einem Mikrocontroller sowie Mikrocontroller und Steuergerät
EP3378006B1 (de) Verfahren zum laden eines sicheren speicherabbilds eines mikrocontrollers und anordnung mit einem mikrocontroller
EP2628706B2 (de) Gewerbliches Fahrzeug, insbesondere Gabelstapler oder Flurförderzeug, mit einem fahrzeugseitig fest angebrachten Datenspeicher in Zuordnung zu einer parametrierbaren elektronischen Steueranordnung
AT513861B1 (de) Verfahren zum Schutz gegen Fehlprogrammierung einer feldprogrammierbaren Logikvorrichtung
DE102004037713A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
EP1359485B1 (de) Steuer- und Überwachungssystem
EP2228723B1 (de) Verfahren zur Fehlerbehandlung eines Rechnersystems
DE102012107717B3 (de) Berührungslos arbeitender Sicherheitsschalter
WO2011035881A1 (de) Verfahren zum bereitstellen von sicherheitsfunktionen
DE102012023182B3 (de) Verfahren zum Betreiben mindestens einer Maschine
EP3459204B1 (de) Verfahren zur realisierung einer diagnosefähigkeit von nicht-automotive-steuergeräten in einem automotive-umfeld
EP1777622A2 (de) Instruktionsspeicherabsicherung durch Control Flow Checking
EP2977894B1 (de) Erstellen eines FPGA-Codes mit automatisch eingefügter Beeinflussungsstruktur
EP1176508B1 (de) Anordnung zur Überwachung des ordnungsgemässen Betriebes von die selben oder einander entsprechende Aktionen ausführenden Komponenten eines elektrischen Systems
EP3523728B1 (de) Befehls- und meldesystem für die automatisierungstechnik
EP4266175B1 (de) Verfahren zum rechnergestützten betreiben einer speichereinheit und ausführen von applikationsprogrammen mit speicherüberprüfung auf speicherfehler
DE102007062915A1 (de) Verfahren zum Betreiben einer speicherprogrammierbaren Steuerung
WO2001031443A2 (de) Integrierter elektronischer baustein mit dublizierter kernlogik und hardware-fehlereinspeisung für prüfzwecke
DE102008004923B4 (de) Verfahren zur Aktualisierung eines Steuerungsablaufes einer Maschinensteuerung sowie Vorrichtung zur Durchführung des Verfahrens
DE102005034572B4 (de) Verfahren zur Fehleranalyse bei der Speicherung von Daten in elektronischen Steuergeräten
DE102014219286A1 (de) Steuergerät und Verfahren zur Absicherung von Daten
EP4266176A1 (de) Verfahren zum rechnergestützten betreiben einer speichereinheit und ausführen von applikationsprogrammen mit redundanter datenspeicherung

Legal Events

Date Code Title Description
PC Change of the owner

Owner name: SIEMENS MOBILITY GMBH, AT

Effective date: 20190814

HC Change of the firm name or firm address

Owner name: SIEMENS MOBILITY AUSTRIA GMBH, AT

Effective date: 20211108