DE102021128637A1 - Gateway and method for connecting a terminal to a bus - Google Patents

Abstract

A gateway for connecting a terminal device to a bus is disclosed, preferably a bus of a vehicle, particularly preferably a bus of a rail vehicle. This gateway (4) comprises: a bus-side connection (6) designed to connect to the bus (2) and to exchange data with the bus (2), a terminal-side connection (7) designed to connect to the terminal (5) and is designed to exchange data with the terminal (5),a message memory (9) in which a representation of a plurality of permitted messages is stored, with a permitted message each defining which specific character/which specific character string for a Further processing is to be considered permitted, a filter unit (8) which is connected in a communicating manner to the bus-side connection (6), the terminal-side connection (7) and the message memory (9) and which is designed to connect to the terminal-side connection (7) to compare received data with at least one of the permitted messages from the message memory (9) and to further process the received data for output to the bus-side connection (6) only if the received data match one of the several permitted messages. It is also a corresponding method disclosed.

Description

The invention relates to a gateway and a method for connecting a terminal device to a bus, preferably a vehicle bus, particularly preferably a rail vehicle bus.

Data buses are used to exchange data between several bus participants. The data is encoded in bus signals and the bus signals are transmitted via a bus medium (copper cable, fiber optic cable, etc.). The bus medium is usually accessed using TDMA - Time Division Multiple Access - which is why only one participant is allowed to send data to the data bus at a time. Otherwise, the bus signals of the various sending participants overlap and the data transmissions can interfere with each other. With some bus technologies, a master assigns transmission authorization to the participants. This can be done by enabling individual bus accesses, by allocating fixed time slots for the participants, by allocating transmission channels and/or the like. With other bus technologies, devices listen into the bus and start sending when no bus activity is detected. As soon as a collision of data transmissions from several participants is possible, mechanisms for collision detection are common. If a collision is detected, a suitable response is made to the detected collision, for example the transmission process is aborted and restarted at a later point in time.

Since a single non-compliant participant - depending on the design of the data bus - can disrupt the entire communication over the bus, it is important that each participant on the bus adheres to the respective specifications, for example specific time specifications for sending bus signals in the bus stops. The higher the safety requirements for communication via the bus, the more important it is to comply with the specifications. Such safety-related buses are used in vehicles, for example. Subscribers that are to be connected to such a data bus therefore usually have to go through a complex certification process before they are approved for operation on the data bus. The certification effort is particularly high for rail vehicles.

In the case of many data buses, these requirements only apply to participants who are to send data onto the bus. Eavesdropping is usually not a problem, since eavesdropping usually does not impair bus communication or at most negligibly impairs it. Such a participant thus has no, or at most very little, repercussion on the bus. In this context, reference is regularly made to “non-reactivity”. Correspondingly, in the case of eavesdropping participants, certification can be dispensed with or significantly simplified by, for example, merely proving that the participant has no reaction on the bus.

In practice, however, such eavesdropping participants cannot always be used, since these participants are always dependent on the required information actually being communicated via the bus. If required information is only transmitted via the bus upon request from a bus user, for example status information or error messages within a bus user, purely listening users fail and a user requiring certification with active bus communication must be used. Due to the certification effort, however, the possibilities are limited to a few end devices, so that the possibilities are generally few. Another problem is that even a small change to an end device, such as replacing a processor or a software update, can lead to a loss of certification and make re-certification necessary. As a result, these approaches are not only expensive, but also inflexible and limited in their options.

The object of the invention is to provide a gateway and a method with which a terminal device can be connected to a bus universally and with little effort, without jeopardizing the stability of the bus and the communication on this bus. It is advantageous if the need for recertification can be avoided when there is a change to the end device.

• einen busseitigen Anschluss, der zum Verbinden mit dem Bus und zum Austauschen von Daten mit dem Bus ausgebildet ist,
• einen endgeräteseitigen Anschluss, der zum Verbinden mit dem Endgerät und zum Austauschen von Daten mit dem Endgerät ausgebildet ist,
• einen Nachrichtenspeicher, in dem eine Repräsentation von mehreren erlaubten Nachrichten gespeichert ist, wobei eine erlaubte Nachricht jeweils definiert, welches konkrete Zeichen/welche konkrete Zeichenfolge für eine Weiterverarbeitung als erlaubt gelten soll,
• eine Filtereinheit, die jeweils kommunizierend mit dem busseitigen Anschluss, dem endgerätseitigen Anschluss und dem Nachrichtenspeicher verbunden ist und die dazu ausgebildet ist, an dem endgeräteseitigen Anschluss empfangene Daten mit mindestens einer der erlaubten Nachrichten aus dem Nachrichtenspeicher zu vergleichen und lediglich bei Übereinstimmung der empfangenen Daten mit einer der mehreren erlaubten Nachrichten die empfangenen Daten für eine Ausgabe an den busseitigen Anschluss weiterzuverarbeiten.

This problem is solved by a gateway with the features of claim 1. Accordingly, the gateway in question comprises:

• a bus-side connection designed to connect to the bus and to exchange data with the bus,
• a connection on the terminal device side, which is designed to connect to the terminal device and to exchange data with the terminal device,
• a message memory in which a representation of several permitted messages is stored, with each permitted message defining which specific character/which specific character string is to be considered permitted for further processing,
• a filter unit which is connected in a communicating manner to the bus-side connection, the terminal-side connection and the message memory and which is designed to compare data received at the terminal-side connection with at least one of the permitted messages from the message memory and only if the received data match one of the several permitted messages to further process the received data for output to the connection on the bus side.

• Empfangen von Daten von dem Endgerät über einen endgerätseitigen Anschluss des Gateways,
• Laden mehrerer erlaubter Nachrichten aus einem Nachrichtenspeicher, wobei eine erlaubte Nachricht jeweils definiert, welches konkrete Zeichen/welche konkrete Zeichenfolge für eine Weiterverarbeitung als erlaubt gelten soll,
• Vergleichen der empfangenen Daten mit zumindest einer der mehreren erlaubten Nachrichten und
• Weiterverarbeiten der empfangenen Daten für eine Ausgabe an den busseitigen Anschluss durch eine Filterschaltung des Gateways, wenn die empfangenen Daten mit einer der mehreren erlaubten Nachrichten übereinstimmt.

With regard to a method, this object is achieved by the features of claim 11. After that, the procedure includes the steps:

• receiving data from the terminal via a terminal-side connection of the gateway,
• Loading several permitted messages from a message memory, with each permitted message defining which specific character/which specific character string should be considered permitted for further processing,
• Comparing the received data with at least one of the multiple allowed messages and
• Further processing of the received data for an output to the bus-side connection by a filter circuit of the gateway if the received data matches one of the multiple permitted messages.

Further, particularly advantageous configurations are disclosed in the respective dependent claims.

It should be pointed out that the features listed individually in the claims can be combined with one another in any technically sensible way (even across category boundaries, for example between method and device) and show further refinements of the invention. The description additionally characterizes and specifies the present disclosure, in particular in connection with the figures.

It should also be noted that a conjunction "and/or" used herein, standing between two features and linking them to one another, must always be interpreted in such a way that in a first embodiment of the described subject matter only the first feature can be present, in a second embodiment only that second feature may be present and in a third embodiment both the first and the second feature may be present.

In addition, it should be noted that the terms “bus” and “data bus” are used as synonyms in the present description. The use of one or the other term does not imply a difference between the properties described.

It has been recognized that it is not absolutely necessary to switch to a bus subscriber with extensive communication capabilities if a purely listening bus subscriber is not sufficient for an application scenario. Rather, it is often sufficient if a bus user has rudimentary communication skills. In such cases, a set of a few to a few tens of messages, which must be sent by the bus subscriber, is usually sufficient. Such messages can, for example, be requests to a bus user x or to several or all bus users, such as "give me data", "give me error messages" or "give me status information". Therefore, the messages that can be sent can be limited, which can significantly reduce the possibility of a feedback in the bus and thus in turn a certification effort.

So that there is as much flexibility as possible with regard to the terminal devices that can be used, a gateway is used according to the present disclosure, which monitors the communication between the terminal device and the bus at least to a certain extent and ensures compliant communication with the bus. For this purpose, the gateway has a filter unit, which can check data sent out by a connected terminal device and monitor compliance with permissible communication. As a result, the communication of the end device in the direction of the bus can be limited to the messages permitted in each case. In this way, the reaction of a terminal device on the bus can be controlled in such a way that non-critical states of the bus can remain guaranteed almost independently of the terminal device used.

In addition to the filter unit, such a gateway has a bus-side connection, a terminal-side connection and a message memory. The connection on the bus side and the connection on the terminal device side are designed to connect and exchange data with the bus or the terminal device, whereby the gateway is connected between the terminal device and the bus and can control the bus communication. The filter unit is coupled between the bus-side connection and the terminal-side connection and is connected in a communicating manner to the bus-side connection and the terminal-side connection. This connection can be direct, ie without any additional components between the connection and the filter unit. However, other units can also be interposed between the connection and the filter unit, such as filters, insulating elements for isolating voltage potentials, transceiver modules, interface converters and/or the like. The filter unit is designed to evaluate data received at the terminal-side connection and to initiate an output at the bus-side connection depending on a result of the evaluation. When evaluating the data, the filter unit accesses the message memory and reads out "permitted messages" that are stored there.

An "allowed message" is a representation of content allowed for communication on the bus. What is allowed should usually have been defined beforehand and checked as non-critical messages, for example during a certification process. In this case, permitted messages can include, for example, requests that have no influence on the status of other bus users, since, for example, no data is changed at other bus users. What is specifically permitted may depend on the respective bus system and/or the respective application scenario.

Permitted content can also be represented in different ways. The representation can specify in detail what a permitted message should look like. This can go as far as the individual bits of the message. However, the representation can also specify only individual details of a message that allow the data received by the terminal to be recognized as a permitted message. However, it is important that the representation of permitted content defines which specific character/characteristic is to be considered permitted for further processing. The mechanisms commonly used, for example, in the content filters of Ethernet firewalls, with which specific website content to be blocked can be abstractly defined, usually do not meet these requirements.

A "concrete character" or "concrete character string" can be defined in many different ways. It is important that the specific character / the specific character string allows a clear distinction between a permitted message. How this goal is achieved is not critical to the present disclosure. A concrete character can be formed by a sequence of bits or bytes. However, specific numbers, specific letters, specific codes that can be interpreted as a command on the bus, and/or specific signal patterns can also function as "specific characters" or "specific character strings". This short, non-exhaustive or limiting list shows how universal this concept is. If messages are transmitted over the bus in packets, the specific character or character string can describe an entire packet. However, it is also conceivable that only the user data of a packet, i.e. without header information, define a permitted message.

If the filter unit receives data from a connected terminal and is to evaluate it, the filter unit loads one or more of the permitted messages from the message memory and compares the received data with one or more of the permitted messages. If the received data is evaluated as permitted after comparison with one of the permitted messages, a comparison with other permitted messages can be dispensed with. However, it is also conceivable that the filter unit has to compare received data with all permitted messages stored in the message memory since, for example, the received data cannot be qualified as “permitted”.

The received data can also be compared with a permitted message in a wide variety of ways. Last but not least, the design of this step also depends on how a permitted message is represented and stored in the message memory. This step was intended to detect whether received data can be qualified as "allowed" or not. In one embodiment, a comparison includes a comparison of the received data and the representation of the permitted message. This can include, for example, comparing the received data bit-by-bit or byte-by-byte with a specific character/a specific character string.

However, regardless of its specific form, the comparison should usually lead to the binary result. This means that a match between the received data and one of the several permitted messages is recognized and the received data is thus qualified as "permissible" or "allowed", or no match can be found, so that the received data is qualified as "not allowed" or "not allowed". If there is a match, the filter unit would trigger further processing of the received data for output to the connection on the bus side. Without a match, there would be no output. In this case, for example, the received data can be discarded or a response can be output to the connection on the terminal device side, with which the terminal device is signaled that transfer to the bus has not taken place.

The gateway can be implemented in different ways. In one embodiment, the gateway is implemented using pure hardware or pure software. In another embodiment, the gateway is implemented using a combination of software and hardware. For example, a microprocessor, a microcontroller and/or a programmable logic circuit can be used, with the programmable logic circuit being able to include, for example, an FPGA—Field Programmable Gate Array—, an ASIC—Application Specific Integrated Circuit—or a CPLD—Complex Programmable Logic Device .

Likewise, the “message store” can be implemented in a wide variety of ways. As long as the message store is capable of storing a representation of allowed messages, that message store may be used in connection with the present disclosure. It can be seen that this requirement can be met by a wide variety of memories. Volatile memory can be used as well as non-volatile memory. RAM (Random Access Memory), MRAM (Magnetoresistive Random Access Memory), EEPROM (Electrically Erasable Read Only Memory) or flash memory may be referred to by way of example only. If a RAM is used, its memory content can be secured via a buffer element, for example a gold cap (or some other capacitor), a battery or an accumulator.

The gateway according to the present disclosure can be used in connection with a wide variety of buses and a wide variety of end devices. The only important thing here is that the gateway, the terminal device and the bus can work together as a system and the terminal device can exchange data with the bus via the gateway. Here, too, it can be seen that this requirement can be met by a wide variety of buses and a wide variety of end devices. The present disclosure is likely to be particularly useful in connection with buses in vehicles, which is why the bus is a vehicle bus in one embodiment and a rail vehicle bus in another embodiment. A data logger, a personal computer, a mobile device such as a laptop, a smartphone or a tablet, a control device or a single-board computer such as a Raspberry Pi can be considered as a terminal device, for example, to name just a few conceivable terminal devices in a non-exhaustive manner and not to mention a limiting way.

In general, it can be seen that the gateway according to the present disclosure enables a universal yet secure connection of a terminal device to a bus with little effort. If certification is required for operation on a bus, it is sufficient to certify the gateway. This is because the gateway can control the entire communication from the terminal device to the bus, so that any feedback on the bus is largely independent of the terminal device used in each case. In addition, what is specifically permitted can be described positively. As a result, any changes to the terminal device are not critical for the operation of the terminal device on the bus, since the gateway can prevent changes in the terminal device from affecting the bus. This in turn can result in a significant reduction in the cost of the terminals and their operation on the bus.

In one embodiment, the gateway can be in the form of a separate device, which is arranged in its own housing, for example, and has its own power supply. In another embodiment, the gateway is designed as a module that is built into another device as an assembly and/or is supplied with energy by this other device. The terminal-side connection can also be designed as an “internal” connection. This also allows the gateway to be retrofitted into an existing end device, thereby enabling subsequent operation on a bus.

In one refinement, the filter unit is additionally designed to output the received data essentially unchanged to the bus-side connection during further processing of received data. Since the filter unit has previously determined that the received data contains a permitted message, the operational security of the bus can be maintained without the filter unit or another component of the gateway having to carry out extensive further steps and/or extensive changes to the received data .

In one embodiment, the filter unit is additionally designed to convert the received data into a predefined bus message based on a correspondence assignment and output it to the bus-side connection when receiving data is further processed, with the correspondence assignment preferably taking place using an assignment table. In this way, admissible communication can be guaranteed even more reliably. Furthermore, the communication between terminal and gateway can be reduced to a minimum. For example, it is conceivable that the end device only sends a kind of "stimulus message" to the gateway, such as "1", "2", "A" or "-". The correspondence assignment then defines in which bus message the respective stimulus message is to be converted. This assignment can be implemented particularly easily in a table. In this embodiment, the end device then sends, for example, only a “3”, possibly together with address information of a requested bus user, to the gateway. There the stimulus message is converted into a bus message, for example in "Give me data", "Give me error messages" or "End of block". This bus message is then sent out by the filter unit, possibly via other components.

In one embodiment, the filter unit is additionally designed to receive data from the connection on the bus side and forward it to the connection on the terminal device side and output it, preferably without filtering. In this way, a listening operation of the terminal can be achieved. Furthermore, in this way a response to data sent by the terminal device can be received without restrictions. Since data reception does not impair the operational reliability of the bus, operational reliability is maintained in this way. It is also conceivable that the filter unit—for example in the case of a packet-based bus—only forwards the user data to the terminal and completely or partially discards the header information. Even if there is preferably no filtering of the data from the bus in this embodiment, this is not ruled out. For example, potentially security-critical messages that indicate a cyber attack from the bus could be blocked.

In one configuration, the filter unit and/or a processing unit connected between the filter unit and the bus-side connection is designed to process data for output to the terminal-side connection in such a way that special features of the bus, for example a time behavior and/or sufficient edge steepness of transmitted bus signals, are observed. In this way, a bus signal can be sent into the bus that is optimally adapted to the bus. This ensures further flexibility with regard to the terminals that can be connected, since the terminals then do not have to have detailed knowledge or even no knowledge at all about the special features of the bus. The processing unit can include a transceiver module that controls the communication via the bus.

In one embodiment, the gateway has an interface converter, which is arranged to communicate between the filter unit and the connection on the terminal device side and/or between the filter unit and the connection on the bus side, with the interface converter being designed to use different interfaces and/or protocols on the bus side and on the bus side adapt to each other. In this way, the flexibility with regard to the connectable end devices is increased even further. For example, the end device can be connected to the gateway via a network connection, such as Ethernet, or via a USB—Universal Serial Bus—interface, while the connection to the bus takes place via another interface, for example RS-485.

In one embodiment, one of the multiple permitted messages includes requesting data from a bus user, requesting error messages from a bus user, requesting status information from a bus user and/or signaling the end of a data block. With these queries or signaling, basic functionalities are available that can further increase the area of application and possibilities of the gateway.

In one embodiment, the filter unit is implemented in such a way that processes within the filter unit can no longer be changed once the filter unit has been completed. In this way, the gateway can be better certified, since the functionality of the gateway can be defined with production and can no longer be changed. This can be realized, for example, by storing a program controlling the processes in a ROM—Read Only Memory—and loading it into a processor of the gateway or a RAM—Random Access Memory—assigned to this processor each time the gateway is started.

In one embodiment, the filter unit is implemented using a microprocessor, a microcontroller and/or a programmable logic circuit, the programmable logic Circuit is preferably formed by an FPGA - Field Programmable Gate Array -, an ASIC - Application Specific Integrated Circuit - or a CPLD - Complex Programmable Logic Device. In this way, the processes within the gateway can be implemented flexibly. In particular, the use of programmable logic modules also enables parallelization and thus an acceleration of the processes within the gateway.

In one embodiment, the bus is based on RS-232, RS-422, RS-485 or SAE J1708 and/or is controlled by a field bus, preferably a vehicle bus, particularly preferably by MVB - Multifunction Vehicle Bus - or CAN - Controller Area Network. , Formed and / or the terminal-side connection is designed as a connection for RS-232, RS-422, RS-485, SAE J1708 or Ethernet. In this way, extensive possibilities are available for communication between bus and gateway or between gateway and end device. In particular, the use of a fieldbus offers the advantage that fieldbuses are a well-established technology for connecting different sensors, actuators, control devices and/or other devices to one another. Fieldbuses are buses that are particularly widespread in the vehicle sector. CAN is particularly widespread in motor vehicles, MVB in the area of rail vehicles.

• 1 ein Blockschaltbild mit Funktionselementen eines Ausführungsbeispiels eines Gateways gemäß der vorliegenden Offenbarung,
• 2 eine detailliertere Darstellung eines Ausführungsbeispiels eines Gateways gemäß der vorliegenden Offenbarung und
• 3 ein Ablaufdiagramm eines Ausführungsbeispiels eines Verfahrens gemäß der vorliegenden Offenbarung.

Further features and advantages of the invention result from the following description of exemplary embodiments of the present disclosure, which are not to be understood as limiting, and which are explained in more detail below with reference to the drawing. In this drawing show schematically:

• 1 a block diagram with functional elements of an embodiment of a gateway according to the present disclosure,
• 2 a more detailed representation of an embodiment of a gateway according to the present disclosure and
• 3 FIG. 12 is a flow chart of an embodiment of a method according to the present disclosure.

In the different figures, parts that are equivalent in terms of their function are always provided with the same reference symbols, so that they are usually only described once.

1 shows a system 1, which includes a bus 2, several bus users 3, a gateway 4 and a terminal 5. In this case, the bus users 3 and the gateway 4/terminal device 5 use the bus 2 in order to exchange data with one another. The gateway 4 comprises a bus-side connection 6, a terminal-side connection 7, a filter unit 8, a message memory 9 and an interface converter 10. The bus-side connection 6 is designed to connect the gateway 4 to the bus 2 and is connected to the bus 2. The connection 7 on the terminal device side is designed to connect the gateway 4 to the terminal device 5 and is connected to the terminal device 5 . Representations of permitted messages, which the filter unit 8 can access, are stored in the message memory 9 . The interface converter 10 provides an interface adaptation for the connection 7 on the terminal device side, here for example a conversion to Ethernet.

When the gateway 4 is in operation, data is received from the terminal 5 via the connection 7 on the terminal device side. The data received are converted by the interface converter 10 and sent to the filter unit 8 . Only the representation of the received data is changed, but not its content. If the end device 5 is connected to the gateway 4 via Ethernet, for example, the interface converter 10 would extract the useful data from received IP (Internet Protocol) packets and forward the raw data obtained in this way to the filter unit 8 .

The received data are checked by the filter unit 8 with regard to their admissibility for a communication in the bus 2. For this purpose, the filter unit 8 accesses the representations of permitted messages stored in the message memory 9 and checks whether the data received satisfies the requirements of the permitted messages. In the present case, this is implemented by searching for specific characters or character strings in the received data. At the same time, this also means that the received data does not include any significant additional characters that go beyond the concrete characters / character strings. For example, received data can be classified as permitted if they contain the specific characters/characteristics from the message memory 9 and only have additional information, such as address information for a requested bus user 3, a message identifier or the like. If the received data entered as allowed are classified, the received data are further processed for an output via the bus-side connection 6 to the bus 2.

This further processing can include converting the received data by means of correspondence assignment. This correspondence assignment can be done, for example, using a table that can contain, for example, the following assignments of received data ("stimulus message") to bus messages: stimulus message bus message "1" "give me dates" "2" "Give me error messages" "3" "Give me status information" "4" "Give me information about bus occupancy" "EOB" "End of Block"

If, for example, the received data contains a “3” and address information for a specific bus user 3, the filter unit 8 first checks whether the received data contains a permitted message. The message contained in the received data is "3". This message is compared with permitted messages from the message memory 9. Since there is a "3" among the permitted messages, the received data is evaluated as permitted. Therefore, the "3" is converted into the bus message "Give me status information" and transmitted to bus subscriber 3, which was contained in the address information of the received data. The filter unit or a processing unit (not shown) connected between the filter unit and the connection on the bus side is then responsible for ensuring that a bus message is correctly transmitted to the bus 2, for example correct timing and sufficient edge steepness is achieved.

If the addressed bus subscriber 3 responds to this request, the bus subscriber 3 sends the requested status information to the bus 2. The gateway 4 receives this data via the bus-side connection 6 and the filter unit 8. The filter unit 8 forwards this data via the interface converter without further filtering 10 and the bus-side connection 7 to the terminal 5 on.

2 shows a more detailed representation of an embodiment of a gateway 4. The gateway 4 has a connection 6 on the bus side and a connection 7 on the terminal device side. The connection 6 on the bus side can be designed for RS-422, RS-485 or J1708, for example. The connection 7 on the terminal device side is designed as an "internal" connection and by RS-232. After the connection 6 on the bus side, a processing unit 11 is arranged, which is formed by a transceiver. An insulating element is also arranged between the processing unit 11 and the filter unit, which insulates voltage potentials between the bus 2 (or the bus users 3 arranged there) and the terminal device 5 . The filter unit itself is formed by a microcontroller 13 and two multiplexers 14 (for example a 74153 standard IC), the multiplexers 14 being controlled by the microcontroller 13 . The microcontroller 13 or the multiplexers 14 are connected in a communicating manner to the connection 7 on the terminal device side. The microcontroller 13 can also access a message memory 9 in order to load representations of permitted messages stored there. With regard to the operation of this gateway 2, refer to the statements 1 referred.

3 10 shows a flow chart of an embodiment of a method according to the present disclosure. In step S1, data is received from the terminal device 5 via the connection 7 of the gateway 4 on the terminal device side. Several permitted messages are loaded from the message memory 9 in step S2. In step S3, the received data is compared with at least one of the plurality of permitted messages and, based on a comparison result, a decision is made in step S4 about the further processing of the received data. If the received data is not evaluated as a permitted message (“no”), the received data is discarded in step S5. If the received data is evaluated as a permitted message (“yes”), the received data is further processed in step S6, ie prepared for output via the bus-side connection 6 into the bus 2.

With regard to further advantageous configurations, to avoid repetition, reference is made to the general part of the description and to the appended claims.

Finally, it should be expressly pointed out that the exemplary embodiments described above only serve to explain the teaching claimed, but do not restrict it to the exemplary embodiments.

Reference List

1

system

2

bus

3

bus participants

4

Gateway

5

end device

6

bus-side connection

7

terminal-side connection

8th

filter unit

9

message store

10

interface converter

11

processing unit

12

insulating element

13

microcontroller

14

multiplexer

Claims (12)

Gateway for connecting a terminal device to a bus, preferably a bus of a vehicle, particularly preferably a bus of a rail vehicle, comprising: a connection (6) on the bus side, which is designed to connect to the bus (2) and to exchange data with the bus (2), a connection (7) on the terminal device, which is designed to connect to the terminal device (5) and to exchange data with the terminal device (5), a message memory (9) in which a representation of several permitted messages is stored, with each permitted message defining which specific character/which specific character string is to be considered permitted for further processing, a filter unit (8) which is connected in a communicating manner to the bus-side connection (6), the terminal-side connection (7) and the message memory (9) and which is designed to transfer data received at the terminal-side connection (7) to at least one of the to compare allowed messages from the message memory (9) and to further process the received data for an output to the bus-side connection (6) only if the received data match one of the several allowed messages. Gateway to claim 1 , characterized in that the filter unit (8) is additionally designed to output the received data essentially unchanged to the bus-side connection (6) when receiving data is further processed. Gateway to claim 1 , characterized in that the filter unit (8) is additionally designed to convert the received data into a predefined bus message based on a correspondence assignment and to output it to the bus-side connection (6) when receiving data is further processed, with the correspondence assignment preferably taking place by means of an assignment table . Gateway to one of the Claims 1 until 3 , characterized in that the filter unit (8) is additionally designed to receive data from the connection (6) on the bus side and forward it to the connection (7) on the terminal device side and output it, preferably without filtering. Gateway after one of Claims 1 until 4 , characterized in that the filter unit (8) and/or a processing unit connected between the filter unit (8) and the connection (6) on the bus side (11) is designed to prepare data for output to the connection (7) on the terminal device side in such a way that special features of the bus (2), for example a time behavior and/or the edge steepness of transmitted bus signals, are observed. Gateway after one of Claims 1 until 5 , characterized in that the gateway (4) has an interface converter (10) which is arranged to communicate between the filter unit (8) and the connection (7) on the terminal device side and/or between the filter unit (8) and the connection (6) on the bus side, the interface converter (10) being designed to match different interfaces and/or protocols on the bus (2) side and on the terminal (5) side. Gateway after one of Claims 1 until 6 , characterized in that one of the several permitted messages includes requesting data from a bus user (3), requesting error messages from a bus user (3), requesting status information from a bus user (3) and/or signaling the end of a data block . Gateway after one of Claims 1 until 7 , characterized in that the filter unit (8) is implemented in such a way that processes within the filter unit (8) can no longer be changed after the filter unit (8) has been completed. Gateway after one of Claims 1 until 8th , characterized in that the filter unit (8) is implemented using a microprocessor, a microcontroller (13) and/or a programmable logic circuit, the programmable logic circuit preferably being implemented by an FPGA - Field Programmable Gate Array -, an ASIC - Application Specific Integrated Circuit - or a CPLD - Complex Programmable Logic Device - is formed. Gateway after one of Claims 1 until 9 , characterized in that the bus (2) is based on RS-232, RS-422, RS-485 or SAE J1708 and/or by a field bus, preferably a vehicle bus, particularly preferably by MVB - Multifunction Vehicle Bus - or CAN - Controller Area Network - is formed and / or that the terminal-side connection is designed as a connection for RS-232, RS-422, RS-485, SAE J1708 or Ethernet. Method for connecting a terminal device to a bus, preferably a bus of a vehicle, particularly preferably a bus of a rail vehicle, using a gateway, preferably a gateway according to one of Claims 1 until 10 , comprising: Receiving (S1) of data from the terminal (5) via a terminal-side connection (7) of the gateway (4), loading (S2) a plurality of permitted messages from a message memory (9), a permitted message each defining which specific characters/which specific character string should be considered permitted for further processing, comparing (S3) the received data with at least one of the multiple permitted messages and further processing (S6) the received data for output to the bus-side connection (6) by a filter circuit ( 8) the gateway (4) if the received data matches one of the multiple allowed messages. procedure after claim 11 , data being additionally received at a bus-side connection (6) of the gateway (4) and being forwarded by a filter unit (8) of the gateway (4), preferably unchanged, to the terminal-side connection (7).

Images