Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
1999-10-12
2002-10-29
Ray, Gopal C. (Department: 2181)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C709S241000, C709S241000
Reexamination Certificate
active
06473824
ABSTRACT:
BACKGROUND OF THE INVENTION
As soon as a computer, for example a personal computer, has to communicate with an external, real device, a so-called device driver has to be implemented in the program. This device driver has to be able to exchange three kinds of data traffic with the real IO device:
The first kind of data flow exchanged with the device controls the device (control flow), which means that the device's status is either set or obtained from the device. This includes activating and deactivating the device, changing the mode the device is in, and reading error messages from the device.
The second kind of data flow exchanged with the device reads data from the device (read flow). In case the device is a sensor or a measuring apparatus, the data produced by the device has to be transferred to the computer by means of said read flow.
The third kind of data flow exchanged with the device writes data to the device (write flow). This kind of data traffic is the predominant data traffic in case the device is an actuator such as, for example, a robot arm having three axles, a valve, a light, a switch, etc.
There exist different ways of how to attach an IO device to the computer. A standard personal computer possesses at least one serial communication port (COM port) and a parallel printer adapter. To both ports, IO devices may be connected.
A further possibility is to use a fraction of the computer's memory, the IO memory, for communicating with the IO device. The IO device is directly connected to several bits of the IO memory. This is called memory-mapped IO.
Another possibility is to connect the IO device to the computer system via a fieldbus. Several fieldbus systems have developed into well-known standards. One example is the fieldbus Interbus-S of the PHOENIX company, which is an industrial standard bus for connecting analog and digital devices to control applications in a manufacturing environment. There exist various adapter cards for different hardware (PLC, IPC, etc.). Another example is the fieldbus Profibus of the Siemens company. It is used in industrial manufacturing for controlling machine tools, robots, and other kinds of manufacturing equipment. Another standard system, the fieldbus CAN, is a very fast realtime bus system. The period of time until an event is taken care of can be made very short. Therefore, this fast fieldbus is applied in vehicles; for example, for the control of intelligent braking systems like ABS. In France, there exists a standard for fieldbusses called FIP.
The IO device may also be connected to the computer system via a dedicated software layer (for example, the Device Data Management System DDMS) controlling an interface device to which the IO device is connected.
In order to test and debug application programs that control an IO device, it is advantageous to make the application program communicate with a simulation of the IO device. The simulator is a program which simulates the behavior of the real IO device and which communicates with the application program via a certain file. There are visualization tools available (for example, Wonderware, Streamline, etc.) which allow for the simulation of an IO device.
So there exists a lot of possibilities of how to attach an IO device to the computer system For some of the interfaces described; for example, for the fieldbusses, the protocols that have to be used are well defined. For others, for example, for the COM port and the parallel printer port, a variety of different protocols may be used. Of course, the way the IO device driver communicates with the external device also depends on the computer's operating system (OS/2, Windows, Unix, VxWorks, QNX).
Another aspect of the communication between an external device and the computer system is called realtime behavior. This means that in case a predefined event occurs, this event has to be handled within a predetermined period of time, which may be very short. For example, when a robot aim hits an unexpected obstacle, it is desirable to immediately stop the robot arm's movement.
There exists a variety of prior art solutions for providing object classes having the functionality of IO device drivers. The most common approach is to implement the device drivers as subclasses in a class tree. Another approach is to provide different libraries containing different device drivers, which can be linked with an application program A third approach discussed in the prior art is to declare all the device drivers as external references. A special file is linked with the application which resolves all the external references.
These solutions of the prior art will be thoroughly discussed in the “Detailed Description of the Drawings,” together with FIG.
2
and FIG.
3
. The main shortcoming of all these approaches is that changing an IO device driver at runtime is not possible.
OBJECT OF THE INVENTION
It is an object of this invention to provide a flexible, object-oriented approach for establishing communication links between an application program and various IO device drivers.
It is another object of this invention to provide a method and means for administrating communication links between an application program and various IO device drivers which allow to exchange an IO device driver at runtime.
SUMMARY OF THE INVENTION
According to the invention, two class trees are introduced: the first class tree comprises the device drivers. The device drivers actually exchange messages with the IO devices. They depend on the protocol used, on the IO interface, and on the operating system. The second class tree comprises the so-called physical objects. Their task is to define parameters that are necessary to describe what an IO device is supposed to do. The parameters only depend on the device's functionality, but not on the protocol, the IO interface or the operating system. In order to couple a physical object with a device driver, the physical object holds a pointer to its device driver. The communication link is provided by a technique called “object reference”.
The main advantage of this approach is that the communication link between a physical object and the IO device drivers may be changed at runtime. The user may connect an alternative IO device with a different hardware interface and redirect the IO data to the new IO device and the new IO interface without stopping his application.
Another advantage is that with the two class trees, an open and transparent structure is provided, which can be easily understood and modified by different persons. All the implementation-dependent features are contained in the IO device drivers, and all the functional structures can be found in the physical objects.
Therefore, it is easy to add new device drivers to an existing framework, because even a programmer that is not familiar with a framework finds the information he or she needs at a well-defined location of the framework.
Furtheron, the principles of object-oriented program design are fully obeyed with this approach. While some prior art approaches violated the principle of encapsulation, here this principle is obeyed to.
Another advantage is that a programmer who has to implement a new IO device driver may reuse an existing physical object. He or she just has to design a new IO device driver with the new implementation.
REFERENCES:
patent: 5301323 (1994-04-01), Maeurer et al.
patent: 5379431 (1995-01-01), Lemon et al.
patent: 5495610 (1996-02-01), Shing et al.
patent: 5544302 (1996-08-01), Nguyen
patent: 5557796 (1996-09-01), Fehskens et al.
patent: 5590313 (1996-12-01), Reynolds et al.
patent: 5787246 (1998-07-01), Lichtman et al.
patent: 6336152 (2002-01-01), Richman et al.
Frank Matthijs et al., “A Flexible I/O Framework for Parallel and Distributed Systems,” IEEE, pp. 187-190, 1995.
Kreissig Astrid
Kreissig Gerald
Stegerer Armin
Ray Gopal C.
Roth Steven W.
LandOfFree
Dynamic association of input/output device with application... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic association of input/output device with application..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic association of input/output device with application... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2989009