Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR OPERATING A PLURALITY OF DIFFERENT TYPES OF DEVICES ON A NETWORK OF A RAIL VEHICLE
Document Type and Number:
WIPO Patent Application WO/2018/054680
Kind Code:
A1
Abstract:
The invention relates to a method for operating a plurality of different types of devices on a network (12) of a rail vehicle, according to which software is transmitted from a server (34) to the devices over the network (12). The devices each comprise, for example, a head module (30) connected to a field bus (20), and at least one measuring module (32) connected, in turn, to the head module (30). Sensor systems (24) can also be included as devices. In order to reduce the amount of hardware only used for servicing purposes in the vehicle, a virtualisation platform with a plurality of virtual environments, each of which contains a converter specific to the type of device, is connected to the network (12), and software is transmitted from a download service of the server (34) to the devices (24; 30, 32) respectively via the converter associated with the respective device (24; 30, 32), said converter carrying out the transmission from the download service to a device-specific download service. A Profinet (18) and the field bus (20), for example a CAN field bus, are part of a runtime system by which means, for example, control appliances (22) are supplied in real time with control data, for example, from an input and output system (16), in the driving state. The control appliances (22) are, for example, brake control appliances that, in turn, control brake actuators or motors on at least one of the bogies by means of the field bus (20) in real time. The sensor systems (24) can be attached to a sensor bus (26) of the network (12), which is also part of the runtime system of the rail vehicle (2). In order to transfer the software from the server (34) to the devices (24; 30, 32), the network (12) contains an ethernet (28) with a fast protocol for transmitting large data quantities, for example TCP/IP or another non-real time protocol. The ethernet (28) is connected to the devices via other interfaces of the devices (24; 30, 32), as the field bus (20). For example, the devices (24; 30, 32) have diagnosis interfaces that form an interface to the ethernet (28).

Inventors:
PORSCH ROLAND (DE)
Application Number:
PCT/EP2017/072197
Publication Date:
March 29, 2018
Filing Date:
September 05, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
International Classes:
B61L15/00; H04L29/08; H04L12/24
Foreign References:
DE102014214225A12015-07-02
Other References:
MATT HELSLEY: "LXC: Linux container tools", IBM DEVELOPERWORKS, 3 February 2009 (2009-02-03), pages 1 - 10, XP055217383, Retrieved from the Internet [retrieved on 20150930]
Download PDF:
Claims:
Patentansprüche

1. Verfahren zum Betreiben mehrerer Geräte (10) unterschiedlichen Typs an einem Netzwerk (12) eines Schienenfahrzeugs (2), bei dem Software von einem Server (34) über das Netzwerk (12) auf die Geräte (10) übertragen wird,

d a d u r c h g e k e n n z e i c h n e t , dass

mit dem Netzwerk (12) eine Virtualisierungsplattform (42) mit mehreren virtuellen Umgebungen (44) verbunden ist, von denen jede einen gerätetypspezifischen Wandler (46) enthält, und eine Softwareübertragung von einem Downloaddienst des Servers (34) auf die Geräte (10) jeweils über den dem jeweiligen Ge¬ rät (10) zugeordneten Wandler (46) erfolgt, der die Umsetzung der Übertragung vom Downloaddienst auf einen gerätespezifi- sehen Downloaddienst übernimmt.

2. Verfahren nach Anspruch 1,

d a d u r c h g e k e n n z e i c h n e t , dass

die virtuellen Umgebungen (44) jeweils Linux-Container sind und jeder Container einen der gerätespezifischen Wandler (46) enthält .

3. Verfahren nach Anspruch 1 oder 2,

d a d u r c h g e k e n n z e i c h n e t , dass

die virtuellen Umgebungen (44) jeweils eine eigene IP-Adresse aufweisen, die jeweils in einer Hardware-Anschaltung eines Hosts des Servers (34) verzeichnet sind.

4. Verfahren nach einem der vorhergehenden Ansprüche,

d a d u r c h g e k e n n z e i c h n e t , dass

die Geräte (10) über einen Feldbus (20) des Netzwerks (12) mit Steuerdaten angesteuert werden und die Software vom Ser¬ ver (34) über eine Ethernetverbindung (28) des Netzwerks (12) auf die Geräte (10) übertragen wird.

5. Verfahren nach Anspruch 4,

d a d u r c h g e k e n n z e i c h n e t , dass

die Geräte (10) über den Feldbus (20) mit einem Laufzeitsys- tem des Fahrzeugs (2) verbunden sind und aus diesem heraus in Echtzeit angesteuert werden.

6. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass

das Netzwerk (12) ein echtzeitfähiges Protokoll und ein

Ethernet-Protokoll auf einer gemeinsamen Leitung (14) aufweist und die Geräte (10) über das echtzeitfähige Protokoll angesteuert werden und die Software über das Ethernet- Protokoll auf die Geräte (10) aufgespielt wird.

7. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass

die virtuellen Umgebungen (44) jeweils Anweisungen (52) zu einem Übertragungsprotokoll enthalten, nach dem die Software auf das jeweils zugeordnete Gerät (10) übertragen wird.

8. Verfahren nach Anspruch 7,

d a d u r c h g e k e n n z e i c h n e t , dass

das Übertragungsprotokoll Anweisungen (52) zu einem Sicher¬ heitslevel enthält, nach dem die Software auf das jeweils zu¬ geordnete Gerät (10) übertragen wird.

9. Verfahren nach Anspruch 8,

d a d u r c h g e k e n n z e i c h n e t , dass

das Sicherheitslevel festlegt, ob ein einfacher File- Transfer, eine prüfsummengeschützte Übertragung oder eine zertifikatgeschützte Übertragung erfolgt. 10. Schienenfahrzeug (2) mit einem Netzwerk (12), an das meh¬ rere Geräte (10) und ein Server (34) mit einem Netzwerk- Downloaddienst angebunden sind, der Software für die Geräte (10) enthält,

d a d u r c h g e k e n n z e i c h n e t , dass

das Netzwerk (12) eine Virtualisierungsplattform (42) mit mehreren virtuellen Umgebungen (44) aufweist, von denen jede einen gerätetypspezifischen Wandler (46) enthält, und die Wandler (46) jeweils eine geräteseitige Anbindung für den Downloaddienst zu dem ihnen zugeordneten Gerät (10) aufwei¬ sen .

11. Schienenfahrzeug (2) nach Anspruch 10,

d a d u r c h g e k e n n z e i c h n e t , dass

der Server (34) die Virtualisierungplattform (42) aufweist.

12. Schienenfahrzeug (2) nach Anspruch 10 oder 11,

d a d u r c h g e k e n n z e i c h n e t , dass

die Geräte (10) an einem Drehgestell (6) des Schienenfahr¬ zeugs (2) angeordnet sind.

13. Schienenfahrzeug (2) nach einem der Ansprüche 10 bis 12, d a d u r c h g e k e n n z e i c h n e t , dass

die Geräte (10) Messgeräte und/oder Steuergeräte an einem Drehgestell (6) des Schienenfahrzeugs (2) umfassen.

Description:
Beschreibung

Verfahren zum Betreiben mehrerer Geräte unterschiedlichen Typs an einem Netzwerk eines Schienenfahrzeugs

Die Erfindung betrifft ein Verfahren zum Betreiben mehrerer Geräte unterschiedlichen Typs an einem Netzwerk eines Schienenfahrzeugs, bei dem Software von einem Server über das Netzwerk auf die Geräte übertragen wird.

Moderne Schienenfahrzeuge zur Personenbeförderung weisen eine Vielzahl von Geräten auf, die von außen gesteuert werden oder nach außen Daten, wie Messdaten, abgeben. Die Geräte sind an einem Netzwerk angeschlossen, mit dem auch korrespondierende Steuer- und Auswertegeräte verbunden sind zur Steuerung beziehungsweise Auswertung der Geräte.

Zur Anpassung von Geräteeigenschaften oder Softwareupdates kommt es vor, dass die Geräte mit neuer Software bespielt werden müssen. Die Software wird über einen Server mit einem Downloaddienst am Netzwerk zur Verfügung gestellt und über das Netzwerk den Geräten zugeführt. Solche Geräte weisen in der Regel eine Ethernet-Schnittstelle auf, beispielsweise ei ¬ ne Diagnoseschnittstelle, über die ein interner Download- dienst verfügbar gemacht wird. Dieser ist auf das Subsystem zurechtgeschnitten und in der Lage, eingehende Software downzuloaden und dem Subsystem verfügbar zu machen.

Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Betreiben mehrerer Geräte unterschiedlichen Typs an einem Netzwerk eines Schienenfahrzeugs anzugeben, mit dem Software von einem Server über das Netzwerk auf die Geräte einfach übertragen werden kann. Diese Aufgabe wird durch ein Verfahren der eingangs genannten Art gelöst, bei dem erfindungsgemäß eine

Virtualisierungsplattform mit mehreren virtuellen Umgebungen mit dem Netzwerk verbunden ist, von denen jede einen geräte- typspezifischen Wandler enthält. Eine Softwareübertragung kann auf diese Weise von einem Downloaddienst des Servers auf die Geräte jeweils über den dem jeweiligen Gerät zugeordneten Wandler erfolgen. Dieser kann dann die Umsetzung der Übertra- gung vom Downloaddienst auf einen gerätespezifischen Downloaddienst übernehmen.

Die Erfindung geht von der Überlegung aus, dass auf Geräte eines Schienenfahrzeugs für die Personenförderung zu übertra- gende Software häufig Software ist, die auf das Schienenfahr ¬ zeug an sich beziehungsweise Eigenschaften des Netzwerks und andere Geräte des Schienenfahrzeugs angepasst ist. Zur Koor ¬ dination solcher Downloads ist beispielsweise ein Profibus geeignet, der einen entsprechenden Downloaddienst auf einem Server des Schienenfahrzeugs aufweist. Für einen erfolgrei ¬ chen Download von Software auf ein Gerät des Schienenfahr ¬ zeugs muss der serverinterne Downloaddienst von dem subsys- tem-proprietären Downloaddienst des Geräts unterstützt wer ¬ den .

Hierfür besteht die Möglichkeit, den Gerätedownloaddienst durch entsprechende Programmierung des Herstellers an den fahrzeugeigenen Downloaddienst anzupassen, was jedoch mit Aufwand und Kosten verbunden ist. Eine etwas einfachere Mög- lichkeit besteht darin, für jedes Gerät beziehungsweise jeden Gerätetyp einen Rechner in das Fahrzeug einzubauen, der nur für Downloadaufgaben und gegebenenfalls für die Bereitstel ¬ lung einer Weboberfläche verwendet wird. Dieser Rechner bil ¬ det dann den servereigenen Download auf den proprietären Download des Geräts ab und stellt beispielsweise einen Web ¬ server bereit. Hieraus ergibt sich allerdings die Notwendig ¬ keit, eine Vielzahl von Rechnern in das Fahrzeug einzubauen, die nur im Service, zum Beispiel für den Download, Verwendung finden, aber bei einem fahrenden Zug keinerlei Aufgaben haben und nur Einbauplatz und Energie verbrauchen.

Durch die erfindungsgemäße Lösung der

Virtualisierungsplattform besteht die Möglichkeit, auf einem Rechner mehrere virtuelle Umgebungen einzurichten, die jede einen gerätetypspezifischen Wandler enthalten. Jedem Gerät oder Gerätetyp ist eine virtuelle Umgebung mit einem geräte ¬ typspezifischen Wandler zugeordnet, der die Umsetzung vom serverinternen Downloaddienst auf den proprietären Downloaddienst des Geräts beziehungsweise Gerätetyps durchführt. Der Wandler kann vom Gerätelieferanten bereitgestellt werden. Es kann hierdurch sowohl auf eine Ausrüstung aller Geräte mit dem entsprechenden Downloaddienst als auch auf angeschlossene und zusätzliche Rechner im Schienenfahrzeug verzichtet wer ¬ den .

Der gerätespezifische Downloaddienst kann örtlich im Gerät vorhanden sein und an den Wandler angebunden sein. Die unter- schiedlichen Geräte können so jeweils einen gerätespezifischen Downloaddienst enthalten, wobei die Downloaddienste der unterschiedlichen Gerätetypen verschieden sind. Die Anpassung vom Downloaddienst des Servers an die gerätespezifischen Downloaddienste wird vom Wandler in der virtuellen Umgebung vorgenommen.

Möglich ist auch, dass der gerätespezifische Downloaddienst ebenfalls in der virtuellen Umgebung lokalisiert ist. Die verschiedenen virtuellen Umgebungen enthalten dann für jeden Gerätetyp den passenden gerätespezifischen Downloaddienst, sodass die Geräte jeweils ohne gerätespezifischen Download ¬ dienst ausgeführt sein können.

Zweckmäßigerweise hat jeder Gerätetyp eine eigene virtuelle Umgebung mit einem eigenen gerätespezifischen Downloaddienst. Jeder Wandler kann jeweils eine geräteseitige Anbindung für den Netzwerk-Downloaddienst aufweisen.

In einer vorteilhaften Ausführungsform der Erfindung sind die virtuellen Umgebungen jeweils Linux-Container, wobei zweckmäßigerweise jeder Container einen der gerätespezifischen Wandler enthält. Der Linux-Container kann im LXC-Format sein und somit eine Virtualisierungslösung sein, die direkt im Linux- Kernel implementiert ist. Möglich sind auch Umgebungen im Do ¬ cker-Format oder LXD-Format, also Container, die ihrerseits LXC-Container verwenden. Weiter ist es vorteilhaft, wenn die virtuellen Umgebungen jeweils eine eigene IP-Adresse aufweisen, die dann jeweils in einer Hardware-Anschaltung eines Hosts des Servers verzeichnet sein können. In einem Schienenfahrzeug für den Personenverkehr müssen eine Vielzahl von Daten in Echtzeit verschickt werden. Beispiels ¬ weise müssen Steuersignale zum Abbremsen des Fahrzeugs von einem Fahrstand des Schienenfahrzeugs zu Bremssteuergeräten des Schienenfahrzeugs übertragen werden. Da es in einem

Ethernet zu zeitlichen Verzögerungen kommen kann, sind die Geräte in einer vorteilhaften Weiterbildung der Erfindung über einen Feldbus mit einem Laufzeitsystem des Fahrzeugs verbunden. Über den Feldbus können Steuerdaten, aber auch Messsignale, in Echtzeit zu den entsprechenden Steuergeräten beziehungsweise Diagnosegeräten übertragen werden. Das Lauf- zeitsystem kann ein System sein, in dem zumindest im Wesentlichen alle Daten in Echtzeit übertragen werden.

Insofern sind die Geräte zweckmäßigerweise allgemein über ei- nen Feldbus des Netzwerkes ansteuerbar, wobei die Software vom Server über eine Ethernet-Verbindung des Netzwerks auf die Geräte übertragen werden kann. Hierfür können die Geräte zwei Schnittstellen aufweisen, beispielsweise eine Steuerschnittstelle und eine Diagnoseschnittstelle.

Ganz allgemein gesprochen ist es vorteilhaft, wenn das Netzwerk ein echtzeitfähiges Protokoll und ein Ethernet-Protokoll auf einer gemeinsamen Leitung aufweist. Die Kommunikation über die gemeinsame Leitung verläuft also in beiden Protokol- len, zweckmäßigerweise sequentiell. So kann ein Gerät über das echtzeitfähige Protokoll in Echtzeit angesteuert werden, und Software kann über das Ethernet-Protokoll auf das Gerät aufgespielt werden. Das Aufspielen der Software geschieht zweckmäßigerweise in einem Zeitfenster, in dem das echtzeit- fähige Protokoll schweigt.

In einer weiteren vorteilhaften Ausführungsform der Erfindung wird vorgeschlagen, dass die virtuellen Umgebungen jeweils Anweisungen zu einem Übertragungsprotokoll enthalten, nach dem die Software auf das jeweils zugeordnete Gerät übertragen wird. Je nach Gerät beziehungsweise Wandler kann es sinnvoll sein, die Übertragung von Software eher zügig und unkompli- ziert oder eher gesichert vorzunehmen. Wird beispielsweise

Software für eine Anzeige für Passagiere übertragen, zum Bei ¬ spiel ein Update für ein Infotainment-Gerät , so kann dies zü ¬ gig und ohne Sicherheitsüberprüfung erfolgen, da ein Fehler bei der Übertragung sicherheitstechnisch nicht bedenklich ist. Wird hingegen Software für ein Gerät einer Fahrzeugtür übertragen, z.B. eine Schließsteuerung für eine Wagentür, so sollte die Übertragung fehlerfrei erfolgen. Noch kritischer ist beispielsweise ein Update auf einem Gerät eines Fahrzeug ¬ bremssystems. Je nach Anforderung können die Anweisungen zur Übertragung so ausgeführt sein, dass die die Übertragung bei ¬ spielsweise ausreichend gesichert ist.

Hierfür ist es vorteilhaft, wenn das Übertragungsprotokoll Anweisungen zu einem Sicherheitslevel enthält, nach dem die Software auf das jeweils zugeordnete Gerät übertragen wird. Beispiele für solche Sicherheitslevel sind ein einfacher Fi ¬ le-Transfer, eine prüfsummengeschützte Übertragung oder eine zertifikatgeschützte Übertragung . Die Erfindung ist außerdem gerichtet auf ein Schienenfahrzeug mit einem Netzwerk, an das mehrere Geräte und ein Server mit einem Netzwerkdownloaddienst angebunden sind, der Software für die Geräte enthält. Um Software vom Server über das Netzwerk in einfacher Weise auf die Geräte übertragen zu können, wird vorgeschlagen, dass das Netzwerk erfindungsgemäß eine Virtualisierungsplattform mit mehreren virtuellen Umgebungen aufweist. Jeder dieser virtuellen Umgebungen kann einen gerätetypspezifischen Wandler enthalten. Die Wandler können ihrerseits jeweils eine ge- räteseitige Anbindung zu dem Downloaddienst zu dem ihnen zu ¬ geordneten Gerät aufweisen. Es können auf diese Weise mehrere gerätetypspezifische Wandler auf einem Rechner laufen, sodass das Schienenfahrzeug diesbezüglich mit einem geringen Hard ¬ wareaufwand auskommt.

Die Virtualisierungsplattform kann auf einem Server laufen, der mit dem Netzwerk verbunden ist und der vom Netzwerkserver mit dem Netzwerk-Downloaddienst die aufzuspielende Software erhält. Besonders vorteilhaft ist es jedoch, wenn der Server mit dem Netzwerk-Downloaddienst auch die Virtualisierungs ¬ plattform aufweist. Zwei Rechner können zusammengelegt wer- den, und es kann Hardware eingespart werden.

Bei Schienenfahrzeugen für den Personenverkehr sind am Drehgestell eine Vielzahl von Geräten, wie Messmodule und/oder Steuergeräte angeordnet. Die Erfindung ist insofern besonders vorteilhaft anwendbar auf ein Schienenfahrzeug, bei dem die Geräte an einem Drehgestell des Schienenfahrzeugs angeordnet sind. Eine Vielzahl von Geräten am Drehgestell kann auf diese Weise mit einem geringen Hardwareaufwand mit Software ver ¬ sorgt werden.

Die bisher gegebene Beschreibung vorteilhafter Ausgestaltungen der Erfindung enthält zahlreiche Merkmale, die in einigen abhängigen Ansprüchen zu mehreren zusammengefasst wiedergege ¬ ben sind. Diese Merkmale können jedoch zweckmäßigerweise auch einzeln betrachtet und zu sinnvollen weiteren Kombinationen zusammenfasst werden, insbesondere bei Rückbezügen von An ¬ sprüchen, sodass ein einzelnes Merkmal eines abhängigen An ¬ spruchs mit einem einzelnen, mehreren oder allen Merkmalen eines anderen abhängigen Anspruchs kombinierbar ist.

Außerdem sind diese Merkmale jeweils einzeln und in beliebi ¬ ger geeigneter Kombination sowohl mit dem erfindungsgemäßen Verfahren als auch mit der erfindungsgemäßen Vorrichtung ge- maß den unabhängigen Ansprüchen kombinierbar. So sind Verfahrensmerkmale auch als Eigenschaft der entsprechenden Vorrichtungseinheit gegenständlich formuliert zu sehen und funktio ¬ nale Vorrichtungsmerkmale auch als entsprechende Verfahrens- merkmale.

Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung, sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusam- menhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen näher erläutert werden. Die Ausführungsbeispiele dienen der Erläuterung der Erfindung und beschränken die Erfindung nicht auf die darin angegebene Kombination von Merkmalen, auch nicht in Bezug auf funktionale Merkmale. Außerdem können dazu geeignete

Merkmale eines jeden Ausführungsbeispiels auch explizit iso ¬ liert betrachtet, aus einem Ausführungsbeispiel entfernt, in ein anderes Ausführungsbeispiel zu dessen Ergänzung einge ¬ bracht und/oder mit einem beliebigen der Ansprüche kombiniert werden.

Es zeigen:

FIG 1 ein Schienenfahrzeug mit Personenwagen und Drehge- stellen, die eine Vielzahl von Geräten enthalten, die über ein Netzwerk miteinander verbunden sind,

FIG 2 eine Protokollgliederung des Netzwerks in mehrere

Ebenen und einen am Netzwerk angeschlossenen Ser- ver,

FIG 3 eine Virtualisierungsplattform auf dem Server mit mehreren virtuellen Umgebungen und

FIG 4 eine schematische Darstellung der Anordnung von

Server, virtueller Umgebung und Geräten zueinander. zeigt ein Schienenfahrzeug 2 für den Personenverkehr mit mehreren Wagen 4 zur Personenbeförderung, von denen der Übersichtlichkeit halber in FIG 1 nur zwei Wagen 4 darge ¬ stellt sind. Jeder Wagen 4 ist mit zwei Drehgestellen 6 aus ¬ gestattet, die jeweils von zwei Radsätzen 8 getragen werden. An jedem der Drehgestelle 6 sind eine Vielzahl von Geräten 10 vorhanden, beispielsweise Temperatursensoren, Beschleunigungssensoren, ein oder mehrere Drehzahlnehmer und andere Messgeräte sowie Steuergeräte, Aktuatoren und andere Geräte 10.

Die Geräte 10 sind alle mit einem Netzwerk 12 verbunden, das sich durch mehrere Wagen 4 des Schienenfahrzeugs 2 erstreckt, wie in FIG 1 angedeutet ist. Das Netzwerk 12 umfasst eine zentrale Leitung 14, mit der die Geräte 10 physisch über An- bindungsleitungen verbunden sind. Das Schienenfahrzeug 2 ist zusätzlich mit weiteren Geräten 10 ausgestattet, beispiels ¬ weise Mess- und Steuergeräten an jeder Tür, Geräten 10 für die Klimasteuerung, die Motorsteuerung, die Stromversorgung, Infotainment und vieles mehr. Ebenfalls mit dem Netzwerk 12 verbunden ist ein Ein- und Ausgabesystem 16 im Fahrstand des Schienenfahrzeugs 2, über das ein Zugführer wesentliche Fahr ¬ funktionen des Schienenfahrzeugs 2 steuert und überwacht.

FIG 2 zeigt eine Protokollstruktur des Netzwerks 12 in einer schematischen Darstellung. Ein Profinet 18 und ein Feldbus

20, beispielsweise ein CAN-Feldbus, sind Teil eines Laufzeit ¬ systems, über das beispielsweise Steuergeräte 22 in Echtzeit mit Steuerdaten, beispielsweise aus dem Ein- und Ausgabesys ¬ tem 16 im Fahrstand versorgt werden. Die Steuergeräte 22 sind beispielsweise Bremssteuergeräte, die wiederum Bremsaktuato- ren oder Motoren an einem oder mehreren der Drehgestelle 6 über den Feldbus 20 in Echtzeit ansteuern. Weitere Sensorsys ¬ teme 24 können an einem Sensorbus 26 des Netzwerks 12 hängen, der ebenfalls Teil des Laufzeitsystems des Schienenfahrzeugs 2 ist. Die Sensorsysteme 24 können ebenfalls als Geräte 10 entsprechend FIG 1 verstanden werden.

Auf die Geräte 10 soll Software aufgespielt werden, insbeson- dere lauffähige Software, wie ein modifiziertes Messprogramm. Die Geräte 10 umfassen beispielsweise jeweils ein Kopfmodul 30, das an den Feldbus 20 angeschlossen ist, und ein oder mehrere Messmodule 32, die ihrerseits am Kopfmodul 30 ange- schlössen sind. Zwei solche Geräte sind in FIG 2 beispielhaft mit Kopfmodul 30 und Messmodul 32 dargestellt.

Zum Übertragen der Software vom Server 34 auf die Geräte 10 enthält das Netzwerk 12 ein Ethernet 28 mit einem schnellen Protokoll zum Übertragen großer Datenmengen, beispielsweise TCP/IP oder einem anderen nicht echtzeitfähigen Protokoll. Das Ethernet 28 ist über andere Schnittstellen der Geräte 10 mit diesen verbunden, als der Feldbus 20. Beispielsweise wei ¬ sen die Geräte 10 Diagnoseschnittstellen auf, die eine

Schnittstelle zum Ethernet 28 bilden. Das gleiche gilt für die Sensorsysteme 24.

Weiter sind mit dem Netzwerk 12 ein oder mehrere Server 34 verbunden. In FIG 1 sind zwei Server 34 gezeigt, von denen einer Software enthält, die für die Geräte 10 bestimmt ist, und der andere eine Virtualisierungsplattform mit mehreren virtuellen Umgebungen. Ebenfalls ist es möglich, beide Server 34 zu einem Server 34 zusammenzufassen, wie dies in FIG 2 angedeutet ist. Dieser Server 34 enthält sowohl die für Geräte 10 bestimmte Update-Software, als auch eine

Virtualisierungsplattform mit mehreren virtuellen Umgebungen. Der Server 34 und die Geräte 10 kommunizieren über das Ethernet 28 zur Übertragung der Software vom Server 34 auf eins oder mehrere der Geräte 10.

FIG 3 zeigt den Server 34 mit einer in ihm ausgebildeten Virtualisierungsstruktur in einer schematischen Darstellung. Der Server 34 enthält Hardware 36, auf der ein LINUX-Kernel 38 aufgesetzt ist. Auf einer darüber liegenden Ebene liegt ein Host-Betriebssystem 40 und eine Virtualisierungsplattform 42, die den Datenraum für mehrere virtuelle Umgebungen 44, die jeweils einen Wandler 46 enthalten, zur Verfügung stellt. Die virtuellen Umgebungen 44 sind LXC Linux-Container, die neben Verzeichnissen und Bibliotheken auch eine eigene IP- Adresse aufweisen, die jeweils in einer Hardware-Anschaltung des Hosts des Servers 34 verzeichnet sind. In den einzelnen Containern beziehungsweise virtuellen Umgebungen 44 laufen Wandler 46 in Form von Anwendungen, die von Lieferanten der Geräte 10 bereitgestellt wurden. Die Wandler 46 umfassen beispielsweise geräteseitige Anbindungen für ei ¬ nen Downloaddienst des Software-Servers 34, einen Webserver und gegebenenfalls die Implementierung für den Downloaddienst in Hardware-Module.

Die Wandler 46 sind gerätespezifische Wandler 46, wobei für mehrere Gerätetypen mehrere Wandler 46 in der Weise vorhanden sind, dass für jeden Gerätetyp ein gerätetypspezifischer

Wandler 46 vorhanden ist. Jeder Wandler 46 hat einen eigenen gerätespezifischen Downloaddienst, der die Umsetzung der Übertragung vom Server-Downloaddienst auf den gerätespezifischen Downloaddienst übernimmt. Hierfür hat jeder Wandler 46 eine geräteseitige Anbindung für den Server-Downloaddienst beziehungsweise Netzwerk-Downloaddienst, sodass ein Software ¬ download vom Software-Server 34 auf das entsprechende Gerät 10 über den Wandler 46 mit seinem gerätespezifischen Downloaddienst ablaufen kann.

FIG 4 zeigt eine schematische Darstellung einer Anordnung mit Server 34, virtueller Umgebungen 44 mit Wandler 46 und Gerät 10. Der Server 34 enthält einen Downloaddienst 48, der mit einer Vielzahl von virtuellen Umgebungen 44 verbunden ist. Diese Verbindungen 50 sind in FIG 4 symbolisch als viele Lei ¬ tungen dargestellt, wobei die Verbindungen 50 üblicherweise über eine physische Leitung 14 erfolgen und durch verschiede ¬ ne Adressierungen hergestellt werden. Die virtuellen Umgebungen 44 enthalten jeweils ihren Wandler 46 und Anweisungen 52 zu einem Übertragungsprotokoll, nach dem die Software auf das jeweils zugeordnete Gerät 10 zu übertragen ist. Die Anweisun ¬ gen 52 beinhalten ein Sicherheitslevel, beispielweise, ob ein einfacher File-Transfer, eine prüfsummengeschützte Übertra- gung oder eine zertifikatgeschützte Übertragung erfolgt.

Zusätzlich zu dem Gerät 10 ist ein gerätespezifischer Downloaddienst 54 vorhanden, der Teil des Geräts 10 sein kann oder in der virtuellen Umgebung 44 enthalten ist, wie durch die gestrichelten Linien des Geräts 10 bzw. der virtuellen Umgebung 44 angedeutet ist, sodass also entweder die gestri ¬ chelte Linie des Geräts 10 oder die der virtuellen Umgebung 44 die aktuelle Konfiguration anzeigt.