Dynamically allocating server processes to client processes

Details Dynamically allocating server processes to client processes Dynamically allocating server processes to client processes

1998-09-22

2001-05-15

Follansbee, John A. (Department: 2154)

Electrical computers and digital processing systems: multicomput

Distributed data processing

Client/server

C709S219000, C709S227000

Reexamination Certificate

active

06233602

ABSTRACT:

FIELD OF THE INVENTION
The invention relates to distributed data processing in a surface vehicle such as an automobile. Present-day car information systems manage various different data categories that are useful to the operation of the vehicle as a whole, such as:
the internal status of the vehicle independent of its actual position;
information relating to its geographical position and route;
information viz-á-viz the driver and passengers, as manifested by input actions and output representations.
A plethora of partial solutions have been and will be realized for engine and environmental control in the vehicle, storing of accessible geography data, route planning and guiding, road-status signalization, external data communication, in-car entertainment control, telephony, and various others. Several of these could translate in stand-alone devices, but interaction therebetween would raise their usefulness. Two examples would be, first, that a low fuel level could guide the route to deviate along a fuel station not on the prechosen route that would by itself be optimum. Second, an incoming mobile telephone call could deactivate any other audio reproduction. Many others would be feasible for improving user functionality, for better physical functionality of the vehicle, or for enhancing data processing capability. A problem would be present in that various partial solutions are realized by different manufacturers, are in different state or realization, have widely different levels of built-in intelligence, such as a binary safety-belt sensor versus a sophisticated route planner computer, all of which problems being aggravated by lengthening software development time and the scarcity of skilled systems analists.
In consequence, amongst other things, the invention envisages the provision of a distributed real-time computer operating system allowing for some or all of the following number of primary goals:
The systems software of the operating system should allow for easy maintenance. It should be simple, and built-up from only few, small, single-function units.
The software should be portable to different hardware, that could be either more sophisticated or downgraded. In particular the system would allow for two different levels of communication. The first, lower level implies transmitting one or more of a finite set of operators (such as on, off, read status), upon which a target will always react with one or more of a finite set of reactions. On the higher level, the destination exhibits a certain degree of non-deterministic behaviour such as is proper to a node or station that is controlled by a local operating system. In this case, the set of reactions need not be finite. Moreover, the answer could be non-deterministically (as seen by the requesting node) delayed by various tasks or processes to be executed by the target node.
The software should have clearly-defined interfaces between its various constituent software modules and also with regard to present or future application software. In this way any software module might be improved without creating havoc in the remaining part.
A principal element should be an operating system for controlling the respective local facilities, that has a powerful nature and easily accessible structure, such as CD-RTOS (Compact Disc Real Time Operating System), derived by Microware, DES Moines, Iowa, from earlier OS-9, or another system of comparable capabilities. In particular this operating system has been designed in the CD-I-(CD-Interactive) subsystem for containing and presenting optical-disk-stored information pertaining to geography and the like.
The interconnection network should allow for deterministic message traffic, that is under normal circumstances the time lag between transmission and arrival of data should have a prespecifiable worst case maximum, which may of course depend on such global system properties as the number of nodes. As explained hereinafter, the ARCNET standard bus protocol allows advantageous realization. This has been developed by Standard Microsystems Corporation of Hauppage, New York, USA, and implemented in Local Area Network Controller COM90 C26, published in their 1988 Components Catalog, pages 207-222.
The interface between He operating system and any application software module should be standardized. In this way, changing the number, nature and performance of the application software modules would not entail change of the control system. Moreover, change of the system hardware would only necessitate changing the system software, but not the application- or node-specific software.
SUMMARY OF THE INVENTION
Accordingly, the invention envisages to allow the software pertaining to the local module being written in C-language, and providing thereto, in addition to assembler means for converting high-level language statements into binary code that directly controls the local hardware and/or database items, a local library for thereby converting various elements of a limited set of primitives to an appropriate format as dictated by the bus protocol. This allows that any change on the bus level (hardware or software) would only necessitate modifying the library, and any change in a first node would only necessitate modifying the accessing facilities of the bus, but never software present in any second nodes. As such limited set, the inventors have seen sufficient (and often necessary) the following ninesome: open, close, read, write, seek, getstat, setstat, signal, create (=create process). These nine have been described as so-called System Calls in a UNIX-environment as a subset of 54 allowable System Calls in M.J. Rochkind, Advanced Unix Programming, Prentice-Hall Inc., Englewood Cliffs, N.Y., USA, 1985. In particular, the getstat/setstat pair are special derivatives from the octl system call which had already been developed in OS-9. The index to the above book lists all system calls as explained hereinafter. For an Arcnet realization, the library need only translate the node-generated entities to the appropriate system call.
According to one of its aspects, the invention realizes its object in that it provides a multinode distributed data processing system in a surface vehicle comprising:
a1. sensing means for sensing physical quantities relating to said vehicle;
a2. storage node means for storing physically partioned and fixed geographical data elements;
a3. data processing node means for processing said physical properties and said geographical data to generate user policy data;
a4. user I/O node means for receiving request data for forwarding to any data processing node to control said processing and for controlled forwarding to a user said user policy data;
a5. user input/output means interfacing said user I/O node means to user signals;
a6. and network means interconnecting said node means, at least one node interfacing to said sensing means; and at least one node executing application software;
said system having the following provisions:
b1. a library of messageable system calls or primitives, comprising: open, close, read, write, seek, getstat, setstat, signal, creat;
b2. a deterministic network control system for effecting any network transport of a primitive within a prespecified maximum time interval;
b3. a message processing organization exclusively allowing processing of a message subject to completed transfer thereof as a unitary entity;
b4. a state-maintaining control to keep any discourse between respective nodes over the bus stateless;
b5. a distributed real-time operating system to allow coexistent running of a plurality of respective processes that share localized processing power and/or a device, and/or a sensor, I/O and/or file data.
The physical quantities may, for example, relate to engine temperature, door closure, direction of earth magnetic field, presence of other vehicles, vehicle speed, and many others. Main store may be on one or more nodes, as RAM, disc, tape or other. Supplementing by non-fixed data such as congestion or local thunderstorms may be advantageous, data

Affiliated with

Also associated with

Rating

Dynamically allocating server processes to client processes does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Dynamically allocating server processes to client processes, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamically allocating server processes to client processes will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2510155