WO1993019423A1 - Data collection interface system - Google Patents

Data collection interface system Download PDF

Info

Publication number
WO1993019423A1
WO1993019423A1 PCT/US1993/002508 US9302508W WO9319423A1 WO 1993019423 A1 WO1993019423 A1 WO 1993019423A1 US 9302508 W US9302508 W US 9302508W WO 9319423 A1 WO9319423 A1 WO 9319423A1
Authority
WO
WIPO (PCT)
Prior art keywords
data collection
host
interface
peripheral
data
Prior art date
Application number
PCT/US1993/002508
Other languages
French (fr)
Inventor
Julio P. Roque
Walter Todd Matthews
Original Assignee
Intersoft Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intersoft Systems, Inc. filed Critical Intersoft Systems, Inc.
Publication of WO1993019423A1 publication Critical patent/WO1993019423A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/12Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • G06F13/124Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine

Definitions

  • the present invention relates generally t,o the field of data collection systems, and, in its most preferred embodiments, to the field of interfacing between data collection peripherals and host applications.
  • Data collection devices have become very popular in recent years. Their popularity is attributable, at least in part, to ever growing desires for faster and more efficient methods of collecting and processing information. It has become very desirable to have information updated and validated on a real time basis Spurred on by the demand, a large number of hardware manufacturers have developed many different types of data collection devices, including fixed station terminals, RF (radio frequency) terminals, barcode readers, scales, PLC's (programmable logic controllers), and verbal response units.
  • RF radio frequency
  • the present invention includes a data collection interface system which, in its most preferred embodiment, includes a method and apparatus for interfacing between various types of data collection devices and various types of host systems communicating through various types of communication formats, wherein the apparatus of the preferred embodiment includes a controller device which includes components and readily configurable programming objects for conditioning, processing, storing, and transferring data received from host systems and data collection devices.
  • the controller device also functions as the host system. Such an embodiment does not include additional host systems separate from the controller device.
  • Another object of the present invention is to provide a data collection network which includes data collection peripherals connected to a readily- configurable controller interface running host applications.
  • Another object of the present invention is to provide a readily-configurable interface between various types of data peripherals and various types of host systems.
  • Yet another object of the present invention is to provide a connectivity system which provides host independence through utilization of local distributed processing and data storage components.
  • Still another object of the present invention is to provide a method and apparatus for graphically configuring a data collection network through CASE (computer aided software engineering) methodology.
  • Still another object of the present invention is to provide a distributed platform method for configuring and operating an interface between .data collection devices and host systems which includes operation procedures which are independent from particular types of data collection devices.
  • Still another object of the present invention is to provide a connectivity interface device which incorporates a method for accommodating terminal emulation (transaction mapping), and peer to peer communication formats with host systems.
  • FIG. 1 is a block diagram representation of the physical domain of a data collection system which includes a Data Collection Interface System in accordance with a preferred embodiment of the present invention.
  • FIG. 2 is a block diagram representation of the physical domain of the data collection interface system of FIG. 1.
  • FIG. 3 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a first layout scenario.
  • FIG. 4 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a second layout scenario.
  • FIG. 5 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a third layout scenario.
  • FIG. 6 is an entity relationship diagram of the data model of the present invention in accordance with the preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now in greater detail to the drawings, in which like numerals represent like components throughout the several views, a block diagram representation of the physical domain of a data collection system 10 is shown in FIG. 1 including an Interface System 50 in accordance with a preferred embodiment of the present invention. The interface system 50 is shown bridging the gap between a host system 12 and a peripheral system 30.
  • the host system 12 is connected to the interface system 50 through a host link 20, and the peripheral system 30 is connected to the interface system 50 through a peripheral link 40.
  • the host system 12 and peripheral system 30 are representative of one or more hosts and data collection peripherals.
  • examples of acceptable host systems 30 include standalone and network arrangements of mainframe computers, midrange computers, mini computers, and personal computers, from manufacturers such as IBM (International Business Machines) of Armonk, N.Y., DEC (Digital Equipment Corporation) of Maynard, MA, and HP (Hewlett-Packard) of Palo Alto, CA, etc. It should be understood that the scope of the present invention is intended to include other host systems 12 not specifically identified above.
  • all disclosures of acceptable examples of elements are intended to be given without limitation, thus the scope of the present invention is intended to cover other examples of such elements.
  • acceptable host links 20 include connection methods considered known and/or sold as "DFT” (Distributed Function Terminal), “SDLC” (Synchronous Data Link Control), “IBM Token Ring”, “IBM ETHER ⁇ ND NETWORK”, “IBM PC NETWORK”, twinaxial, X.25, and asyncronous.
  • DFT Distributed Function Terminal
  • SDLC Serial Control
  • IBM Token Ring "IBM ETHER ⁇ ND NETWORK”
  • IBM PC NETWORK twinaxial, X.25, and asyncronous.
  • Acceptable communication protocols include communication protocols known and/or sold as “APPC” (Advanced Program to Program Communication), “DAE” (Distributed Automation Edition), “NETBIOS”, “3270 TRANSACTION MAPPING”, “5250 TRANSACTION MAPPING”, “NOVELL IPX/SPX”, “OS/2 MAIL” (OS/2 Inter-Process Communication), “OS/2 NAMED PIPES”, “TCP/IP”, and “DECNET”, etc.
  • examples of acceptable peripheral systems 30 include fixed station terminals, RF (radio frequency) terminals, barcode readers, scales, PLC's (programmable logic controllers), verbal response units, and printers, etc., from manufacturers such as IBM, Intermec of Everett, WA, LXE of N ⁇ rcross, GA, Norand of Cedar Rapids, IA, Symbol/MSI of Bohemia, NY, and Telxon of Akron, OH, etc.
  • Examples of acceptable peripheral links 40 include RS-232, RS-422, token ring, ISA bus, and MCA bus. It should also be understood that the scope of the present invention is intended to include other peripheral systems 30 and peripheral links 40 not listed above.
  • FIG. 2 is a block diagram representation of the physical domain of the interface system 50 in accordance with the preferred embodiment of the present invention.
  • a processor system 51 which includes a real time source, is shown attached to a host adapter 52 and an async device 81, which are connected to the host link 20 and the peripheral link 40, respectively.
  • a mouse 48 and a keyboard 49 are shown as input devices for the interface system 50.
  • a graphical display adapter 53 is shown connecting a graphical display 54 to the processor system 51.
  • the two types of memory systems shown connected to the processor system 51 are RAM 45 (Random Access Memory) and fixed disc 47, shown connected through a fixed disc controller 46.
  • an acceptable physical domain of an interface system 50 includes an "IBM” "PS/2" Model 80 personal computer with at least 6 MB (megabytes) of RAM, 60 MB of fixed disc space, a graphical display, a mouse, and a host adapter corresponding to one of the host link connection types listed above.
  • Other acceptable examples include other personal computers manufactured by IBM and others having both Micro ⁇ Channel and Industry Standard Architectures (MCA and ISA) .
  • MCA and ISA Micro ⁇ Channel and Industry Standard Architectures
  • ARTIC/2 an intelligent serial communications controller, sold under the tradename "ARTIC/2" from IBM, to increase the number of available ASYNC ports is also considered within the scope of the present invention.
  • FIG. 3 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a first layout scenario.
  • the host system 12 is shown including HI 14 (Host No. 1) and H2 15 (Host No. 2) connected together in a network arrangement and connected to the host adapter 52 of the interface system 50 through the host link 20.
  • the peripheral system 30 is shown connected to the async device 81 of the interface system 50 through the peripheral link 40.
  • Included within the peripheral system 50 is an RF base 32 which is linked through radio waves to two data collection peripherals represented as TA 33 (Terminal A) and TB 34 (Terminal B) .
  • the portions of the program domain of the first layout scenario of the preferred embodiment of the present invention which are shown in FIG. 3 include various programming elements of the interface system 50.
  • the connections shown are understood to be logical, message delivery connections which are accomplished through methods which are discussed in greater detail below.
  • a host communication manager 55 consisting of an adapter driver 56 and a protocol manager 57, is shown connected to the host adapter 52.
  • the host adapter 52 is embodied in hardware, and the host communication manager 55 is embodied in software.
  • Two host HAE's Host Application Engines
  • HI HAE 60 Host No. 1 HAE
  • H2 HAE 61 Host No. 2 HAE
  • the host HAE's 60, 61 are shown connected to the protocol manager 57, a host router 65, and a scheduler 69.
  • the host router 65 and scheduler 69 are connected to two terminal PAE's (Peripheral Application Engines) which are indicated as TA PAE 72 (Terminal A PAE) and TA PAE 73 (Terminal B PAE).
  • the terminal PAE's 72, 73 are also shown connected to a peripheral router 67,, which, along with the scheduler 69, is also connected to a device controller 77.
  • a device driver 78 is shown connecting the device controller 77 to an async driver 80, which is shown connected to the async device 81.
  • a resource manager 83 is shown connected through a repository server 84 to a stored repository 86.
  • a runtime generator 92 is also shown connected to the stored repository 92.
  • a user facility 94 is also shown connected to the repository 86.
  • the HAE's 60, 61, PAE's 72, 73, host router 65, scheduler 69, peripheral router 67, and device controller/driver 77, 78 are independent software application threads having their own memory and functioning as independent processes. Each of those threads are created, configured, or activated by the user through use of the user facility 94 in conjunction with the resource manager 83 and repository server 84. Such configurations are stored in the repository 86 as objects, associations, and properties and spawned at initialization by the runtime generator 92. Many of these aspects of the program domain of the interface system 50 are discussed in greater detail below with reference to FIG. 6.
  • the TA PAE 72 sends a message to the scheduler 69 requesting a particular screen be sent to TA 33, while referencing TA 33 with a logical name which is independent of any actual physical device.
  • the scheduler 69 determines that the device controller 77 should receive the message by looking to a table data structure created for the scheduler 69 and routes the message to the device controller 77.
  • the device controller 77 references another table data structure to determine the actual address of the T ⁇ 33.
  • the device driver 78 then communicates with the RF base 32 through the async driver 80, async device 81, and peripheral link 40 in a device-specific protocol to send the screen of information to the TA 33 .
  • a user Upon viewing the resulting screen on the TA 33, a user responds by entering appropriate information into the TA 33, which transmits the response information back to the RF base 32.
  • the RF base 32 then transmits the information back to the device controller 77 through the peripheral link 40, async device 81, async driver 80, and device driver 78.
  • the device driver 77 translates the actual address of TA 33 back into the logical name of T ⁇ 33 and forwards the information to the peripheral router 67.
  • the peripheral router 67 determines that TA PAE 72 should receive the information and subsequently routes the information to the TA PAE 72.
  • the TA PAE 72 which had been idle before receiving the response information, then chooses to have the information validated by the HI 14.
  • the TA PAE 72 then generates and sends another message to the scheduler 69 to send the response information to HI 14.
  • the scheduler 69 correlates the request with the HI HAE 60 and sends the information to the HI HAE 60.
  • the HI HAE 60 then communicates with the host communication manager 55 to send the information through the host adapter 52 and host interface 20 to HI 14.
  • HI 14 then processes the information as programmed and responds through the host interface 20 and host adapter 52.
  • the host communication manager 55 then forwards the response to the HI HAE 60, which transfers the information to the host router 65.
  • the host router 65 correlates the host response with another table data structure and determines that T ⁇ PAE 72 should receive the response and subsequently routes the information to the TA PAE 72.
  • the TA PAE 72 then repackages the result of the validation and sends that information to the TA 33 in a manner similar to the transfer of the data-entry screen.
  • FIG. 4 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a second layout scenario.
  • This second layout scenario is similar, in many respects, to the first layout scenario shown in FIG. 3. Rather than identify the similarities, the following disclosure focuses on the distinctions.
  • the host system 12 includes one mainframe computer running two 3270 sessions, denoted 3270 SI 17 and 3270 S2 18.
  • the peripheral system 30 includes two bases, a fixed station concentrator 37 and an RF base 32.
  • the fixed station concentrator 37 is connected to two data collection terminals, denoted T ⁇ 33 and TB 34.
  • the RF base 32 is connected through radio waves to radio terminal TC 35.
  • the fixed station concentrator 37 is connected to the interface system 50 through a peripheral link 40', and the RF base 32 is connected to the interface link 50 through another peripheral link 40' ' .
  • two session HAE's 62, 63 are connected between the protocol manager 57 and the host router 65.
  • a session pooler 88 is connected between the scheduler 69 and the HAE's 62, 63.
  • Three PAE's denoted TA PAE 72, TB PAE 73, and TC PAE 74, are connected between the host router 65, peripheral router 67, and scheduler 69.
  • Two device controllers denoted device controller/driver I 77', 78' and device controller/driver II 77* ', 78' ', are shown connected between scheduler 69, peripheral router 67 and async driver 80.
  • host system 12 "IBM” 3090 mainframe computer running two 3270 sessions
  • host link 20 "DFT” cable
  • host adapter 52 "DFT” adapter
  • adapter driver 56 "DFT” driver from the "IBM OS/2 COMMUNICATION MANAGER” software system
  • protocol manager 57 "EHLLAPI” (Emulation High Level Language Application Programming Interface) protocol subsystem from the "IBM OS/2 COMMUNICATION
  • the layout scenario shown in FIG. 4 is designed to perform 3270 transaction mapping and session sharing. Transaction mapping is accomplished when the interface system 50 is configured to select only certain portions of output from a 3270 session and display those portions in various screen locations on the data collection terminal 33, 34, 35. Each screen on each data collection terminal 33, 34, 35 is designed by the user to reflect custom mapping. Such mapping includes the rules and procedures that define how one user interface is mapped to another user interface.
  • the interface system 50 accomplishes session sharing, thereby maximizing use of a limited host resource, through use of the session pooler 88.
  • the session pooler 88 monitors the status of each HAE 62, 63 to determine which of them receives a particular message, regardless of from which PAE 72, 73, 74 the message originated. If both of the HAE's 62, 63 are busy, or the host system 12 is down, the session pooler 88 queues the messages in a first-in/first-out queue structure. In this manner, all three data collection terminals 33, 34, and 35 can operate virtually simultaneously while utilizing only two 3270 sessions 17, 18.
  • FIG. 5 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a third layout scenario.
  • This third layout scenario is similar, in many respects, to both the first and second layout scenarios shown in FIGS. 3 and 4. Again, rather than identify the similarities, the following disclosure focuses on the distinctions.
  • the host system 12 includes one mainframe computer.
  • the peripheral system 30 is attached to the interface system 50 through the peripheral link 40 and includes one fixed terminal base 38 connected to two terminals TA 33 and TB 34.
  • only one host HAE 64 is shown connected between the protocol manager and the host router 65.
  • An additional server SAE (Server Application Engine) 90 is shown connected between the PAE's 72, 73 and the host HAE 64.
  • host link 20 RS-232 cable
  • host adapter 52 "SDLC” adapter
  • adapter driver 56 "SDLC” driver from the "IBM OS/2 COMMUNICATION MANAGER” software system
  • protocol manager 57 "APPC” protocol subsystem from the "IBM OS/2 COMMUNICATION MANAGER” software system
  • async driver 80 "IBM” async driver from the "IBM OS/2” software system
  • peripheral system 30 "INTERMEC” 9154/9511 fixed terminal system.
  • the server SAE 90 utilizes two tables stored both in RAM 45 and on the fixed disk 47 (shown in FIG. 2).
  • the SAE 90 utilizes a user state table to track the status of each terminal so that a user can change from terminal to terminal during any one session.
  • a terminal state table is utilized to record the status of each terminal to preserve the state of the data collection system 10 in the event of a power failure.
  • all of the application engines (PAE's, HAE's, and SAE's) throughout the various layout scenarios shown in FIGS. 3 - 5 run as independent interpreters of applications which utilize user-defined objects, associations, and properties stored in the repository 86.
  • the application engines interpret user-defined procedures
  • the routers 65, 67, scheduler 69, and device controllers 77 are predefined, looping processes which act only when so directed by application engines. There is, therefore, a great deal of versatility available in designing a layout scenario.
  • FIG. 6 is an entity relationship diagram of the conceptual data model of the present invention as it exists in the repository 86 after having been created by a user utilizing the user facility 94 (shown in FIGS. 3 - 5), in accordance with the preferred embodiment of the present invention.
  • the repository 86 is a storage location for the objects, associations, and properties which define a data collection system layout scenario.
  • the blocks shown in FIG. 6 represent objects which are maintained in the repository 86.
  • the interconnecting lines and icons represent the associations between the objects, the links which join all of the components of a layout together. These associations are also maintained in the repository 86. Properties of each of the objects and associations, including specialized properties known as procedures, are also maintained in the repository 86.
  • a data collection application object 116 is shown connected to a host application object 132 by a line with icons which are read "zero to many".
  • a data collection application object 116 is associated with "zero to many" host application objects 132
  • a host application object 132 is associated with "zero to many" data collection application objects 116.
  • a data collection application object 116 may nevertheless be associated with a large number of host application objects 132, and visa versa.
  • the data collection application object 116 is also associated with a terminal object 114 in such a way that the data collection application object 116 is associated with "zero to many" terminal objects 114, yet the terminal object 114 is associated with "one and only one" data collection application object 116.
  • the only other icon included in FIG. 6 is shown to relate a peripheral network object 112 to the terminal object 114.
  • the terminal object 114 is said to be associated with "zero to many" peripheral network objects 112, but the peripheral network object 112 is associated with "one to many" (or “at least one") terminal objects 114.
  • Diagrams such as FIG. 6 are also frequently referred to as meta-models, or data about data.
  • FIG. 6 and the following explanatory information are considered to provide a conceptual view of the rules of relationships between the objects shown.
  • the user facility 94 (FIGS. 3 - 5) provides a CASE (computer aided software engineering) environment where a user designs a particular data collection system layout scenario through the use of graphical and prompted input screens.
  • the rules of relationships shown in FIG. 6 are automatically maintained by the interface system 50 during the design of a layout scenario.
  • the configuration object 110 is the object representing a data collection system and can be viewed as the parent record of any particular layout scenario.
  • a configuration object 110 is associated with zero to many host application objects 132, peripheral network objects 112, server application objects 130, event objects 128, and serial devices 126.
  • the host application object 132 is associated with zero to many configuration objects 110, server application objects 130, external procedure objects 118, and data collection application objects 116.
  • the host application object 132 describes the communication path to an application running on a host computer.
  • a procedure property of the host application object 132 is responsible for (1) putting information in whatever format the host expects, (2) sending the information, (3) accepting the host's response, and (4) putting the response information in a form which can be used by the interface system 50 (shown in FIGS. 3 - 5). If applicable, another host procedure is responsible for transaction mapping rules.
  • Another group of properties of the host application object 132 describes the particular type of communication method used, including APPC, DAE, 3270/5250 transaction mapping, and user-defined methods.
  • the interface system 50 communicates via conversations which are listed for a user to add, delete, or change.
  • Each APPC host application object 132 is an independent transaction program that runs concurrently with other host transaction programs and can communicate over one or more conversations occupying one or more LU (Logical Unit) sessions.
  • LU Logical Unit
  • APPC properties include conversation name (the name used by interface system 50 procedures to address a particular conversation), local LU (name of local logical unit), partner LU (name of the host application's logical unit), local TP (name of local transaction program), partner TP (the fully qualified file name of the host application), and mode.
  • the DAE communication method also communicates via conversations, thus a similar user-accessible list is provided for editing.
  • DAE properties include conversation name (the name used by interface 50 procedures to address a particular conversation) , local resource name (identification of the interface system 50, including program name and network node address), and partner resource name (the name and network address of the host application) .
  • the 3270/5250 transaction mapping communication method supports multiple concurrent 3270 or 5250 terminal sessions. Properties include identifying which terminal sessions are used.
  • a user-defined communication method offers custom communication programs access to a library of subroutines which allow the user to send and receive mail from the interface system 50. The only property of this method is the fully qualified path name of the custom host program.
  • the peripheral network object 112 is associated with zero to many configuration objects 110 and with one to many terminal objects 114.
  • the peripheral network object 112 includes properties which describe the type of terminal controller used, such as RF Base 32 or fixed station concentrator 37 shown in FIG. 4. These properties include vendor, model, serial communication port name, baud rate, parity, data bits, stop bits, and other vendor-specific and model-specific parameters.
  • the terminal object 114 is associated with zero to many peripheral network objects 112 and with one and only one data collection application object 116. Any device connected to a peripheral network is considered to be a terminal, including RF terminals, fixed terminals, printers, scanners, scales, etc.
  • the terminal object 114 includes properties describing, at least, the vendor, model and address of the terminal.
  • the serial device object 126 is associated with zero to many configuration objects 110 and with one and only one data collection application 116.
  • the serial device object 126 includes properties which describe serial communication with devices which attach directly to the interface system 50 without an intervening peripheral network controller. These properties include serial port name, baud rate, parity, data bits, and stop bits.
  • the data collection application object 116 is associated with zero to many terminal objects 114, host application objects 132, serial device objects 126, server application objects 130, form objects 120, and external procedure objects 118.
  • the data collection application object 116 represents the task to which a terminal or serial device is dedicated.
  • the principle task of a data collection application object 116 is to collect information from terminals or serial devices.
  • a procedure property of the data collection application object 116 often includes steps instructing a terminal to prompt a user for information, accepting a response, conducting one of several processes based on the response, and optionally preparing and sending information to a host application for transfer to a host.
  • the form object 120 is associated with zero to many data collection application objects 116, external procedure objects 118, and field objects 122.
  • the form object 120 is a terminal, or serial device, screen layout specification.
  • the properties of the form object 120 include the terminal type, the text appearing on the screen, and the location of the text.
  • the field object 122 is associated with zero to many form objects 120.
  • Field objects 122 represent the variable parts of a form object 120. Properties of field objects 122 include field type, eg., alphanumeric, date, phone, time, etc., and field length.
  • a location property is attached to the association between field objects 122 and form objects 120 to define where a field object 122 is placed on a particular screen.
  • the external procedure object 118 is associated with zero to many host application objects 132, data collection application objects 116, form objects 120, event objects 128, and server application objects 130.
  • the external procedure object 118 is similar in structure to procedure properties of the other applications 130, 132, 116.
  • an external procedure object 118 does not belong to any particular application.
  • procedural tasks which must be performed more than once, such as computing a factorial can be isolated into an external procedure objects 118 to make the procedural code re-usable.
  • an external procedure object 118 is running, it is treated as part of the application that called it, thus, the external procedure object 118 has access to all of the parent's information.
  • the parent application is a terminal data collection application object 116, the external procedure object 118 can also communicate with a terminal.
  • the server application object 130 is associated with zero to many host application objects 132, data collection application objects 116, configuration objects 110, and external procedure objects 130.
  • the server application object 130 is an object with a procedure property that provides a service or manages a resource that can be shared by other applications.
  • the above discussions regarding the server SAE 90 shown in FIG. 5 pertain to two sample server application objects 130.
  • the server application object 130 is a shared resource which involves storing or transferring information within the interface system 50.
  • the event object 128 is associated with one and only one configuration object 110 and external procedure object 118.
  • the event object 128 is a scheduled initiation by the configuration object 110 of an external procedure object 118 or other external program supported by the interface system 50 which is scheduled to occur at a given time or at regular intervals. Requests can also be sent to other applications.
  • a user utilizes the user facility 94, a GUI (Graphical User Interface) CASE tool system, to create and edit the repository 86.
  • the CASE interface also provides system activity monitoring services, diagnostic capabilities which include animation and prototyping of proposed system operation, and notification of the effects on other objects of proposed changes to any particular layout scenario based on associations and rules of relationships.
  • the following ten tools are included: network configuration facility, application assignment matrix, application flow chart, procedure flow chart, application structure chart, procedure structure chart, data structure facility, form painter facility, repository object list, repository services.
  • the network configuration facility tool is used to graphically define the hardware components (peripheral system 30) in a particular layout scenario. Defining an object involves adding the object, entering its properties, and associating it to other objects (if applicable).
  • the application assignment matrix is used to define applications and associate them with terminals.
  • the application flow chart is used to graphically define the logical flow of an application in terms of objects and flows.
  • the procedure flow chart is used to graphically define the logical flow of a procedure in terms of objects and flows.
  • the application structure chart is used to graphically define the calling hierarchy of procedures associated with an application, a high-level decomposition of an application.
  • the procedure structure chart is used to graphically define the calling hierarchy among different procedures.
  • the data structure facility is used to define the data structure associated with a data area (forms, transactions, tables), including mapping a 3270 or 5270 screen to a transaction data structure.
  • the form painter facility is used to define the characteristics of a screen form.
  • the repository object list is used to list all of the objects in a repository by object type so that objects can be added, deleted, and renamed.
  • the repository services tool is used to keep track of all of the repositories in the current system, acting as a repository container.

Abstract

A data collection interface system (50) which includes a method and apparatus for interfacing between various types of data collection devices (30) and various types of host systems (12) communicating through various types of communication formats, wherein the apparatus includes a controller device (51) which includes components and readily configurable programming objects for conditioning, processing, storing, and transferring data received from host systems and data collection devices.

Description

DATA COLLECTION INTERFACE SYSTEM
BACKGROUND OF THE INVENTION The present invention relates generally t,o the field of data collection systems, and, in its most preferred embodiments, to the field of interfacing between data collection peripherals and host applications. Data collection devices have become very popular in recent years. Their popularity is attributable, at least in part, to ever growing desires for faster and more efficient methods of collecting and processing information. It has become very desirable to have information updated and validated on a real time basis Spurred on by the demand, a large number of hardware manufacturers have developed many different types of data collection devices, including fixed station terminals, RF (radio frequency) terminals, barcode readers, scales, PLC's (programmable logic controllers), and verbal response units.
The advantages associated with using the various types of data collection devices are considered well known and understood in the industry. However, there are also various problems associated with the devices which are considered equally well understood. There are currently large varieties of hosts, host applications, host connectivity formats, and data collection devices which are both currently in use and on the market today. Most of the data collection device systems utilize communication techniques which are unique to each particular manufacturer.
Unfortunately, it is often very difficult, time consuming, and expensive for users to integrate data collection systems into their host computer systems. Users are often forced to hire specially skilled computer hardware specialists to go through costly trial and error programming and reprogramming efforts in order to get any particular type of data collection system to communicate with any particular host system. Furthermore, after the custom integration tasks are completed, changes or additions to the data collection network often involve similar difficulties. Moreover, and perhaps most unfortunately, mundane connectivity concerns often outweigh the logically more important performance, pricing, and applicability concerns. Also, most data collection networks are host dependant and very vulnerable to host downtime. Consequently, data collection device users are often unable to record data, or worse yet, the recorded data is lost. Moreover, most data collection networks are guilty of poor host resource allocation, and terminal mismatch problems are all too common. There is, therefore, a need in the industry for a system which addresses these and other related, and unrelated, problems.
SUMMARY OF THE INVENTION
Briefly described, the present invention includes a data collection interface system which, in its most preferred embodiment, includes a method and apparatus for interfacing between various types of data collection devices and various types of host systems communicating through various types of communication formats, wherein the apparatus of the preferred embodiment includes a controller device which includes components and readily configurable programming objects for conditioning, processing, storing, and transferring data received from host systems and data collection devices.
In an alternate embodiment of the present invention, the controller device also functions as the host system. Such an embodiment does not include additional host systems separate from the controller device.
It is therefore an object of the present invention to provide a data collection network which includes data collection peripherals connected to at least one host system through a readily-configurable controller interface.
Another object of the present invention is to provide a data collection network which includes data collection peripherals connected to a readily- configurable controller interface running host applications.
Another object of the present invention is to provide a readily-configurable interface between various types of data peripherals and various types of host systems.
Yet another object of the present invention is to provide a connectivity system which provides host independence through utilization of local distributed processing and data storage components.
Still another object of the present invention is to provide a method and apparatus for graphically configuring a data collection network through CASE (computer aided software engineering) methodology.
Still another object of the present invention is to provide an object-oriented method for configuring and operating an interface between data collection devices and host systems. Still another object of the present invention is to provide a method for configuring and operating an interface between data peripherals and host systems which includes spawning at least one independent software application thread for each data collection peripheral and each host application.
Still another object of the present invention is to provide a distributed platform method for configuring and operating an interface between .data collection devices and host systems which includes operation procedures which are independent from particular types of data collection devices.
Still another object of the present invention is to provide a connectivity interface device which incorporates a method for accommodating terminal emulation (transaction mapping), and peer to peer communication formats with host systems.
Still another object of the present invention is to provide selective methods of host session sharing for optimal host resource allocation. Still another object of the present invention is to provide a data collection system interface which provides for peripheral-to-peripheral communication.
Other objects, features and advantages of the present invention will become apparent upon reading and understanding this specification, taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram representation of the physical domain of a data collection system which includes a Data Collection Interface System in accordance with a preferred embodiment of the present invention. FIG. 2 is a block diagram representation of the physical domain of the data collection interface system of FIG. 1.
FIG. 3 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a first layout scenario.
FIG. 4 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a second layout scenario.
FIG. 5 is a block diagram representation of portions of the physical and program domains of the data collection system of FIG. 1 shown in accordance with a third layout scenario. FIG. 6 is an entity relationship diagram of the data model of the present invention in accordance with the preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Referring now in greater detail to the drawings, in which like numerals represent like components throughout the several views, a block diagram representation of the physical domain of a data collection system 10 is shown in FIG. 1 including an Interface System 50 in accordance with a preferred embodiment of the present invention. The interface system 50 is shown bridging the gap between a host system 12 and a peripheral system 30. The host system 12 is connected to the interface system 50 through a host link 20, and the peripheral system 30 is connected to the interface system 50 through a peripheral link 40. The host system 12 and peripheral system 30 are representative of one or more hosts and data collection peripherals. In the preferred embodiment of the present invention, examples of acceptable host systems 30 include standalone and network arrangements of mainframe computers, midrange computers, mini computers, and personal computers, from manufacturers such as IBM (International Business Machines) of Armonk, N.Y., DEC (Digital Equipment Corporation) of Maynard, MA, and HP (Hewlett-Packard) of Palo Alto, CA, etc. It should be understood that the scope of the present invention is intended to include other host systems 12 not specifically identified above. Furthermore, throughout the specification, all disclosures of acceptable examples of elements are intended to be given without limitation, thus the scope of the present invention is intended to cover other examples of such elements.
Examples of acceptable host links 20 include connection methods considered known and/or sold as "DFT" (Distributed Function Terminal), "SDLC" (Synchronous Data Link Control), "IBM Token Ring", "IBM ETHERΛND NETWORK", "IBM PC NETWORK", twinaxial, X.25, and asyncronous. Acceptable communication protocols include communication protocols known and/or sold as "APPC" (Advanced Program to Program Communication), "DAE" (Distributed Automation Edition), "NETBIOS", "3270 TRANSACTION MAPPING", "5250 TRANSACTION MAPPING", "NOVELL IPX/SPX", "OS/2 MAIL" (OS/2 Inter-Process Communication), "OS/2 NAMED PIPES", "TCP/IP", and "DECNET", etc.
In accordance with the preferred embodiment of the present invention, examples of acceptable peripheral systems 30 include fixed station terminals, RF (radio frequency) terminals, barcode readers, scales, PLC's (programmable logic controllers), verbal response units, and printers, etc., from manufacturers such as IBM, Intermec of Everett, WA, LXE of Nσrcross, GA, Norand of Cedar Rapids, IA, Symbol/MSI of Bohemia, NY, and Telxon of Akron, OH, etc. Examples of acceptable peripheral links 40 include RS-232, RS-422, token ring, ISA bus, and MCA bus. It should also be understood that the scope of the present invention is intended to include other peripheral systems 30 and peripheral links 40 not listed above. FIG. 2 is a block diagram representation of the physical domain of the interface system 50 in accordance with the preferred embodiment of the present invention. A processor system 51, which includes a real time source, is shown attached to a host adapter 52 and an async device 81, which are connected to the host link 20 and the peripheral link 40, respectively. A mouse 48 and a keyboard 49 are shown as input devices for the interface system 50. A graphical display adapter 53 is shown connecting a graphical display 54 to the processor system 51. The two types of memory systems shown connected to the processor system 51 are RAM 45 (Random Access Memory) and fixed disc 47, shown connected through a fixed disc controller 46.
One example of an acceptable physical domain of an interface system 50 includes an "IBM" "PS/2" Model 80 personal computer with at least 6 MB (megabytes) of RAM, 60 MB of fixed disc space, a graphical display, a mouse, and a host adapter corresponding to one of the host link connection types listed above. Other acceptable examples include other personal computers manufactured by IBM and others having both Micro¬ Channel and Industry Standard Architectures (MCA and ISA) . Inclusion of an intelligent serial communications controller, sold under the tradename "ARTIC/2" from IBM, to increase the number of available ASYNC ports is also considered within the scope of the present invention.
FIG. 3 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a first layout scenario. Within the physical domain, the host system 12 is shown including HI 14 (Host No. 1) and H2 15 (Host No. 2) connected together in a network arrangement and connected to the host adapter 52 of the interface system 50 through the host link 20. The peripheral system 30 is shown connected to the async device 81 of the interface system 50 through the peripheral link 40. Included within the peripheral system 50 is an RF base 32 which is linked through radio waves to two data collection peripherals represented as TA 33 (Terminal A) and TB 34 (Terminal B) .
The portions of the program domain of the first layout scenario of the preferred embodiment of the present invention which are shown in FIG. 3 include various programming elements of the interface system 50. The connections shown are understood to be logical, message delivery connections which are accomplished through methods which are discussed in greater detail below. A host communication manager 55, consisting of an adapter driver 56 and a protocol manager 57, is shown connected to the host adapter 52. In the preferred embodiment, the host adapter 52 is embodied in hardware, and the host communication manager 55 is embodied in software. Two host HAE's (Host Application Engines) are indicated as HI HAE 60 (Host No. 1 HAE) and H2 HAE 61 (Host No. 2 HAE). The host HAE's 60, 61 are shown connected to the protocol manager 57, a host router 65, and a scheduler 69. The host router 65 and scheduler 69 are connected to two terminal PAE's (Peripheral Application Engines) which are indicated as TA PAE 72 (Terminal A PAE) and TA PAE 73 (Terminal B PAE). The terminal PAE's 72, 73 are also shown connected to a peripheral router 67,, which, along with the scheduler 69, is also connected to a device controller 77. A device driver 78 is shown connecting the device controller 77 to an async driver 80, which is shown connected to the async device 81. A resource manager 83 is shown connected through a repository server 84 to a stored repository 86. A runtime generator 92 is also shown connected to the stored repository 92. Furthermore, a user facility 94 is also shown connected to the repository 86. The following are examples of acceptable components and characteristics for the layout scenario of the preferred embodiment shown in FIG. 3: HI 14 & H2 15 = "IBM" personal computers connected over an "IBM TOKEN RING" network system as an "IBM" "CIM" (Computer Integrated Manufacturing) system, communicating through the "DAE" (Distributed Automation Edition) peer-to-peer communication method; host adapter 52 = "IBM TOKEN RING" adapter; adapter driver 56 = "IBM TOKEN RING" driver from the "IBM OS/2 COMMUNICATION MANAGER" software system; protocol manager 57 = "DAE" protocol subsystem from the "IBM COMMUNICATION SYSTEM/2" software system; async driver 80 = "IBM" async driver from "IBM OS/2"- software system; peripheral system 30 = "LXE" RF system. The HAE's 60, 61, PAE's 72, 73, host router 65, scheduler 69, peripheral router 67, and device controller/driver 77, 78 are independent software application threads having their own memory and functioning as independent processes. Each of those threads are created, configured, or activated by the user through use of the user facility 94 in conjunction with the resource manager 83 and repository server 84. Such configurations are stored in the repository 86 as objects, associations, and properties and spawned at initialization by the runtime generator 92. Many of these aspects of the program domain of the interface system 50 are discussed in greater detail below with reference to FIG. 6.
The following sample operational steps are given in order to further explain the operation of the first layout scenario of the interface system 50 shown in FIG. 3. In order to send a data-entry screen from the interface system 50 to TA 33, receive response information from the user of TA 33, use the HI 14 to validate the information, and apprise the user of the validation, the following steps are performed by the data collection system 10. After initialization, the TA PAE 72 sends a message to the scheduler 69 requesting a particular screen be sent to TA 33, while referencing TA 33 with a logical name which is independent of any actual physical device. The scheduler 69 determines that the device controller 77 should receive the message by looking to a table data structure created for the scheduler 69 and routes the message to the device controller 77. The device controller 77 references another table data structure to determine the actual address of the TΛ 33. The device driver 78 then communicates with the RF base 32 through the async driver 80, async device 81, and peripheral link 40 in a device-specific protocol to send the screen of information to the TA 33 .
Upon viewing the resulting screen on the TA 33, a user responds by entering appropriate information into the TA 33, which transmits the response information back to the RF base 32. The RF base 32 then transmits the information back to the device controller 77 through the peripheral link 40, async device 81, async driver 80, and device driver 78. The device driver 77 translates the actual address of TA 33 back into the logical name of TΛ 33 and forwards the information to the peripheral router 67. By correlating the information with another table data structure, the peripheral router 67 determines that TA PAE 72 should receive the information and subsequently routes the information to the TA PAE 72.
The TA PAE 72, which had been idle before receiving the response information, then chooses to have the information validated by the HI 14. The TA PAE 72 then generates and sends another message to the scheduler 69 to send the response information to HI 14. The scheduler 69 correlates the request with the HI HAE 60 and sends the information to the HI HAE 60. The HI HAE 60 then communicates with the host communication manager 55 to send the information through the host adapter 52 and host interface 20 to HI 14. HI 14 then processes the information as programmed and responds through the host interface 20 and host adapter 52. The host communication manager 55 then forwards the response to the HI HAE 60, which transfers the information to the host router 65. In a manner similar to the peripheral router 67, the host router 65 correlates the host response with another table data structure and determines that TΛ PAE 72 should receive the response and subsequently routes the information to the TA PAE 72. The TA PAE 72 then repackages the result of the validation and sends that information to the TA 33 in a manner similar to the transfer of the data-entry screen.
In the preferred embodiment of the present invention, messages are sent, ie. information is transferred, through a technique known as interprocess communication. Each independent thread creates a mailbox, or a linked-list, in memory space which is shared by multiple processes. When an addressed message is sent, a separate mail process packages the information and notifies the recipient that mail is waiting. The recipient thread then reads the mail from the shared memory to complete the communication. FIG. 4 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a second layout scenario. This second layout scenario is similar, in many respects, to the first layout scenario shown in FIG. 3. Rather than identify the similarities, the following disclosure focuses on the distinctions. Within the physical domain, the host system 12 includes one mainframe computer running two 3270 sessions, denoted 3270 SI 17 and 3270 S2 18. The peripheral system 30 includes two bases, a fixed station concentrator 37 and an RF base 32. The fixed station concentrator 37 is connected to two data collection terminals, denoted TΛ 33 and TB 34. The RF base 32 is connected through radio waves to radio terminal TC 35. The fixed station concentrator 37 is connected to the interface system 50 through a peripheral link 40', and the RF base 32 is connected to the interface link 50 through another peripheral link 40' ' . In the program domain, two session HAE's 62, 63 are connected between the protocol manager 57 and the host router 65. A session pooler 88 is connected between the scheduler 69 and the HAE's 62, 63. Three PAE's, denoted TA PAE 72, TB PAE 73, and TC PAE 74, are connected between the host router 65, peripheral router 67, and scheduler 69. Two device controllers, denoted device controller/driver I 77', 78' and device controller/driver II 77* ', 78' ', are shown connected between scheduler 69, peripheral router 67 and async driver 80.
The following are examples of acceptable components and characteristics for the layout scenario of the preferred embodiment shown in FIG. 4: host system 12 = "IBM" 3090 mainframe computer running two 3270 sessions; host link 20 = "DFT" cable; host adapter 52 = "DFT" adapter; adapter driver 56 = "DFT" driver from the "IBM OS/2 COMMUNICATION MANAGER" software system; protocol manager 57 = "EHLLAPI" (Emulation High Level Language Application Programming Interface) protocol subsystem from the "IBM OS/2 COMMUNICATION
MANAGER" software system; async driver 80 = "IBM" async driver from the "IBM OS/2" software system; peripheral system 30 = "LXE" RF system and "INTERMEC" 9154 fixed station system. The layout scenario shown in FIG. 4 is designed to perform 3270 transaction mapping and session sharing. Transaction mapping is accomplished when the interface system 50 is configured to select only certain portions of output from a 3270 session and display those portions in various screen locations on the data collection terminal 33, 34, 35. Each screen on each data collection terminal 33, 34, 35 is designed by the user to reflect custom mapping. Such mapping includes the rules and procedures that define how one user interface is mapped to another user interface. The interface system 50 accomplishes session sharing, thereby maximizing use of a limited host resource, through use of the session pooler 88. The session pooler 88 monitors the status of each HAE 62, 63 to determine which of them receives a particular message, regardless of from which PAE 72, 73, 74 the message originated. If both of the HAE's 62, 63 are busy, or the host system 12 is down, the session pooler 88 queues the messages in a first-in/first-out queue structure. In this manner, all three data collection terminals 33, 34, and 35 can operate virtually simultaneously while utilizing only two 3270 sessions 17, 18. FIG. 5 is a block diagram representation of portions of the physical and program domains of the data collection system 10 in accordance with the preferred embodiment of the present invention and in accordance with a third layout scenario. This third layout scenario is similar, in many respects, to both the first and second layout scenarios shown in FIGS. 3 and 4. Again, rather than identify the similarities, the following disclosure focuses on the distinctions. Within the physical domain, the host system 12 includes one mainframe computer. The peripheral system 30 is attached to the interface system 50 through the peripheral link 40 and includes one fixed terminal base 38 connected to two terminals TA 33 and TB 34. In the program domain, only one host HAE 64 is shown connected between the protocol manager and the host router 65.
An additional server SAE (Server Application Engine) 90 is shown connected between the PAE's 72, 73 and the host HAE 64.
The following are examples of acceptable components and characteristics for the layout scenario of the preferred embodiment shown in FIG. 5: host link 20 = RS-232 cable; host adapter 52 = "SDLC" adapter; adapter driver 56 = "SDLC" driver from the "IBM OS/2 COMMUNICATION MANAGER" software system; protocol manager 57 = "APPC" protocol subsystem from the "IBM OS/2 COMMUNICATION MANAGER" software system; async driver 80 = "IBM" async driver from the "IBM OS/2" software system; peripheral system 30 = "INTERMEC" 9154/9511 fixed terminal system. The server SAE 90 utilizes two tables stored both in RAM 45 and on the fixed disk 47 (shown in FIG. 2). The SAE 90 utilizes a user state table to track the status of each terminal so that a user can change from terminal to terminal during any one session. A terminal state table is utilized to record the status of each terminal to preserve the state of the data collection system 10 in the event of a power failure.
It should be understood that, in the preferred embodiment of the present invention, all of the application engines (PAE's, HAE's, and SAE's) throughout the various layout scenarios shown in FIGS. 3 - 5 run as independent interpreters of applications which utilize user-defined objects, associations, and properties stored in the repository 86. Whereas the application engines interpret user-defined procedures, the routers 65, 67, scheduler 69, and device controllers 77 are predefined, looping processes which act only when so directed by application engines. There is, therefore, a great deal of versatility available in designing a layout scenario.
Also, all of the application engines have access to the fixed disk 47 (shown in FIG. 2) for storage of information, thus host independence is easily realized. Furthermore, additional processing by the application engines of the interface system 50 results in a data collection system 10 with distributed processing, thus reducing unnecessary or undesirable host access. Moreover, since the applications have access to a real time source in the processor system 51 (FIG. 2), user are provided the ability to design layout scenarios where the local and host processing are dependant on real time considerations, maximizing time-dependant host resources. Finally, through appropriate data system configuration, terminal-to-terminal communication is easily accomplished.
The utilization and arrangement of independent threads and objects which utilize logical terminal names and table data structures which isolate the application engines from specific devices facilitate layout scenario alterations. The tables data structures utilized by each of the independent threads shown in FIGS. 3 - 5 are created during initialization, thus altering a layout scenario, such as adding, deleting, or changing a data collection terminal, is readily accomplished without substantial effort.
FIG. 6 is an entity relationship diagram of the conceptual data model of the present invention as it exists in the repository 86 after having been created by a user utilizing the user facility 94 (shown in FIGS. 3 - 5), in accordance with the preferred embodiment of the present invention. The repository 86 is a storage location for the objects, associations, and properties which define a data collection system layout scenario. The blocks shown in FIG. 6 represent objects which are maintained in the repository 86. The interconnecting lines and icons represent the associations between the objects, the links which join all of the components of a layout together. These associations are also maintained in the repository 86. Properties of each of the objects and associations, including specialized properties known as procedures, are also maintained in the repository 86.
The icons shown connected to each box represent cardinalities which are considered understood by those reasonably skilled in the industry. In addition, the icons are fully explained in Recommended Diagramming Standards for Analysts & Programmers, by James Martin, 1987, published by Prentice-Hall, Inc., Englewood Cliffs, New Jersey 07632. The following is an explanation of the icons shown in FIG. 6. A data collection application object 116 is shown connected to a host application object 132 by a line with icons which are read "zero to many". Thus, a data collection application object 116 is associated with "zero to many" host application objects 132, and a host application object 132 is associated with "zero to many" data collection application objects 116. In other words, although it is not necessary that a data collection application object 116 be associated with any host application objects 132, a data collection application object 116 may nevertheless be associated with a large number of host application objects 132, and visa versa. The data collection application object 116 is also associated with a terminal object 114 in such a way that the data collection application object 116 is associated with "zero to many" terminal objects 114, yet the terminal object 114 is associated with "one and only one" data collection application object 116. The only other icon included in FIG. 6 is shown to relate a peripheral network object 112 to the terminal object 114. The terminal object 114 is said to be associated with "zero to many" peripheral network objects 112, but the peripheral network object 112 is associated with "one to many" (or "at least one") terminal objects 114.
Diagrams such as FIG. 6 are also frequently referred to as meta-models, or data about data. FIG. 6 and the following explanatory information are considered to provide a conceptual view of the rules of relationships between the objects shown. In the preferred embodiment of the present invention, the user facility 94 (FIGS. 3 - 5) provides a CASE (computer aided software engineering) environment where a user designs a particular data collection system layout scenario through the use of graphical and prompted input screens. The rules of relationships shown in FIG. 6 are automatically maintained by the interface system 50 during the design of a layout scenario. The configuration object 110 is the object representing a data collection system and can be viewed as the parent record of any particular layout scenario. Although the repository 86 can contain many configuration objects 110, only one configuration object 110 is allowed to be in operation at any given time. A configuration object 110 is associated with zero to many host application objects 132, peripheral network objects 112, server application objects 130, event objects 128, and serial devices 126.
The host application object 132 is associated with zero to many configuration objects 110, server application objects 130, external procedure objects 118, and data collection application objects 116. The host application object 132, with its properties, describes the communication path to an application running on a host computer. A procedure property of the host application object 132 is responsible for (1) putting information in whatever format the host expects, (2) sending the information, (3) accepting the host's response, and (4) putting the response information in a form which can be used by the interface system 50 (shown in FIGS. 3 - 5). If applicable, another host procedure is responsible for transaction mapping rules.
Another group of properties of the host application object 132 describes the particular type of communication method used, including APPC, DAE, 3270/5250 transaction mapping, and user-defined methods. With the APPC method, the interface system 50 communicates via conversations which are listed for a user to add, delete, or change. Each APPC host application object 132 is an independent transaction program that runs concurrently with other host transaction programs and can communicate over one or more conversations occupying one or more LU (Logical Unit) sessions. APPC properties include conversation name (the name used by interface system 50 procedures to address a particular conversation), local LU (name of local logical unit), partner LU (name of the host application's logical unit), local TP (name of local transaction program), partner TP (the fully qualified file name of the host application), and mode.
The DAE communication method also communicates via conversations, thus a similar user-accessible list is provided for editing. DAE properties include conversation name (the name used by interface 50 procedures to address a particular conversation) , local resource name (identification of the interface system 50, including program name and network node address), and partner resource name (the name and network address of the host application) . The 3270/5250 transaction mapping communication method supports multiple concurrent 3270 or 5250 terminal sessions. Properties include identifying which terminal sessions are used. A user-defined communication method offers custom communication programs access to a library of subroutines which allow the user to send and receive mail from the interface system 50. The only property of this method is the fully qualified path name of the custom host program. In the preferred embodiment of the present invention, all procedures are maintained in a high level Fourth Generation Language (4GL) which is modeled after the "IBM" "PROCEDURES LANGUAGE/2 REXX" software language and includes extensions to provide for device independent host-to-terminal communications. This language is an interpreted language, thus not requiring preparation steps such as compilation and linking to be executed and allowing for quick and easy updating and testing. The application engines (PAE's, HAE's, SAE's) of FIGS. 3 - 5 are independent language interpreters which are spawned by the runtime generator 92 to interpret the user-defined procedures of corresponding application objects 116, 132, 130 shown in FIG. 6.
The peripheral network object 112 is associated with zero to many configuration objects 110 and with one to many terminal objects 114. The peripheral network object 112 includes properties which describe the type of terminal controller used, such as RF Base 32 or fixed station concentrator 37 shown in FIG. 4. These properties include vendor, model, serial communication port name, baud rate, parity, data bits, stop bits, and other vendor-specific and model-specific parameters.
The terminal object 114 is associated with zero to many peripheral network objects 112 and with one and only one data collection application object 116. Any device connected to a peripheral network is considered to be a terminal, including RF terminals, fixed terminals, printers, scanners, scales, etc. The terminal object 114 includes properties describing, at least, the vendor, model and address of the terminal. The serial device object 126 is associated with zero to many configuration objects 110 and with one and only one data collection application 116. The serial device object 126 includes properties which describe serial communication with devices which attach directly to the interface system 50 without an intervening peripheral network controller. These properties include serial port name, baud rate, parity, data bits, and stop bits. Since messages coming from the,serial device can vary, other serial device properties include message headers and trailers which enclose messages from the serial device message lengths for fixed length messages. The data collection application object 116 is associated with zero to many terminal objects 114, host application objects 132, serial device objects 126, server application objects 130, form objects 120, and external procedure objects 118. The data collection application object 116, with its properties, represents the task to which a terminal or serial device is dedicated. The principle task of a data collection application object 116 is to collect information from terminals or serial devices. A procedure property of the data collection application object 116 often includes steps instructing a terminal to prompt a user for information, accepting a response, conducting one of several processes based on the response, and optionally preparing and sending information to a host application for transfer to a host.
The form object 120 is associated with zero to many data collection application objects 116, external procedure objects 118, and field objects 122. The form object 120 is a terminal, or serial device, screen layout specification. The properties of the form object 120 include the terminal type, the text appearing on the screen, and the location of the text. The field object 122 is associated with zero to many form objects 120. Field objects 122 represent the variable parts of a form object 120. Properties of field objects 122 include field type, eg., alphanumeric, date, phone, time, etc., and field length. A location property is attached to the association between field objects 122 and form objects 120 to define where a field object 122 is placed on a particular screen.
The external procedure object 118 is associated with zero to many host application objects 132, data collection application objects 116, form objects 120, event objects 128, and server application objects 130. The external procedure object 118 is similar in structure to procedure properties of the other applications 130, 132, 116. However, an external procedure object 118 does not belong to any particular application. Thus, procedural tasks which must be performed more than once, such as computing a factorial, can be isolated into an external procedure objects 118 to make the procedural code re-usable. When an external procedure object 118 is running, it is treated as part of the application that called it, thus, the external procedure object 118 has access to all of the parent's information. Furthermore, if the parent application is a terminal data collection application object 116, the external procedure object 118 can also communicate with a terminal.
The server application object 130 is associated with zero to many host application objects 132, data collection application objects 116, configuration objects 110, and external procedure objects 130. The server application object 130 is an object with a procedure property that provides a service or manages a resource that can be shared by other applications. The above discussions regarding the server SAE 90 shown in FIG. 5 pertain to two sample server application objects 130. The server application object 130 is a shared resource which involves storing or transferring information within the interface system 50.
The event object 128 is associated with one and only one configuration object 110 and external procedure object 118. The event object 128 is a scheduled initiation by the configuration object 110 of an external procedure object 118 or other external program supported by the interface system 50 which is scheduled to occur at a given time or at regular intervals. Requests can also be sent to other applications.
As is discussed above, in accordance with the preferred embodiment of the present invention, a user utilizes the user facility 94, a GUI (Graphical User Interface) CASE tool system, to create and edit the repository 86. In addition to providing enhanced creating and editing capabilities, the CASE interface also provides system activity monitoring services, diagnostic capabilities which include animation and prototyping of proposed system operation, and notification of the effects on other objects of proposed changes to any particular layout scenario based on associations and rules of relationships. The following ten tools are included: network configuration facility, application assignment matrix, application flow chart, procedure flow chart, application structure chart, procedure structure chart, data structure facility, form painter facility, repository object list, repository services. The network configuration facility tool is used to graphically define the hardware components (peripheral system 30) in a particular layout scenario. Defining an object involves adding the object, entering its properties, and associating it to other objects (if applicable). The application assignment matrix is used to define applications and associate them with terminals.
The application flow chart is used to graphically define the logical flow of an application in terms of objects and flows. The procedure flow chart is used to graphically define the logical flow of a procedure in terms of objects and flows. The application structure chart is used to graphically define the calling hierarchy of procedures associated with an application, a high-level decomposition of an application. The procedure structure chart is used to graphically define the calling hierarchy among different procedures. The data structure facility is used to define the data structure associated with a data area (forms, transactions, tables), including mapping a 3270 or 5270 screen to a transaction data structure. The form painter facility is used to define the characteristics of a screen form. The repository object list is used to list all of the objects in a repository by object type so that objects can be added, deleted, and renamed. The repository services tool is used to keep track of all of the repositories in the current system, acting as a repository container.
While the embodiments of the present invention which have been disclosed herein are the preferred forms, other embodiments of the present invention will suggest themselves to persons skilled in the art in view of this disclosure. Therefore, it will be understood that variations and modifications can be effected within the spirit and scope of the invention and that the scope of the present invention should only be limited by the claims below.
I claim:

Claims

1. A data collection system apparatus comprising: a plurality of data collection peripheral means for receiving data from a user; a host means for processing user data; and an interface means interposed between said plurality of data collection peripheral means and said host means for receiving data from said plurality of data peripheral means, conditioning the received data, and transferring the conditioned data to said host means, wherein said interface means includes, at least, a configuration means for selectively configuring the data collection system to include various data collection peripherals operating under alternate communication schemes.
2. Apparatus of Claim 1, wherein said data collection peripheral means includes a base unit physically connected to said interface means and at least one remote terminal connected to said base unit through radio.
3. Apparatus of Claim 1, wherein said data collection peripheral means includes a base unit physically connected to said interface means and at least one remote terminal connected to said base unit through telephone lines.
4. Apparatus of Claim 1, wherein said interface means includes, at least, a processor means for processing information. a keyboard means for enabling a user to interacting with said processor means, a graphical display means for displaying information for a user, a fixed disc means for permanently storing information passing through said processor means, a random access memory source, a host adapter for interfacing between said processor means and said host means, and an async means for serially interfacing between said processor means and said data collection means.
5. Apparatus of Claim 1, wherein said interface means further includes, at least, means for automatically saving data collected by said data collection peripheral means when said host means is unavailable.
6. Apparatus of Claim 1, wherein said interface means further includes, at least, means for communicating between two or more data collection peripheral means of said plurality of data collection peripheral means.
7. Apparatus of Claim 1, wherein said interface means further includes, at least, session sharing means for enabling a smaller number of host sessions to be shared by a larger number of data collection peripherals of said plurality of data collection peripherals.
8. Apparatus of Claim 1, wherein said interface means further includes, at least, architecture means for running application procedures which are independent from specific types of data collection peripherals of said plurality of data collection peripherals.
9. Apparatus of Claim 8, wherein said architecture means includes, at least, tables for connecting independent procedures to specific types of terminals .
10. Apparatus of Claim 1, wherein said configuration means includes, at least, CASE (computer aided software engineering) means for aiding a user in configuring a data collection system apparatus.
11. Method of interfacing between a data collection peripheral system and a host system, said method comprising the steps of: locating an interface system between a data collection peripheral system and a host system; generating data collection peripheral screens at the interface system; transferring the screens to data collection peripherals; receiving response information at the interface system from the data collection peripherals as users respond to the screens; processing the response information at the interface system; generating host messages containing the response information; and transferring the host messages to the host system.
12. Method of Claim 11, wherein said method further includes the step of receiving host response information at the interface system after the host processing the host message.
PCT/US1993/002508 1992-03-18 1993-03-18 Data collection interface system WO1993019423A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US85313492A 1992-03-18 1992-03-18
US07/853,134 1992-03-18

Publications (1)

Publication Number Publication Date
WO1993019423A1 true WO1993019423A1 (en) 1993-09-30

Family

ID=25315160

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1993/002508 WO1993019423A1 (en) 1992-03-18 1993-03-18 Data collection interface system

Country Status (2)

Country Link
AU (1) AU3924593A (en)
WO (1) WO1993019423A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL1011599C2 (en) * 1999-03-19 2000-09-20 No Wires Needed B V Interface card and computer provided with such an interface card.

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4805134A (en) * 1986-01-09 1989-02-14 International Business Machines Corporation Electronic system for accessing graphical and textual information
US4825354A (en) * 1985-11-12 1989-04-25 American Telephone And Telegraph Company, At&T Bell Laboratories Method of file access in a distributed processing computer network
US4887204A (en) * 1987-02-13 1989-12-12 International Business Machines Corporation System and method for accessing remote files in a distributed networking environment
US4982324A (en) * 1988-12-19 1991-01-01 International Business Machines Corporation Method of and system for using device drivers to couple the communication and data storage of remote computer systems
US5146561A (en) * 1988-06-02 1992-09-08 Sears Communications Network, Inc. Communication network data manager system
US5197128A (en) * 1991-03-04 1993-03-23 Hewlett-Packard Company Modular interface

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4825354A (en) * 1985-11-12 1989-04-25 American Telephone And Telegraph Company, At&T Bell Laboratories Method of file access in a distributed processing computer network
US4805134A (en) * 1986-01-09 1989-02-14 International Business Machines Corporation Electronic system for accessing graphical and textual information
US4887204A (en) * 1987-02-13 1989-12-12 International Business Machines Corporation System and method for accessing remote files in a distributed networking environment
US5146561A (en) * 1988-06-02 1992-09-08 Sears Communications Network, Inc. Communication network data manager system
US4982324A (en) * 1988-12-19 1991-01-01 International Business Machines Corporation Method of and system for using device drivers to couple the communication and data storage of remote computer systems
US5197128A (en) * 1991-03-04 1993-03-23 Hewlett-Packard Company Modular interface

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
COMPU SERVE INTRODUCTORY MEMBERSHIP, September 1991, Compu Serve, Incorporated, pp. 11-19. *
ELECTRONIC MAILARD BEYOND, 1984, CARL TOWNSEND, pp. 127-135. *
GE NIE, 1991, General Electric Co., pp. 2-6. *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL1011599C2 (en) * 1999-03-19 2000-09-20 No Wires Needed B V Interface card and computer provided with such an interface card.
EP1039695A1 (en) * 1999-03-19 2000-09-27 No Wires Needed B.V. Interface card and computer provided with such an interface card

Also Published As

Publication number Publication date
AU3924593A (en) 1993-10-21

Similar Documents

Publication Publication Date Title
KR100328516B1 (en) SYSTEM AND METHOD FOR SETTING COMMUNICATION PROTOCOL BETWEEN APPLICATIONS
EP0456249B1 (en) System for integrating application programs in a heterogeneous network enviroment
CN108449418A (en) A kind of mixed cloud platform management system and method
KR100212347B1 (en) Network management with acquisition of formatted dump data from remote process
US7827238B2 (en) Exchanging data using programmatic conversion to emulated HTML form data
WO2021088641A1 (en) Data transmission method, data processing method, data reception method and device, and storage medium
JP3887672B2 (en) Protocol stack generation apparatus and method
CN110008267B (en) Data processing system and method
CN101411165B (en) Technique of controlling communication of installed apparatus with outside by means of proxy server
Lutter et al. Using VHDL for simulation of SDL specifications
CN107644322A (en) The multiple terminals measures and procedures for the examination and approval and system based on OnlineBox systems
CN115865680A (en) Method, system and device for distributed equipment access, control and data transmission
WO1993019423A1 (en) Data collection interface system
CN115237547A (en) Unified container cluster hosting system and method for non-intrusive HPC computing cluster
Allen et al. Distributed methodology management for design-in-the-large
CN114546683A (en) Service processing method, device, electronic equipment and storage medium
CN113111111A (en) Multi-data source database access method
CN113111108A (en) File data source warehousing analysis access method
JP2568374B2 (en) Simulation device for networking code
CN114866609B (en) Data interconnection and intercommunication method and device based on unified information model
CN113852516B (en) Method, system, terminal and storage medium for generating switch diagnostic program
WO2023035147A1 (en) Data processing method of industry edge product and distributed computing protocol engine thereof
CN115695405A (en) Equipment control method, device, control terminal, execution terminal and service terminal
CN100357906C (en) Method for acquiring connection point information in computer group system
CN116886530A (en) Comprehensive communication method and system based on database plug-in

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase