Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
5968115
Trout
October 19, 1999
Title
Complementary concurrent cooperative multi-processing multi-tasking processing system (C3M2)
Abstract
The system concept of the C3M2 System is to have the capability of providing a Process for each major processing step of automated data processing, i.e. if you have four steps then you need a minimum of four but it could be 8 or 12 or 16 processes. The four major complementary functions encompass the four major functions of data processing (Input/Output, Data Computation, Storage and User I/F). The system shall be Multi-tasking for each step. Source headers, link lists and entity or object identifiers are the methods that shall be used for identity of the different classes, types and objects for the variety of data in the system. The source and data type are contained in the source header. The class and type identity are contained in the object identifiers. The multi-tasking would be by schedule (interleaved by priority). This was selected instead of cycle sharing for improved concurrency.
Inventors:
Trout; Ray C.
(Houston,
TX
)
Assignee:
Complementary Systems, Inc.
(Houston,
TX
)
Appl. No.:
794045
Filed:
February 3, 1997
Current U.S. Class:
718/107
710/20
Field of Search:
395/670-675,840,841,827 709/107
U.S. Patent Documents
5016166
May 1991
Van Loo et al.
5113500
May 1992
Talbott et al.
5257372
October 1993
Furtney et al.
5307485
April 1994
Bordonaro et al.
5317693
May 1994
Cuenod et al.
5402350
March 1995
Kline
5450581
September 1995
Bergen et al.
5566349
October 1996
Trout
Other References
Heinrich et al, The Performance Impact of Flexibility in the Stanford Flash Multiprocessor, ACM Mar. 1994. .
Heinlein et al, Integration of Message Passing and Shared Memory in the Stanford Flash Multiprocessor ACM Mar. 1994. .
Arthur, Lowell Jay, Improving Software Quality, 1993, Table of Contents. .
Arthur, Lowell Jay, Improving Software Quality, Chap 13: Rapid Evolutionary Devel. .
IBM Dictionary of Computing, Aug. 1993 Preface. .
Booch, Grady, Object Oriented Design With Applications, 1991, Table Content. .
Connell et al, Structured Rapid Proto Typing, 1989, Table of Contents. .
Yourdan, Edward, Decline and Fall of the American Programmer, 1992 Table Content..~
Primary Examiner:
Toplu; Lucien U.
Attorney, Agent or Firm:
Casperson; John R.
Claims
What is claimed is:
1. A computer system having
at least one CPU for performing
an IO process for receiving data inputs and processing said data inputs to provide data outputs;
a DP process for performing a data processing function;
a DM process for performing a data distribution function; and
a DS process for performing a data storage function;
at least one computer memory means including
at least one memory means for storing data from the IO process;
a dedicated DP memory for storing data from the DP process;
a dedicated DM memory for storing data from the DM process; and
a dedicated DS memory for storing data from the DS process;
and instructions for the at least one CPU including
IO instructions and means for causing the IO process to transfer data outputs to the at least one memory means for storage;
DP instructions and means for causing the DP process to retrieve data from the at least one memory, process said data to form calculated data; and to transfer the calculated data to the DP memory for storage;
DM instructions and means for causing the DM process to retrieve data from the DS memory and to transfer the data retrieved to the DM memory for storage; and
DS instructions and means for causing the DS process to retrieve data from at least one of the memory means for storing data from the IO process and the DP memory and to transfer the retrieved data to the DS memory for storage.
2. A computer system as in claim 1
wherein the at least one memory means for storing data from the IO process comprises
a DP complementary shared memory operably associated with the DP process; and
a dedicated IO memory for storing data from the IO process;
said computer system further comprising
IO instructions and means for causing the IO process to transfer data outputs to the DP complementary shared memory and to the dedicated IO memory;
wherein the DP instructions and means for causing the DP process to retrieve data from a memory causes the DP process to retrieve data from the DP complementary shared memory; and
the DS instructions and means for causing the DS process to retrieve data from at least one of the memory means for storing data from the IO process causes the DS process to retrieve data from the dedicated IO memory.
3. A computer system as in claim 1 further comprising
an archive memory for storing data for archive from the DS process;
instructions and means for causing the DS process to retrieve data for archive from the first memory portion of the DS memory and the second memory portion of the DS memory and to transfer such data to the archive memory for storage.
4. A computer system as in claim 1 further comprising
a user interface operably associated with the DM process;
wherein the DM instructions include
a routine for determining whether a user notification should be transmitted to the user interface;
a routine for generating the user notification; and
a routine for transmitting the user notification from the DM process to the user interface.
5. A computer system as in claim 1 further comprising
an external user interface operably associated with the IO process;
wherein the IO instructions include
a routine for processing queries from the external user interface;
a routine for transmitting the processed queries from the external user interface to the DM process;
a routine for processing query responses received from the DM process; and
a routine for transmitting the processed query responses to the external user interface;
and wherein the DM instructions include
a routine for processing queries received from the IO process;
a routine for retrieving data responsive to said query from the DM memory;
a routine for generating a query response based on the retrieved data; and
and a routine for transmitting the query response to the IO process.
6. A computer system as in claim 1 wherein
the IO instructions and means for causing the IO process to transfer data to the IO memory for storage further comprises a routine for causing a flag to be placed with the transferred data; and
the DP instructions and means for causing the DP process to retrieve data from a memory and to transfer calculated data to the DP memory for storage further comprises a routine for removing the flag from the retrieved data and a routine for placing a flag with the transferred data.
7. A computer system as in claim 1 further comprising
a user interface operably associated with the DM process;
wherein the DM instructions include
a routine for processing queries from the user interface;
a routine for retrieving data responsive to said query from the DM memory;
a routine for generating a query response based on the retrieved data; and
and a routine for transmitting the query response to the user interface.
8. A computer system as in claim 1 further comprising
an IO complementary shared memory operably associated with the IO process;
a DM complementary shared memory operably associated with the DM process;
an external user interface operably associated with the IO process;
external user interface instructions and means for causing the external user interface to transmit queries to the IO complementary shared memory for storage; and
a dedicated external user interface memory operably associated with the external user interface;
wherein the IO instructions include
a routine to retrieve queries from the IO complementary shared memory;
a routine to format the queries in an appropriate protocol;
a routine to identify and transmit the queries to the DM complementary shared memory for storage;
a routine to retrieve query responses from the DM complementary shared memory;
a routine to format the query responses from the DM complementary shared memory into the protocol;
a routine to transmit the queries and the query responses to the external user interface memory for storage.
9. A computer system as in claim 1 further comprising
a DS complementary shared memory operably associated with the DS process;
an archive memory for storing data for archive from the DS process;
wherein the DS instructions and means for causing the DS process to retrieve data from IO memory causes the DS process to retrieve such data into the DS complementary shared memory:
wherein the DS instructions further include
a routine to retrieve dynamic data from the DS complementary shared memory;
a routine to retrieve static data from the DS complementary shared memory;
a routine to retrieve calculated data from the DS complementary shared memory;
a routine to retrieve the identifiers for the dynamic data, the static data, and the calculated data from the DS complementary shared memory;
a routine to convert the identifiers to record numbers;
a routine to convert the dynamic data, the static data, the calculated data and the record numbers to a relational data base format for storage as a relational data base;
a routine for storing the relational data base in the DS memory;
a routine for retrieving the relational data base from the DS memory;
a routine for storing the thus retrieved relational data base in the archive memory;
a routine for transferring the relational data base from the archive memory to an archive media for storage; and
a routine for transferring a relational data base from an archive media to the archive memory.
10. A computer system as in claim 1 further comprising:
a DM complementary shared memory operably associated with the DM process; and
a user interface operably associated with the DM process;
and wherein the DM instructions include
a routine to retrieve data from the DS memory and to transfer the data retrieved to the DM complementary shared memory for storage;
a routine to cause a flag to be placed with the data last retrieved from the DS memory;
a routine to transmit the data stored with the flag to the user interface;
a routine for determining whether a user notification should be transmitted to the user interface;
a routine for generating the user notification; and
a routine for transmitting the user notification from the DM process to the user interface.
11. A computer system as in claim 1 further comprising:
a DM complementary shared memory operably associated with the DM process; and
a user interface operably associated with the DM process;
at least one external database operably associated with the DM process;
wherein the DM instructions include
a routine for processing queries received from the user interface;
a routine for identifying the external database containing data responsive to said query;
a routine for retrieving the data responsive to said query from the external database;
a routine for generating a query response based on the retrieved data; and
and a routine for transmitting the query response to the user interface.
12. A process for concurrently using four process functions to cooperatively perform complementary data processing, said process comprising
receiving a data input in an IO process function;
processing the data input in the IO process function and producing an IO output;
transferring the IO output to an IO memory for storage;
transferring the IO output to a DP complementary shared memory for storage;
retrieving an IO memory output from the IO memory;
receiving the retrieved IO memory output in a DS process function;
processing the received IO memory output in the DS process function and producing a DS output;
transferring the DS output to a DS memory for storage;
retrieving a DP complementary shared memory output from the DP complementary shared memory;
receiving the DP complementary shared memory output in a DP process function;
processing the received DP complementary shared memory output in the DP process function and producing a DP output;
transferring the DP output to the DP complementary shared memory;
transferring the DP output to a DP memory for storage;
retrieving an DP memory output from the DP memory;
receiving the retrieved DP memory output in a DS process function;
processing the received DP memory output in the DS process function and producing a DS output;
transferring the DS output to the DS memory for storage;
retrieving a DS memory output from the DS memory;
receiving the retrieved DS memory output in a DM process function;
processing the received DS memory output in the DM process function and producing a DM output; and
transferring the DM output to a DM memory for storage.
13. A process as in claim 12 further comprising
assigning a processing priority designator to data inputs to the IO process function; and
scheduling the data outputs from the IO process function for ordered transmission to the DP process function in a priority scheduler having a cyclic unvarying predetermined priority designator sequence.
14. A process as in claim 12 further comprising
causing a flag to be placed with the IO output transferred to the IO memory for storage;
causing a flag to be placed with the IO output transferred to the DP complementary shared memory for storage;
causing a flag to be placed with the DP output transferred to the DP memory for storage;
causing a flag to be placed with the DS output transferred to the DS memory for storage; and
causing a flag to be placed with the DM output transferred to the DM memory for storage.
15. A process as in claim 12 further comprising:
calculating a value for a predetermined relationship between data most recently retrieved from the DP complementary shared memory and data previously retrieved from the DP complementary shared memory;
transferring the value to the DP complementary shared memory for storage;
calculating a calculated value trend from the stored values;
predicting a predicted value for the next retrieved data from the DP complementary shared memory based on the trend from the stored values;
comparing the calculated value with the predicted value and completing further processing of the calculated value when the calculated value is outside of predetermined limits from the predicted value; and
transferring the calculated value from the DP complementary shared memory to the DP memory for storage.
16. A process as in claim 12 further comprising:
processing a query from a user interface;
retrieving DM memory output responsive to said query from the DM memory;
generating a query response based on the retrieved DM memory output in the DM process function; and
transmitting the query response to the user interface.
17. A process as in claim 12 further comprising
assigning a unique multicharacteristic identifier to each data input to the IO process function;
transferring the multicharacteristic identifier as IO output to the IO memory for storage; and
transferring the multicharacteristic identifier as IO output to the DP complementary shared memory for storage.
18. A process as in claim 12 further comprising
identifying dynamic data in the IO process function;
identifying static data in the IO process function;
transferring the dynamic data as IO output to a first portion of the IO memory for storage;
transferring the static data as IO output to a second portion of the IO memory for storage; and
transferring the multicharacteristic identifiers as IO output to a third portion of the IO memory for storage.
19. A process as in claim 12 further comprising
determining in the DM process function whether a user notification should be transmitted to a user interface;
generating the user notification; and
transmitting the user notification from th e DM process function to the user interface.
Description
BACKGROUND OF THE INVENTION
This invention is a methodology for configuring complementary data processes to: operate in concert; have reduced applications and operating system software, perform concurrent cooperative multi-processing multi-tasking operations, have over
1000% improvement in performance and have outstanding implementation cost.
The following references were a part of the literature study undertaken during the 1992 and 1993 time frame during the invention period.
1. Structured Rapid Prototyping, John L. Connell and Linda Shafer, 1989 Prentice-Hall, Englewood Cliffs, N.J.
2. Improving Software Quality, Lowell Jay Aurthur, 1993 John Wiley & Sons, New York, N.Y.
3. Object-Oriented Design with Applications, Grady Booch, 1991 Benjamin/Cummings Publishing, Redwood City, Calif.
4. Decline and Fall of the American Programmer, Edward Yourdom, 1992 Prentice-Hall, Englewood Falls, N.J.
5. Pentium Processor Users Manual, Vol 3, Architecture and Programmers Manual, Intel Literature, PO Box 7641, Mt. Prospect, Ill.
6. Alpha Architecture Reference Manual, Richard L. Sites, Digital Press, Maynard, Mass.
7. Inside SCO UNIX, Steve Glines, Peter S. Spicer, Benjamin A. Hunsberger, Karen Lynn White, 1992 New Rider Publishing, Carmel, Ind. 46032.
8. Guide Real-Time Programming, POSIX 1003.4, Digital Equipment Corp., Maynard, Mass.
9. Sable Systems Overview, Digital Equipment Corp., Maynard, Mass.
10. SEI Documents, Software Engineering Institute, Annotated Listing of Documents, 1993 Carnegie Mellon University, Pittsburgh, Pa. 15213
11. IBM Dictionary of Computing, ISBN 0-07-113383-6, 10th Edition (August 1993) McGraw-Hill, New York, N.Y.
Multi-Tasking and Multi-Processing are tasks that cost software developers millions of hours in development time. The major problem is using the sequential processing Operating system and invoking interrupts while attempting to resolve multiple process requirements. Current system throughput is effected by the Overhead required by the Operating system of the platform, >50%. The time delays are due to interrupts, context switching, exceptions and wait states. Schedulers and Priority Allocations also use interrupts and context switching for accomplishment of their tasks. Concurrency and Cooperative Processing normally uses clock sharing, wait states or multi-processors to achieve their objectives. Current system procedures and operational procedures must be revised through a planned methodology that accomplishes the same objective with simpler steps and in much less time.
The number of processors used in a system requires special Software modifications for Multiple parallel processing or Symmetric processing. Multiple parallel processing does not work well when the number of processors is less than 10. However, Symmetric processing does not work well when the number of processors is more than 10 due to operating system problems and allocations of memory. The Multiple parallel processing divides one large task into N tasks. Symmetric processing divides a number of tasks into equal work load tasks.
This causes multi-processing problems for the Operating system. Multi-tasking is very difficult for the Multiple parallel processing configuration but can be segregated to one task per processor in the symmetric configuration. The processes must perform multi-tasking of all types with simpler methodology. Concurrent operations are normally handled by sharing clock cycles, 1/N, or assigning one processor for each task. Cooperative processing normally uses Wait-States or FIFO modes of operations. They normally add to the Overhead of the Operating system. Single, MMP or Symmetric configurations do not have Complementary processing. Complementary Processing (CP) capabilities need to be added to the system. Complementary Processing will allow Multi-Processing with much lower Software Overhead, far simpler operations, reduced design costs and Software design time.
Real Time Kernels are normally used for Real Time or Embedded Systems. These kernels still use Interrupts and Context Switching. The Real Time Kernel can also be preempted by the System Operating system. The operating performance of the Real Time Kernel is about the same as the System Operating system but it restricts performance to tasks in the kernel. The overall operating time is about the same for the Real Time Kernel as for the System Operating system. There are no outside interferences for the Real Time Kernel except in the case of Preemption. The Real Time Kernel was analyzed, but could not be used due to the system constraints of its operating procedures. The Real Time operating system needs to be designed in a manner that will reduce its operating time by 50 or 60 percent (no Interrupts or Context Switching). Data drivers for the Applications Programs (AP) are also scheduled by the Operating system. These data drivers are for the disk system, interim buffers, input/output for the interim buffers and the AP, display generators and other associated AP's. These data drivers are separte drivers and are handled sequentially. These steps are lengthy and should be reduced to simple memory transfers, without interim buffers and done concurrently. Allocation of memory is normally made at compile time, by Operating system allocations and other dedicated memory tasks. Applications programs normally use memory allocations from disk swapping and other memory requirements from virtual memory. Virtual memory is also used for storage of processed data from the applications programs. The cost of memory has declined during the preceding years and the philosophy needs to change for allocations of memory. There should be less disk swapping, more dedicated memory, more processed data in dedicated memory and more Real Time operations using dedicated memory.
The Von Naumann architecture, still currently in use, was for a single computer with limited memory. Software design personnel still use this architecture in all of their designs. Design problems are effected by this architecture and primarily due to the computer implementations by the computer manufacturers in order to use existing Software. The design problems are normally dealt with by an Ad Hoc Group (from the SEI of Carnegie Mellon University reference data source) and the individual problems are treated as separate entities. This is a case-by-case basis versus a standards basis. The design must mitigate a large number of problems by eliminating their causes.
System Configurations are normally dependent on the platform and its Operating system. The external interfaces are normally Commercial-off-the-shelf (COTS) or custom design. The system throughput is normally limited by the disk data rates or the internal bus structure. These two factors must be independent of the system throughput. The system should not be limited by External IO rates, Disk Data rates or system bus rates. Internal system interfaces and/or protocols are also factors which can complicate or limit throughput or data input rates. These interfaces must also be independent and accomplished in the simplest fashion on known data types and in the largest feasible data blocks. System Operations are normally planned by the Data base administrator or his System Guru equivalent. The repeatability from one system to another may be similar but normally does not follow published procedures that were initiated during systems implementation and testing but are a result of prior lessons learned. System procedures for System Configuration must be available from the prototyping system testing, must be standardized, and must be used for all future systems.
The majority of real-time CPU's do not have facilities for a Knowledgebase (KB), a data archive facility, a Relational data base with its real-time memory, Displays, or User Graphic user interface interfaces. The components for these facilities need to be added and integrated with the system.
OBJECTS OF THE INVENTION
The C3M2 system methodology can be utilized with a single processor or a many tiered system configuration. The system can operate in series, parallel or both. The processors of the system are loosely coupled. All processes are encapsulated with only data inputs and data outputs. The system is independent of Equipment Components, Operating Systems, Data Bases and Languages. The C3M2 system uses COTS hardware and Software. The Costs (Implementation and Life cycle cost) versus Computing Power is very low when compared to current methods of computation. Modification, updates or changes to any process are isolated to the process being modified and do not affect other processes. The system can be reconfigured by the user without changes to the equipment or Software. The C3M2 system can operate in a Distributed data base management system environment with Remote data accesses. The operating systems (Concerted Operating Systems) are much simpler than current Operating systems and with much less Overhead. The system gracefully supports Multi-Processing and Multi-Tasking in a concurrent and cooperative manner. The system supports a multi-user interface and responds to Real-Time/Critical-Time requirements. The systems computational capacity can vary from functional GigaFlops to a large number of Gigaflops. The software complexity does not increase. The systems availability is outstanding and with its fault tolerant capability the reliability of the large systems is as good as the minimum baseline systems. This is a big advancement in software technology.
SUMMARY OF THE INVENTION
In one embodiment of the invention, a computer system comprises four processes, four memories, and a set of instructions for each process. An IO process receives data inputs and processes the data inputs to provide data outputs. A DP process performs a data processing function. A DM process performs a data distribution function. A DS process performs a data storage function. At least one memory means is provided for storing data from the IO process. A dedicated DP memory is provided for storing data from the DP process. A dedicated DM memory is provided for storing data from the DM process. A dedicated DS memory is provided for storing data from the DS process. IO instructions and means for causing the IO process to transfer data outputs to the at least one memory means for storage are provided in the IO process. DP instructions and means for causing the DP process to retrieve data from the IO memory, process the data to form calculated data; and transfer the calculated data to the DP memory for storage are provided in the DP process. DM instructions and means for causing the DM process to retrieve data from the DS memory and to transfer the data retrieved to the DM memory for storage are provided in the DM process. DS instructions and means for causing the DS process to retrieve data from at least one of the memory means for storing data from the IO process and the DP memory and to transfer the retrieved data to the DS memory for storage are provided in the DS process.
Computer system design is simplified by complementary processes which allow concurrent operations. Multi-tasking and multi-processing is solved by using multi-processes in a Complementary manner. The dissection and solving of design and maintenance problems is much simpler with the Complementary design where each function is independent. Lock and Unlock functions are avoided by only one process writing to and the other processes reading from any specific data files. The customers are much better served by the system, because it is independent of Platforms, Operating Systems and Languages for excellent system inter-operability. The customer also has an excellent economic advantage; i.e., the platforms considered are economical, high speed Reduced instruction computing or PC type processes and not Mainframe, Medium Range or Mini Processors. The complete Command Control System or Transaction System can respond to any user requests in a much simpler fashion and in a far shorter time. Complementary Processing will also allow the system to perform its functions with less hardware and far less Software.
Complementary Processing will contribute significant improvements to information processing. This design methodology not only gracefully allows multi-processor implementation but also contributes to multiple-instruction-issue implementation through concurrent operations and reduced Overhead.
In a further preferred embodiment of the invention, the IO instructions include a routine for assigning a processing priority designator to data inputs and a routine for scheduling the data inputs for ordered transmission to the DP process in a priority scheduler having a cyclic unvarying predetermined priority designator sequence. The method of using interleaving instead of Interrupts and Context Switching for changing classes of tasks also provide a significant improvement in performance.
In a further embodiment of the invention, there is provided the invention of Complementary Processing. In Complementary Processing the four major complementary functions encompass the four major functions of data processing (Input/Output, Data Computation, Storage and User I/F). This allows each process to be encapsulated. This decoupling of processes significantly reduces the software design and maintenance.
The Complementary Processing of the present invention can be summarized as follows, A data input is received by an IO process. The data input is processed in the IO process and an IO output is produced. The IO output is transferred to an IO memory for storage. The IO output is preferably also transferred to a DP Complementary Shared Memory (CSM) for storage, for faster pickup by the DP process. The IO memory output is retrieved from the IO memory. The retrieved IO memory output is received in a DS process. The received IO memory output is processed in the DS process and a DS output is produced. The DS output is transferred to a DS Complementary Shared Memory (CSM) for storage. A DP CSM output is retrieved from the DP CSM. The DP CSM output is received by a DP process. The received DP CSM output is processed in the DP process and a DP output is produced. The DP output is transferred to the DP CSM. The DP output is transferred to a DP CSM for storage. A DP memory output is retrieved from the DP CSM. The retrieved DP memory output is received by a DS process. The received DP memory output is processed by the DS process and a DS output is produced. The DS output is transferred to the DS memory for storage. The DS memory output is retrieved from the DS memory. The retrieved DS memory output is received by a DM process. The received DS memory output is processed in the DM process and a DM output is produced. The DM output is transferred to a DM memory for storage.
Programming the four separate functions in the processes greatly simplifies the applications for systems use. This allows the team members to have well defined tasks. The interfaces between team members are the process interfaces and this can be accomplished through existing POSIX modules or memory storage cells (Write/Read being an ideal interface). The application programmer for that function would receive a given input and needs only to provide the prescribed output.
The process can be carried out using a Concerted Operating System (COS) for each function. The COS tends to be generic for each separate function. The interfaces between the separate processes are preferably high speed parallel busses and the Congruent memory. The data interfaces between the processes are preferably at the ISO 5 Level which is the domain of POSIX. POSIX modules will preferably be a part of the COS Software modules. Levels 6 and 7 will not be required, since there is no interim buffering. Since interrupts and Context Switching are not required, the functions of the COS are much simpler and much less time consuming when compared to its equivalent portion of a "Real-Time" Kernel or Operating system. The structure of the COS's lend themselves to being replicated to other processes of the same functionality.
It is preferred in the invention to store data in the DS memory and to maintain the DM memory in a Relational Data Base format. This would eliminate all of the book-keeping required for transfers between Applications File and a Relational Data Base File. This will also allow a direct access to be made in response to a Structured Query Language query instead of a lengthy file search (this is based on an assumption that you are looking for something specific--not panning for gold). DEC has adopted a Load-locked/store-conditional sequence and eliminated strict read-write ordering between processes. This allows one process to write to its memory location and allows other processes to read the data file. This was a premise that was used to specify a congruent memory instead of a common memory. This can be further enforced by link lists. All processes will be able to use a large memory without fear of conflict and data will no longer be transferred from one process to another.
BRIEF DESCRIPTION OF THE DRAWINGS
The schematic drawings illustrate certain features of the present invention.
______________________________________ Figure Number Description ______________________________________ 1 C3M2 System Domain - Shows representative External Interfaces for the C3M2 System. 2 C3M2 Systems Conceptual Drawing - 3 C3M2 System Block Diagram - First block diagram showing COTS hardware Components 4 C3M2 Replicated System Expansion, Serial-Parallel-Or Both-Block diagram to show method of expanding systems for tiered or cascade configurations. 5 UNIX-COS Shell and Interface - Shows separate stand-alone configurations, UNIX for development and COS for Operations, no preemption. 6 Operational Sequence of Developing COS's - Shows how the UNIX Operating system will provide the development environment using COTS Software, UNIX Compiler, Ada Compiler, POSIX Software, and Inventions Software. 7 C3M2 Rapid Prototyping Evolution - Methodology for defining inputs, outputs, user interfaces, and displays before allocation of Software and hardware functions. 8 Closed Loop C3M2 System Design Methodology-Method for defining the class of engineers to accomplish the design tasks Systems, hardware and Software. 9 Object Link List for Input Data - Method for tracking input data and their storage records. 10 C3M2 Function Operations Sequence (FOS), Shows the data trail through the C3M2 System. 11 Interleaving Classes of Objects by Priority - Method of interleaving data classes and types by priority and schedule to mitigate the use of Interrupts and Context Switching.
12 C3M2 software Context Diagram - Components of the C3M2 system effecting Software Processes. 13 C3M2 software System Processes - The Software system processes of the C3M2 System and their interfaces with the different databases. 14.1 C3M2 Control Flow Diagram for IO (Input). 14.2 C3M2 Control Flow Diagram for IO- (Query). 15 C3M2 Control Flow Diagram for DP. 16.1 C3M2 Control Flow Diagram for DM (User Data). 16.2 C3M2 Control Flow Diagram DM (Query). 17 C3M2 Control Flow Diagram DS 18
Sources, Data Sets, and Memory Allocation. 19 Comparisions of MPP, Symmetric & C3M2 Processing Methods 20 System Module Interface Drawing ______________________________________
DETAILED DESCRIPTION OF THE INVENTION
Terminology
Terms used in this disclosure include
Class: In object-oriented programming, a group of objects that share a common definition, common properties, operations and behavior.
Complementary: Processes producing effects in concert which are different from those produced individually.
Complementary Processing: Two processes interfacing together in a concerted and cohesive manner to produce an output which greatly exceeds those produced separately.
Concerted: Accomplished together in harmonious agreement.
Concerted Operating Systems (COS): A Trademark Term for Replicated Operating Systems by functions. The COS are complementary and do not require Interrupts or Context Switching.
Concurrent: Two or more processes operating in conjunction with separate instruction control units.
Congruent Memory: A Trademark Term for the separate dedicated memories that perform the C3M2 storage functions. One process writes and other processes read No (Lock or Unlock). All storage elements are multiples or submultiples of other allocated memories and overlay its allocated storage cells.
Concerted Operating Systems (COS): Operating systems for each of the Complementary Processes (CP). Each COS provides the Input and Output of the CP, calls the Application programs (AP) for each process, processes the priorities and schedules of each process, can be replicated for use in similar processes, and reduces the processing time to its absolute minimum.
Cooperative: Joint processing activity where one process does not wait on another process to begin operations.
Disk Management: The Archive Disk Storage is a mirror image of the Congruent memory. The Congruent memory transfers data to the Archive disk on a cyclic basis that is determined during the planning phase. Latency time is in the tens of milliseconds.
Entity: An object, event or process that is of interest in the context under consideration, and about which data may be stored in a data base.
Interfaces: The interconnect of two or more hardware components or items for the transfer of data from one entity to another in data processing.
Knowledgebase: A database that contains information about prior experienced encounters in a particular field and the data and procedures resulting from that encounter, and the identity and/or solution.
Long Term Archive: Archive Media which augments the Archive Disk. Latency time of the archive media is in the hundreds of milliseconds.
Memory Management: Memory allocations made during the planning phase for all memory users. Memory segments are divided into 1/1024 segments of dedicated total active memory. The data archive memory occupies the majority of the memory and is in a Relational Database Format. The other memory segments provide the required memory storage elements of the Complementary processing's, systems Software and utilities. Each Processes writes to its memory, Load/Locked. Other processes Read or Exchange. The memory also serves as an interface between the Processes. The memory is identified as the Congruent Memory (CM).
Methodology: The system of principles, practices and procedures as applied to the field of computer engineering.
Multi-Processing: Two or more processes operating in concert (perform together in harmony) with cooperative and concurrent operations.
Multi-Tasking: Two or more processes operating in concert with cooperative and concurrent operations.
Object: In Structured query language, anything that can be created, accessed or manipulated with Structured query language statements, such as databases, tables, records, views or indexes.
Operating Systems: Operating system for the CPU. Controls all operations of the CPU, Memory Management, IO Drivers, Disk Drivers, AP, Priority, and schedule in a sequential fashion.
Standards: Named identities under specified conditions that defines conditions for information processing and inter-operability.
Type: A class of objects. All, objects of a specific type can be accessed through one or more of the same interfaces.
User Interface: Dedicated interface for all Internal and external users. This include group displays and/or User/Servers or Client/Servers. The User interface is an interface to one of the Complementary process's and receives data in real-time.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the embodiment of the invention shown in FIG. 20, a computer system comprises four processes, four memories, and a set of instructions for each process. An IO process 10 receives data inputs and processes the data inputs to provide data outputs. A DP process 20 performs a data processing function. A DM process 30 performs a data distribution function. A DS process 40 performs a data storage function. At least one memory means is provided for storing data from the IO process. A dedicated DP memory 5.3 is provided for storing data from the DP process. A dedicated DM memory 5.5 is provided for storing data from the DM process. A dedicated DS memory 5.4, 5.7 is provided for storing data from the DS process. IO instructions and means for causing the IO process to transfer data outputs to the at least one memory means for storage are provided in the IO process 10. DP instructions and means for causing the DP process to retrieve data from the at least one memory, process said data to form calculated data; and transfer the calculated data to the DP memory for storage are provided in the DP process 20. DM instructions and means for causing the DM process to retrieve data from the DS memory and to transfer the data retrieved to the DM memory for storage are provided in the DM process 30. DS instructions and means for causing the DS process to retrieve data from at three of the memory means for storing data from the IO process and the DP memory and to transfer the retrieved data to the DS memory for storage are provided in the DS process 40.
It is preferred that the at least one memory means for storing data from the IO process 10 comprises a DP CSM memory operably associated with the DP process 20. Usually, the CSM memory will be integral with the DP process. The memory means further comprises a dedicated IO memory 5.1, 5.2, 5.6 for storing data from the IO process 10. The computer system preferably further comprises IO instructions in the IO process 10 and means for causing the IO process to transfer data outputs to the DP CSM and to the dedicated IO memory. The DP instructions in the DP process 20 and means for causing the DP process to retrieve data from a memory preferably causes the DP process to retrieve data from the DP CSM. The DS instructions in the DS process 40
and means for causing the DS process to retrieve data from three of the memory means for storing data from the IO process causes the DS process to retrieve data from the dedicated IO memory.
Preferably, each data output from the IO process is associated with a unique multicharacteristic identifier. The dedicated IO memory includes a first memory portion 5.1 for storing dynamic data; a second memory portion 5.2 for storing static data; and a third memory portion 5.6 for storing the multicharacteristic identifiers for the dynamic data and the static data. The DS memory preferably includes a first memory portion 5.4 for storing dynamic data, static data and calculated data grouped by a characteristic of the identifier associated with such data and a second memory portion 5.7 for storing the identifiers for the dynamic data, the static data and the calculated data. The DS instructions further preferably cause the DS process to reformat the retrieved data based on identifier characteristic and to transmit the reformatted data for storage in the DS memory. The multicharacteristic identifier includes an object number and a receipt time for each data input. The DM instructions preferably further cause the DM process 30 to reformat the retrieved data for the production of user notices, and to transfer the reformatted data to the DM memory 5.5 for storage.
In a further preferred embodiment of the invention, the computer systems is provided with a knowledgebase 200. The knowledgebase is formed from a KB process and means for the KB process to receive calculated data having a common identifier characteristic from the DP process 20. The Knowledgebase can perform a prediction function based on data trends for the data having the common identifier characteristic and produce a deviation signal when the calculated data from the DP process is outside of predetermined limits from the value predicted by the KB process. A KB memory can be provided for storing response information appropriate for each of a plurality of deviation signals. Instructions and means for causing the KB process to retrieve the appropriate response information from the KB memory in response to the deviation signal and to transfer such response information to the DP process are provided in the KB process
In a further preferred embodiment of the invention, there is provided an archive memory 400 for storing data for archive from the DS process 40. Instructions and means are provided with the DS process 40 for causing the DS process to retrieve data for archive from the first memory portion 5.4 of the DS memory and the second memory portion 5.7 of the DS memory and to transfer such data to the archive memory 400 for storage.
A user interface 300 is preferably operably associated with the DM process 30. The DM instructions preferably include a routine for determining whether a user notification should be transmitted to the user interface 300, a routine for generating the user notification, and a routine for transmitting the user notification from the DM process 30 to the user interface 300. To speed up the transmission of new information and notices to the user interface, a DM CSM can be employed. Generally the DM CSM will be operably associated with the DM process 30. The DM instructions include a routine to retrieve data from the DS memory and to transfer the data retrieved to the DM CSM for storage, a routine to cause a flag to be placed with the data last retrieved from the DS memory; a routine to transmit the data stored with the flag to the user interface 300, a routine for determining whether a user notification should be transmitted to the user interface, a routine for generating the user notification, and a routine for transmitting the user notification from the DM process to the user interface.
An external user interface 600 is preferably operably associated with the IO process 10. Where the external user interface is present, the 10 instructions preferably include a routine for processing queries from the external user interface, a routine for transmitting the processed queries from the external user interface to the DM process 30, a routine for processing query responses received from the DM process, and a routine for transmitting the processed query responses to the external user interface 600. The DM instructions preferably include a routine for processing queries received from the IO process 10, a routine for retrieving data responsive to said query from the DM memory 5.5, a routine for generating a query response based on the retrieved data, and a routine for transmitting the query response to the IO process 10. Queries can also be preferably processed by the DM process 30. The user interface 300 is present. The DM instructions include a routine for processing queries from the user interface 300, a routine for retrieving data responsive to said query from the DM memory 5.5; a routine for generating a query response based on the retrieved data; and a routine for transmitting the query response to the user interface 300.
Interleaving incoming data for processing is an important feature of certain embodiments of the invention. For interleaving, there is provided in the IO instructions a routine for assigning a processing priority designator to data inputs, and a routine for scheduling the data inputs for ordered transmission to the DP process 20 in a priority scheduler having a cyclic unvarying predetermined priority designator sequence. To keep data processing in Real Time, the computer system can be characterized as having a clock cycle speed and the sequence for the scheduler is selected based on said clock cycle speed so that the computer system has completed retrieval, processing and transmission to the DM memory of a first data sample having a common identifier characteristic prior to receipt by the IO process of a second data sample having such common identifier characteristic.
For fast processing, it is desirable that new data be flagged for processing when it is placed in memory. The IO instructions and means for causing the IO process 10 to transfer data to the IO memory 5.1, 5.2, and 5.6 for storage further comprises a routine for causing a flag to be placed with the transferred data. The DP instructions and means for causing the DP process 20 to retrieve data from a memory and to transfer calculated data to the DP memory 5.3 for storage further comprises a routine for removing the flag from the retrieved data and a routine for placing a flag with the transferred data. The DM instructions and means for causing the DM process 30 to retrieve data from the DS memory 5.4, 5.7 and to transfer the retrieved data to the DM memory 5.5 further comprises a routine for removing the flag from the retrieved data and a routine for placing a flag with the transferred data. The DS instructions and means for causing the DS process 40 to retrieve data from the IO memory 5.1, 5.2, 5.6 and the DP memory 5.3 and to transfer the retrieved data to the DS memory 5.4, 5.7 for storage further comprises a routine for removing the flag from the retrieved data and a routine for placing a flag with the transferred data.
The DP instructions and means for causing the DP process 20 to retrieve data from the DP CSM, process the data to form calculated data and to transfer the calculated data to the DP memory 5.3 for storage preferably further comprises a routine for transferring the calculated data to the DP CSM for storage.
The DP instructions preferably further comprise a routine for establishing a relationship between a most recently formed calculated data and a previously formed calculated data in the DP CSM, generating a data value representative of such relationship, and transferring such value to the DP memory 5.3 for storage.
For many applications, it is desirable to calculate information such as the rate of change of the information relating to an object. For example, for aircraft, location can be calculated from a single set of data inputs. Velocity and direction require two sets of data inputs. Acceleration calculations require three sets of data inputs. To perform these calculations, the DP process must access old information. If the aircraft is not accelerating, there is no need to perform acceleration calculations. To perform this functionality, the required information is preferably retained in the DP CSM. The DP instructions include a routine for calculating a value for a predetermined relationship between data most recently retrieved from the DP CSM and data previously retrieved from the DP CSM, a routine for transferring the value to the DP CSM for storage, a routine for calculating a calculated value trend from the stored values, a routine for predicting a predicted value for the next retrieved data based on the trend from the stored values, a routine for comparing the calculated value with the predicted value and completing further processing of the calculated value when the calculated value is outside of predetermined limits from the predicted value, and a routine for transferring the calculated value from the DP CSM to the DP memory for storage.
Incoming data to be processed will generally arrive with a data header containing information relating to data source, class, data format, and associated data parameters. The data will generally relate to dynamic information, such as object position, or static information, such as object identity or information from an external database. External interface 600 will be the source of the data. Preferably, an IO Complementary Shared Memory (CSM) is operably associated with the IO process. The data source is operably associated with the IO CSM. The data source transmits object data and external I/F data to the IO CSM for storage. The IO instructions include a routine to retrieve object data from the IO CSM, a routine to retrieve external I/F data from the IO CSM, a routine for identifying the source, class and type of data formats and associated data parameters and a routine to transfer the object data to the IO memory 5.1, 5.2, 5.6 for storage. For tracking purposes, the IO instructions generally further include a routine for causing the IO process to assign a multicharacteristic identifier to each data input and a routine for causing the IO process to transmit the muiticharacteristic identifier to the third memory portion
5.6 of the IO memory.
In a preferred embodiment of the invention, queries can be processed from external users through the IO process 10. Preferably, an IO CSM is operably associated with the IO process 10. A DM Complementary Shared Memory (CSM) is operably associated with the DM process 30. An external user interface 600 is operably associated with the IO process 10. External user interface instructions and means for causing the external user interface to transmit queries to the IO CSM for storage are also provided. A dedicated external user interface memory is operably associated with the external user interface 600, usually internally. The IO instructions include a routine to retrieve queries from the IO CSM, a routine to format the queries in an appropriate protocol, a routine to identify and transmit the queries to the DM CSM for storage, a routine to retrieve query responses from the DM CSM, a routine to format the query responses from the DM CSM into the protocol, and a routine to transmit the queries and the query responses to the external user interface memory for storage.
One of the features of a preferred embodiment of the invention is the storage of data in a relational database for fast retrieval and response. This functionality is provided by the DS process 40. A DS CSM is preferably operably associated with the DS process. An archive memory 5.4 is provided for storing data for archive from the DS process. The DS instructions and means for causing the DS process to retrieve data from IO memory 5.1, 5.2, 5.6 causes the DS process to retrieve such data into the DS CSM. The DS instructions further include a routine to retrieve dynamic data from the DS CSM, a routine to retrieve static data from the DS CSM, a routine to retrieve calculated data from the DS CSM, and a routine to retrieve the identifiers for the dynamic data, the static data, and the calculated data from the DS CSM. The identifiers are converted to record numbers by a routine in the DS instructions. The DS instructions further include a routine to convert the dynamic data, the static data, the calculated data and the record numbers to a relational data base format for storage as a relational data base in the DS memory and a routine for storing the relational data base in the DS memory. To provide long term storage and accessibility of information in the long term storage, the DS instructions further include a routine for retrieving the relational data base from the DS memory, a routine for storing the thus retrieved relational data base in the archive memory, a routine for transferring the relational data base from the archive memory to an archive media for storage, and a routine for transferring a relational data base from an archive media to the archive memory.
One of the features of a preferred embodiment of the invention is to provide a pathway for internal users to access external databases. To carry this out, a DM CSM operably is preferably associated with the DM process 30. The user interface 300
is also operably associated with the DM process. At least one external database operably associated with the DM process. The DM instructions include a routine for processing queries received from the user interface, a routine for identifying the external database containing data responsive to said query, a routine for retrieving the data responsive to said query from the external database, a routine for generating a query response based on the retrieved data, and a routine for transmitting the query response to the user interface 300.
To practice the process of a preferred embodiment of the invention a data input is received in an IO process 10. The data input is processed in the IO process and an IO output is produced. The IO output is transferred to an IO memory 5.1, 5.2,
5.6 for storage. The IO output is preferably also transferred to a DP CSM for storage, for faster pickup by the DP process 20. The CSM will generally be a part of the DP process. The IO memory output is retrieved from the IO memory 5.1, 5.2, 5.6. The retrieved IO memory output is received in a DS process 40. The received IO memory output is processed in the DS process and a DS output is produced. The DS output is transferred to a DS memory 5.4, 5.7 for storage. A DP CSM output is retrieved from the DP CSM. The DP CSM output is received in a DP process 20. The received DP CSM output is processed in the DP process and a DP output is produced. The DP output is transferred to the DP CSM. The DP output is transferred to a DP memory 5.3 for storage. A DP memory output is retrieved from the DP memory 5.3. The retrieved DP memory output is received in a DS process 40. The received DP memory output is processed in the DS process and a DS output is produced. The DS output is transferred to the DS memory 5.4, 5.7 for storage. The DS memory output is retrieved from the DS memory 5.4, 5.7. The retrieved DS memory output is received in a DM process 30. The received DS memory output is processed in the DM process and an DM output is produced. The DM output is transferred to a DM memory 5.5 for storage.
To carry out interleaving, a processing priority designator is assigned to data inputs to the IO process 10. The data outputs from the IO process 10 are scheduled for ordered transmission to the DP process 20 in a priority scheduler having a cyclic unvarying predetermined priority designator sequence.
To carry out the flagging feature of the invention, a flag is placed with all data when it is transferred to a memory.
The data processing function is carried out by calculating a value for a predetermined relationship between data most recently retrieved from the DP CSM and data previously retrieved from the DP CSM. The value is transferred to the DP CSM for storage. A calculated value trend is calculated from the stored values. A predicted value for the next retrieved data from the DP CSM based on the trend from the stored values. The calculated value is compared with the predicted value. Further processing of the calculated value is performed when the calculated value is outside of predetermined limits from the predicted value. The calculated value is transferred from the DP CSM to the DP memory for storage.
For processing a query from a user interface, a DM memory output is retrieved responsive to the query from the DM memory. A query response is generated based on the retrieved DM memory output in the DM process. The query response is transmitted to the user interface. User notices may also be generated for the user interface. The DM process determines whether a user notification should be transmitted to a user interface. If so, the user notification is generated by the DM process and transmitted from the DM process to the user interface.
For tracking, a unique multicharacteristic identifier is assigned to each data input by the IO process. This multicharacteristic identifier is transferred as IO output to the IO memory for storage and the DP CSM for storage.
To prepare for setting up the relational database, the IO process identifies the dynamic data and the static data and transfers the dynamic data as IO output to a first portion of the IO memory for storage and the static data as IO output to a second portion of the IO memory for storage. The multicharacteristic identifiers are transferred as IO output to a third portion of the IO memory for storage. The DS process completes setting up the relational database. An IO memory output is retrieved from the first portion of the IO memory, the second portion of the IO memory, and the third portion of the IO memory. The retrieved IO memory outputs are received by the DS process. The received IO memory outputs are reformatted in the DS process which produces a reformatted DS output. The reformatted DS output is transferred to the DS memory for storage.
Description of the Best Mode
The system concept of the C3M2 System is to have the capability of providing a Process for each major processing step of automated data processing, i.e. if you have four steps then you need a minimum of four processes but it could be 8 or 12 or
16 processes. The system shall be Multi-tasking for each step. Source headers, link lists and entity or object identifiers are the methods that shall be used for identity of the different classes, types and objects for the variety of data in the system. The source and data type are contained in the source header. The class and type identity are contained in the object identifiers. The multi-tasking would be by schedule (interleaved by priority). This was selected instead of cycle sharing for improved concurrency.
The multi-tasking by application processing steps requires much less time than the normal Serial Operating system Processing time. Each of the Processes shall operate independently of the other Processes and shall operate Concurrently. The data processes shall run until task completion prior to beginning the next process, Cooperative Processing. Each Process shall operate independently, using it's COS. The COS's have generic modules and can be configured for multiple processes. Each COS will operate independently and shall interface directly with the Operating system of the Process, but without preemption. The system speed is further enhanced by its lack of system overhead where interrupts, context switching and process initiation times are not required.
Data records for use by the system are Relational Database (RDB) formats for the entities, objects and attributes in a Flat File. The Flat File is defined as an array of data records. The files are by classes of system elements. The RDB files to reside in the Congruent Memory (CM) for Real Time access and are stored in the Archive Media (AM) on a cyclic basis that is determined in the planning phase. The latency time for access of the AM will be in the millisecond range. The cyclic time for exchange of data from the CM to the AM would be in the Hours-Type time period. Data files for making up the Object data records are initial or identity Data, Calculated Data for object performance & etc., Reference Data from the External Data base managers and Knowledgebase, Link List and Data Source data for each record. The entire record then becomes a part of the individual records for each object file number for the Real Time Archive data set.
The C3M2 system in its basic configuration has 4 or more separate Processes running on one or more Processors. The processes share a direct access Congruent Memory (CM). The CM is partitioned to specific storage areas with one Process writing to and one Process reading from the same partitioned memory cells.
The first selection considered for Data Class Priorities was the use of a scheduler. The current system criteria does not allow the use of interrupts or context switching. This criteria eliminated the normally accepted method of decision making capability for the Scheduler. It soon become apparent that the requirement could be met by delaying the process for one or more cycle times (through Interleaving) and insert the parameter in it proper data class and with its own object number. Since all parameters were time stamped, the actual processing time in its own Type and Class is still accomplished in real-time. The major factor was to keep the processing time in Real Time (less than the time between two data samples). Other alternate methods were explored to ascertain if other methods were more efficient than a scheduler. A "Data Interleaver" method appeared to be much simpler than a scheduler, if you observed the required criteria, This method would eliminate an entire Scheduler Module. Since "Known data" is used to plan operations, the types and classes of data are all that is needed to formulate an interleaver scheme. The lowest Data Rate has the highest Priority. The highest data rates have the lowest priority (number of samples per second). The criteria for the interleaver design is:
1. The cycle time of the computer must be faster than the sampling rate of the total data samples (more cycle times than sample clocks per second).
2. The sample times per data class and type shall be in their order of priority.
3. Each data sample is sampled in its order of priority. If data samples are not available, the process falls through to the next lower priority (no loss of time or addition of overhead).
4. The system can accommodate any number of data classes and types if this criteria is followed.
An example of the interleaving scheme is shown by FIG. 11, Inter-leaving Classes of Objects by Priority, for 7 classes of data. The system will allow almost any number of objects, types and classes that are known to the user. Any new data type can be entered when it is known to the user or identified by the system and is entered on the pointer or link list.
The interleaving of data for processing occurs at the IO. The priority are normally allocated in reverse order, i.e. the least sampled and the slowest sampled has the highest priority and the most frequently sampled with the most data has the lowest priority. The sampling priority falls through to the next lowest priority if data is not available. The data samples are listed in order of priority and by class. The classes are identified on FIG. 11. The time segments are shown arbitrarily in 200 millisecond segments. This is further reduced to subsegments of 50 milliseconds. The 50 millisecond subsegment is sampled in the order of priorities established in the planning phase. The first 50 millisecond subsegment has a sampling rate of 1
through 7 for the first 7 samples, then 4 through 7 for the remainder of the 50 millisecond subsegment. Each of the three remaining 50 millisecond subsegments begin with a Priority 3 sample and then reverts to the 4 through 7 priority for the remainder of the subsegment. There are 5 samples of Class 1 and 2 Priorities per second. There are 20 samples of Class 3 Priority per second. There will be approximately 2.times.10(6) priority samples per second for the IO or 1,999,970 samples remaining for Classes 4, 5, 6, and 7. Two hundred computer instructions per sample was used for timing purposes. The encapsulation of the IO is not effected by other operations of the system and the timing is solely a function of the IO Process.
The System Connectivity is shown by FIG. 12, C3M2 Software Context Diagram. System Functions of the C3M2 System includes the Communication Links to External Sources of Data (600), Data Servers (300), User Work Stations (310), Real Time Displays (330), Data Archival Devices (400) and the C3M2 System (100). The system design envisions any number of communications interfaces for Fiber Optic Interfaces to External Users. The communications interfaces of the C3M2 system would be connected directly to Standard Communications Links, i.e. High Speed Data Transfer Links and Networks using standard formats and protocols. Data to be communicated to the C3M2 System includes Sensor and Acquisition Data (500) from Real Time Sources (Dynamic Data) and External Data (600) of interest to the Users, Remote data accesses and Distributed data base management system (Static or Reference Data). The data would be processed by the C3M2 System (100) and made available to the System Users (310), Displays (330) and Data Archive (400). The data would also be available to all authorized External Users. The Users could perform at work stations interconnected directly to the Real Time distributed memory function of the C3M2 System or to a Data Server (300) connected to the Real Time DM Function. Display functions could be connected directly to the Real Time DM Function or to a Data Server.
The block diagram of the C3M2 system processes is shown by FIG. 13, C3M2 Software System Processes. The system design envisions any number of bridges from the Fiber Optic Interfaces to External Users. Data to be communicated to the IO (1.0) include all position data and external data from databases and other external resources. The IO will transform any required external data to a standard protocol and format for use in the C3M2 System. The IO shall then store the data in the Position Database (5.1) of the Congruent Memory (5.0). The data shall be stored in the record or object format and the IO shall update its associated Link List. The DP (2.0) shall access the Congruent Memory when data is available. Data availability is conveyed by the Link List. External data shall be accessed by the IO (1.2) and it's data shall be stored in the External Data Database (5.2) and the IO shall update it's Link List. The DP (2.1) shall provide data to the Knowledgebase (2.2) for Objects and their attributes and receive identity or support data in return. The processed data will be stored in the Calculated Data Database (5.3) by the DP. The DP shall also update the Link List of the calculated Data Database. The DS (4.0) shall control all archive data in the Congruent Memory and Archive Data Database (5.4). The Data storage Process shall transfer data from the Position Data (5.1), Calculated Data (5.2), and External Data (5.3) to the Archive Database (5.4) on a cyclic basis. The archive data to be real-time, critical-time and historical data. The Real Time DM (3.0) shall provide the User interfaces to the C3M2 system, support all display systems (3.1), User Queries (3.2), User Work Stations and Database Servers.
The IO (1.0) is the interface to all outside interfaces, Comm Lines and other Processing Nodes. Resident Data in the IO shall be the interfacing formats and control methodology for each external interface. Intrasystem interfaces for the IO include the Real Time DM and the Congruent Memory. Resident data for the intra-system interfaces include instructions for the Real Time DM and the dedicated memory locations (Record and Link List) for each record of each external interface. Link List and Look-Up Table locations for all dedicated intra-system interfaces are resident in the IO and the Congruent Memory. The Control Flow Diagram (CFD) is shown by FIGS. 14.1 (Input) and 14.2 (Query), C3M2 Control Flow Diagrams for the IO. Associated with the CFD is one or more Input Function/Process Output (IFPO) table listing Inputs, functions performed by the process and the processing required for each section of the CFD.
The IFPO for the 10 Processes are shown by Table 4-1.1 (Input) and 4-1.2 (Query) IO (Input/output) Requirements.
TABLE 4-1.1 __________________________________________________________________________ INPUT/OUTPUT (IO) Requirements (Input) INPUT FUNCTION/PROCESS OUTPUT (IFPO) (Baseline IO Requirements) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft - 50 inputs. 1. Receive samples (Range and Bearing) & Classify 1. 3 Store Reference data as applicable, Samples every 20 Seconds, from Surface Craft Speed < 50 Knots. store sample data once/minute in Range and Bearing. 2. Receive data from external reference sources common memory 3. Store sample and rederence data in memory. 1. 4 Update Link List when Store External Reference Data 4. Construct a link list for records in memory completed. B. Special Vehicles 50 inputs. 1. Receive samples (Range, Bearing & Elev.) 1. 3 Store Reference data as applicable, Samples ever 4 seconds, Classify from SP Vehicle. Speed < 250 Knots. store sample data once/20 Seconds Range, Elev. & Bearing 2. Receive data from external reference sources in common memory 250 Knots Max. 3. Store sample and reference data in memory 1. 4 Update Link List when Store External Reference Data 4. Construct a link list for records in memory completed. C. Aircraft - 100 inputs, samples 1. Receive samples (Range, Bearing, Elev. & Rl) 1. 3 Store Reference data as applicable, every 0.5 seconds, Range, Classify from Aircraft. Speed > 250
Knots. store sample data once/2 Seconds bearing. elev. & refractice 2. Receive data from external reference sources in common memory index - if avail. 3. Store sample and reference data in memory 1. 4 Update Link List when Store External Reference Data 4. Construct a link list for records in memory completed. D. Short Range Missiles 1. Receive samples (Range, Bearing, Elev. & Rl) 1. 3 Store Reference data as applicable, 25-inputs-Samples every . Classify from Short Range Missile. Speed > 2500 store sample data once/1 Seconds 25 Second, Range, 2. Receive data from external reference sources In common memory Bearing, Elevation, Retrac- 3. Store sample and reference data in memeory 1. 4 Update Link List when Store ion index, 3000 Knots Mx 4. Construct a link list for records in memory completed. E. Long Range Missiles 1. Receive samples (Range, Bearing, Elev. & Rl) 1. 3 Store Reference data as applicable, 10-inputs Samples every . Classify from LRM's. Speed > 6000 Knots. store sample data once/0.5 Seconds 0.1 Second, Range, 2. Receive data from external reference eources in common memory Bearing, Elevation, Refrac- 3. Store sample and reference data in memeory 1. 4 Update Link List when Store tion index, 6000 Knots Mx 4. Construct a link list for records in memory completed. __________________________________________________________________________ Processing 1.1.1 Receive Data and Classity (1.1.1) a. Retrieve the sampled dynamic data from the External Interface (600). b. Identify each data sample from the communications header as to its Source, Class, Type and Object. c. Provide Priority and schedule for each data sample during current time frame. d. Retrieve static data from the External I/F (600). e. Identifies the static data from the communications header for data source, database, query No., data records, date validated, and time stamp 1.1.2 Construct a Link List (1.1.2) a. Provide Dynamic data to the Object Link List (5.1), Includes Record No., time stamp, and updated data Flag. b. Provide data for the Static Data Link List and includes the Static Record No., Database name, Time stamp, Source, Class, Type, Object and update data Flag. 1.1.3 Store Data (1.1.3) a. Provide outputs of Dynamic data to the IO dedicated Object memory and set the updated data Flag. b. Stores the Static data in the EXT dedicated memory (5.2) for external data from databases and external sources, set the data update Flag. c. Stores Link List data in the L/L dedicated memory (5.6), set the data update Flag.
TABLE 4-1.2 __________________________________________________________________________ Input/Output (I) Requirements (Query) INPUT FUNCTION/PROCESS OUTPUT (IFPO) (Baseline IO Requirenments) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft 1. Interfaces with External interfaces (Safenet). 1. External User Query Request. Queries to RDA's or DDMS 2. Provides interface compatability for all
2.eries. CRDB User Query to DDMS. Queries from RDA or DDMS 3. Provided I/O data storage for Ref. & Query 3.ta. External Reference Data as queried Refer. data from/to DDMS's 4. Provides the IO.sub.-- Process & DM.sub.-- Process interface. by CRDB Users. Queries from C3M2 Users B. Special Vehicles 1. Interfaces with External interfaces (Safenet). 1. External User Query Request. Queries to RDA's or DDMS 2. Provides interface compatability for all 2.eries. CRDB User Query to DDMS. Queries from RDA or DDMS 3. Provided I/O data storage for Ref. & Query 3.ta. External Reference Data as queried Refer. data from/to DDMS's 4. Provides the IO.sub.-- Process & DM.sub.-- Process interface. by CRDB Users. Queries from C3M2 Users C. Aircraft - 100 inputs, samples 1. Interfaces with External interfaces (Safenet). 1. External User Query Request. Queries to RDA's or DDMS 2. Provides interface compatability for all 2.eries. CRDB User Query to DDMS. Queries from RDA or DDMS 3. Provided I/O data storage for Ref. & Query 3.ta. External Reference Data as queried Refer. data from/to DDMS's 4. Provides the IO.sub.-- Process & DM.sub.-- Process interface. by CRDB Users. Queries from C3M2 Users D. Short Range Missiles
1. Inferfaces with External interfaces (Safenet). 1. External User Query Request. Queries to RDA's or DDMS 2. Provides interface compatability for all 2.eries. CRDB User Query to DDMS. Queries from RDA or DDMS 3. Provided I/O data storage for Ref. & Query 3.ta. External Reference Data as queried Refer. data from/to DDMS's 4. Provides the IO.sub.-- Process & DM.sub.-- Process interface. by CRDB Users. Queries from C3M2 Users E. Lcng Range Missiles 1. Interfaces with External interfaces (Safenet). 1. External User Query Request. Queries to RDA's or DDMS 2. Provides interface compatabiiity for all 2.eries. CRDB User Query to DDMS. Queries from RDA or DDMS 3. Provided I/O data storage for Ref. & Query 3.ta. External Reference Data as queried Refer. data from/to DDMS's 4. Provides the IO.sub.-- Process & DM.sub.-- Process interface. by CRDB Users. Queries from C3M2 Users __________________________________________________________________________ Processing
1.2.1 Receive and Tranmits Queries (1.2.1) a. Retrieves Query inputs from the External I/F (external DDMS). b. Transfers Query data to Query identity (1.2.2). c. Receives data from the Query Request (1.2.3), formats and transfers to the desired External User. d. Received Query Data from Query Data Store (1.2.4), formats and transfe the data to the requesting External User. 1.2.2 Query identity (1.2.2) a. Provides identity of External Data Queries using the Message Headers for Source, Class, Types, Objects & Time Stamps. b. Transfers the Query request tot the DM Process (3.0). 1.2.3 Query Request (1.2.3) a. Receives Query Request from the DM.sub.-- Process (3.0). b. Provides the properly formatted query (includes Communications Header) for transfer to the correct External User. 1.2.4 Query Data Store (1.2.4) a. The IO.sub.-- Process provides interim storage for the Query data provided by the DM Procees (30). b. The IO.sub.-- Process provides format and message heading information for the requested Query Data, as requested by External authorized Users.
Processing steps for the Control flow diagrams are shown in the processing section of the IFPO. The processing section of the IFPO will be expanded one or two layers during detail design. The process shall schedule all inputs and outputs of the systems, provide a priority for each IO, and have the Address Pointers for it's outputs, to ensure that all requirements and transfers are met. All input data (1.1) shall be converted to binary data and all output data (1.3) shall be converted to the desired format from binary data. Any overload to be transferred to a Cooperative Process.
The DP (2.0) shall provide the data processing for the complete system or for the individual system at its level, depending on the Loading Level and the priority levied for each process. The priorities and loading levels are determined at the Planning Phase before initiation of the Operating time period. The Control flow diagram for the DP is shown by FIG. 15, C3M2 Control Flow Diagram DP.
The IFPO for the DP is shown by Table 4-2.
TABLE 4-2 __________________________________________________________________________ Data Processing (DP) Requirments INPUT FUNCTION/PROCESS OUTPUT (IFPO) (Baseline Data Processing Requirements) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft 1. Scan the Link List and process the next 1.cord. Transfer derived data of first 1. Range and Bearing 2. Convert Range and Bearing to X, Y, Z. data to KB. 2. Data from external 3. Process the algorithms required for the 2.cord. Transfer Dynamic Calculated Reference data 4 Reset the status bit(s) indicating the DP Data to Concurrent Memory 3. Link List maintained process is completed. 3. Update Link List by IO Process 5. Maintain a count of the number of records. 4. Update Data Record Count 4. Ref. data from KB B. Special Vehicles 1. Scan the Link List and process the next 1.cord. Transfer derived data of first 1. Range and Bearing 2. Convert Range and Bearing to X, Y, Z. data to KB. 2. Data from external 3. Process the algorithms required for the 2.cord. Transfer Dynamic Calcuiated Reference data 4 Reset the status bit(s) indicating the DP Data to Concurrent Memory 3. Link List maintained is completed. 3. Update Link List by IO Process 5. Maintain a count of the number of records. 4. Update Data Record Count 4. Ref. data from KB C. Aircraft 1. Scan the Link List and process the next 1.cord. Transfer derived data of first 1. Range and Bearing 2. Convert Range and Bearing to X Y, Z. data to KB. 2. Data from external 3. Process the algorithms required for the 2.cord. Transfer Dynamic Calculated Reference data 4 Reset the status bit(s) indicating the DP Data to Concurrent Memory 3. Link List maintained process is completed. 3. Update Link List by IO Process 5. Maintain a count of the number of records. 4. Update Data Record Count 4. Ref. data from KB D. Short Range Missiles 1. Scan the Link List and process the next 1.cord. Transfer derived data of first 1. Range and Bearing 2. Convert Range and Bearing to X, Y, Z. data to KB. 2. Data from external 3. Process the algorithms required for the 2.cord. Transfer Dynamic Calculated Reference data 4 Reset the status bit(s) indicating the DP Data to Concurrent Memory 3. Link List maintained process is completed. 3. Update Link List by IO Process 5. Maintain a count of the number of records. 4. Update Data Record Count 4. Ref. data from KB E. Long Range Missiles 1. Scan the Link List and process the next 1.cord. Transfer derived data of first 1. Range and Bearing 2. Convert Range and Bearing to X, Y, Z. data to KB. 2. Data from external 3. Process the algorithms required for the 2.cord. Transfer Dynamic Calculated Reference data 4 Reset the status bit(s) indicating the DP Data to Concurrent Memory 3. Link List maintained process is completed. 3. Update Link List by IO Process 5. Maintain a count of the number of records. 4. Update Data Record Count 4. Ref. data from KB __________________________________________________________________________ Processing 1. Next Record for Processing (2.1) a. Scan Data Ready Flags in OBJ Memory (5.1). b. Provide Next Record No. by Priority and Schedule to "Get Current Record" Module (2.2). 2. Get Current Record (2.2) a. Retrieve the Next Recod from the OBJ Memory (5.1). 3. Get Prior Record (2.3) a. Provide Prior Object Data Value and Time Stamp from OBJ Memory (5.1) t Calculation Module (2.4). 4. Calculations (2.4) a. Compare current value with Prior Value plus Trend Value; if equal then processing is not required. b. If processing is required then complete the process, each class and type has its own process. c. If object idenity or Decision Support is required; forward the Object Type and its attributes to KB. d. Retrieve Decisioin Data from the KB. e. Store Calculated Data and Decision Data in Calculated Data Database (5.3).
Processing actions of the Control flow diagram are described in the processing section of the IFPO. Data transferred to the DP will be dynamic data, Data Records, data words for Alarm Conditions and appropriate data for priority designations or requests. Static Data sources will be identified at the initiation of Operating time periods and will consist of Database and Field Identities, Address Locations, storage instructions, and destinations for the data. Interfaces of the DP are the Congruent Memory and the Knowledgebase. All modules in the DP shall be reusable, resides in a Library, are memory resident, and operated in a priority sequence for blocks of data or Alarm Data. The DP shall complete its current cycle before the initiation of any following sequences.
The Real Time DM (3.0) shall provide the Active Real Time Data repository for the system, provides an active interface with the IO, Data storage, Graphic user interface and Users, provides the proper formatted data for displays, reports and external data sources. The Control flow diagrams for the Real Time DM are 16.1 (User Data) and 16.2 (Query Data).
The IFPO's for the Real Time DM are shown in Table 4-3.1 for User Data and 4-3.2 for Query Data.
TABLE 4-3.1 __________________________________________________________________________ DATE MEMORY (DM) Requirements (User Date) INPUT FUNCTION/PROCESS OUTPUT (IFPO) (Baseline DM Requirements-User Data) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft 1. Sample the desired real-time track data in the 1. Provide required Alarms and Real-Time Track Data in 2. Forward any Alarm or Critical info to the info to the required Users and Congruent Memory (CM) Users and display the info on required displays displays 3. Provide the selected displays for all users 2.d Initialize and update al displays displays and maintain the updates of the requested by the users. with the current applicable data. Updates to be on a cyclic basis, using current real-time data. B. SP Vehlcies 1. Sample the desired real-time track data in the 1. Provide required Alarms and Real-Time Track Data in 2. Forward any Alarm or Criticai info to the info to the required Users and Congruent Memory (CM) Users and display the info on required displays. displays 3. Provide the selected displays for all users 2.d Initialize and update al displays displays and maintain the updates of the requested by the users. with the current applicable data. Updates to be on a cyclic basis, using current real-time data. C. Aircraft 1. Sample the desired real-time track data in the 1. Provide required Alarms and Real-Time Track Data in 2. Forward any Alarm or Critical info to the into to the required Users and Congruent Memory (CM) Users and display the info on required displays displays 3. Provide the selected displays for all users 2.d Initialize and update al displays displays and maintain the updates of the requested by the users. with the current applicable data. Updates to be on a cyclic basis, using current real-time data. D. Short Range Misslie 1. Sample the desired real-time track data in the 1. Provide required Alarms and Real-Time Track Data in 2. Forward any Alarm or Critical info to the into to the required Users and Congruent Memory (CM) Users and display the info on required displays displays 3. Provide the selected displays for all users 2.d Initialize and update al displays displays and maintain the updates of the requested by the users. with the current applicable data. Updates to be on a cyclic basis, using current real-time data. E. Long Range Missile 1. Sample the desired real-time track data in the 1. Provide required Alarms and Real-Time Track Data in 2. Forward any Alarm or Critical info to the info to the required Users and Congruent Memory (CM) Users and display the info on required displays displays 3. Provide the selected displays for all users 2.d Initiaiize and update al display displays and maintain the updates of the requested by the users. with the current applicable data. Updates to be on a cyclic basis, using current real-time data. __________________________________________________________________________ Processing: 1. Process User Data (3.2.1) a. Retrieve the updated Record No. of the R/L Memory (5.7) and reset the Update Flag of the Record Link List. b. Retrieve the Archieve Record data from the Archieve memory. c. Format the data to the Users requirement. d. Transfer the data to temporary storage for Users Updated Data (3.1.3). e. Retrieve Priority data from the R/L Memory (5.7) and reset the Priorit Flag. f. Formats the Alarm, Alert or Trigger Mesaages and transfers to the User Priotity Data Module (3.1.2). 2. User Priority Data (3.1.2) a. Provides temporary storage for Priority, Triggers, Alarms and Notices data. b. Notifies Transfer Module (3.2.1) that Priotity Data is available and sets Priority Flag. 3. User Record Data (3.12.3) a. Provides temporary data storage for data records and record updates. b. Notifies Transfer Module (3.2.4) that record data is available and set Data Record Flag. 4. Transfer Data (3.1.4) a. Retrieves record data from temporary storage and resets the Data Recor Flag. b. Retrieves the Priority Data from temporary storage and resets the Priority Flag. c. Transfers the received information to the Users interface (300) on a priority and schedule basis.
TABLE 4-3.2 __________________________________________________________________________ DATA MEMORY (DM) Requirements (Query Data) INPUT FUNCTION/PROCESS OUTPUT (IFPO) (DM Requriements - Query) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft 1. User Query request consisting of Track ID & 1.me All track or query data, with each User query, i.e. consisting of Track period or other queries that correspond to record or set of data furnished in a number the Start and Stop Time. 2. Access the Link List for Track or other Query FIFO sequence. Archived track data file, CM or requested by the User. archive media or both, and the 3. Scan the Link List for the Record numbers and/or Link List for each track.. columns corresponding to the time intervals or data requested by the user. 4. Retrieve all selected data queried by the User. B. Special Vehicle 1. User Query request consisting of Track ID & 1.me All track or query data, with each User query, i.e. consisting of Track period or other queries that correspond to record or set of data furnished in a number the Start and Stop Time. 2. Access the Link List for Track or other Quiery FIFO sequence. Archived track data file, CM or requested by the User. archive media or both, and the 3. Scan the Link List for the Record numbers and/or Link List for each track.. columns corresponding to the time intervais or data requested by the user. 4. Retrieve all selected data queried by the User. C. Aircraft 1. User Query request consisting of Track ID & 1.me All track or query data, with each User query, i.e. consisting of Track period or other queries that correspond to record or set of data furnished in a number the Start and Stop Time. 2. Access the Link List for Track or other Query FIFO sequence. Archived track data file, CM or requested by the User. archive media or both, and the 3. Scan the Link List for the Record numbers and/or Link List for each track.. columns corresponding to the time intervals or data requested by the user. 4. Retrieve all selected data queried by the User. D. Short Range Missile 1. User Query request consisting of Track ID & 1.me All track or query data. with each User query. i.e. consisting of Track period or other queries that correspond to record or set of data furnished in a number the Start and Stop Time. 2. Access the Link List for Track or other Quiery FIFO sequence. Archived track data file, CM or requested by the User. archive media or both, and the 3. Scan the Link List for the Record numbers and/or Link List for each track.. columns corresponding to the time intervals or data requested by the user. 4. Retrieve all selected data queried by the User. E. Long Range Missile 1. User Query request consisting of Track ID & 1.me All track or query data, with each User query. i.e. consisting of Track period or other queries that correspond to record or set of data furnished in a number the Start and Stop Time. 2. Access the Link List for Track or other Quiery FIFO sequence. Archived track data file, CM or requested by the User. archive media or both, and the 3. Scan the Link List for the Record numbers and/or Link List for each track.. columns corresponding to the time intervals or data requested by the user. 4. Retrieve all selected data queried by the __________________________________________________________________________ User. Processing: 1. User Query (3.2.1) a. Retrive User Query from the User interface (300) b. Process the query for proper Format, ID, and transfer to the Access Query Data Module (3.2.2) 2.Access Query Data (3.2.2) a. Accesses Record Link List (5.7) for Query Data Record Numbers. b. Retrieves Query records from the Archive memory (5.4). c. Transfers the Query records to the Transfer Module (3.2.3). 3. Transfer Module (3.2.3) a. Provides temporary storage for the Query record data. b. Transfers the Query records to the User interface (300) on a cyclic scheduled basis.
The processing steps for the Control flow diagrams are shown in the Processing Section of the IFPO. All data transfers shall be by File and Records or memory pages and not by individual active data words. Memory locations are designated by the link lists during initial configuration and include all dynamic and static data. The data repository for the Real Time DM is part of the Congruent Memory. The Partitioned Data Storage (PDS) areas are for each individual track or object, which may be grouped for displays or reports as selected by the User. The data is transferred to the Real Time DM allocations from the Real-time/Critical-time segments of the Congruent Memory and Data Archive Media. All data updates for the PDS are from the latest data samples of each applicable data record. Displays, reports and User notifications occur within milliseconds from the arrival time of the event or occurrence. The slowest response of the entire system will be by the user in observations or actuation. The updates for the Real Time DM will occur concurrently with the updates for the Data archive Media. The outputs and input requests could number in the thousands but for any one instance would probably be in the hundreds. The process duration could be from minutes, to hours to days depending on the class of objects or targets. The Real Time DM would also be the respondent for Weapons and tactical systems.
The Data Storage (4.0) can be described as a database that responds to a "Direct Access" or Structured query language type query. The database shall consist of portions of the Congruent Memory (5.0) and other storage media. The Data storage shall a collection of "Flat Files" that shall be the repository of all static and dynamic data in the system. The data storage record formats shall contain all of the data required to identify all input data types, all output data types, and reference data parameters or algorithms (i.e. Calibration Data, Processing Instructions, & etc.). The data shall be stored in "Static and Dynamic" locations. The Static Data will be a one time entry (persistent data) and the Dynamic Data will be the Real Time plus any Processed data. The Process requiring access to these data record sets is the Real Time DM (3.0). Interfaces to the Data storage are the Congruent memory, Data Archive media and the Real Time DM. The Control flow diagram for the Data storage is contained in FIG. 17.
The IFPO for the Data storage is Table 4-4, Data Storage Requirements.
TABLE 4-4 __________________________________________________________________________ Data Storage (DS) Requirements INPUT FUNCTION/PROCESS OUTPUT (IFPO) (Baseline DS Requirements) Inputs Functions Outputs __________________________________________________________________________ A. Surface Craft 1. Montiors the real-time object or track data in 1.e Real-time Alarms, Alerts, and Real-time track or object data Concurrent Memory & their Record Numbers information Messages, to Concurrent Memory 2. Provides any alarm or data information 2.sages Real-time displays and reports Record Numbers the Users or Query Users. for On-Une Users. 3. Initialize and update displays and reports for the On-Line Users. B. SP Vehicles 1. Montiors the real-time object or track data in 1.e Real-time Alarms, Alerts, and Real-time track or object data Concurrent Memory & their Record Numbers information Messages, to Concurrent Memory 2. Provides any alarm or data information 2.sages Real-time displays and reports Record Numbers the Users or Query Users. for On-Line Users. 3. lnitialize and update displays and reports for 3.e Real-time Archive to Archive On-Line Users. Media C. Aircraft 1. Montiors the real-time object or track data in 1.e Real-time Alarms, Alerts, and Real-time track or object data Concurrent Memory & their Record Numbers information Messages, to Concurrent Memory 2. Provides any alarm or data information 2.sages Real-time displays and reports Record Numbers the Users or Query Users. for On-Line Users. 3. Initialize and update displays and reports for 3.e Real-time Archive to Archive On-Line Users. Media D. Short Range Missiles 1. Montiors the real-time object or track data in 1.e Real-time Alarms, Alerts, and Real-time track or object data Concurrent Memory & their Record Numbers information, Messages. to Concurrent Memory 2. Provides any alarm or data information 2.sages Real-time displays and reports Record Numbers the Users or Query Users. for On-Line Users. 3. Initiaiize and update displays and reports for 3.e Real-time Archive to Archive On-Line Users. Media E. Long Range Missile 1. Montiors the real-time object or track data in 1.e Real-time Alarms, Alerts, and Real-time track or object data Concurrent Memory & their Record Numbers information Messages, to Concurrent Memory 2. Provides any alarm or data information 2.sages Real-time displays and reports Record Numbers the Users or Query Users. for On-Line Users. 3. Initialize and update displays and reports for 3.e Real-time Archive to Archive On-Line Users. Media __________________________________________________________________________ Processing: 1. Record Count in Archive Media (4.1) a. Retrieve the updated Data Object data list for Object Records and rese the updated data Flag. b. Transfer the updated Record No.'s to the Access Data in Memory (4.2) Module. 2. Access Data in Memory Module (4.2) a. Retrieve the Object Data Records from the Object Data Memory (5.1). b. Retrieve the Calculated Data Records from the Calculated Data Memory (5.3). c. Format the data into the prescribed RDB format for the Class, Type and Object. d. Transfer the RDB format records to the Transfer Records Module (4.3). 3. Transfer Records (4.3) a. Assigns sequential record numbers to each record for each class and type. b. Transfers the last updated RDB Records to the Archive Memory Database (5.4). 4. Transfer Records Between Archive Media (4.4) a. Processes Transfer Trigger from DM (30). b. Transfer the prescribed number of records from the Archive Memory Database (5.4) to the Archive Media (400). c. Processes Retrieve Trigger from DM (30). d. Transfers the prescribed number of records from the Archive Media (400 to the Archive Memory (5.4).
The processing steps for the Control flow diagram, FIG. 17, are contained in the processing section of Table 4-4. The initial Data Dictionary and Structure of the Data Records shall be completed and documented from User Procedures and Standards and from documents provided by associated sources. The Data storage shall have IO Link List and pointer address information for all Data storage applications and data files. The process shall control and schedule all external request for data, monitor and record all data inputs, record all requests for data, verify that the data requestor is authorized and provide an audit trail for all data access requests.
The C3M2 System must be configured to meet Operations requirements. This evolves around the basic Software systems requirements, i.e. inputs-sources, functions/processing-data sets, and outputs-archived memory allocations. In C3M2 ternfinology it involves the IO-Input, DP, IO/DP/DS/Real Time DM-Functions, and Data storage-Memory Allocation for persistent or archived data. This sequence of events is depicted by FIG. 18, Sources, Data Sets and Memory Allocation.
The external Interface (600) provides the communications data links to the IO (10). The communications interface will be standard communications interfaces that are concentrated by HUBS or Concentrators. The communications links and message headers will identify the data source and class of data to the IO. The data sources include Sensor, acquisition, Comm. Links, Comm. I/F's, Remote data access, DDMS and Test Data. The Test Data will be generated by the C3M2 System and will be a Closed Loop test of the C3M2 system, a communications port that is connected to an external port on the External Interface or routed to a remote source for re-transmission to the External Interface for communication link tests.
The data sets are routed from the External Interface (600) the IO (10). The IO identifies the Source, the class of data, determines that the data is Dynamic or Static, determines that the data requires or does not require processing, and applies a track or data number if one has not been assigned. The data is then exchanged with the External Data Memory (5.2) or the DP (20), the Position Data Memory (5.1), and updates the Object Link List (5.6). The DP processes the available data (a flag was set in the Object Link List (5.6) that the data was available) with processing required for that class of data. This calculated data is then exchanged with the Calculated Data (5.3) by the DP (20). The DP (20) will also exchange the initial calculated attribute data with the Knowledgebase (200). The knowledge base will use existing Reference Data and current target or signature data to attempt to perform identification of the request. The Knowledgebase (200) will respond to the DP (20) in a small number of milliseconds. The DP (20) and Knowledgebase (200) will also respond to Alarms, Notices, Critical Events and other Attention Occurrences to the Real Time DM (30) in 100's of MicroSeconds. Processed Data is now available for C3M2 use in 100's of Microseconds after arrival at the External Interface (600). The Real Time DM (30) will monitor the Record Link List (5.7) for new updates and update all User Data Files (310), Servers (320), and Displays (330) being maintained by the Real Time DM (30). All current displays, reports and files requiring dynamic updates are maintained by the Real Time DM (30) in the real-time Real Time DM (5.5). The DS (40) maintains all dynamic and static data in the system by source and sequential track/data number and in the time sequence of the time stamp associated with each individual data sample. The data is transferred from the Position (5.1) and Calculated (5.3) Data on a cyclic basis determined in the planning phase (from 100's of microseconds to seconds or minutes). The External Data (5.2) will be transferred to the applicable track or data number upon receipt (100's MicroSeconds). Data will be exchanged with the Archive Media (400) by the DS (40) on a cyclic basis, to be determined during the Planning Phase. This time frame could be a large number of minutes, hours or days. Due to the dynamic concurrent operations of the C3M2 System all of these actions can occur in realtime without system waits or interrupts.
The Memory allocation of the Congruent Memory (50) is comprised of 7 memories of various sizes and allocations. The memory size normally is a product of 2, i.e. 8, 16, 32, 64, 128, 512, 1024. The maximum memory size for processes, under consideration, is 1 Giga-Byte (GB). The internal storage size is 32 GB. The latency time for internal memory is in the order of NanoSeconds while the internal storage is in the order of multiple milliseconds. External DS is in the order of TeraBytes (TB). The internal memory is normally segmented into pages of 4096 Bytes or a maximum of 250,000 pages per CPU. The maximum memory for a four CPU configuration is 4 GB. The seven memories are shown in FIG. 18. Each dedicated memory is allocated its memory size during the Planning Phase but could be readily adjustable.
How to make and use a preferred embodiment of the invention is further illustrated by the following examples.
EXAMPLE I
The system operations capabilities shall include:
A communication interface with the data sources of interest.
Providing data of interest to Operational Users.
The data of interest includes Operations, Modeling, Simulation, Training and Operations Planning.
Output data is provided to Large Screen Displays, Work Stations, Queries and External Users.
Planning phase to identify and Import Data from all known database of interest.
Menus will be provided for all identified databases, their data fields & related columns, operations scenarios, and C3M2 Operations
Display screens to be defined in the planning phase.
Index and link list for External Databases (RDA) to be prepared during the planning phase.
Planning phase to be two or more hours prior to Operations Testing.
Active Data to be the Dynamic data provided by Sensors, Data Acquisition Devices and other Real-Time devices.
Reference Data to be the support data provided by Users and other remote databases for use in identifying, supporting or describing the Dynamic Data.
The System shall have the capability to receive and analyze data from a large number of classes and objects. The input data being used for throughput and sizing is shown by FIG. 1, C3M2 System Domain. The data contemplated for inputs to the C3M2 (100) are Communications Links that interface with the External Interfaces (600). The data on these communication links include acquisition data, sensor data, data files, or portions of data bases. The data inputs can be Real Time Data (Dynamic) or Descriptive Support Data (Static). The Internal interfaces include the User Interface (330), Data Archive (400) and the Knowledge Base (400). The Archive Media shown is over and above the Gigabyte data storage of the C3M2. The KB provides the decision support for the C3M2 System.
The current mode of operations utilizes databases as a separate entity from system applications. Separate stand alone queries are used to obtain any desired data. This method of operations utilizes the Operating System extensively, along with a large number of computer operations for interrupts and context switching. The Overhead (OH) of current Operating Systems is normally larger than 50%. Current operating system methodology requires special software applications for Multi-Tasking and Multi-Processing. This adds to the operating system overhead and decreases the effectivity of the Process. This also adds new procedures which also delays the software processing. These procedures are Preemptive Interrupts, Exceptions, Wait States, Cycle Sharing and Task Sharing. Multi-Processing also adds two new terms and procedures, i.e. Massively Parallel Processing (MPP) and Symmetrical Processing (SMP). MPP configurations share work tasks and each process has its own memory. The SMP share work loads and have a common memory. SMP works better when the Processes are less than 10 and the MPP when the processes are more than 10. Either process complicates the Operating System and Applications software. Some experts predict that it will take software Engineers 20 years to advance as far as the hardware engineers in Operating System and Multi-Processing.
The planned mode of operations for C3M2 will not depend on the Operating System for operations or the compiler for addresses. The planned system configuration requires multiple processes for performance of complementary system functions, i.e. IO, DM, DP, DS. The separate but integrated processes will permit a simpler performance of Information and data processing applications using COTS equipments and modules (hardware & software). The COTS hardware and software can be configured into System, Subsystems, hardware Subsystems, software Subsystems, equipments or modules. This mode of configurations is made possible by the design methodology and the planned allocation of functions in the software and the hardware. The system design philosophy will also allow for a large number of data types for Objects, Targets, Triggers, Alarms, Critical Events, ADT's or BLOBS. This is accomplished through Task Inter-Leaving and Priority Insertion. The Priority Insertion of data into the data being processed can be accomplished without the data process being interrupted but it is delayed one instruction time. The replication of each system function will have interfaces to its complementary components in the system but may require configuration for that individual application. The baseline system will have a capability of approximately 1.6 Gigaflops. The systems data bus is 64-Bits wide. The system operates in a complementary fashion and each process or baseline system can be connected in series, parallel or both as the requirements dictate. The baseline system can also be configured for a Multi-Level System with Multi-Gigaflop capability. The Block Diagram of the System Concept is shown by FIG. 2, C3M2 Systems Conceptual Drawing. The Multiple Level configurations are shown by FIG. 3, C3M2 System Block Diagram. The Hardware (hardware) and the software components shall be replicated by system until every data input parameter is reduced to its lowest usable form and archived. The software replication and configuration of system levels are shown by FIG. 4, Replicated System Expansion, Serial-Parallel-or-Both.
The system concept shown by FIG. 2 is to list all of the potential interfaces of the system and their inter-connections. The method shown is for Parallel High Speed Buses (PHDB) of 32 or 64 bits. The Futurebus+ or PCI fulfills this requirement. The fiber-optics interface provides the noise free environment. The parallel data bus interfaces the IO function (10) to local interfaces of the GUI (330), Knowledge Base (200), External I/F (600) and Storage Devices (300) in the Multi Hundred MB Range. The External Interface will interface with external data sources and users on fiber-optics links of 100 Megabits per second. The external interface covers a wide variety of users and accomplishes this in Critical time periods, with the only constraint being the communications latent time. The system bus connecting the CPU's, i.e., IO (10), DP (20), DM (30), and DS (40), is 667 MB/Sec. The biggest deterrent to Real-Time/Critical-Time data processing is the external communications times to external data sources. Synchronous satellites will insert time delays of seconds. The system block diagram is used to show the flexibility of cascading baseline system configurations. The configured system, shown in FIG. 3, could be of an overall system and its subsystems or a large system with many multi-processing requirements. The External Interface (600) would be interconnected to any or all of the external devices shown in FIG. 2. The data bus interconnecting Level 0 (100), Level 1 (101), Level 2
(102) and Level 3 (103) will have a throughput of 150 to 300 MegaByte (MB) Range. Local support devices, KB (200), Client/server (700), Work Stations (300) and Data Archival (400) will share the same data bus. This is a tremendous data path for data interchange since the systems bus for the CPU's, Congruent Memory (CM) and Discs are internal to each of the 4 CPU system configuration and operate at 667 MB second. Any of the Processes can be paralleled with the same type process for fault tolerance or improved system performance.
The system flexibility of the C3M2 system is shown in FIG. 4. The External Interface (600) serves as the interfaces to the world. The Ext. I/F is interconnected to the IO module in each level. Each level will only respond to messages addressed to it. The Ext. I/F could be the interface to a large number of inputs. The five levels of the system could be responding to separate interfaces and have interchanges of data between systems levels (100, 200, 300, 400, 500) or performing mathematical processing for some of the individual subsystems, i.e. multi-spectral scanning, synthetic antenna arrays, or side looking radars. Each process in an array of processes can respond to any other process in the system or to any external input through its IO.
The system criteria and methodology shall be based on meeting all system requirements, having robust response times, having compatible IO Interfaces, and having Multi-Media/User Friendly interfaces for the Users. Major systems criteria are:
1. The system shall be multi-tasking, (i.e. multiple tasks with cooperative processing in the current time period).
2. The system shall have multi-processes, (i.e. complementary functions performed by individual processes during the current time period).
3. The operations of the C3M2 systems/subsystems shall be concurrent, (i.e. all tasks and processes are being performed in the same time periods).
4. The architecture of the system shall use Multi-Processes having COS's that has been configured for the process that it is performing.
5. The COS's shall not use Preemption or have Wait States.
6. The system shall use COTS hardware and applicable COTS software.
7. The system methodology shall allow for design and validation as the system evolves.
8. The system design shall define all known data types prior to initialization of the design effort.
9. The Processors shall have 64-bit or 128-bit wide bus.
10. The system shall be tested as the system evolves.
11. The system shall be Fault Tolerant.
12. The MBTF shall be 10,000 hours for the system.
13. The system shall be capable of being Tempest Tested.
14. The system shall have Built-In-Test (BIT) equipment.
The system criteria will be used for defining the capabilities of the C3M2 that is being implemented. The design methodologies shall be tailored to achieve these goals and objectives. The Design Methodology requirements to meet the implementation goals are listed below:<