- Major Requirements:
-
One of the requirements of APTS was that it had to be available anywhere in the World and any changes to the system be immediately available to all users at the same time. The system also should be easy to use and satisfy all of Rockwell's reporting requirements as well as that of their customers. The Browser environment satisfies these requirements and ASP allows the development of a user friendly, easily modified and updated system. APTS has been developed using Interdev as the development tool and ASP, HTML, DHTML, SQL and Javascript as the development languages. It is designed to run in Netscape 4.05 or above. The database in use is Oracle 7.3.
- Service Calls:
-
The technicians board the customer's aircraft and performs certain service work, from PM to troubleshooting and replacement of equipment. They carry with them a pre-printed form where they record the services performed as well as aircraft id, flight number, arrival time, etc. All information required is entered onto the form for later entry into APTS. I have started the development of a portable version of APTS to eliminate the need for these printed forms.
- Data Entry:
-
The technician or a data entry person, enters the required information from the Service Call into APTS. This is accomplished through the use of Data input screens which I designed to be functional, easy to use and allow as much validation as possible. The service call data may be completely entered at one sitting or saved and completed at a later time. When all of the information has been entered and validated it is then put directly into the Oracle database. This information is then ready for analysis and reporting. This gives Rockwell the edge over it's competition due to the fact that it has the service information "real time".
- Inventory Control:
-
APTS must also have the ability to move any part to any location within the Rockwell organization. While allowing for this movement it must also track the current location of any part as well as all parts currently on any aircraft. A part should be tracked from installation on customer aircraft to removal to repair to inventory and back to an aircraft. APTS does all of this and more. I have designed a system which allows all of the tracking required as well as the ability to see what parts are available as spares at any Rockwell facility. APTS also allows the transferring of a part from one facility to another.
In other words, APTS is much more than an Airborne Performance Tracking System it is also an Inventory and Spares tracking system
- Reporting:
-
APTS should contain an ability to report on the data collected. One way APTS does this is through the use of a Report Designer utility I designed. This utility allows the user to select the fields they want to use in their report. This data is contained in the 2 tables which contain most of the data collected from the service calls. The user may select the column, sort order, column width, enter the column title and column alignment. The user may also select the Font size to use for the output. There is also an option to output to Excel. Included on this screen is user selected criteria so the report will select the facility, customer, date ranges, part, etc. There are many more criteria available. When the user is finished designing the report it may be displayed, then modifications made then displayed again. When the report is exactly what the user wants the report can then be named, a description entered and saved for use later by the user or by other users if desired. A report may also be recalled, modified and saved again.
There are many other "hard coded" reports available for the users, most of these reports have user selected criteria. A problem with any reporting via a Browser and a large database is the time required to "download" the completed report, they can be hundreds of pages many times. I solved that problem a few years ago when I created a series of reusable ASP subroutines. These subroutines allow me to create a new hard coded report very quickly, usually a few hours. However, the big advantage in using these subroutines is that they create a large report with as many pages of HTML as is necessary.
I have created approximately 1500 pages of report from a database in less than 2 minutes. These subroutines also create a series of "clickable index" pages so that the user can quickly navigate through the total report very quickly. I also provide a "print" link on each report page so that the frame containing the report may be printed simply by clicking this link.
Another set of reports shows what is "currently" going on in APTS, what service calls have been entered, what was done, where, by whom, when, etc. Also, more detail can be displayed in a portion of the screen and from there a detailed report may be display simply by clicking a link. This gives the 24/7 room the ability to monitor what is happening in "real time".
A great day-to-day management tool.
- Messaging:
-
APTS needed a method of sending messages to any or all repair facilities. I designed a simple Messaging page which is executed when a user logs in to APTS. After about a minute this page closes itself automatically. When a user wants to see these messages there is a "link", press the link and the Message page appears and closes automatically.
Any user can also send a message APTS users. APTS also displays an "information message" on the most commonly used screen in APTS. This message is controlled by the APTS management team. I also built in a method of allowing management to imbed a "link" within this message.
This provides the ability to provide all facilities with common reports, summaries, statistics, etc.
- Data extraction:
-
Many users of the APTS system have the need to extract certain data from the system. I provided this feature by providing a screen which is dynamic in that it displays the names of all tables the user has the need to extract from. This list is created based on the current tables in the Database, so that if any new tables are added they will be listed automatically. There are certain hard coded criteria involved in this process.
- Database maintenance:
-
As in any database system, the data must be maintained, users added, parts added, new customers added, etc. I provide this through the use of the report subroutines and editing screens. All of the tables are maintained this way, except for some of the tables which are linked to each other. In this case there are special editing screens so that the updates are completed properly.
- Portable Use:
-
Make APTS available to be used on a portable computer. I am currently working on this feature. I will use much of the Javascript code currently in APTS, the proper changes will be made and the Service Calls will be able to be input into this system in much the same way as the non-portable APTS system. The major difference is that the data will be transmitted to an Internet site via wireless and there the verification process will be completed and the data will be inserted into the database. This will give the technicians the ability to complete the Service Call and send the data immediately to APTS.
This will give Rockwell even faster access to their critical data.
- Business Rules:
-
I designed portions of APTS so that certain functionality depends on the use of Rules contained in a database table.
For example: Certain Rejection and Service codes are allowed for particular types of Services, these codes are contained in a "Rule" and when it is necessary to modify the way APTS handles these Services, the Rule is changed, not the program. This type of feature is used throughout APTS for various functions. One of the entries in the Rule table is a Javascript function, when the function requires modification, I just change it in the Rule table and the program which uses it changes the way it functions. Of course, the program must be written to read and process the Rule when needed, but that is a trivial matter compared to always having to modify the program, test and put into production.
A big time saver and convenience.
- Table driven:
-
Much of the input required for APTS is either checked against tables or is available from drop-down boxes. Some of these tables are dynamically built as the APTS system is utilized more and more.
For example: When an aircraft id is entered it is verified against the aircraft table, if it is not found a message is generated telling the user. An aircraft type/part table is available so the user doesn't have to type a part number, simply select it from a drop down box. If the part is not in this table it will be added upon completion and verification. Over time no part should have to be typed unless new to the system.
- Future Plans:
-
I am experimenting with making APTS more graphical and less text and input based. This will be done utilizing graphical representations of the serviced aircraft.
This will make the gathering and input of service information much easier for the technicians as well as provide much more accurate data.