IE950046A1 - A data communication method - Google Patents

Abstract

A communication method (40) provides for synchronisation between a mainframe computer (2) and a large number of hand-held terminals (HHTs) (4). An intermediate communications controller (3) searches for identifier fields (20,21) and generates a key (22) and refers to a reference database (23). Depending on values in a transmit counter and on data in a current record (18) and a reference record (23(a)), various actions may be taken including writing of a record to an OUT file (31). The OUT file (31) has a similar structure to an incoming file (INP) and the structure is to optimise facilities available in the HHTs (4).

Description

A data communication method The invention relates to a method for data communication between a central host data processor and a large number of remote portable data processors.

In recent years, there has been an increasing need for 5 carrying out data processing in the field instead of simply logging or collecting data. Examples of people who are required to carry out such data processing are people who are involved in building site development, electrical maintenance, insurance sales, or electrical appliance maintenance.

At present, it is known to provide portable data processors which have a high processing and data storage capability. For example, British Patent Specification No. GB 2168515B describes a system in which there are portable master and slave devices and coupling units which are useful for a restaurant environment. In this situation, however, the level of data processing at the portable data processor is not very high and the complete system is not extensive. British Patent Specification No. GB 2136246 describes an arrangement whereby a host CPU communicates with remote devices .

It is an object of the invention to provide a communications method which provides versatility in communication between a host data processor and a large number of portable data processors. Another object is to provide for real-time interfacing between the various data processors and a still further object is to optimise use of the relatively small memory capacity of portable data processors. Finally, another object of the invention is to provide for interfacing between host and portable data 3 incompatible so that OPEN TO PUP! · OSPECHON SECTION 26 AND RULE 23 JNL No....... ...OF VlAfa - 2 disparate data processors may be brought into the one system in a way which allows the individual components to perform their most suitable function.

According to the invention, there is provided a data communications method carried out by a host data processor, a communications controller, and a plurality of portable data processors, the communications controller comprising a microprocessor circuit, a memory and a nonvolatile data storage device, the method comprising the steps of:for initialisation, the communications controller transmitting signals to the host processor setting a data record structure in which communications-specific fields are embedded, thereby allowing the host processor to carry out either batch or real-time data processing operations and generating an output file in a structure which may be used for further communications; for communications, the communications controller carrying out the following steps:receiving a common-format file having a preset structure and comprising processed data records from the host processor; automatically sorting the records in groups according to the processed data record type; writing each record in turn into the communications controller memory and for each record:950046 - 3 reading at least two embedded communicationsspecific identifier data fields within the record and combining them to generate a unique record key; addressing a reference database stored in the non-volatile data storage device with the generated key and retrieving a corresponding reference record; comparing the current and reference records; identifying any data difference and writing any updates included in the current record and which are not included in the reference record to the reference record; incrementing an embedded communicationsspecific transmit counter value in the current record; if there are no differences, reading values of the transmit counter in the current and reference records; and if there are data differences, or if there are transmit counter value differences, writing the current record to an outgoing file; when all records for a particular set of portable data processors have been processed by the communications controller, the controller establishing a communications session and directing transmission of the outgoing file to the 9 5 0 ο 4 β - 4 relevant portable data processors and monitoring transmission characteristics for integrity; if correctly transmitted and received, updating the reference database by incrementing the transmit counters of all relevant reference records; and in the same communications session, receiving an input file of updated data records from the portable data processors and automatically writing them to the storage device, and subsequently processing the file in the memory to convert it to the common format for the host processor and transmitting the file to the host processor in this format.

In one embodiment, the outgoing file structure includes initial file deletion instructions if there is greater than a preset number of records in that file which are to be updated, thereby allowing clearing of large blocks of memory in the portable data processor at the start of the communications session.

Preferably, the file deletion instruction is repeated to ensure integrity.

In another embodiment, the outgoing file includes update instructions for individual records, instructions for particular record types being contiguous and each instruction comprising in sequence an indicator of the record type, an update command, the key and communications sequence.

Ideally, the update command includes appending, deleting, or searching and amending commands. - 950(,4 6 - 5 In a further embodiment, the outgoing file includes an instruction at the end of a contiguous string of instructions summarising the number of instructions and indicating the nature of the records involved.

Preferably, the outgoing file includes an end instruction which indicates the quantity of instruction records included in the file.

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:Fig. 1 is a schematic representation of a data processing system which carries out a method of the invention, an outline diagram showing the major data flows; Fig. 2 is a diagrammatic data flow diagram illustrating the data flows in communication between a host and remote portable data processors; and Fig. 3(a) and 3(b) are together a flow chart illustrating a communications method of the invention.

Referring to the drawings, and initially to Fig. 1, there is shown a data processing apparatus of the invention, indicated generally by the reference numeral 1. The apparatus 1 comprises a host or mainframe computer 2 which is connected to a communications controller 3. Further, there is a large number (only three being shown) of remote portable data processors 4 which are used in the field - 6 remotely from the mainframe computer 2 and the communications controller 3.

The communications controller 3 comprises a microprocessor circuit 5 connected to a random access memory 7, two fixed disk storage devices 6 and to a modem bank 8.

In more detail, the microprocessor circuit 5 utilises the Intel 486™ microprocessor and there is a read/write memory capacity in excess of 10 MB. Further, the storage capacity is in excess of 120 MB.

The portable data processors 4 are commonly referred to as hand-held terminals (HHTs) and accordingly that term is used in this specification. Each HHT 4 has an NEC V25+™ microprocessor operating at a clock speed of 8 MHz. There is in the range of 0.64 to 3.0 MB of memory and the operating system is MS-DOS™. Communications for the HHTs 4 are provided by RS232/V24 serial ports. A communications and charging rack is provided for connection with each HHT by two 25-Pin D-type connectors having one DC low voltage power input.

To very briefly describe operation of the system 1, the mainframe computer 2 carries out both real-time and batch data processing and at all times communicates synchronously with external devices using a common-file format, in this case ASCII. The HHTs 4 also carry out local data processing, although the data records which are generated are not in a format which may be used by the mainframe computer 2. The diagram in Fig. 1 explains in outline manner operation of the system 1 whereby the mainframe computer 2 receives data, processes the data and acts as a filter within a general data flow circuit. The communications controller 3 transmits and receives data. Like the mainframe computer 2, the HHTs 4 receive, process - 7 and filter data, although in this case it is done at a local level, remotely from the mainframe computer 2. Data flows in a cycle 10 indicated by the arrows 11 and as is clear from this diagram it may be updated in two different places in the circuit. The function of the communications controller 3 and of the communications method of the invention is to ensure that all of the different data processing devices work synchronously.

Referring now to Fig. 2, the overall data flow in the outgoing direction from the mainframe computer 2 to the hand-held terminals 4 is illustrated. During initialisation, the communications controller 3 transmits data structure signals to the mainframe computer 2 to set a common format structure by which the mainframe computer 2 outputs data. This is a simple delimited structure in ASCII format. This structure delimits data records which include fields for embedded communications-specific codes which are not addressed by the mainframe computer. In this embodiment, the embedded fields are for a transmit counter (not shown) and fields 20 and 21 for identifier codes, referred to below.

An output file which is generated by the mainframe computer with this structure is indicated by the numeral 16 in Fig. 2. This file is very large - in the range of 20 to 50 MB. In general, it is generated during a batch process, however, it could be generated in real-time during a data processing period. The communications controller 3 receives the file 16 and sorts the records into groupings of files according to subject matter of the data records. A single data record 17 is illustrated in detail. This comprises a number of data fields 19 which have a pre-set data length, some fields possibly being empty. The microprocessor circuit 5 of the communications controller 3 searches for two identifier fields 20 and 21 - 8 when the record 18 is loaded into the memory 7. These identifier fields are combined to form an address or key 22. This is used in retrieval of a reference record 23(a) from a reference database 23.

The microprocessor circuit 5 then compares the reference record 23(a) with the current record 18 in step 24 and if there are any differences as indicated by the decision step 25, it updates a counter field (not shown) in the current record 18 in step 26. As indicated by the interrupted lines, it also amends the reference record 23(a) accordingly, and in step 27 it writes the current record 18 to an outgoing file referred to as an OUT file 31. If there are no data differences as indicated by the decision step 25, in step 28 the microprocessor circuit 5 compares transmit counters in the current and reference records 18 and 23(a) and if there is a difference, the current record 18 is written to the OUT file 31. Otherwise, no action is taken.

The OUT file 31 is then transmitted to the relevant HHTs 4 and when acknowledgement is safely received a counter in the reference record 23(a) is updated; as indicated by the decision step 30.

The diagram of Fig. 2 gives an overview of some of the major operations for outgoing transmission of data from the mainframe computer 2 to the HHTs 4. The transmit counter which is referred to indicates whether or not the current record has already been safely transmitted to the relevant HHTs 4 when its value is compared with that in the reference record 23(a). However, the relevant HHT 4 is updated even if the counters are the same if data differences are detected in step 24. This is an extremely simple arrangement which allows the mainframe computer 2 to process data without reference to the transmit counter 950046- 9 and therefore, the data record may be amended by the mainframe computer 2 without the counter being incremented. However, the communications controller 3 increments the counter immediately upon detection of a data difference, and also ensures that the reference record is up-to-date when communications have been safely carried out. This outgoing flow of data from the mainframe computer 2 to the HHTs 4 and also the incoming return path indicated by the arrows 11 is now described.

Referring to Figs. 3(a) and 3(b) together with Fig. 2, the complete communications method is illustrated. There is an initial step 41 whereby the mainframe data file 16 is received. As described above, this file is extremely large, being in the range of 20 to 50 MB. However, because of the structure which has been preset by the communications controller 3, it may be quickly sorted in step 42 into relevant files according to data category such as product, customer or history files. This breakdown is indicated by the numeral 17 in Fig. 2. In step 43, the microprocessor circuit 5 writes the current record 18 to memory and in step 44, it reads the identifier fields 20 and 21. These are combined in step 45 to provide an address or key 22 which is used in addressing the reference database 23. As indicated by the decision step 46, if no reference record is located, the microprocessor circuit 5 resets the transmit counter in the current record 18 to a base value, in this case 0. Subsequently, the current record 18 is written to the reference database 23 in step 51 and is also written to the OUT file 31 in step 27.

If a reference record 23(a) is found, this is retrieved in step 48 and the data in it is compared with that in the current record 18 in step 24, already described. Some of the next steps in the communications method 40 are similar ®5 00 4 β ϊ - 10 to those already described with reference to Fig. 2 and are indicated by the same reference numerals. The step of writing difference data to the reference record 23(a) is indicated by the numeral 51 and in step 52 the counter in the current record 18 is updated where there is different data. As is clear from this diagram, the current record 18 is written to the OUT 31 file in step 27 if there is a difference in data, or if there is a difference in the counter values .

As indicated by the decision step 56, steps 43 to 56 are repeated for each record for a particular one or set of HHTs 4.

Referring now to Fig. 3(b), the OUT file 31 is transmitted in step 57 and in step 58, the microprocessor circuit 5 monitors the modem bank 8 to check for a valid transmission to the relevant HHT 4. To achieve a valid transmission, it may be necessary to activate a retry process 60 until there is a positive acknowledgement as indicated by the decision step 59.

In more detail, the structure of the OUT file 31 is important to optimise use of the processing and memory capacities of the HHTs 4. The microprocessor circuit 5 determines initially if more than a preset number of records for a particular file are to be updated, and where this is so, the first instructions in the OUT file 31 are for wiping or clearing of all of the file in the HHT 4. This instruction comprises a wipe command W followed by a flag indicating the file involved. This instruction is repeated in sequence to ensure that it is not incorrectly transmitted or recognised. By including these instructions at the beginning of the OUT file 31, the processor of the HHT 4 can immediately clear an approximately large memory block and there will be a much - 11 higher proportion of records to be appended during one communications session instead of processing records to update data, this being more intensive.

Instructions relating to updating of records are written to the OUT file 31 in a preset manner to optimise facilities in the HHT 4. Instructions for records are contiguous according to the nature of the record. Each individual instruction comprises a character indicating the record type, a character indicating the nature of the update, the set of characters forming the key 22, and finally a sequence identifier. For example, the instruction:CAXXX00123 indicates that the record is of type C and the update nature is indicated by A which means that the record is to be appended to the file. The key is the sequence of X's and the 123 indicates a communications sequence identifier.

All instructions relating to a C-type record are written together in a contiguous manner and they are followed by an identifier indicating that the contiguous string of record update instructions for record type C is complete and an indicator of the number of instructions is given. In this case, this final instruction may be ZC2, Z indicating ending of that particular instruction record string, C indicating that they relate to record type C, and 2 indicating that there are two instructions in the string. In this example, the update operation is appending of a record to a file. However, the update character may be R which instructs the processor of a HHT 4 to search for an existing record and update it. If the record does not exist, a new record will be created. 0p 4 $ Another type is represented by the character D which instructs the HHT processor to search for an existing record and delete it. If the relevant record is not found, the instruction is ignored and no errors are reported. The set of instructions in the OUT file 31 is completed by indicators of the total number of record instructions included in the file and an end of file indicator. In this case, this may take the form ZZ12, ZZ indicating end of file and 12 indicating the total number of instructions contained within the file.

The retry process 60 for transmission of the OUT file 31 involves use of various counters including a connect retry counter and a failure retry counter. The connect retry counter is incremented if there is a failure to connect or a failure during log-on. The failure retry counter is incremented if the communications session is interrupted, if there is an invalid check on an outgoing file, if there are invalid wipe records, or if connection is lost during reception of the OUT file, etc.

In step 61, the transmit counter in the reference records 23(a) associated with a validly transmitted OUT file are incremented in the reference database 23. In step 62, an input file referred to as an INP file is received during the same communications session from the relevant HHT 4. The retry process 60 is used for validation as indicated by the step 63 in which similar counter arrangements are used and checksum calculations are made. The microprocessor circuit 5 immediately writes the INP file to disk in its as received format and in step 65 it converts it to a common, delimited format whereby it may be transmitted to the mainframe computer 2 as indicated by the step 66. 0(,4 6 - 13 When the mainframe computer 2 receives the INP file, it automatically monitors all of the records to determine what amendments have been made by the HHTs 4. Some of these amendments or updates may be allowable for a given HHT 4 and some may not be allowable and may be reset by the mainframe computer 2. In addition, fresh update data may be inputted at the mainframe computer 2. Accordingly, the next mainframe file 16 which is received by the communications controller 3 may include a large number of updates which were made in the final two steps of the previous cycle and the various comparing operations are therefore very important. If a fresh update has been made, the difference in data will be determined even though the counters will have the same values. If the update is not fresh and has not been successfully transmitted to the relevant HHT 4, then a counter difference will be determined. Either event causes the record to be written to the relevant OUT file for transmission to the various HHTs 4. The INP file has a similar record instruction structure to that of the OUT file, the only difference being that wipe commands are not included.

It will be appreciated that the invention provides a communications method which allows transmission and reception of data in an extremely simple manner. The main advantages of a mainframe or large host computer 2 are achieved even though they are not compatible with a large number of HHTs 4. Synchronisation is achieved by operation of the communications controller 3 in an extremely simple and reliable manner.

The invention is not limited to the embodiments hereinbefore described, but may be varied in construction and detail.

Claims (9)

1. A data communications method carried out by a host data processor, a communications controller, and a plurality of portable data processors, the communications controller comprising a microprocessor circuit, a memory and a non-volatile data storage device, the method comprising the steps of:for initialisation, the communications controller transmitting signals to the host processor setting a data record structure in which communicationsspecific fields are embedded, thereby allowing the host processor to carry out either batch or real-time data processing operations and generating an output file in a structure which may be used for further communications; for communications, the communications controller carrying out the following steps :receiving a common-format file having a preset structure and comprising processed data records from the host processor; automatically sorting the records in groups according to the processed data record type; writing each record in turn into the communications controller memory and for each record:reading at least two embedded communications-specific identifier data fields within the record and combining them to generate a unique record key; -9500*6 addressing a reference database stored in the non-volatile data storage device with the generated key and retrieving a corresponding reference record; comparing the current and reference records; identifying any data difference and writing any updates included in the current record and which are not included in the reference record to the reference record; incrementing an embedded communicationsspecific transmit counter value in the current record; if there are no differences, reading values of the transmit counter in the current and reference records; and if there are data differences, or if there are transmit counter value differences, writing the current record to an outgoing file; when all records for a particular set of portable data processors have been processed by the communications controller, the controller establishing a communications session and directing transmission of the outgoing file to the relevant portable data processors and monitoring transmission characteristics for integrity; if correctly transmitted and received, updating the reference database by incrementing the transmit counters of all relevant reference records; and in the same communications session, receiving an input file of updated data records from the portable data processors and automatically writing them to the storage device, and subsequently processing the file in the memory to convert it to the common format for the host processor and transmitting the file to the host processor in this format.

2. A method as claimed in claim 1, wherein the outgoing file structure includes initial file deletion instructions if there is greater than a preset number of records in that file which are to be updated, thereby allowing clearing of large blocks of memory in the portable data processor at the start of the communications session.

3. A method as claimed in claim 2, wherein the file deletion instruction is repeated to ensure integrity.

4. A method as claimed in any preceding claim, wherein the outgoing file includes update instructions for individual records, instructions for particular record types being contiguous and each instruction comprising in sequence an indicator of the record type, an update command, the key and communications sequence.

5. A method as claimed in claim 4, wherein the update command includes appending, deleting, or searching and amending commands. - 17

6. A method as claimed in any of claims 2 to 5, wherein the outgoing file includes an instruction at the end of a contiguous string of instructions summarising 5 the number of instructions and indicating the nature of the records involved.

7. A method as claimed in any of claim 2 to 6, wherein the outgoing file includes an end instruction which indicates the quantity of instruction records 10 included in the file.

8. A method as claimed in any preceding claim, wherein the incoming file has a similar record instruction structure to the outgoing file.

9. A method substantially as hereinbefore described, 15 with reference to and as illustrated in the accompanying drawings .