US20020062239A1

US20020062239A1 - Program planning management system

Info

Publication number: US20020062239A1
Application number: US08/812,622
Authority: US
Inventors: Lloyd E. Smith; Edward W. Balunas
Original assignee: Lockheed Martin Corp
Current assignee: Lockheed Martin Corp
Priority date: 1997-03-07
Filing date: 1997-03-07
Publication date: 2002-05-23
Anticipated expiration: 2017-03-07
Also published as: US6609100B2

Abstract

A data processing system provides development of complex schedule plans under user control by using sorting and grouping processing to interface between a relational database and a scheduler application. The sorting and grouping processing provides for user-interactive editing of data in the database by presentation of groupings of activities developed in accordance with attributes of the activities concurrently with activities which are not included in a group. Editing of the group based on the presentation of other activities allows the user to apply acquired knowledge and understanding of the subtleties and dynamics of the activities and to make business decisions which therefore do not need to be represented in the scheduler application. Changes to data in the database are logged in a notebook or scratch-pad store so that data may be returned to its original or any prior state.

Description

[0001] This invention was made with Government support under contract F336657-83-C-0264 awarded by the U.S. Air Force. The Government has certain rights in this invention.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to scheduling systems and, more particularly, to computer systems for developing, managing and periodically modifying complex schedules and projects.

2. Description of the Prior Art

Programmed data processors have long been used to store and selectively present portions of potentially massive quantities of data and to carry out lengthy and complex data processing tasks in which a series of operations must be carried out in a particular sequence. Among these types of tasks, the development of schedules for carrying out a particular course of action or plan is often especially complex. As a practical matter, numerous concerns may present conflicting requirements such as when a project and activities therein must be carried out concurrently with continued operations of a business.

For example, consider a manufacturer or operator of aircraft (or any other fleet of vehicles or other plurality of similar objects) which must oversee maintenance of aircraft which have been placed in service by the manufacturer's customers. Modifications and upgrades will often be designed and implemented on a more-or-less continual basis to enhance safety and performance of the aircraft or to meet particular performance requirements and it is desirable that all previously built aircraft receive such modifications in a timely fashion while maintaining an adequate number of aircraft in service at all times which is sufficient to support the customer's business. It is also often desirable in implementing modifications that as few modification states as possible exist in the fleet of aircraft or plurality of objects and frequently only a maximum of only two modification states are permitted at any time.

In this particular example, it should be understood that modifications and service of aircraft is particularly subject to complication by the complexity and size of commercial aircraft and process criticality of maintenance and modifications. Not only does service and modification often require disassembly of significant portions of the aircraft but special tools and facilities are often required which may be available at only a few locations nationwide. Further, modifications and upgrades often involve lead-time for design, fabrication and distribution of parts of as long as several years and which may be extended by the process of funding of such activities. Therefore, at any given time, many such upgrades or modifications may be planned or in process and modifications must generally be coordinated with regular maintenance schedules both as to timing and location. Additionally, some modifications may rely on others being carried out earlier or concurrently and may also involve training of flight crews as well as personnel to carry out the modifications or maintenance. Flight testing and other processes of validation and approval for the modification, which can be extremely expensive, may also be required.

Accordingly, it is seen that service and upgrading of aircraft, in particular, takes on the form of an ongoing complex plan which may extend over many years (e.g. the entire service life of the aircraft including the period of its original design, manufacture and certification). Further, each of the above potential complications, requirements and dependencies of activities within the plan (referred to as an attribute of an activity) of each service or modification and many others must be considered in the formulation and alterations of the plan from time to time as business contingencies and capabilities may permit or require.

It can therefore be readily understood that the complexity of the overall plan or schedule increases rapidly with each of the number of objects under the plan, the number of attributes of each action to be taken, the number of activities or actions to be carried out on the objects and the length of time over which the plan extends. If the plan is generated by manual methods, as is the current practice, such increase of complexity increases the time required to do so and greatly increases the likelihood of error. Any change in attributes or the addition or alteration of any modification may require most, if not all, of the schedule generation process to be repeated. As a practical matter, frequency of plan or schedule changes encountered in maintenance and modification of even a small fleet of aircraft and many other business endeavors is such that the plan or schedule is seldom current or accurate. Foreseeable increases in numbers of attributes which must be considered in a schedule plan are such that the frequency of changes may exceed the rate at which the plan or schedule can be updated using manual methods.

Therefore use of data processors to generate schedules has been attempted in recent years but has achieved little success for schedules of more than low complexity. Approaches to date have generally involved programming the computer to make all of the logical decisions in grouping and scheduling of activities. However, this type of approach requires the logical combinations applicable to the attributes of the activities to be embodied in the programming and results in program complexity approaching that of a neural network for relatively modest numbers of objects, activities and attributes of the activities. Such programming requires extensive definition of the individual activities and elaborate and complicated decision-making algorithms. These complexities of programming require substantial development time and expense for the program and large hardware and computational overhead while resulting in a program which has little flexibility, limited applicability, requires extensive and costly changes to accommodate any alteration of data or logic and does not easily accommodate user interaction to permit business decisions to be used or their effect to be evaluated in the course of schedule development. Additionally, such systems do not ordinarily support communication of the schedule in a timely fashion when changes in the schedule are made.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide an easily alterable, flexible system for supporting the formulation of long-range schedule planning which allows a high degree of user interactivity and presentation of supporting data.

It is another object of the invention to provide for presentation of sub-sets of data to a user together with an ordered list of other data in a serial fashion to facilitate user interaction and decision making in the development of a complex scheduling plan.

In order to accomplish these and other objects of the invention, a data processing system is provided including a relational database containing data representing a plurality of activities and attributes of the activities, a scheduler application and an interface between said relational database and said scheduler application including an arrangement for editing the attributes and grouping the activities in accordance with edited attributes.

In accordance with another aspect of the invention, a method of operating a data processing system is provided including the steps of developing a database including a plurality of entries, each entry including a plurality of associated attributes, selecting an entry based on at least one of the attributes, presenting at least the selected entry to a user in a first list together with remaining entries as a second list for editing of the first list.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which: [0015]
FIG. 1 is a high-level block diagram of a preferred form of the scheduling system in accordance with the invention, [0016]
FIG. 2 schematically illustrates data flow in accordance with the invention, [0017]
FIG. 3 illustrates interaction of software applications with an interface therebetween in accordance with the invention, [0018]
FIG. 4 illustrates a preferred implementation of the invention with a communication system, [0019]
FIGS. 5A and 5B form a detailed flow diagram illustrating operation of a preferred form of the invention, and [0020]
FIGS. 6, 7, [0021] 8, 9, 10, 11, 12, 13, 14, 15 and 16 are preferred screens developed in accordance with and to facilitate the use of the invention in a preferred application.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

Referring now to the drawings, and more particularly to FIG. 1, there is shown a high-level block diagram of a preferred form of the invention. It should be understood that the illustration of FIG. 1 is equally representative of the structure of a special purpose processor or a suitably programmed general purpose computer, in which latter case the functional elements illustrated would be allocated to hardware within the general purpose computer upon invoking the application or initialization of the programming. [0022]
The arrangement of FIG. 1 shows the invention as including three principal processing sections and the [0023] processor 40 which performs or controls the respective processing sections and develops the user and communications interfaces 60, 70. Relational database 10 contains an entry in a memory structure for each activity to be included within the schedule plan, each entry including a plurality of attributes and flag bits (e.g. 70- 100 or more, depending on the complexity, requirements and dependencies of the activity) indicating information associated with the activity. Relational database 10 is preferably implemented with a commercial software relational database application such as Paradox™ for Windows™, Microsoft™ Access '95™ or the like. Similarly, the invention preferably includes a commercially available scheduler application 30 which maintains its own schedule database 35 such as Microsoft™ Project '95™, Primavera™ or the like. The details of any of these programs are not at all critical to the practice of the invention. It is, however, convenient to use database and scheduler programs that are compatible with each other and are written in a programming language which can also be employed for the sorting and grouping processing 20 which forms an interface between them in accordance with the invention. Microsoft Access includes the Access Basic language and Access '95 and Project '95 are preferred commercial products for that reason. The same effect can also be achieved using OS/2™ and Primavera™.
Attribute data may be stored in the [0024] relational data base 10 in any convenient form including clear text although some compression or coding reduces memory requirements. Compression and decompression are generally provided as part of the database application. If coding is employed, decoding or clear text which is accessible, for example, in the form of a look up table 50, is preferably provided for the user interface (also generally within the database program if coding is provided) although not particularly necessary for the sorting and grouping processing in which correspondences and similarities of attributes may be found by comparing encoded data in much the same manner as clear text.
Since the invention is intended to provide for user interaction and the user is thus enabled to change the attributes (e.g. start date, completion date, materials, equipment, etc.) corresponding to various activities to be included in the schedule plan, a [0025] notebook 80 in the nature of a scratch-pad memory, well-understood in the art, is preferably provided to automatically maintain a record of attribute changes, dates of change, user identification and the like and allowing the user to add commentary to the record of changes to indicate, for example, the rationale for a business decision such as advancing a completion date for obtaining or manufacturing parts on which the activity relies. It has been found useful and is preferred to automatically log all transactions, changes and decisions made during the course of operation of the invention so that a record of all exercises of judgment made by the user in the course of use of the invention can be reported with the completed schedule plan.
Referring now briefly to FIG. 2, the basic operation of the invention will now be described. The basic process begins with data entry of the activities to be carried out and the attributes of the respective activities to form [0026] data base 10. Initial entries need be done only once for each activity since previously entered activities are preferably retrieved from the schedule data base which holds the results of any schedule plan previously developed by use of the invention. The invention need only be used when one or more activities are to be added, a change is to be made or a potential change is to be studied. It is also preferred to retrieve earlier entered data from an existing plan to ensure that the current schedule plan is always used for study and/or modification.
Once the list of activities (hereinafter sometimes referred to as “mods”, as a contraction for “modifications” although the activities are not so limited as indicated by the inclusion of a program depot maintenance (PDM) activity) is available in [0027] database 10, the attributes, together with any existing schedule information, is transferred (as indicated at 12) for grouping and sorting processing 20 as will be discussed in detail below with reference to FIGS. 5A-16. This processing has the basic purpose of detecting which activities are important to consider in the development of a schedule plan, limiting development of the schedule plan to those activities and, among those, to determine the most important to the schedule plan, referred to as “driver mods” (since the importance or inflexibility of the activity “drives” the schedule plan) and which will form a skeleton of the schedule plan. Then, the activities are traversed in a looping fashion to group the remaining important activities with the “driver mods”. As will also be discussed in detail below, the user may alter attributes to determine how the schedule plan will be affected and is prompted at appropriate points of the processing to exercise judgment over the grouping performed by the sorting and grouping processing.
Once the activities which are important to schedule plan development are arranged into a reasonable number of groups, each of which corresponds to a driver mod, the remaining activities can be added to desired groups or additional groups generated, if needed, at the will of the user. The schedule plan may then be further studied and/or refined by the user and the groupings may be evaluated through the final stages of the sorting and [0028] grouping processing 20. The groups can then the forwarded for scheduler processing 30 to generate the detailed schedule plan from date information and other attributes in each group. The detailed schedule plan is then stored in the schedule data base 35 and made available for communication through a communications facility such as a network server 70 associated with processor 40.
It is also useful to note from FIG. 2 in regard to the basic operation of the invention that the schedule data base is depicted in the form of a time line. Thus the mods of a first group, for example, designated mod[0029] 1, mod3, mod7 and mod21 which form a group are depicted as occurring simultaneously or concurrently during the first period G1 of the plan which begins at approximately the present time. (It is considered helpful to show the entire period for a group where activities remain in process.) Similarly, mod4, mod12, mod13, mod19 and mod20 form another group depicted as occurring simultaneously or concurrently during period G2. Operations which must occur prior to each of the mods of this second group are depicted as occurring during period G1 (or, if prior to period G1, they may be associated with an earlier period which remains in the schedule plan for that reason). This information is also useful since it enables these operations to be tracked and scheduled closely before the activity so that the overhead due to the cost of such operations (e.g. cost of parts, warehousing, transportation and the like) can be kept to a minimum in accordance with so-called “just-in-time” management protocols.
Referring now to FIG. 3 the communications between modules of the database and scheduler applications and the sorting and grouping processing discussed above in connection with FIGS. 1 and 2 are shown in greater detail. To relate FIG. 3 to FIG. 1, activity database [0030] 10 (together with the sorting and grouping processing 20) and scheduler 30 are shown separated by a dashed line while communications between modules of these respective applications are depicted. It should be noted that the activity database 10 preferably provides a data entry interface preferably in the form of tables 11, 12, 13 and the data so entered can the communicated to the activity database memory, more particularly indicated by reference numeral 10′, the sorting and grouping processor 20 and the project matrix 31 and resource matrix 32 of the scheduler 30, respectively. Logging of transactions through the processing control table 12 provides the function of notebook 80. The project matrix 31 and the resource matrix 32 communicate bidirectionally with each other. The sorting and grouping processing 20 thus provides an interface between the activity database storage 10′ and the projects matrix 31 while allowing user interaction with either or both.
Once the groups of activities are scheduled and entered in the [0031] schedule database 35, other information to form the detailed schedule is communicated directly from selected attributes of the activity database memory 10′. When a schedule plan is modified, data is communicated back to activity database storage 10′ from the schedule database 35 so that changes and studies always proceed from the current schedule. Each of the activity database application 10 and the scheduler application 30 has its own output data format interface 14 and 33, respectively. Either or both may include a net server 70 (FIG. 1) or an interface thereto for communication over a local area network or wide area network (including the Internet) 90 for communication to customers, employees, manufacturers, suppliers, facility operators and the like as needed, as shown in FIG. 4.
Referring now to FIGS. 5A and 5B, the operation of the invention will be described in detail. It should be understood that FIGS. 5A and 5B illustrate the sorting and [0032] grouping processing 20 of FIGS. 1 and 3 as it interacts with the activity database 10, 10′ and the projects matrix 31 of scheduler 30. As will be appreciated from the following discussion, compared to previous approaches to schedule processing, the invention moves many of the logical decisions from the schedule processing and provides solutions as well as resolution of conflicts and violations by user interaction. Steps in FIGS. 5A and 5B calling for user interaction are identified by the term “USER:” in the upper left of the block representing the step. At the same time, the user is presented with all necessary information to make those decisions. Further, the user is guided through a logical process whereby the schedule can be rapidly generated, evaluated and optimized. Additionally, as compared to previous approaches, the attributes are removed from the decision-making logic embodied in the program (which cannot be changed without costly and time-consuming program revision) and are treated as data; not only allowing but encouraging modification thereof for solution and optimization of the schedule plan.
When the [0033] process 100 is invoked (Start 110) the user is prompted by a screen preferably similar to that of FIG. 6 which allows control of the location in the process at which the user wishes to enter it. Specifically, if the user selects “ADD A NEW MOD”, the process will be started at 114 of FIG. 5A and if the second selection, “EDIT/VIEW AN EXISTING MOD” is selected, step 114 will be bypassed and the process will begin at step 116. Similarly, if the third selection, “PROCESS GROUPS” is selected, the process will be entered at step 118. The last selection provides for entering the process at “D”, step 178, to generate reports under control of the scheduler 30 representing the current schedule plan.
Assuming the user selects the first option and enters the program at [0034] 114, the user is prompted to enter data corresponding to a new activity with a screen which is preferably similar to that of FIG. 7. This screen is preferably customized for the particular purpose for which the plan is intended but may be generic. In either case, the screen format and text can usually be customized from the commercial database 10 or the operating system (e.g. Windows 95™) in a manner well-understood in the art but unimportant to the practice of the invention. Even if customization must be done as an incident of software development, the screen designs are a part of the interface (e.g. 14, 33 of FIG. 3) and do not require extensive modification of other functional parts of the program. It should be noted from FIG. 7 that an acquisition data dialog box is preferably provided, allowing the user to indicate whether an activity is funded or not (which sets flag bit F in the attributes of FIG. 1) and whether the activity is to be included in the processing (which sets flag bit I/E of FIG. 1 to force exclusion if not set). In the same manner, stand-alone mods may be designated (setting flag bit SA of FIG. 1) and selection of an activity as a driver mod can be similarly forced.
Similarly, other dialog boxes or tables are provided for specification of other attributes such as technical definition, installation information, program risk and dependencies. If desired or necessary, other sub-screens of a similar nature can be called for further types of information such as cost data, schedule data, technical information and the like using on-screen cursor selectable areas such as [0035] 701 or keyboard definitions. Additional information such as the project name, mod number and priority can be included as desired on any of these screens. A screen such as that of FIG. 7 will also be used to present data already existing in database 10 when imported from schedule database 35 at step 116 of FIG. 5A.
The sorting process actually begins after the [0036] database 10 is completed at step 118 at which the user is prompted to specify whether particular activities are to be included or not based on the F bit, indicating whether the activity is currently funded. A screen such as that shown in FIG. 8 may be provided for the purpose. Based on user input in response thereto, this sort provides the capability of comparing the effects on the schedule plan when funding for an activity is provided and the activity should be carried out. For example, the user may include unfunded activities with funded activities in an evaluation for the purpose of establishing a funding profile for the unfunded activities and determination of economies which could be realized if funding allocation is altered or obtained by certain dates.
Similarly, [0037] step 120 provides for forced exclusion of an activity from the processing based of the I/E bit. This facility allows accumulating data for an activity while the activity, itself, is being planned and evaluation of the effect of the activity on the schedule plan on the basis of the best available information even though the available information may be too incomplete for the total activity information to even be considered “valid” (at which point the user would presumably set the I/E bit as described above).
The next sort [0038] 122 is to remove so-called stand-alone mods which are considered to be those activities with no dependencies or special requirements which can be carried out at any location at any time and thus need not be considered in the schedule plan until the detailed schedule is produced. Determination of stand-alone mods can be forced by data entered through the screen of FIG. 7 in the same manner that driver mods may be forced or determined by applying criteria to the attributes of the activity.
Step [0039] 124 sorts the activities to determine the driver mods which are either forced, as described above, or have attributes indicating requirements or dependencies which cannot be readily accommodated by other plan adjustments and thus must be considered to “drive” the schedule plan development. When determined, the driver mods are presented to the user by a screen preferably similar to that of FIG. 9. The screen of FIG. 9 provides a table of driver mods sorted by date and a second table of non-driver mods sorted by priority. Using this screen, the user can edit the list of driver mods by additions and deletions, as desired as indicated by step 126 of FIG. 5A. Once the list of driver mods is acceptable to the user, the process proceeds to step 128 in which the driver mods are checked for hardware dependencies (e.g. software cannot be installed until the hardware has been installed to receive it) and predecessor activities (which indicate the earliest date at which the activity can be performed such that the activity cannot be allowed to “slip left” to an earlier date than its predecessor) at step 128. If a violation is found where a driver mod is scheduled prior to its hardware dependency or predecessor, if its dependency or predecessor is a driver mod, a reordering of the driver mods is required and carried out automatically. The user can intervene by again displaying the screen of FIG. 9 to edit the start dates of the driver mods or remove driver mods from the driver mod list. Of course, deletion of an activity which is a hardware dependency or predecessor of another driver mod activity should not be permitted but within the possibility for an activity to be “slipped left”, new start dates for the dependency or predecessor may be entered. Such changes are essentially an alteration of attribute data as a speculative business decision (e.g. that parts can actually be obtained in less than a fixed time) and are logged in a notebook memory, as alluded to above, so that they may be restored to an original or any prior state if a schedule solution is not found or if it is later found that the change cannot actually be accommodated or accomplished.
Once an ordered list of driver mods is established, a group of activities is created (although the group will not yet have members) for each driver mod at [0040] step 130 and the group install start date is set to the date of the driver mod start date at step 132. The groups are placed in a like order and a loop is created to group other mods with each driver mod, starting with the group having the earliest group start date at step 134 as the current group. (All loops may be generated concurrently or a loop may be created as each driver mod/group is taken up for processing; in which latter case the process loop to “C” would be to step 134 rather than 136, as shown in FIG. 5A.)
For convenience, mods are added to the current group and then ungrouped as conflicts are found. For example, at [0041] step 136, all mods having a start date earlier than the current group start date are added to the group and at step 138, all mods which could “slip left” to an earlier start date than the current group are added to the group. Then, at step 140, lead time (e.g. preaward negotiations, design, development and an additional period such as thirty days) is summed if the mod is not active (e.g. in process) and the mod is ungrouped if the lead time is insufficient. This ungrouping can be overridden by the user and the short lead time logged in notebook 80 (FIG. 1) so that steps can be taken to meet the reduced lead time.
Similarly, mods with hardware dependencies not in the present group or a previous group are ungrouped. (All previous group hardware dependencies will have been considered and, if the hardware dependency is satisfied by a mod in a prior group, the mod is no longer hardware dependent.) This handling of hardware dependencies allows them to be satisfied and the dependency removed from consideration (although duly logged in notebook [0042] 80) at the earliest possible point in the processing. Further, activities which can be conducted concurrently with their dependencies are performed at the earliest possible time. A similar rationale applies to the ungrouping of mods with predecessors in step 144.
Once some of the mods are ungrouped in [0043] steps 142 and 144, the remaining mods in the group are sorted by area of the object on which the activity is to take place. For instance, in an aircraft numerous mods may require the removal of a substantial portion of structure such as an engine or heat exchanger. Therefore, in the interest of efficiency, it may be desirable to alter dates of mods which may have been rejected for the current group in steps 136 and 138 so that they can be included in the group. Recalling that the grouping was done in those steps based upon dates, changes of dates is effectively a discretionary advance of dates and an alteration of data in the database 10 which must be duly logged in notebook 80 in order to accommodate the advance of their dates (e.g. by ordering parts for earlier delivery) or the return of data to its original state.
The mods in a current group which are directed to a particular area are preferably presented to the user by a screen similar to that of FIG. 10. This screen is similar to that of FIG. 9 in that a list of grouped mods is presented in a table and another table is provided to present a list of other mods which could be included. This screen thus prompts the user to edit the list of mods by advancing the dates of some mods to be included in the group or by deleting mods which might extend the completion date or require a particular location or procedure (e.g. a flight test) inconsistent with other mods from the group if it were unavoidable that further mods would be required to the same area at a later date. It should be noted that altering dates of activities or mods will require re-entering the process at [0044] step 118 so that all decisions are applied to all mods.
An additional screen such as that of FIG. 11 can be employed to evaluate impacts of special required procedures in the course of this editing process by the user. Specifically, since such special procedures (and flight testing in particular) are generally expensive, it is generally advantageous to cover as many mods with the same special procedure as possible; possibly resulting in advancement of ungrouped mods into the group or deletion of other grouped mods from the group to be performed and tested in other groups with later performed mods. [0045]
Next, the mods of the current group are presented grouped by the locations (e.g. facilities, as distinct from areas of the object) where the mods are possible. Again, this is preferably presented using a screen such as that shown in FIG. 12 with sorted lists of grouped and ungrouped mods at [0046] step 150. At the same time, the location is set as a default to the location of the driver mod. The user is then prompted to edit the grouped mod list and/or override the default location if the driver mod can be performed elsewhere, although at potentially a greater risk, at step 152. Again, this is a mangement or business decision and should be duly logged or recorded in notebook 80.
The above step generally serve to optimize the current group to include all the activities which can be accommodated together at the same time and completion date at a single location. The following steps assist in evaluation of the grouping, allow an additional opportunity for editing the group and provide for the appropriate number of objects on which the activity is to be carried out. [0047]
Specifically, step [0048] 154 queries the user about preferred procedures such as if the mod should involve a trial installation (which may vary in dependence on potential interactions and interrelationships with other concurrent or prior mods) or whether a “kit proof” or both a trial installation and “kit proof” is to be employed. (A “kit proof” is a validation and/or verification of technical installation and usage instructions.)
These procedures may involve the same special procedures but the special procedures may require separate performance. For example, the trial installation and kit proof may or may not be testable in the same flight test of a single aircraft. If not, then a plurality of separate objects must be provided to undergo different mods of the group which involve separate special procedures. This, in turn, will probably require an adjustment of the amount of time required for completion of the group of mods (step [0049] 158). A screen such as that shown in FIG. 13 is preferably provided to aid in the estimation of the adjusted time for completion. Specifically, the screen of FIG. 13 provides for direct entry of a time adjustment factor for the first mod to be done together with a lag time of beginning the mod on another object to accommodate both installation and testing or the like.
The sum of additional installation periods for other objects is then computed and adjusted by a group install reduction factor reflecting economies of time due to presence of several objects at the facility for undergoing the installation of a group of mods which do not proceed concurrently and computes the actual number of work days for completion of the group of mods on all objects. It should be understood that the parameters and calculation shown are arbitrary and any parameters and calculation can be input by the user in making this time adjustment factor for multiple objects being subjected to a group of activities. [0050]
The resulting completion date may thus be extended relative to the completion date for a group of mods on a single object and NLT (“not later than”) violations are checked at [0051] step 160, allowing them to be resolved by user editing at step 162 preferably using a screen similar to that shown in FIG. 14. The completion date could also be reduced by reducing the number of objects on which the group of mods is carried out. Accordingly, the invention provides for using the data input through the screen of FIG. 13 to compute completion dates for the group of mods performed on a lesser number of objects at step 164, allowing the user to select an acceptable number of objects with an associated acceptable completion date at step 166 which is then checked for violation of the start date of the next group at 168.
The user is then given the option of further editing the mods or the group dates at [0052] step 170 and a screen similar to that of FIG. 15 is preferably provided to allow the user to ascertain the feasibility of allocating specific objects (e.g. aircraft) to this group of activities. Similarly, a screen such as that shown in FIG. 16 is provided to allow the user to resolve driver overlap. Resolution of any inter-group violation, driver overlap and object availability essentially completes the sorting an grouping process for the current group and the records for the current group can be transferred to the scheduler to generate the detailed schedule in due course at step 172. Again, throughout the group processing, all user decisions and exercises of judgement are preferably logged to become part of the permanent record that describes the schedule plan developed as described above.
The process can then proceed to the next mod group and driver mod by checking for remaining ungrouped mods (e.g. those mods remaining after step [0053] 122) at step 174 and looping to “C” (step 136) to process succeeding groups until no ungrouped, included mods remain, transferring data to the scheduler 30 each time step 172 is executed. In this regard, the user may wish to generate one or more further groups by forcing a remaining mod to be selected as a driver mod or remove one driver mod and substitute one or more others, as discussed above. This can be done at any point in the schedule plan development process in accordance with the invention. Further, the user can return to any previous point in the process described above from any screen as is well-understood in the art, using data modification records from the notebook 80 to restore data or not as may be desired.
When no ungrouped, included mods remain, the process branches at [0054] 174 to allow the user to allocate resources to the standalone mods which, it will be recalled, are to be included in the plan but are of such a character (e.g. short completions time, flexibility as to parts, personnel and facility, etc.) that they can be included without significant effect or impact on completion dates at points in the schedule plan which will invariably be developed. This process is performed at step 176 of FIG. 5B and is preferably carried out by review of screens such as those of FIGS. 9. 10, 12 and 13. As each standalone mod is assigned to a group, that assignment is transferred to scheduler 30 so that, when all standalone mods have been assigned to a group, the scheduler will be in possession of all data in the plan with the data organized in a fashion that the generation of a detailed plan containing all attribute information is very straightforward and principally involves collection of data from the attributes of the activities of each group and establishing the schedules of precursor operations (e.g. procuring of parts, movement of objects and the like) for each group, such as those operations occurring in period G1 of FIG. 1 but relating to the activities of the group of activities to be performed during period G2. This collection of schedule plan detail data may then be presented as reports defined in any desired manner as is well-understood in the art and such reports can be transmitted as needed over any desired distribution system such as that depicted in FIG. 4, as described above.
In view of the foregoing, it is seen that the invention provides a high degree of user interaction and maintains a high degree of flexibility and applicability to a variety of complex planning tasks without requiring significant programming alteration other than customization of user interface screens. Further, alteration of data can be done simply by changing of attribute entries or addition or deletion of activities in a database and does not involve changes of the logic applied thereto. The user is constrained into a logical process of consideration of a sequence of small and manageable portions of an arbitrarily complex problem and is presented with all pertinent data for making logical choices within the process framework as those decisions are needed. The invention thus provides for a high degree of optimization of the schedule plan and includes procedures for evaluation and immediate editing of the plan as well as rapid generation and distribution thereof. [0055]
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims. [0056]

Claims

Having thus described my invention, what I claim as new and desire to secure by Letters Patent is as follows:

1. A data processing system including

a relational database containing data representing a plurality of activities and attributes of said activities stored in memory,

a scheduler application, and

an interface between said relational database and said scheduler application, said interface including

means for editing said attributes and storing edited attributes in memory, and

means for grouping said activities in accordance with said edited attributes.

2. A system as recited in claim 1, wherein said interface further includes

a notebook for logging changes to said attributes made by said means for editing.

3. A system as recited in claim 1, wherein said interface further includes

means for determining driver activities among said activities, and

means for forming a group of activities in accordance with each said driver activity.

4. A system as recited in claim 3, wherein said interface further includes

means for defining an activity as a driver activity.

5. A system as recited in claim 3, wherein said interface further includes

means for determining a driver activity from said attributes of one of said activities.

6. A system as recited in claim 3, wherein said editing means includes

means for concurrently presenting to a user all activities included in a group and a list of said activities which are not included in a group.

7. A system as recited in claim 1, further including

means for forcing exclusion of an activity from operation of said means for grouping.

8. A system as recited in claim 7, wherein said means for forcing exclusion includes

means for designating an activity as one of a stand-alone activity or an unfunded activity.

9. A method of operating a data processing system including the steps of

developing a database including a plurality of entries, each entry including a plurality of associated attributes, said entries and said attributes being stored in a memory,

selecting an entry from among said plurality of entries based on at least one of said attributes,

presenting said entry selected by said selecting step to a user in a first list together with remaining entries as a second list, and

editing said first list in accordance with said second list.

10. A method as recited in claim 9, including the further step of

selecting entries for said second list in accordance with said attributes.

11. A method as recited in claim 9, including the further step of

ordering said entries of said second list in accordance with said attributes.

12. A method as recited in claim 10, including the further step of

ordering said entries of said second list in accordance with said attributes.

13. A method as recited in claim 9, including the further step of

editing said attributes of at least one entry, wherein said selecting and grouping steps are performed in accordance with said attributes edited by said editing step.

14. A method as recited in claim 13, including the further step of

selecting entries for said second list in accordance with said attributes.

15. A method as recited in claim 13, including the further step of

ordering said entries of said second list in accordance with said attributes.

16. A method as recited in claim 15, including the further step of

ordering said entries of said second list in accordance with said attributes.

17. A method as recited in claim 13, including the further step of

recording content of each said editing step.

18. A method as recited in claim 9, including the further step of

grouping another entry with said selected entry in accordance with an attribute of said another entry, wherein said presenting step includes

presenting said entries grouped by said grouping step to said user as said first list.