1. Field of the Invention
The present invention relates to a network interface as well as to a network and a method of creating a network for secure data transmission.
2. Description of Related Art
There is a plurality of different types of communication networks for different applications. In correspondence therewith, the demands on transmission reliability and robustness in transmission vary. For the transmission of e-mails, for example, the demands on the network may be comparatively low. In cases of networks employed for the transmission of safety-relevant data, e.g. in motor vehicles, by contrast, maximum demands are made on the networks. To ensure a high reliability in transmission, both the hardware and the software of the network must be appropriately designed.
The explanations set forth below relate, inter alia, to the OSI reference model (basic reference model “open systems interconnection”) according to ISO. In that model, communication architectures are subdivided into seven layers. In correspondence with these layers, different measures are known for ensuring a defined reliability in transmission. The following specification refers to the term “layer” also in the sense of the meanings of entities of the layer.
For example, the data sheet TLE 6254-2G of Apr. 30, 2002, published by Infineon Technologies AG, Muenchen, discloses a “Fault Tolerant Differential CAN-Transceiver.” This transceiver detects different fault conditions of the lines used for signal transmission and controls faultless lines, if possible, in such a way that signals can still be transmitted via these lines.
FIG. 6 of the TLE 6254-26 data sheet illustrates a CAN transceiver controlled by means of a microprocessor with an integrated CAN module. This arrangement presents the advantage, that in the case of faults or malfunction in the line system signal, transmission is still possible in many cases. However, provisions are not envisioned here for protection from errors in the software of the microprocessor. When, for example, the microprocessor is loaded or overloaded, respectively, by the execution of application services in such a way that it can no longer respond to the bus signals, a communication via the bus is no longer possible.
The effects of errors affecting the transmission of the bus system as a whole are far more serious. This may be the case, for example, when in the case of a fault a continuous data stream is output onto the bus, which does not comply with the standard. Such a data stream could be created, for instance, by an incorrect behaviour of the microprocessor controlling the CAN transceiver. When the bus is blocked by such a data stream, other nodes can no longer communicate with each other. When the error case of microprocessor overload, which has been described first, only affects on node, it is possible that a fault described in the second case blocks a complete bus system and results in the failure of essential functionalities of the system. Such a condition is not acceptable, specifically in applications critical in terms of security of, for example, applications in motor vehicles.
For a reduction of such faults to an acceptable level it is necessary to test the entire software of the microprocessor exhaustively. In this test, not only the function relevant for the communication via the bus but also all other functions must be tested. This is necessary because each code in the microprocessor has access to the hardware functions of the bus or may at least result in failure of the bus service on account of microprocessor overload. Particularly in complex networks including a plurality of different nodes, this results in a problem that can hardly be solved because in the test all conceivable conditions of all nodes should to be taken into account. In practical application, this leads to the execution of tests on the basis of simplifying assumptions. Yet, a high test complexity remains with an unsatisfactory result.
The data sheet “C167CR, C167SR 16-bit Single-Chip Microcontroller,” July 2001 of Infineon Technologies AG, Muenchen, describes a typical micro controller with an integrated CAN interface by way of an example. This interface comprises a CAN module that is capable of emitting or receiving data independently. As is apparent from Table 7 of this data sheet, the CAN module is directly mapped into the linear address space of the micro controller. As a result, any element of the code whatsoever can—intentionally or unintentionally—have access to this code. Errors in computation are particularly critical in indirect addressing, for example. As in this case, the CAN module is located in the linear address space such that an addressing error could result in a fault on the bus in its entirety. When, for example, the bus cycle is unintentionally modified the supply of data with an incorrect cycle frequency may cause a breakdown of the communication throughout the bus system in its entirety.
Another case of a possible failure occurs when, for example, a reset of a node, including the network interface, is triggered due to a fault in an application or by a user, respectively. Here, the node loses its network connection and must be re-synchronized to the network. Specifically in the case of networks with a ring architecture, this may lead to a failure of the transmission for the time of the booting cycle up to a new synchronization. As these operations may last often for several seconds up to minutes, such a failure of a complete network, e.g. a network used in motor vehicles, is unacceptable. When, as a consequence of a fault in hardware or software associated to a node, this booting operation is no longer possible, this situation may result in a permanent impairment or in a total failure of the network.
The problems described here by the example of a CAN bus occur, of course, also in the other known bus systems. One example for Ethernet is specified in the data sheet “DP83820 10/100/100 MB/s PCI Ethernet Network Interface Controller,” February 2001, National Semiconductor Corporation. There, a network interface controller is described that is mapped by means of an integrated PCI bus interface directly into the linear address space of a microprocessor.
U.S. Pat. No. 6,457,056 discloses a network interface controller to which a microprocessor may have access directly via the system bus. This results in the same problems, too, as those occurring in the aforedescribed case of the CAN interface.
In an approach to improve the reliability of computer systems fundamentally certain operating systems are provided with a so-called “protected mode” for essential parts of the core of the operating system. As in this approach, drivers are incorporated for the entire hardware of a computer system causing the operating system core to be large and, hence, error-prone. When a fault occurs within this core, for instance, due to errors in the software or as a result of faults in any hardware component, this fault may lead to the consequence that the network interface is no longer controlled. Again, this may result in the above-described faults in the entire system interconnected by the network. Moreover, in these operating systems, a subdivision is made between the parts executed in the protected mode and the remaining part primarily under the aspect of simple programming interfaces and less under the aspect of security. For example, only the driver for the hardware is protected in the protected mode for conventional network connections of PCs whereas other essential functionalities such as the TCP IP stack are implemented in the operating system in a conventional manner.
USPTO Backgrounds
USPTO Backgrounds