Title of Invention

A METHOD FOR MONITORING A DATA TRANSMISSION BETWEEN MINIMUM TWO PARTICIPANTS OF A NETWORK

Abstract

Process for monitoring or supervision of a data transmission between at least two participants of a network, where at least one transmitter transmits to at least one receiver data in the form of files (SF, FF, CF), where a data transmission is carried out through at least one file (SF and the receiver transmits to the sender then at least one flow control diagram (FC) if the data of a data transmission is forwarded compartmented in a first file (FF) and at least one consequent file (CF), is thereby characterized that after the last message/file (SF, LCF) of a data transmission an additional flow control telegram (FCB) is transmitted by the receiver to the sender.

Full Text

Process and Device for monitoring of a Data Transmission State-of-the Art-of-Technology The Invention relates to the Process and Device for monitoring a data transmission between two minimum participants of a network in accordance with generic term of the independent claims. Processors for data transmission, in particular the corresponding transmitting protocols, are applied all over where large data quantities, in small lots or packets, hereinafter referred to as files, should be safely transmitted. For example, a CAN-telegram (CAN: Controller Area Network) allows the transmission of a certain number of User Bytes. If larger lots and/or data quantities are to be sent, then a transmission protocol for the segmenting must be applied at the transmitter and/or during the assembly at the receiver. Particularly for diagnosis applications, the ISO (International Standardization Organization) has published the Standard 15765. In the second part of the Standard of the ISO, 15765-2, a transmission protocol is specified under which no confirmation of the transmitted files under the framework of a data transmission takes place. The reason for this is that under different applications, particularly in the automobile industry, data or files with certain information are cyclically sent. If in the process, data, especially a file gets lost, then the synchronization of this lost data is done during the next file or message. If files however are transmitted in an event-oriented manner, then a missing confirmation of the file/message is unacceptable. Possible solutions for the problem of a missing confirmation, especially in CAN- based systems, are available for one thing thereby that a dedicated transmission is used, which however has the disadvantage that it is not compatible to the protocols required by a multiplicity of applications, especially under the framework of the diagnosis in an automobile, or that the required confirmation is carried out on higher protocol layers, a so called additional security layer, as a result of which disadvantageous^ a significantly higher expenditure under increased susceptibility to errors as well as a greater ineffectiveness, especially through an enhanced bus-load. Thus it is the responsibility of the Invention to expand an existing transmitting protocol, which is highly compatible to a very large number of applications, especially a transmission protocol as per the ISO-Standard 15765-2, towards the objective that the protocol is itself not substantially not altered and on the other a confirmation of the files is enabled, despite the fact that this is not foreseen in the protocol. Advantages of the Invention With the objective of solving this task, the Invention presents a process and a device for monitoring a data transmission between a minimum of two participants of a network whereby at least one sensor transmits to at least one receiver data in the form of files, whereby a data transmission takes place through at least one file and the receiver then transmits to the sender at least one flow control block, if the data is transmitted in a transmission separated into a first file and at least one following file, whereby advantageously after the last file of a data transmission an additional flow control block is transmitted from the receiver to the sender. What is advantage here is that the data transmission is carried out in accordance with protocol as per ISO 15765-2. That means advantage of the described process and the device described lies in the compatible expansion of an existing protocol, especially of the ISO-Standard 15765-2, without substantial modification of the ISO-Standard, that is for example, no new or modified files, especially protocol control information are introduced. Again thus with great advantage but with minimum expenditure a confirmed communication service and/or a confirmed data transmission is achieved. The receiver can then continue to be operated purposefully with a simple implementation of the known protocol, that is with a pure ISO-Implementation, which function has tooling without problems, within the boundary of the protocol expansion described in the network. Thus under the framework of ISO 15765-2 Standard, an acknowledge of a data transmission through transmission of an additional flow control telegram FC, after the last file/message of a data transmission is advantageously enabled. i Two types of such flow control blocks/telegrams (FC) are distinguished; whereby a first flow control telegram FC.CTS is used as positive confirmation and a second flow control telegram FC.WAIT has negative confirmation. What is further more advantageous is that the transmitter verifies whether in a prescribed first time span N_Bs_Timeout, after sending at least one message, a flow control diagram is received and the transmitter in case of error repeats the last sent file or all lost sent files of a data transmission. What is similarly advantageous is that the transmitter verifies whether the receiver can be operated in a confirmed type of operation, that is with the outward despatch of the flow control telegram at the end of the data transmission, in which the transmitter sends a single text message and monitors the arrival of the flow control telegram as confirmation. In this case therefore two types of operations can be distinguished from each other: the first type of operation which allows the transmission of the additional flow control telegram after the last message of a data transmission from the receiver to the sender and a second type of operation which does not allow it, whereby while receipt of the flow control telegram after the Test file/message at the Receiver, it is operated in the first type of operation, and in another case diverted to the second type of operation. In this context, in a special design form an additional purposeful verification can be made whether the flow control telegram after the test message arrives within a prescribed second time span N_ Bs_Timeout 2 at the receiver. In a special design form the first and second time span is identical (N_Bs_Timeout = N_Bs_Timeout 2). A special and advantageous realization and application of the Invention consists in the use of a computer programme on a data carrier, which serves the purpose of adopting a process in accordance with the Invention. Through the Invention described in more detailed here-below thus results in a very efficient enhancement of the security in the network because for one thing the network can be operated in a confirmed type of operation, and on the other a well-known highly compatible transmission protocol, especially the ISO 15765-2 can be deployed and simultaneously network participants who do not possess the expansion or extension to the standard protocol can continue to be operated in the existing network. Further advantageous and profitable design forms emerge from the description as well as the characteristics of the claims. Drawing The Invention is explained further on the basis of the figures illustrated in the drawing. In this context, figure 1 displays a network or a bus system with at least two participants under the framework of the data transmission to be monitored. Figure 2 displays a first flow diagram under the framework of a message confirmation in case of a single message/file. In Figure 3, a second flow diagram displays with negative file confirmation in case of a single message/file, that is under a recognized error. Figure 4 shows a special design example in case of a single message/file with timeout. Figure 5 shows in a fourth flow diagram the message/file confirmation under compartmented data transmission. Description of the Design Example Figure 1 shows a network N with a bus connection 100 and at least two participants 101 and 102. Further participants such as 103 in this example are optional but are conceivable naturally in keeping with the Invention. The network and/or the bus system particularly correspond to ISO 15765-2, for example to a CAN-System with special reference to an automobile. Further applications, especially in the machine tools branches or in the industry and in the consumer goods branches are similarly conceivable, as in the case of other bus-systems. The above referred to ISO 15765-2, especially ISO/DIS 157652-2 as on 30.11. 1999 are assumed to be the transmission protocol in the discussion that follows here-below (ISO/TC 22/SC3/WG 1/TF 2 N 124). In this context, however each further protocol, which fulfill the properties or characteristics of the ISO Standard, which are used according to the Invention, and offers no confirmed service. The bus participant (time sharing) in the example in Figure 1 has a bus interface 104, 105 and/or 106 as well as processing units 107, 108 and 109 as well as memory elements 110, 111 as well as 112. These processing units or memory elements can be accommodated on the one hand in the participant itself as illustrated in 101 and 102, or it can also be integrated in the interface unit according to participant 103. The servicing of the process according to the Invention takes place in this context through the processing units, particularly in conjunction with the memory elements, for example for recording a corresponding programme. In this process a computer programme according to the Invention can be stored in the memory elements illustrated in Figure 1 on the one hand or also can be localized on other data carriers, especially before it is realize therein. All conceivable data carriers such as a transmission, for instance via internet can be applied according to the Invention. The core of the Invention is based on the special utilization of a flow control telegram, that is flow control telegram FC of the ISO Standard referred to. A flow control block FC is transmitted according to the process described as per the Invention additionally at the end of each transmission from the receiver of the message/file to the sender. In this context, for example, participant 101 as sender and participant 102 as receiver with reference to a sample data transmission are visualized. Naturally each participant especially under the framework of a CAN-system can be both a sender as well as a receiver. Also a I " stipulation which participant functions as sender and which as receiver is conceivable as per the Invention. These standard compatible flow control blocks FC are then interpreted according to the Invention as positive or negative confirmation of the entire data transmission, that is all messages/files connected with the data transmission, as follows: The flow control blocks FC can be distinguished in two types: FC.CTS (Flow Status is continued to send) as well as FC-WAIT (Flow Status is wait). In this context, according to the Invention, the FC-CTS is applied as positive confirmation, that is as an acknowledgement of an error-free transmission and FC.WAIT as negative confirmation, that is as an indication for a transmission error. In this context, this stipulation or fixation is arrived at according to the context or sense' of purpose. What is also conceivable is the reversed application of both the types of flow control blocks. Now, based on the following Figures 2 to 5, the examples in accordance with the Invention are illustrated in the form of flow diagrams or sequential diagrams. In the following description, the abbreviations as per the ISO/DIS 15765-2 are used. They denote: SF: Single Frame, one single message/file FC: Flow Control, the flow control block FC.CTS: Flow Control (continue to send) as Positive Confirmation FC.WAIT: Flow Control (Wait) as Negative Confirmation FF: First Frame as first message/file in respect of at least two messages of a data transmission CF: Consecutive Frame as subsequent message/file of a data transmission with at least two messages LCF: Last Consecutive Frame as last subsequent message and N_Bs: Network Layer Timing Parameter Bs, that is the time up to the next FC- Receipt The expansion of the process according to the Invention described here vis-a-vis the Standard Protocol is illustrated with dotted lines. For reasons of transparency, the timer N_Bs is merely indicated at the spot, which for the explanation of error recognition is important. This is in Figure 4. Generally, both in the case of short data transmissions, for which only a message/file SF must be sent as well as the long data transmissions with several files/messages FF and CF are covered. The basic principle according to the Invention is the same: After receipt of the respective last data telegram SF or LCF, the Receiver sends out an additional flow control block FC. In this context it is important that this flow control block FC exactly confirms from the point of view of format with the ISO-Specification. Merely the interpretation of the flow control blocks experiences an expansion: An FC.CTS is interpreted by the sender as • positive acknowledge and FC.WAITJn contrast, as negative. The flow diagram or the sequence in Figure 2 illustrates the message/file sequence in case of a short data transmission, that means, an unsegmented data transmission, again that is an individual message SF in error-free mode. That means, the sender particularly the participant 101, sends a message SF to the receiver, here especially participant 102. After the receiver has received SF- telegram, that means the individual message/file, he/it sends for positive confirmation in this happy instance an FC.CTS-Telegram, that is the corresponding flow control block to the sender. This receives a confirmation of the individual message SF, as expansion/extension as against the ISO-Protocol. Figure 2 illustrates a flow diagram or a sequence, which corresponds to the one in Figure 1, with the difference that the Receiver finds an error in receiving of the individual message, that means of the SF telegram. Under or after a recognized error, the Receiver sends out to the Sender a negative confirmation, that is in this case, the flow control block FC.WAIT. As an error reaction, the Sender can then repeat his individual message, that is his SF Telegram, and is successful this time, as illustrated here in this example, which reflects itself in the positive confirmation through the flow control block FC.CTS from the Receiver to the Sender. An extraordinary case is now illustrated in Figure 4. In this flow diagram or this sequence a case is handled under which the receiver erroneously sends out no flow control block, that is no FC-Telegram as acknowledgement, because for example the single or individual message/file SF is lost in the transmission. Even this case can be recognized through a special provision or design, that is through a sender-side monitoring of a first time span. In this context, the timer N_Bs prescribed as per the ISO Standard can be used, which is always started then if one has to wait for a flow control block. Purposefully therefore and at this position exactly the identical timer N_Bs is used in this context, and the time span N_Bs Timeout is watched through the Sender. It is also conceivable according to the Invention to apply a different timer or a different time span whereby the use of N_Bs has the advantage to minimize also here the matching of the existing protocols. As a reaction to the expiry of the time span, N_Bs Timeout the repetition of the single message SF follows as an error reaction, which then again merges for instance in a positive confirmation with FC.CTS. Naturally, even combination of all sequences illustrated according to the Invention with the recognized errors, without recognized errors, with Timeout, without Timeout etc., are possible and are taken care of in the Invention. Finally in Figure 5, in the flow diagram or the Sequence only a long data transmission that means a segmented data transmission is illustrated. In such a segmented data transmission, that is by application of a first message/file FF and subsequently following messages/files CF, to start with flow control telegram is applied standard-wise and after the first message FF, a FC-TF is sent, which for instance contains information Bs and ST mjn, according to ISO 15765-2, that is the block size and the minimum distance or interval between two subsequently following messages CF. In expanding the ISO Standards, merely a positive acknowledgement after the last message CF, that LCF, is sent from the Receiver as confirmation to the Sender. In accordance with Figure 3 and 4, error cases illustrated therein are possible in this instance, and can be handled. In this context, of course, under certain circumstances, only the defective message or the defective messages that follow between two flow control blocks are repeated, but because of the design type of the ISO Standard protocol, generally in the case of an error the entire data transmission, that is all messages/files, are repeated. In the following paragraphs, we shall briefly be dealing with the compatibility to the ISO-conformed implementations, that is implementations for individual participants, which do not allow an interpretation as per our Invention. The Invention-based process presupposes that both the Sender through waiting for a confirmation as flow control block, as well as the Receiver through sending of the confirmation as flow control block must be modified or matched with particular reference to programme technology. That means however also that an older transmitter, namely a purely ISO-conformed transmitter with a new receiver in accordance with the new Invention would function without any problem. It could become a problem however if a Sender in conformity with the Invention but working with a purely ISO-conformed receiver works together. Especially on account of a timeout it could then lead to undesirable repetitions. Nevertheless in order to enable downward compatibility, the process can be supplemented in a special design around a configuration run. In this process, for example by sending a test message from the Invention-based transmitter and verification within a prescribed second time span N_Bs_Timeout 2, whether a flow control telegram returns or not can be determined. If yes, then an operation type according to the Invention, that is with confirmed services, can be made use of. Otherwise, with reference to the Receiver it must be converted in the purely ISO- conformed operation type, that is without the expansion as per our Invention. Two variants can be thought of for this: For one, a special test message/file recognizable as such us sent, namely the sender does not work then in the error mode, but presumes under the non-receipt of the confirmation to have a purely ISO-conformed receiver, or in a second instance that a certain time is visualized, in which a verification regarding error is not made, but with regard to compatibility as per the Invention-based process and/or purely ISO-conformed design. Such a time is for instance granted after each run-up during sending out of the first message. It is possible however that a different time is prescribed. For enhancing this security, such a configuration run in this context can be carried out even several times one after the other, in order that the overlapping of an error occurring in the configuration run is effectively prevented and/or minimized. If the configuration run is executed after each run-up during sending out of the first message/file, then a receiver expanded according to this suggestion must work in principle at the time of starting according to the invention-based protocol in order to react already at the first message of the transmitter, and to send the flow control block as acknowledgement. That means merely by combination of the new transmitter/sender according to the Invention and a purely ISO- conformed old receiver, no acknowledgement is possible according to our Invention. In this event however according to the Invention switching over to the purely ISO-conformed protocol is possible. Thus with the adoption of our Invention, despite use of a highly compatible standard protocol, in which originally no acknowledgement operation is visualized, such an acknowledgement provision can be introduced. The error- free instance or a good case in this context is almost immediately recognized on the basis of the positive confirmation, that means there are no additional timeout or similar things to be observed. Besides, the implementation in accordance with the invention can be achieved very easily, it relates to a relatively small expansion or extension of an existing layer and/or the existing protocol and is therefore significantly less expensive than a protocol layer implemented by itself for confirmation, in accordance with the security player referred to at the beginning. Claims: 1. Process for monitoring or verification of a data transmission between minimum two participants of a network, whereby at least one transmitter/sender transmits at least to one receiver data in the form of files (SF, FF, CF), whereby a data transmission through at least one message SF is carried out and the receiver forwards to the sender at least one flow control telegram (FC), if the data of a data transmission is compartmented in a first message/file (FF) and at the minimum one following message/file (CF) is transmitted, is thereby characterized that after the last file/message (SF, LCF) of a data transmission an additional flow control block (FCB) is transmitted by the receiver to the sender. 2. Process according to Claim 1 is thereby characterized that the data transmission runs as per protocol in accordance with ISO 15765-2. 3. Process according to Claim 1 is thereby characterized that between two types of flow control blocks a differentiation is made, where one first flow control block (FC.CTS) is used as positive confirmation and a second flow control block (FC.WAIT) as negative confirmation. 4. Process according to Claim 1 is thereby characterized that the sender verifies whether in a prescribed first time span (N_Bs_Timeout) after transmission of at least one message/file a flow control telegram is received and the sender, in the event of an error repeats the last sent message or all last messages of a data transmission. 5. Process according to Claim 1 is thereby characterized that the sender verifies whether the receiver can be operated in a confirmed operation mode-with desptach of flow control telegram at the end of the data transmission, in that the sender sends out a single test message (TF) and verifies the arrival of the flow control telegram (FC) as confirmation. 6. Process according to Claim 5 is thereby characterized that a distinction is made between two operating modes: one, the first operating mode permits the transmission of the additional flow control telegram after the last file (SF, LCF) of a data transmission from the receiver to the sender, and 2, the second operating mode does not permit it, whereby at the receipt of the flow control telegram (FC) after the test message (TF) at the sender it works in the first operating mode and in another case switches over to the second operating mode. 7. Process according to Claim 5 is thereby characterized that a verification is done whether the flow control telegram (FC) arrives in at the receiver after the test message (TF) within a prescribed second time span (N_Bs_Timeout2) 8. Process according to Claim 4 and 7 is thereby characterized by the fact that the second time span (N_Bs_Timeout2) corresponds to the first time span (N_Bs_Tiemout). 9. Computer Programmer on a data carrier for application according to a Process as per one of the Claims 1 to 8. 10. Device for monitoring data transmission between at least two participants of a network whereby at least one transmitter forwards or transmits to at least one receiver data in the form of messages/files (SF, FF, CF), whereby a data transmission is achieved through at least one message/file (SF) and the receiver then transmits to the sender at least one flow control telegram (FC), if the data of a data transmission is transmitted compartmented in a first file (FF) and at least one consequent file (CF), is thereby characterized that means or devices are provided through which after the last file (SF, LCF) of a data transmission, an additional flow control telegram (FCB) is transmitted from the receiver to the sender. 11. A process for monitoring or verification of a data transmission between minimum two participants of a network, substantially as herein described with reference to the accompanying drawings.

Documents:

3015-CHENP-2004 AMENDED CLAIMS 12-03-2013.pdf

3015-CHENP-2004 AMENDED PAGES OF SPECIFICATION 12-03-2013.pdf

3015-CHENP-2004 CORRESPONDENCE OTHERS 23-04-2013.pdf

3015-CHENP-2004 OTHER PATENT DOCUMENT 12-03-2013.pdf

3015-chenp-2004 abstract.pdf

3015-chenp-2004 claims.pdf

3015-CHENP-2004 CORRESPONDENCE OTHERS 11-01-2012.pdf

3015-CHENP-2004 CORRESPONDENCE OTHERS 29-03-2012.pdf

3015-chenp-2004 correspondence others.pdf

3015-chenp-2004 correspondence po.pdf

3015-chenp-2004 description (complete).pdf

3015-chenp-2004 drawings.pdf

3015-CHENP-2004 EXAMINATION REPORT REPLY RECEIVED 12-03-2013.pdf

3015-CHENP-2004 FORM-1 12-03-2013.pdf

3015-chenp-2004 form-1.pdf

3015-chenp-2004 form-18.pdf

3015-CHENP-2004 FORM-3 23-04-2013.pdf

3015-CHENP-2004 FORM-3 12-03-2013.pdf

3015-chenp-2004 form-3.pdf

3015-chenp-2004 form-5.pdf

3015-chenp-2004 pct.pdf

3015-CHENP-2004 POWER OF ATTORNEY 12-03-2013.pdf