DE102021133560A1

DE102021133560A1 - Verfahren zum Erweitern von Anwendungsmöglichkeiten eines Sensors, Sensor und Anwendung des Sensors

Info

Publication number: DE102021133560A1
Application number: DE102021133560.4A
Authority: DE
Inventors: Stefan Kempf; Stefan Robl
Original assignee: Endress and Hauser Conducta GmbH and Co KG
Current assignee: Endress and Hauser Conducta GmbH and Co KG
Priority date: 2021-12-16
Filing date: 2021-12-16
Publication date: 2023-06-22
Also published as: CN116429167A; US20230195447A1

Abstract

Die Erfindung offenbart ein Verfahren zum Erweitern von Anwendungsmöglichkeiten eines Sensors (1), umfassend die Schritte Übertragen einer App (2) auf den Sensor (1) über eine Kommunikationsschnittstelle (6) des Sensors (1), wenn sich die App (2) noch nicht auf dem Sensor (1) befindet, wobei die Firmware des Sensors (1) dazu ausgestaltet ist, Apps (2) zu empfangen und zu speichern; wobei die App (2) zumindest Identifikationsmerkmale (21), insbesondere Name und Version, einen oder mehrere Einsprungpunkt(e) (22), und eine Hauptlogik (23) umfasst; Auswählen der App (2) über eine Kommunikationsschnittstelle (6) des Sensors (1) mittels einer übergeordneten Einheit über die Identifikationsmerkmale (21) der App (2); Ausführen der ausgewählten App (2), wobei der Sensor (1) den Einsprungpunkt aufruft; und Rückgabe zumindest eines Rückgabewerts von der App (2) an den Sensor (1).Die Erfindung offenbart einen Sensor (1) zur Ausführung des Verfahrens und eine Anwendung des Sensors (1) mit dem Verfahren.

Description

Die Erfindung betrifft ein Verfahren zum Erweitern von Anwendungsmöglichkeiten eines Sensors, einen Sensor und eine Anwendung des Sensors.
Sensoren, vor allem optische Sensoren erfassen physikalische Kenngrößen (Rohwerte, häufig als Spannungswert) und errechnen daraus für die Applikation relevante Messwerte. Ein Beispiel ist dabei die Berechnung des Fettgehalts in Milch anhand des Lichtspektrums der Milch. Ein weiteres Beispiel ist die Bestimmung der Konzentration eines bestimmten Stoffes anhand der Leitfähigkeit des Messmediums. Die für die Umrechnung von Rohwerten in Messwerte verantwortlichen Algorithmen werden als (Rechen-)Modelle bezeichnet.
Die Modelle in den Sensoren sind nicht beliebig ergänzbar oder gar austauschbar. Der Sensor bringt entweder nur einen fest in der Firmware eingebauten Satz an Modellen mit (oder nur ein einziges Modell), wobei Satz allenfalls minimal parametrierbar ist, falls überhaupt.
Sensoren unterstützen von ihren technischen Daten häufig mehr Applikationen als ursprünglich vermutet. Beispielsweise wäre ein Trübungssensor, der eigentlich für die Messung von Schlämmen im Abwasserbereich entwickelt wurde, vom Messprinzip in der Lage, auch Fettgehalt in Milch zu messen. Da aber das Modell für die Bestimmung des Fettgehalts nur über ein aufwändiges Firmwareupdate den Sensor in die Lage bringt, diesen zu messen, verbleibt der Sensor in der ursprünglichen Applikation.
Der Erfindung liegt die Aufgabe zugrunde, den Funktionsumfang eines Sensors auf einfache Art und Weise zu erweitern.
Die Aufgabe wird gelöst durch ein Verfahren, umfassend die Schritte Übertragen einer App auf den Sensor über eine Kommunikationsschnittstelle des Sensors, wenn sich die App noch nicht auf dem Sensor befindet, wobei die Firmware des Sensors dazu ausgestaltet ist, Apps zu empfangen und zu speichern; wobei die App zumindest Identifikationsmerkmale, insbesondere Name und Version, einen oder mehrere Einsprungpunkt(e), und eine Hauptlogik umfasst; Auswählen der App über eine Kommunikationsschnittstelle des Sensors mittels einer übergeordneten Einheit über die Identifikationsmerkmale der App; Ausführen der ausgewählten App, wobei der Sensor den Einsprungpunkt aufruft; und Rückgabe zumindest eines Rückgabewerts von der App an den Sensor.
Eine Ausgestaltung sieht vor, dass beim Ausführen der App, der Sensor dem Einsprungpunkt einen oder mehrere Parameter mitgibt.
Eine Ausgestaltung sieht vor, dass der Sensor eine Programmierschnittstelle API umfasst und die App darüber einen oder mehrere Parameter vom Sensor abfragt.
Eine Ausgestaltung sieht vor, dass der Sensor den Einsprungpunkt zyklisch aufruft.
Eine Ausgestaltung sieht vor, dass der Schritt „Rückgabe zumindest eines Rückgabewerts von der App an den Sensor“ als direkte Rückgabe der App an den Sensor erfolgt.
Eine Ausgestaltung sieht vor, dass der Schritt „Rückgabe zumindest eines Rückgabewerts von der App an den Sensor“ dadurch erfolgt, dass der Sensor eine Programmierschnittstelle API umfasst, über die die App den Rückgabewert an den Sensor mitteilt.
Eine Ausgestaltung sieht vor, dass es sich bei der App um eine App zur Berechnung eines Messwerts über ein Modell handelt, wobei der Sensor der App den Rohwert als Parameter übergibt bzw. die App den Rohwert über die Programmierschnittstelle API abruft, wobei die Hauptlogik Algorithmen zur Signalverarbeitung und Routinen zur Berechnung des Messwerts aus einem Rohwert über das Modell umfasst, und wobei der Messwert der Rückgabewert ist.
Eine Ausgestaltung sieht vor, dass der Sensor mehrere Apps umfasst.
Dies umfasst die beiden Fälle, dass

1) unterschiedliche Apps, insbesondere Modelle, für den gleichen Messparameter verwendet werden, und aber ebenso
2) auch unterschiedliche Apps, insbesondere Modelle, für unterschiedliche Messparameter verwendet werden.

Im ersten Fall gibt es eine unterschiedliche Messperformance, beispielsweise bezüglich Genauigkeit, z.B. getrennt in Messbereiche o.ä. Im zweiten Fall wird beispielsweise ein ermitteltes Spektrum für einen anderen Parameter anders verarbeitet.
Eine Ausgestaltung sieht vor, dass der Sensor mehrere Apps umfasst und jede App ein anderes Modell zur Berechnung eines Messwerts umfasst.
Eine Ausgestaltung sieht vor, dass die Messwerte aus den unterschiedlichen Apps verglichen werden und im Fall einer Abweichung ein Messwert ausgewählt wird. Hierbei können die verschiedenen Apps weiterlaufen. Der „richtige“ Messwert wird anhand eines definierten Kriteriums gewählt, etwas dass der Messwert größer oder kleiner einem bestimmten Schwellenwert ist.
Eine Ausgestaltung sieht vor, dass die Messwerte aus den unterschiedlichen Apps verglichen werden und im Fall einer Abweichung über einem Schwellenwert ein Alarm ausgelöst wird.
Eine Ausgestaltung sieht vor, dass das Modell für eine einzige Messstelle konfiguriert ist.
Eine Ausgestaltung sieht vor, dass über den Einsprungpunkt der Sensor die App konfiguriert oder Statusabfragen durchgeführt werden.
Eine Ausgestaltung sieht vor, dass der Sensor eine virtuelle Maschine umfasst. In einer Ausgestaltung ist die virtuelle Maschine als Interpreter, insbesondere als Emulator, als Ahead-of-Time-Kompilierer, Just-in-Time-Kompilierer, Hypervisor oder eine Kombination daraus ausgestaltet.
Eine Ausgestaltung sieht vor, dass der Sensor einen Interpreter, insbesondere einen Software-Emulator oder einen Skriptspracheninterpreter, umfasst, die App in einem interpretierbaren Format auf dem Sensor vorliegt und das Ausführen der App über den Interpreter erfolgt.
Eine Ausgestaltung sieht vor, dass der Sensor einen Just-in-time-Kompilierer umfasst und die App in einem entsprechenden Format auf dem Sensor vorliegt.
Eine Ausgestaltung sieht vor, dass der Sensor einen Ahead-of-Time-Kompilierer umfasst und die App in einem entsprechenden Format auf dem Sensor vorliegt.
Eine Ausgestaltung sieht vor, dass pro Sensor mehrere Interpreter/Kompilierer ausführbar sind, insbesondere wird pro Interpreter/Kompilierer nur eine App ausgeführt.
Eine Ausgestaltung sieht vor, dass der Sensor ein oder mehrere Systemaufrufe für die App bereitstellt, wobei die App Systemaufruf-Stubs umfasst.
Eine Ausgestaltung sieht vor, dass ein Systemaufruf optimierte Signalverarbeitungsroutinen und Sensorfunktionen umfasst, um die aktuellen Rohwerte abzufragen und den berechneten Messwert zu bestimmen.
Die Aufgabe wird weiter gelöst durch einen Sensor zur Ausführung des oben beschriebenen Verfahrens, umfassend ein Sensorelement zur Erfassung einer Messgröße eines Messmediums und eine Datenverarbeitungseinheit mit einem Speicher.
Eine Ausgestaltung sieht vor, dass der Sensor als optischer Sensor ausgestaltet ist, mit einer Lichtquelle und einem Lichtempfänger, insbesondere ist der Sensor ein Spektrometer.
Eine Ausgestaltung sieht vor, dass der Sensor zur Erkennung von Grenzschichten, insbesondere als Schlammspiegelsensor, oder des Füllstands ausgestaltet ist, mit einem Sender zum Senden von elektromagnetischen Wellen, Licht, insbesondere optischem Licht, akustischen Wellen, oder Ultraschall in Richtung der Grenzschicht oder der Oberfläche, und mit einem Empfänger zum Empfangen der zurückgesendeten Wellen oder Licht.
Eine Ausgestaltung sieht vor, dass der Sensor als zweidimensionaler optischer Sensor ausgestaltet ist, insbesondere zum Partikel- oder Bakterienzählen.
Eine Ausgestaltung sieht vor, dass der Sensor als dreidimensionaler optischer Sensor ausgestaltet ist, insbesondere als Lidar-Sensor.
Die Aufgabe wird weiter gelöst durch die Anwendung des Verfahrens wie oben beschrieben mit einem Sensor wie oben beschrieben zur Bestimmung der Zusammensetzung, beispielsweise des Fettgehalts, von Milch.
Dies wird anhand der nachfolgenden Figuren näherer erläutert.

1 zeigt den Kern des beanspruchten Verfahrens in einer Übersicht.
2 zeigt den beanspruchten Sensor.
3a/b zeigen die App.

In den Figuren sind gleiche Merkmale mit gleichen Bezugszeichen gekennzeichnet.
Sensoren unterstützen von ihrem Messprinzip häufig viel mehr Applikationen, als ursprünglich vermutet. Beispielsweise wäre ein Trübungssensor, der eigentlich für die Messung von Schlämmen im Abwasserbereich entwickelt wurde, vom Messprinzip in der Lage, auch Fettgehalt in Milch zu messen. Um sich hier flexibel neue Applikationen erschließen zu können, sollten Modelle nicht fest im Sensor gespeichert sein, sondern in Form von nachladbaren Apps entwickelt werden.
Somit sind auch Sensoren, die bereits produziert wurden, ohne Firmware-Update in der Lage, neue Applikationen zu bedienen. Ebenso können Kunden, die ihren Sensor für eine andere Applikation nutzen wollen, mühelos umrüsten. Die Nachladbarkeit der Rechenmodelle ermöglicht es, hochspezialisierte Rechenmodelle, die gegebenenfalls nur auf eine einzige Messstelle hin optimiert sind, zu verwenden.
1 zeigt den Sensor 1 mit nachladbaren Apps 2 mit völlig frei definierbarer Signalverarbeitung 3, also Modellen, und Parametrierung 4. Der Sensor 1 umfasst eine Datenverarbeitungseinheit 14 mit einem Speicher 5, der groß genug ist um mehrere Apps 2 zu Speichern (symbolisiert durch die freien Bereiche).
Die App 2 ist also ein (nach-)ladbares Stück Programmcode, das dem Host, also dem Sensor 1, zusätzliche Funktionen bietet. Der ladbare Code ist so strukturiert, dass er an zwei Enden mit dem Sensor 1 interagieren kann:

• es gibt Einsprungpunkte 22, im Allgemeinen Schnittstellenmethoden, die der Sensor aufruft, um eine bestimmte Funktionalität in der App 2 aufzurufen; Beispiel: Berechnung von Messwerten, siehe unten
• der Sensor 1 stellt Funktionen über Systemaufrufe 24a bereit, die über Systemaufruf-Stubs 24 innerhalb der App aufgerufen werden; Beispiel: Zugriff auf Indexstrukturen oder erweiterte Rechenmethoden

Das Ausführen der App 2 wird verweigert, wenn die Systemaufrufe 24a oder Interface-Methoden 22 nicht vorhanden sind oder nur in inkompatibler Version vorhanden sind oder das Zielsystem nicht übereinstimmt, also die App 2 für ein falsche Basissystem 1 geschrieben wurde. Die App 2 wird abgebrochen, wenn diese zur Laufzeit versucht, einen Systemaufruf 24a auszuführen, der nicht im Basissystem 1 vorhanden ist oder in einer inkompatiblen Version vorliegt.
Die Firmware des Sensors 1 ist so ausgestaltet, dass diese über eine Schnittstelle Apps 2 empfangen und intern speichern kann. Der Sensor 1 bietet eine Kommunikationsschnittstelle 6, über die dem Sensor 1 mitgeteilt wird, welche der gespeicherten App(s) zur Messwertberechnung geladen werden sollen. Der Sensor 1 ist über die Kommunikationsschnittstelle 6 mit einer übergeordneten Einheit verbunden, etwa einem Transmitter (Messumformer) oder einem Leitsystem (Leitwarte). Die Kommunikationsschnittstelle 6 ist üblicherweise drahtgebunden und kann einem proprietären Protokoll unterliegen oder ein Bussystem wie etwa HART, Modbus, Foundation Fieldbus, o.a. unterliegen.
Im Folgenden soll auf den Sensor 1 an sich eingegangen werden.
Der Sensor 1 umfasst zumindest eine Lichtquelle 11, ein Spektrometer 13 und eine Datenverarbeitungseinheit 14. Der Sensor 1 bzw. die Datenverarbeitungseinheit 14 sind dazu ausgestaltet ist, die Schritte des beanspruchten Verfahrens auszuführen, also beispielsweise die Lichtquelle 11 ein- und auszuschalten oder die Datenverarbeitung durchzuführen.
Dargestellt ist ein optischer Sensor, genauer ein Spektrometer. Dies wird im Folgenden näher erläutert. Grundsätzlich ist das beanspruchte Verfahren aber auch auf andere Sensoren mit anderen physikalischen oder chemischen Messverfahren anwendbar.
Das Spektrometer 13 ist in 2 nur symbolisch dargestellt und umfasst beispielsweise zumindest ein strahlformendes Element, etwa einen Spiegel 15, ein Gitter 16 (im Allgemeinen ein dispersives Element, beispielsweise auch ein Prisma) und einen Empfänger 17. Spiegel 15 und Gitter 16 können als ein einzelnes Bauteil ausgestaltet sein. Der Empfänger ist als CCD-Sensor oder Zeilenarray-Detektor ausgestaltet. Am Eingang des Spektrometers 13 befindet sich ein Eintrittspalt 18. Grundsätzlich funktioniert der erfindungsgemäße Gedanke mit allen spektrometrischen Messsystemen, unabhängig davon ob etwa ein Prisma oder Gitter verwendet wird.
Licht von der Lichtquelle 11, die etwa als Xenon-Blitzlampe ausgestaltet ist, wird von der Lichtquelle 11 ausgehend in Richtung Messmedium 12 gesendet. Die Lichtquelle 11 kann auch als LED ausgestaltet sein. Ist das Emissionsspektrum der Lichtquelle 11 temperaturabhängig, umfasst der Sensor 1 einen Temperatursensor 19, welche bei, in oder zumindest in der Nähe der Lichtquelle 1 angeordnet ist. Dadurch kann das Emissionsspektrum gegebenenfalls bezüglich der Temperatur korrigiert werden.
Dargestellt ist eine Transmissionsmessung. Dazu umfasst die Lichtquelle 11 ein oder mehrere Fenster, die für das ausgesendete Licht zumindest teiltransparent sind. Über die Fenster ist das Messmedium 12 abgetrennt von den optischen und elektronischen Komponenten des Sensors 1. Andere Messprinzipien wie Absorptionsmessung, Streu- oder Fluoreszenzmessung sind ebenso möglich.
Die Datenverarbeitungseinheit 14 umfasst ein oder mehrere Apps 2, dargestellt durch den quadratischen Kasten. Die Apps 2 befinden sich im Speicher 5. Befinden sich die Apps 2 noch nicht im Speicher 5, wird die App 2 darauf geladen. Dies erfolgt beispielsweise über die Kommunikationsschnittstelle 6. Je nach Ausgestaltung des Sensors kann auch ein direktes Übertragen der Apps 2 auf den Sensor, etwa über eine drahtlose Datenverbindung wie Bluetooth o.ä. erfolgen. Ebenso können die Apps 2 über eine Speicherkarte, etwa eine SD-Karte, in die Datenverarbeitungseinheit 14 geladen werden, falls der Sensor 1 eine solche Möglichkeit umfasst.
Um die im Sensor 1 gespeicherten Apps 2 unterscheiden zu können, müssen die Apps 2 ein Identifikationsmerkmal 21 mitbringen, wie etwa der Name und Version der App, beispielsweise als Metainformation. Die App 2 liegt beispielsweise als eine Image-Datei vor, in der der eigentliche Programmcode und das Identifikationsmerkmal 21 (Metainformation) der App 2 selbst liegen.
Dies zeigt auch die allgemeine Darstellung der App 2 in 3a. Die App 2 umfasst beispielsweise drei Teile: die eigentliche Hauptlogik 23, Interface-Methoden 22, die vom Basissystem aufgerufen werden und System-Call-Stubs 24, anhand derer Funktionalität im Sensor 1 aufgerufen wird.
Der Code der App 2 kann aus beliebigen Algorithmen bestehen, um die Rohwerte in Messwerte umzurechnen. Rohwerte sind die physikalische Kenngrößen, etwa als Spannungswert, während der Messwert etwa der Fettgehalt von Milch oder eine Konzentration eines bestimmten Stoffes im zu messenden Medium darstellt. Um konkreter zu werden: im oben dargelegten Beispiel sind die Interface-Methoden 22 die Einsprungspunkte zur Messwertberechnung. Die Hauptlogik 23 stellen die eigentlichen Algorithmen zur Signalverarbeitung dar. System-Calls 24 wären z.B. optimierte Routinen, die häufig in Signalverarbeitungsalgorithmen genutzt werden und Sensorfunktionen, um die aktuellen Rohwerte abzufragen und den berechneten Messwert zu bestimmen. Der Sensor 1 kann der Interface-Methode 22 der App 2 die aktuellen Rohwerte als Parameter mitgeben, oder die App 2 kann über eine API die aktuellen Rohwerte des Sensors 1 abfragen. Die App 2 liefert die Messwerte, gegebenenfalls mit der jeweiligen Einheit, an den Sensor 1a zurück, z.B. als Rückgabewert oder indem der Sensor eine API anbietet, über die die App den aktuellen Messwert und die Einheit mitteilt.
3b zeigt die Beziehung zwischen App 2 und Sensor 1. Auf dem Sensor 1 können mehrere Apps 2 gleichzeitig laufen. Dies ist durch die in der Mitte der Zeichnung angedeuteten untereinander liegenden Puzzleteile illustriert. Im Sensor 1 gibt es Interface-Stubs 22a, anhand derer die Interface-Methoden 22 in der App 2 aufgerufen werden. Der Sensor 1 bietet der App 2 Funktionalitäten in Form von System-Calls 24a an. Damit eine App 2 die im Sensor 1 liegenden System-Calls 24a aufrufen kann, gibt es entsprechende System-Call-Stubs 24 in der App 2.
Wie in der 3b dargestellt, können mehrere Apps 2 gleichzeitig ausgeführt werden, aber alle Apps 2 für denselben Sensortyp haben dieselben Schnittstellen. Apps 2 laufen in einer Ausgestaltung in einer isolierten Umgebung, um zu verhindern, dass eine fehlerhafte App 2 den Host (Sensor 1) zum Absturz bringt. Aufgrund dieser Isolierung kann der Sensor eine Methode in der App 2 nicht direkt aufrufen. Die App 2 kann auch keine direkten Aufrufe an den Sensor 1 durchführen. Apps 2 laufen auch in ihrem eigenen Adressraum und können standardmäßig nicht auf Daten des Sensors 1 zugreifen.
Stattdessen läuft der Prozess wie in dargestellt ab. Um mit einer App 2 zu interagieren, gibt es Schnittstellen-Stubs 22a auf der Sensor-Seite. Eine App 2 wird nur über die Schnittstellen-Stubs 22a „betreten und verlassen“. Wenn der Sensor 1 einen Stub 22a aufruft, springt ein Dispatch-Mechanismus in die App 2 und ruft die entsprechende Schnittstellenmethode 22 auf. Die Schnittstellenmethoden 22 rufen die Hauptlogik 23 auf, die ihre Funktion ausführt und zurückkehrt. Die Hauptlogik 23 kann zusätzlich auf Systemaufrufe 24a zurückgreifen. In diesem Fall ruft die Hauptlogik 23 einen Stub 24 auf und ein Dispatch-Mechanismus leitet wiederum einen Systemaufruf 24a auf der Sensor-Seite weiter. Jetzt ist die Ausführung wieder im Sensor 1, der Systemaufruf 24a führt seine Aktion aus, kehrt dann zur App 2 zurück und schließlich kehrt die App 2 wieder zum Sensor 1 zurück. Der Anwendungscode kann aus einer Hauptschleife bestehen, sodass dieser Zyklus ewig wiederholt werden kann.
Der Sensor 1 muss Apps 2 laden und ausführen können, beispielsweise indem die Sensor-Firmware eine virtuelle Maschine implementiert, in der Apps interpretiert / ausgeführt werden. Die virtuelle Maschine ist als Interpreter, insbesondere als Emulator, als Ahead-of-Time-Kompilierer, Just-in-Time-Kompilierer, Hypervisor oder eine Kombination daraus ausgestaltet. Die CPU-Architektur von Host (Sensor 1) und Gast (darauf laufende App 2) müssen dabei nicht unbedingt gleich sein. Vor allem im Fall des Hypervisors ist es für eine performante Ausführung der App aber ratsam, den gleichen CPU-Befehlssatz zu wählen.
Bei der Ausgestaltung als virtuelle Maschine ergeben sich inhärente Maßnahmen zum Speicherschutz und damit auch zur Sicherheit. Ein möglicher Schadcode kann aus der virtuellen Maschine nicht herausgreifen und dadurch die Firmware oder andere laufende virtuellen Maschinen (es können mehrere parallel laufen, siehe unten) nicht negativ beeinflussen. Es gibt eine Trennung zwischen den verschiedenen virtuellen Maschinen, da keine gemeinsamen Speicherbereiche genutzt werden. Die verschiedenen virtuellen Maschinen interagieren nur über definierte Schnittstellen, so dass dadurch nur begrenzte Funktionen ausgeführt werden können. Die virtuelle Maschine, insbesondere in ihrer Ausgestaltung als Interpreter (Emulator), bildet eine Umgebung zur Ausführung der App in Form einer virtuellen CPU mit virtuellem Arbeitsspeicher. Dieses System ist dabei abgeschottet vom restlichen System, also vom Hostsystem, also von der Firmware des Sensors. Sollte eine App fehlerhaft sein, hat das keine Auswirkung auf das restliche System. Dieses läuft weiter, selbst wenn die fehlerhafte Erweiterung abstürzt. Die Kommunikation erfolgt über definierte Schnittstellen.
Die App 2 kann aber auch „nativ“ auf dem Sensor ausgeführt werden. Der Sensor 1 umfasst dazu etwa einen Ahead-of-Time-Kompilierer oder einen Just-in-Time-Kompilierer. Die App 2 liegt in einem entsprechenden Format auf dem Sensor 1 vor.
Erfolgt keine Emulation über eine virtuelle Maschine, siehe oben, und stimmen die CPU-Architekturen von Host und Gast überein, ist eine Unterstützung des Prozessors des Sensors 1 nötig, um die App auszuführen, z.B. braucht es dann eine Memory-Management-Unit (MMU) in Hardware, damit der Speicherschutz realisiert werden kann.
Zur Interpretation / Ausführung von Apps muss die Programmcode enthalten, der interpretierbar / ausführbar ist oder in eine interpretierbare / ausführbare Form übersetzt werden kann, beispielsweise maschinenunabhängiger Bytecode. Ebenso muss das Programm in einem Binärformat gespeichert sein, z.B. im Executable and Linking Format (ELF). Das Binärformat gibt Aufschluss über das Speicherlayout der App, z.B. Lage und Größe von Code und Daten. Diese Information ist notwendig zum Laden einer App und zur Vorbereitung ihrer Ausführung.
Der Programmcode kann über einen Interpreter (virtuelle Maschine) ausgeführt werden oder vor Ausführung in den Maschinencode des auf dem Sensor eingesetzten Prozessors übersetzt werden (Kompilierer).
Die Einsprungpunkte können z.B. Programmadressen sein, die in der Metainformation, etwa als Teil des Identifikationsmerkmals 21, hinterlegt sind. Die virtuelle Maschine bzw. der Kompilierer führt dann die App 2 ausgehend von dieser Programmadresse aus.
Die Einsprungpunkte können auch IDs als Kennung sein. Die virtuelle Maschine ruft die App 2 immer an einer im ELF-File hinterlegen Startadresse mit der Einsprungpunkt-ID als weiteres Argument auf. Die App 2 muss so programmiert sein, dass sie die ID auswertet und den gewünschten Einsprungpunkt aufruft. Die ID kann beim Erstellen der App explizit eingegeben werden oder wird automatisch vergeben.
Die Apps 2 bieten einen Einsprungpunkt (siehe oben, „Interface-Methoden 22“), den der Sensor 1 aufruft, damit die App 2 aus den aktuell erfassten Rohwerten einen Messwert zu berechnen. Der Sensor 1 kann dem Einsprungpunkt der App 2 die aktuellen Rohwerte als Parameter mitgeben, oder die App 2 kann über eine API die aktuellen Rohwerte vom Sensor abfragen.
Der Sensor 1 bietet generische, optimierte Signalverarbeitungsroutinen, auf die die App zurückgreifen kann.
Die App 2 liefert die Messwerte, gegebenenfalls mit der jeweiligen Einheit, an den Sensor 1 zurück, z.B. als Rückgabewert oder indem der Sensor eine API anbietet, über die die App den aktuellen Messwert und die Einheit mitteilt.
Die Apps 2 können auch weitere Einsprungspunkte besitzen, über die der Sensor z.B. die App konfiguriert, Statusabfragen macht, etc.
In einer weiteren Ausgestaltung kann der Sensor 1 zwei oder mehr unterschiedliche Modelle für ein und dieselbe Applikation betreiben. Die unterschiedlichen Modelle können so miteinander verglichen werden, um z.B.: durch den Anwender, oder maschinell zu entscheiden, welches Modell die genaueren Messwerte berechnet oder um Abweichungen zwischen den berechneten Messwerten zu erkennen und um zu warnen, dass im Prozess eine ungewöhnliche Situation aufgetreten ist. Der Vergleich erfolgt etwa über einen Schwellenwert, d.h. dass im Fall einer Abweichung über dem Schwellenwert ein anderes Modell gewählt (also eine andere App 2) oder sogar ein Alarm ausgelöst wird. In einer weiteren Ausgestaltung kann der Sensor 1 ein, zwei oder mehr unterschiedliche Modelle für zwei oder mehr unterschiedliche Applikationen betreiben. Dadurch können etwa im Falle eines Spektrometers die Konzentrationen unterschiedlicher Stoffe im Messmedium anhand der gleichen Rohmesswerte ermittelt werden.
Bezugszeichenliste

1: Sensor
2: App
3: Signalverarbeitung / Modell
4: Parametrierung
5: Speicher
6: Kommunikationsschnittstelle
11: Lichtquelle
12: Messmedium
13: Spektrometer
14: Datenverarbeitungseinheit
15: Spiegel
16: Gitter
17: Empfänger
18: Eintrittsspalt
19: Temperatursensor
21: Identifikationsmerkmal
22: Interface-Methode / Einsprungpunkt
22a: Interface-Stubs / Einsprungpunkt-Stubs
23: Hauptlogik
24: System call stubs / Systemaufruf-Stubs
24a: System call / Systemaufruf

Claims

Verfahren zum Erweitern von Anwendungsmöglichkeiten eines Sensors (1), umfassend die Schritte - Übertragen einer App (2) auf den Sensor (1) über eine Kommunikationsschnittstelle (6) des Sensors (1), wenn sich die App (2) noch nicht auf dem Sensor (1) befindet, wobei die Firmware des Sensors (1) dazu ausgestaltet ist, Apps (2) zu empfangen und zu speichern; - wobei die App (2) zumindest Identifikationsmerkmale (21), insbesondere Name und Version, einen oder mehrere Einsprungpunkt(e) (22), und eine Hauptlogik (23) umfasst; - Auswählen der App (2) über eine Kommunikationsschnittstelle (6) des Sensors (1) mittels einer übergeordneten Einheit über die Identifikationsmerkmale (21) der App (2); - Ausführen der ausgewählten App (2), wobei der Sensor (1) den Einsprungpunkt aufruft; und - Rückgabe zumindest eines Rückgabewerts von der App (2) an den Sensor (1).
Verfahren nach Anspruch 1, wobei beim Ausführen der App (2), der Sensor (1) dem Einsprungpunkt (22) einen oder mehrere Parameter mitgibt.
Verfahren nach Anspruch 1, wobei der Sensor (1) eine Programmierschnittstelle API umfasst und die App (2) darüber einen oder mehrere Parameter des Sensors (1) abfragt.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) den Einsprungpunkt (22) zyklisch aufruft.
Verfahren nach einem der vorherigen Ansprüche, wobei der Schritt „Rückgabe zumindest eines Rückgabewerts von der App (2) an den Sensor (1)“ als direkte Rückgabe der App (2) an den Sensor (1) erfolgt.
Verfahren nach einem der vorherigen Ansprüche, wobei der Schritt „Rückgabe zumindest eines Rückgabewerts von der App (2) an den Sensor (1)“ dadurch erfolgt, dass der Sensor (1) eine Programmierschnittstelle API umfasst, über die die App (2) den Rückgabewert an den Sensor (1) mitteilt.
Verfahren nach einem der vorherigen Ansprüche, wobei es sich bei der App (2) um eine App zur Berechnung eines Messwerts über ein Modell handelt, wobei der Sensor (1) der App (2) den Rohwert als Parameter übergibt bzw. die App (2) den Rohwert über die Programmierschnittstelle API abruft, wobei die Hauptlogik Algorithmen zur Signalverarbeitung und Routinen zur Berechnung des Messwerts aus einem Rohwert über das Modell umfasst, und wobei der Messwert der Rückgabewert ist.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) mehrere Apps (2) umfasst.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) mehrere Apps (2) umfasst und jede App (2) ein anderes Modell zur Berechnung eines Messwerts umfasst.
Verfahren nach dem vorherigen Anspruch, wobei die Messwerte aus den unterschiedlichen Apps (2) verglichen werden und im Fall einer Abweichung ein Messwert ausgewählt wird.
Verfahren nach dem vorvorherigen Anspruch, wobei die Messwerte aus den unterschiedlichen Apps (2) verglichen werden und im Fall einer Abweichung über einem Schwellenwert ein Alarm ausgelöst wird.
Verfahren nach einem der vorherigen Ansprüche, wobei das Modell für eine einzige Messstelle konfiguriert ist.
Verfahren nach einem der vorherigen Ansprüche, wobei über den Einsprungpunkt (22) der Sensor (1) die App (2) konfiguriert oder Statusabfragen durchgeführt werden.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) einen Interpreter, insbesondere einen Software-Emulator oder einen Skriptspracheninterpreter, umfasst, die App (2) in einem interpretierbaren Format auf dem Sensor (1) vorliegt und das Ausführen der App (2) über den Interpreter erfolgt.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) einen Just-in-time-Kompilierer umfasst und die App (2) in einem entsprechenden Format auf dem Sensor (1) vorliegt.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) einen Ahead-of-Time-Kompilierer umfasst und die App (2) in einem entsprechenden Format auf dem Sensor (1) vorliegt.
Verfahren nach einem der vorherigen Ansprüche, wobei pro Sensor (1) mehrere Interpreter/Kompilierer ausführbar sind, insbesondere wird pro Interpreter/Kompilierer nur eine App (2) ausgeführt.
Verfahren nach einem der vorherigen Ansprüche, wobei der Sensor (1) ein oder mehrere Systemaufrufe (24a) für die App (2) bereitstellt, wobei die App (2) Systemaufruf-Stubs (24) umfasst.
Verfahren nach dem vorherigen Anspruch, wobei ein Systemaufruf (24a) optimierte Signalverarbeitungsroutinen und Sensorfunktionen umfasst, um die aktuellen Rohwerte abzufragen und den berechneten Messwert zu bestimmen.
Sensor (1) zur Ausführung des Verfahrens nach einem der vorherigen Ansprüche, umfassend - ein Sensorelement zur Erfassung einer Messgröße eines Messmediums, - eine Datenverarbeitungseinheit (14) mit einem Speicher.
Sensor (1) nach dem vorherigen Anspruch, wobei der Sensor (1) als optischer Sensor ausgestaltet ist, mit einer Lichtquelle (11) und einem Lichtempfänger (17), insbesondere ist der Sensor (1) ein Spektrometer.
Anwendung des Verfahrens nach einem der vorherigen Ansprüche mit einem Sensor (1) nach einem der vorherigen Ansprüche zur Bestimmung der Zusammensetzung, beispielsweise des Fettgehalts, von Milch.