WO2018054680A1 - Verfahren zum betreiben mehrerer geräte unterschiedlichen typs an einem netzwerk eines schienenfahrzeugs - Google Patents

Verfahren zum betreiben mehrerer geräte unterschiedlichen typs an einem netzwerk eines schienenfahrzeugs Download PDF

Info

Publication number
WO2018054680A1
WO2018054680A1 PCT/EP2017/072197 EP2017072197W WO2018054680A1 WO 2018054680 A1 WO2018054680 A1 WO 2018054680A1 EP 2017072197 W EP2017072197 W EP 2017072197W WO 2018054680 A1 WO2018054680 A1 WO 2018054680A1
Authority
WO
WIPO (PCT)
Prior art keywords
devices
network
software
server
rail vehicle
Prior art date
Application number
PCT/EP2017/072197
Other languages
English (en)
French (fr)
Inventor
Roland Porsch
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2018054680A1 publication Critical patent/WO2018054680A1/de

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0081—On-board diagnosis or maintenance
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0018—Communication with or on the vehicle or train
    • B61L15/0036—Conductor-based, e.g. using CAN-Bus, train-line or optical fibres
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/022—Multivendor or multi-standard integration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40293—Bus for use in transportation systems the transportation system being a train

Definitions

  • the invention relates to a method for operating a plurality of devices of different types on a network of a rail vehicle, in which software is transmitted from a server to the devices via the network.
  • Modern rail vehicles for passenger transport have a variety of devices that are controlled from the outside or outside data, such as measured data, leave.
  • the devices are connected to a network, with which also corresponding control and evaluation devices are connected for controlling or evaluating the devices.
  • the software is made available via a server with a download service on the network and fed via the network to the devices.
  • Such devices generally have an Ethernet interface, for example ei ⁇ ne diagnostic interface via which an internal Download- is service made available. This is tailored to the subsystem and able to download incoming software and make it available to the subsystem.
  • Virtualization platform with multiple virtual environments connected to the network each of which Type-specific converter contains.
  • a software transfer can be made in this way by a download service of the server to the devices in each case via the converter associated with the respective device. The latter can then transfer the transmission from the download service to a device-specific download service.
  • the invention is based on the idea that software is often on devices of a rail vehicle for personal transportation to be transmitted restrictive software that is adapted to the rail running ⁇ convincing itself or properties of the network and other devices of the rail vehicle.
  • a Profibus is suitable, for example, which has a corresponding download service on a server of the rail vehicle.
  • the intra-server download service must be supported by the subsys- tem proprietary download service of the unit who ⁇ .
  • Virtualization platform is the possibility on one Computer to set up multiple virtual environments, each containing a device-type converter.
  • Each device or device type is associated with a virtual environment with a device ⁇ type-specific converter that performs the implementation of the server-internal download service on the proprietary download service of the device or device type.
  • the transducer can be provided by the equipment supplier. It can hereby waived both to equipment of all devices to the appropriate download service as well as to connected and additional computers in the rail vehicle who ⁇ .
  • the device-specific download service can be located locally in the device and connected to the converter.
  • the different devices can thus each contain a device-specific download service, whereby the download services of the different device types are different.
  • the adaptation of the download service of the server to the device-specific download services is made by the converter in the virtual environment.
  • the device-specific download service is also located in the virtual environment.
  • each device type has its own virtual environment with its own device-specific download service.
  • Each converter can each have a device-side connection for the network download service.
  • the virtual environments are each Linux container, wherein expediently each container contains one of the device-specific converter.
  • the Linux container can be in LXC format and thus a virtualization solution that can be used directly in the Linux Kernel is implemented.
  • the virtual environments each have their own IP address, which can then each be recorded in a hardware connection of a host of the server.
  • Example ⁇ as control signals for braking the vehicle must be transmitted from a control position of the rail vehicle to the brake control devices of the rail vehicle. Because it is in one
  • Ethernet can come to time delays, the devices are connected in an advantageous embodiment of the invention via a fieldbus with a runtime system of the vehicle.
  • Control data but also measurement signals, can be transmitted in real time to the corresponding control devices or diagnostic devices via the fieldbus.
  • the runtime system can be a system in which at least substantially all data is transmitted in real time.
  • the devices are expediently generally accessible via a field bus of the network, wherein the software can be transmitted from the server to the devices via an Ethernet connection of the network.
  • the devices can have two interfaces, for example a control interface and a diagnostic interface.
  • the network has a real-time protocol and an Ethernet protocol on a common line.
  • the communication via the common line thus runs in both protocols, expediently sequentially.
  • a device can be controlled in real time via the real-time protocol, and software can be uploaded to the device via the Ethernet protocol.
  • the software is played expediently in a time window in which the real-time protocol is silent.
  • the virtual environments each contain instructions for a transmission protocol according to which the software is transmitted to the respectively assigned device.
  • the software may make sense to carry out the transfer of software rather quickly and easily or more securely.
  • Transfer software for a display for passengers to play ⁇ In an update to an infotainment device, this can be done IG ⁇ gig and without security clearance because an error in transmission is not critical to safety. If, on the other hand, software for a device of a vehicle door is transmitted, for example a closing control for a car door, then the transmission should take place without errors. Even more critical, for example, an update on a device of a vehicle brake system ⁇ . Depending on requirements, the instructions may be executed for the transmission so that the transmission is play sufficiently secured at ⁇ .
  • the transmission protocol contains instructions for a security level, after which the software is transmitted to the respectively assigned device.
  • security levels are a simple Fi ⁇ le transfer, a checksum protected transmission or a certificate-protected transmission.
  • the invention is also directed to a rail vehicle having a network to which a plurality of devices and a server are connected with a network download service containing software for the devices.
  • the network according to the invention comprises a virtualization platform with multiple virtual environments.
  • Each of these Virtual Environments may include a device-type converter.
  • the transducers may in turn to each comprising a device-side connection to the download service them ⁇ parent device. It can run in this way, a plurality of device-specific converter on a computer, so that the rail vehicle in this respect requires only a small amount of hardware ⁇ effort.
  • the virtualization platform can run on a server that is connected to the network and receives the software to be played by the network server with the network download service.
  • the server with the network download service also has the virtualization ⁇ platform. Two computers can be combined and hardware can be saved.
  • a large number of devices such as measuring modules and / or control devices, are arranged on the bogie.
  • the invention is particularly advantageous applicable to a rail vehicle, in which the devices are arranged on a bogie of the rail vehicle.
  • a variety of devices on the bogie can in this way with a small amount of hardware with software ver ⁇ provides.
  • FIG. 1 shows a rail vehicle with passenger cars and bogies, which contain a plurality of devices which are connected to each other via a network
  • 3 shows a virtualization platform on the server with several virtual environments
  • FIG. 1 shows a rail vehicle 2 for passenger transport with several cars 4 for passenger transport, of which for the sake of clarity in FIG 1 only two cars 4 Darge ⁇ represents are.
  • Each carriage 4 is allowed with two bogies 6 ⁇ , which are each supported by two sets of wheels 8.
  • a plurality of devices 10 are present, such as temperature sensors, acceleration sensors, one or more speed sensors and other measuring devices and control units, actuators and other devices 10th
  • the devices 10 are all connected to a network 12 which extends through a plurality of carriages 4 of the rail vehicle 2, as indicated in FIG.
  • the network 12 includes a central line 14 to which the devices 10 are physically connected via attachment lines.
  • the rail vehicle 2 is additionally equipped with other devices 10, example ⁇ measuring and control devices on each door, devices 10 for climate control, engine control, power supply, infotainment and much more.
  • Also connected to the network 12 is an input and output system 16 in the control station of the rail vehicle 2, via which a train driver controls essential driving ⁇ functions of the rail vehicle 2 and monitors.
  • FIG. 2 shows a protocol structure of the network 12 in a schematic representation.
  • control devices 22 are part of a runtime ⁇ system over which, for example, control devices 22 are supplied in real time with control data, for example from the input and Ausgabesys ⁇ tem 16 in the control station.
  • the control devices 22 are, for example, brake control devices which in turn actuate brake actuators or motors on one or more of the bogies 6 via the field bus 20 in real time.
  • More Sensorsys ⁇ systems 24 may be attached to a sensor bus 26 of the network 12, which is also part of the runtime system of the rail vehicle 2.
  • the sensor systems 24 can also be understood as devices 10 according to FIG.
  • the devices 10 should be installed on the devices 10, in particular such executable software as a modified measuring program.
  • the devices 10 comprise, for example, in each case a head module 30 which is connected to the field bus 20, and one or more measurement modules 32, which in turn are connected to the head module 30. Two such devices are shown in FIG. 2 by way of example with head module 30 and measuring module 32.
  • the network 12 includes an Ethernet 28 with a high-speed protocol for transferring large amounts of data, such as TCP / IP or other non-real-time protocol.
  • the Ethernet 28 is connected via other interfaces of the devices 10 with these, as the field bus 20.
  • the devices wei ⁇ sen 10 diagnostic interfaces, the one
  • one or more servers 34 are connected to the network 12. 1 shows two servers 34, one containing software intended for the devices 10 and the other a virtualization platform with multiple virtual environments. It is also possible to combine both servers 34 to form a server 34, as indicated in FIG. This server 34 contains both the specific software for 10 update software, as well as a
  • Virtualization platform with multiple virtual environments The server 34 and the devices 10 communicate over the Ethernet 28 to transfer the software from the server 34 to one or more of the devices 10.
  • the server 34 includes hardware 36 on which a LINUX kernel 38 is mounted.
  • a host operating system 40 On an upper level there is a host operating system 40 and a virtualization platform 42, which provides the data space for multiple virtual environments 44, each containing a converter 46.
  • the virtual environments 44 are LXC Linux containers that in addition to directories and libraries also have their own IP address, which are each recorded in a hardware interface of the host of the server 34.
  • transducers 46 run in the form of applications provided by suppliers of the devices 10.
  • the transducer 46 for example, device-side connections for egg ⁇ NEN software download service of the server 34, a web server and, if the implementation of the download service in hardware modules.
  • the transducers 46 are device-specific transducers 46, with multiple transducers 46 being provided for multiple device types in such a way that for each device type a device-type specific one
  • Converter 46 is present. Each converter 46 has its own device-specific download service, which handles the implementation of the transfer from the server download service to the device-specific download service. For this purpose, each converter 46 has a device-side connection for the server download service or network download service, so that a software download ⁇ can run from the software server 34 to the corresponding device 10 via the converter 46 with its device-specific download service.
  • FIG 4 shows a schematic representation of an arrangement with server 34, virtual environments 44 with converter 46 and device 10.
  • the server 34 contains a download service 48, which is connected to a plurality of virtual environments 44.
  • These compounds 50 are symbolically represented in FIG 4 as many Lei ⁇ obligations, wherein the connections 50 typically take place via a physical line 14 and are prepared by Various ⁇ ne addressing.
  • the virtual environments 44 each contain their converter 46 and instructions 52 for a transmission protocol according to which the software is to be transmitted to the respectively assigned device 10.
  • the instruc ⁇ gen 52 include a security level, for example, whether a simple file transfer, a transmission prüfsummengetrendte or a certificate-protected transfer.
  • a device-specific download service 54 is provided, which may be part of the device 10 or contained in the virtual environment 44, as indicated by the dashed lines of the device 10 and the virtual environment 44, so that either the gestri ⁇ Smiled line of the device 10 or the virtual environment 44 displays the current configuration.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mechanical Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben mehrerer Geräte unterschiedlichen Typs an einem Netzwerk (12) eines Schienenfahrzeugs, bei dem Software von einem Server (34) über das Netzwerk (12) auf die Geräte übertragen wird. Die Geräte umfassen beispielsweise jeweils ein Kopfmodul (30), das an einen Feldbus (20) angeschlossen ist, und ein oder mehrere Messmodule (32), die ihrerseits am Kopfmodul (30) angeschlossen sind. Sensorsysteme (24) können ebenfalls als Geräte verstanden werden.Zum Einsparen von Hardware im Fahrzeug, die nur zu Servicezwecken verwendet wird, wird vorgeschlagen, dass mit dem Netzwerk (12) eine Virtualisierungsplattform mit mehreren virtuellen Umgebungen verbunden ist, von denen jede einen gerätetypspezifischen Wandler enthält, und eine Softwareübertragung von einem Downloaddienst des Servers (34) auf die Geräte (24; 30, 32) jeweils über den dem jeweiligen Gerät (24; 30, 32) zugeordneten Wandler erfolgt, der die Umsetzung der Übertragung vom Downloaddienst auf einen gerätespezifischen Downloaddienst übernimmt. Ein Profinet (18) und der Feldbus (20), beispielsweise ein CAN-Feldbus, sind Teil eines Laufzeitsystems, über das beispielsweise Steuergeräte (22) in Echtzeit mit Steuerdaten, beispielsweise aus dem Ein- und Ausgabesystem (16) im Fahrstand versorgt werden. Die Steuergeräte (22) sind beispielsweise Bremssteuergeräte, die wiederum Bremsaktuatoren oder Motoren an einem oder mehreren der Drehgestelle über den Feldbus (20) in Echtzeit ansteuern. Die Sensorsysteme (24) können an einem Sensorbus (26) des Netzwerks (12) hängen, der ebenfalls Teil des Laufzeitsystems des Schienenfahrzeugs (2) ist. Zum Übertragen der Software vom Server (34) auf die Geräte (24; 30, 32) 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 (24; 30, 32) mit diesen verbunden, als der Feldbus (20). Beispielsweise weisen die Geräte (24; 30, 32) Diagnoseschnittstellen auf, die eine Schnittstelle zum Ethernet (28) bilden.

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.

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.
PCT/EP2017/072197 2016-09-26 2017-09-05 Verfahren zum betreiben mehrerer geräte unterschiedlichen typs an einem netzwerk eines schienenfahrzeugs WO2018054680A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016218429.6 2016-09-26
DE102016218429.6A DE102016218429A1 (de) 2016-09-26 2016-09-26 Verfahren zum Betreiben mehrerer Geräte unterschiedlichen Typs an einem Netzwerk eines Schienenfahrzeugs

Publications (1)

Publication Number Publication Date
WO2018054680A1 true WO2018054680A1 (de) 2018-03-29

Family

ID=59846570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/072197 WO2018054680A1 (de) 2016-09-26 2017-09-05 Verfahren zum betreiben mehrerer geräte unterschiedlichen typs an einem netzwerk eines schienenfahrzeugs

Country Status (2)

Country Link
DE (1) DE102016218429A1 (de)
WO (1) WO2018054680A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111301487A (zh) * 2020-03-18 2020-06-19 中车资阳机车有限公司 一种交流传动内燃机车牵引电机力矩超限值报警***
CN113002591A (zh) * 2021-04-13 2021-06-22 株洲中车时代电气股份有限公司 一种混合式列车网络及包含其的列车

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018209797A1 (de) * 2018-06-18 2019-12-19 Siemens Mobility GmbH Verwendung eines Mehradernkabels mit vier jeweils verdrillten Adernpaaren, welche gegeneinander geschirmt sind, oder eines Lichtleitkabels als Verkabelung für ein Schienenfahrzeug und Schienenfahrzeug
FR3096951B1 (fr) * 2019-06-05 2021-10-29 Alstom Transp Tech Système de communication de données pour véhicule ferroviaire

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014214225A1 (de) * 2014-07-22 2015-07-02 Siemens Aktiengesellschaft Schienenfahrzeug mit einer Datenkommunikationseinrichtung

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007030396B4 (de) 2007-06-29 2014-11-27 Trumpf Werkzeugmaschinen Gmbh + Co. Kg Vorrichtung zur Steuerung einer Maschine sowie Fernkommunikationssystem
DE102009026807A1 (de) 2009-06-08 2010-12-09 Robert Bosch Gmbh Verfahren und Vorrichtung zur Fehlerüberwachung eines mehrere Anlagen aufweisenden Gesamtsystems
US8418166B2 (en) 2011-01-11 2013-04-09 International Business Machines Corporation Transparent update of adapter firmware for self-virtualizing input/output device
ES2579480T3 (es) 2011-05-26 2016-08-11 Siemens Aktiengesellschaft Procedimiento para el acceso a un sistema de automatización, así como sistema de funcionamiento según el procedimiento
US8973124B2 (en) 2012-04-30 2015-03-03 General Electric Company Systems and methods for secure operation of an industrial controller

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014214225A1 (de) * 2014-07-22 2015-07-02 Siemens Aktiengesellschaft Schienenfahrzeug mit einer Datenkommunikationseinrichtung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MATT HELSLEY: "LXC: Linux container tools", IBM DEVELOPERWORKS, 3 February 2009 (2009-02-03), pages 1 - 10, XP055217383, Retrieved from the Internet <URL:http://www.ibm.com/developerworks/library/l-lxc-containers/l-lxc-containers-pdf.pdf> [retrieved on 20150930] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111301487A (zh) * 2020-03-18 2020-06-19 中车资阳机车有限公司 一种交流传动内燃机车牵引电机力矩超限值报警***
CN113002591A (zh) * 2021-04-13 2021-06-22 株洲中车时代电气股份有限公司 一种混合式列车网络及包含其的列车

Also Published As

Publication number Publication date
DE102016218429A1 (de) 2018-03-29

Similar Documents

Publication Publication Date Title
WO2018054680A1 (de) Verfahren zum betreiben mehrerer geräte unterschiedlichen typs an einem netzwerk eines schienenfahrzeugs
DE102012102173B4 (de) Re-konfigurierbare Schnittstellen-basierende elektrische Architektur
EP2705430A1 (de) System zur diagnose einer komponente in einem fahrzeug
EP2631878A1 (de) Diagnoseverfahren und Diagnosevorrichtung für eine Fahrzeugkomponente eines Fahrzeugs
DE112012007250T5 (de) Fahrzeuginterne Vorrichtung und Programm
WO2003052531A2 (de) Kraftfahrzeugsteuersystem und verfahren zur kraftfahrzeugsteuerung
DE112018001894T5 (de) Steuervorrichtung, Übertragungsverfahren und Computerprogramm
DE102012202540A1 (de) Diagnoseverfahren und Diagnosevorrichtung für eine Fahrzeugkomponente eines Fahrzeugs
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
EP3692390A1 (de) Radarzielemulator, prüfstand und verfahren zur signalverarbeitung
DE102015215480A1 (de) Verfahren und Vorrichtung zum Übertragen einer Nachricht in einem Fahrzeug
DE102009007426A1 (de) Verfahren zur Fahrzeugdiagnose und Anpassung von Steuerungsabläufen bei Flurförderzeugen
DE102013205390A1 (de) Datenausgabevorrichtung für ein fahrzeug
DE102021104420A1 (de) Verfahren zum Betreiben eines Bordnetzes, Bordnetz, und Steuergerät
EP2870726B1 (de) Verfahren zur inbetriebnahme zumindest eines funktionsgeräts und schienenfahrzeugsverband
DE102013213856A1 (de) Vorrichtung, Verfahren und System zur Kommunikation mit einer Steuerungseinrichtung eines Kraftfahrzeugs
DE10357118A1 (de) Laden von Software-Modulen
EP4003823B1 (de) Verfahren zum initialisieren eines kraftfahrzeugs
DE102012216391A1 (de) Kommunikation zwischen Wagen eines Schienenfahrzeugs
DE102021104422A1 (de) Verfahren zum Betreiben eines Kommunikationssystems, Kommunikationssystem und Rechensystem
EP2501596A1 (de) Kraftfahrzeugsteuerungssystem
EP4004518A1 (de) Verfahren zum testen eines kraftfahrzeugs
DE102019132428A1 (de) Funktionsorientierte Elektronik-Architektur
DE102018119422A1 (de) Elektrische servolenkungssysteme und verfahren
DE102021104421A1 (de) Verfahren zum Betreiben eines Bordnetzes, Bordnetz, und Rechensystem

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17764794

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17764794

Country of ref document: EP

Kind code of ref document: A1