■ Because of military drawdowns and the need foradditional transportation lift requirements, theUnited States Marine Corps developed a conceptthat enabled it to modify a commercial containership to support deployed aviation units. However,a problem soon emerged in that there were too fewpeople who were expert enough to do the uniquetype of planning required for this ship. Addition-ally, once someone did develop some expertise, itwas time for him/her to move on, retire, or leaveactive duty. There needed to be a way to capturethis knowledge. This condition was the impetusfor the T-AVB AUTOMATED LOAD-PLANNING SYSTEM

(TALPS) effort. TALPS is now a fielded, certified appli-cation for Marine Corps aviation.

Historically, one of the most difficultproblems facing marine aviation logis-tics planners was finding an affordable,

flexible, and rapid means of providing interme-diate maintenance capability for forward-deployed aircraft. To overcome these chal-lenges, in the mid-1980s, the Department ofthe Navy purchased the T-AVBs, and UnitedStates Marine Corps (USMC) aviation simulta-neously introduced the MARINE AVIATION LOGIS-TICS SUPPORT PROGRAM (MALSP) (figure 1).

MALSP incorporates a flexible building-blockconcept, known as contingency support packages(CSPs), that follows a prearranged deploymentand employment scenario for assembling theright mix of marines, support equipment,mobile facilities, and spare parts within aMarine aviation logistics squadron (MALS) tosupport deployed aircraft. The key word is flex-ible. CSPs can rapidly be configured to supportthe contingency aircraft mix and marshaled formovement. CSPs comprise the fixed-wing orrotary-wing common support and/or the pecu-liar intermediate maintenance activity (IMA)

and supply support for the various deployingaircraft. Initial support packages (30 days ofspare parts) called fly-in support packages (FISPs)are flown into the operational theater as part ofthe fly-in echelon (FIE); the balance of theMarine Air Ground Task Force (MAGTF) com-mander’s tailored aviation logistics supportarrives in theater aboard the T-AVB. Withoutthe T-AVB, it would require more than 140 C-141 cargo aircraft flights to deploy an MALSwith an IMA-level capability to a crisis area.

The T-AVB ships were acquired as a result ofthe USMC (1983) “Feasibility Study of the Avi-ation Logistics Support Ship.” Two ships havebeen modified for use by USMC I-Level avia-tion maintenance and supply organizations.The Department of Transportation MaritimeAdministration (MARAD) maintains the shipsin a five-day reduced readiness status using acivilian, commercial U.S. Merchant Marineretention crew stationed aboard each ship tomonitor equipment conditions and conductvessel maintenance and repair. The T-AVBs arepart of the maritime prepositioning force(MPF).

The mobile facility work centers used by theMarine Corps conform to the standard com-mercial International Standardization Organi-zation (ISO) container dimensions, which are8’ x 8’ x 20’. Figure 2 shows a typical work cen-ter mobile facility being prepared for loading.Figure 3a shows mobile facilities “complexed”at a shore base, and figures 3b and 3c showspart of the same capability on the ship. Com-plexing is the process of moving mobile andassembling facilities into functioning workspaces. A complete work space is said to becomplexed when it is capable of doing itsassigned job(s). A collection of functional workcenters is called a complex. Figure 3c shows a

Articles

SUMMER 2002 77

TALPSThe T-AVB Automated

Load-Planning System

Paul S. Cerkez

Copyright © 2002, American Association for Artificial Intelligence. All rights reserved. 0738-4602-2002 / $2.00

AI Magazine Volume 23 Number 2 (2002) (© AAAI)

special doublewide arrangement, scaffold lad-ders, and additional maintenance mobile facil-ities. Access modules are used to access second-and third-tier mobile facilities that are com-plexed below decks in support of IMA-levelrepair capability. Figure 4 shows a typicalaccess module.

The modifications to the ships to support amobile facility setup allows a MALS to operatefully functional work centers on board a ship,in an expeditionary mode ashore, or both. Twobasic load-out configurations exist for eachship: transport mode and operational mode.

In the transport configuration, the ship isloaded for maximum capacity. In this mode,mobile facilities are not accessible, and theequipment contained therein cannot be oper-ated. In this configuration, more than 650twenty-foot equivalent unit (TEU) containerscan be loaded. In this mode, the ship is a stan-dard container ship and supports resupplyoperations and missions. The function ofresupply is the secondary mission of the T-AVB.

In the operational configuration, the ship isloaded such that mobile facilities can be placedin a functional, operating condition. What youhave in effect is a tailorable, floating, aviationrepair facility. Officially, in this configuration,300 mobile facilities and 42 access modules canbe loaded, or 342 TEUs. This configurationallows the embarked work centers to processand repair defective or broken aircraft compo-nents while en route to an operational theateror, should the concept of operations in theaterdictate, continue operating until finally movedashore (referred to as operating in stream). Thismode describes the primary mission of the T-AVB and the most difficult area of load plan-ning. The views in figures 3b and 3c show theoperational mode.

A third mode exists called combination. Asyou might guess, it is any time the ship is inany condition other than operational or trans-port. As mentioned earlier, flexibility is the key.Some holds of the ship might be fully loaded intransport mode, yet others are in operationalmode. Combination mode is usually plannedfor when more cargo than is used in opera-tional mode must be embarked, but some capa-bility must be available at all times. Typicallyin this mode, the ship is offloaded at the desti-nation and then “back loaded,” if necessary, toprovide full capability. The term back loading(or back loaded) refers to putting mobile facili-ties back on the ship in operational mode thatmight have been nonfunctioning prior to theoffload.

Articles

78 AI MAGAZINE

Figure 1. SS Curtiss (T-AVB 4) on an Exercise off the Coast of California.

Figure 2. Mobile Facility Being Prepared for Loading.

Load-Planning OverviewThe embarking Marines responsible for a par-ticular ship must develop the load plan for thisship. The civilians manning and loading the T-AVB will load the ship any way the Marines tellthem as long as it does not put the ship in anunsafe condition. Unsafe is defined as any con-dition that would “hazard” the vessel. Forexample, if the ship were loaded so that it wastop heavy or too heavy on one side, it wouldput the ship at risk of capsizing. “Most signifi-cantly, a ship’s officer is concerned to keep hisship from capsizing. Without sufficient stabili-ty in a rolling motion, this goal would be injeopardy” (La Dage and Van Germert 1990). Atop-heavy vessel is said to be tender or cranky.The ship’s roll is slow and tends to lag behindthe changes in sea-surface inclinations. Theship tends to not return to a vertical position.

T-AVB load planning is a time-consuming,inflexible process made more so by the hightempo of operations and pressure to executeoperational orders in the time allotted in atime of war. The manual system of load plan-ning is not responsive (in a timely manner) tomodifications in the force structure, concept ofemployment, or both. There is no formal train-ing, and on-the-job training (OJT) opportuni-ties for implementing and exercising load-planning considerations are scarce. The lack ofthis experience and training was abundantlyevident when the T-AVBs had to be loaded forDesert Shield and Desert Storm. At this time,the T-AVB concept was still new, and therewere no experts. It took 5 full 24-hour days toload one of the ships for deployment to thedesert. With all the changes, the actual mani-fest and inventory had to be validated manual-ly after the ship set sail (figure 5). Changes werebeing made until the end. Despite the prob-lems, the value of the T-AVBs was fully realized.

The following facts are true: First, load plan-ning is complex and tedious. Two, no formaltraining is available. Three, attrition of experi-enced personnel occurs regularly (orders,retirement, force reductions, and so on).Fourth, if the load plan is found unstable ormodified after being presented to the ship’sfirst mate or master, it must be redone. Fifth,for a variety of reasons, the T-AVBs will not beexercised often enough to maintain a knowl-edge base readily available to plan loads anddeploy.

To develop a load plan, the planner musthave a list of all mobile facilities and cargo tobe loaded. Mobile facilities embarked includenot only maintenance work centers but alsosupply department mobile facilities, bulk car-go, and rolling stock. This list must identify

mobile facility-container power requirements;mobile facilities needing air or water hookups;mobile facilities-containers needing access;mobile facility interconnection requirements(shop integrity); ownership of the mobile facil-ities (rotary wing, fixed wing, work center, andso on); type of mobile facility; projected off-

Articles

SUMMER 2002 79

Figure 3. Mobile Facility Complexes.A (top). Mobile facilities “complexed” ashore in operational mode. B (middle).Mobile facilities complexed on ship in operational mode. C (bottom). Mobilefacilities complexed inside the ship.

A

B

C

can develop a load plan to present to the ship’sfirst mate or master in about 8 to 10 hours. Inreality, it takes anywhere from 1.5 to 2.5 daysto develop the initial load plan. In private con-versations I have had with experienced loadplanners, a common theme is “a twenty-footbox in a twenty-foot hole, throw me in thatbriar patch…. You want the T-AVB in the oper-ational mode? Goodbye. Call me when you fig-ure out where you want everything and thenI’ll load it for you.”

The problem presented here has beenlikened by some to an extension of the classicbin-packing problem. Others have called it ascheduling problem. In reality, I see it as both.When you add the temporal aspect of theordering that cargos must be loaded (in whichof five ports will it be loaded on and which offive it will come off), the system must be“aware” of the spaces above and below when itis identifying a cargo item for storage. Forexample, if a cargo item is not going to beloaded until port 3, then cargo items loaded inports 1 or 2 cannot be designated for the spaceabove the one being held for the port 3 item.You would end up having a “container inspace.” Prior to TALPS, T-AVB load planning hadalways been done manually, (the “stubby pen-cil” method). Figure 5 is an actual planningsheet used for one load out). The particularproblems presented by this unique situationmade it an ideal candidate for automation.

load priority; the availability and locations offacility assets on the ship (air, power, and soon); special limitations on locations or mobilefacilities; types of additional cargo (rotorblades, nose cones, rolling stock [mobile motorgenerators (MMGs), mobilizers, and so on],petroleum, oils, lubricants, and so on); pier-side facilities at both departure and destinationports; and status of the ship’s cargo-handlingequipment, mobile facility support systems,and ship access points (hatches, ramps, anddoors).

Once the load planner has all the requisitedata in hand, he/she must compare what isneeded against the ship’s facilities and developa proposed load plan. After the load plan iscompleted, it must be presented to the ship’sfirst mate or master for approval. If the gener-ated plan is found to be unsafe (that is, “…theship floats upside down”), it must be redone.Any modifications to an approved plan alsorequire resubmission and approval.

Taking into account the earlier conditions,assume it takes the load planner only 1 minutefor each item of cargo to identify where toplace it in the ship, with more than 350 mobilefacilities and access modules, it will take over 5hours to develop a load plan for just theseitems (figure 6). Now, add to this rolling stockand other bulk stores-cargos that might taketwo minutes for each item because of irregularshapes and sizes and ability to stack (or lackof). Assuming no changes in what is to beloaded, an experienced, seasoned load planner

Articles

80 AI MAGAZINE

Figure 4. Access Module. Figure 5. Manual Load-Planning Sheet.

Automation of the Load-Planning Process

The purpose of the T-AVB AUTOMATED LOAD-PLAN-NING SYSTEM (TALPS) is to automate the T-AVBload-planning process. The TALPS program usesAI to follow the same logical steps that anexpert uses in completing complex tasks asso-ciated with load planning.

The ability to develop load plans with a Pro-log-based expert system was proven in the early1980s when SRI International developed theAUTOMATED AIR LOAD-PLANNING SYSTEM (AALPS) forthe U.S. Air Force using Quintus Prolog. AALPS

was constraint based, but like a number of oth-er load-planning programs, it requires the userto place the item of cargo. The aircraft cargoloading system then validated the load againstall constraints. Stanley and Associates devel-oped a ship loading program called COMPUTER-AIDED EMBARKATION MANAGEMENT SYSTEM (CAEMS)using a Paradox database driving an AUTOCAD

user interface, interfaced using the C language,for the USMC in the late 1980s. CAEMS was usedto help load the ships coming back from DesertStorm, and a much improved, updated versionis still in use by the USMC embarkation com-munity today. AUTOSHIP (Autoship Systems Cor-poration) is another software tool available tocommercial shipping companies that supportsloading containerized cargo. AUTOSHIP is a ship-type, class-specific tool and is configured at pur-chase time for the vessel(s) it will support. TheU.S. Army Military Traffic Management Com-mand had an application called CODES that is inthe process of being upgraded, modernized,and renamed to ICODES (INTEGRATED COMPUTERIZED

DEPLOYMENT SYSTEM). ICODES is being developedby the CAD Research Center, California Poly-technical Institute in San Luis Obispo, Califor-nia, and has seen limited fielding (as of thiswriting). This listing is by no means exhaustive.There are a number of other applications thatare similar to the ones mentioned here.

CAEMS, ICODES, and AUTOSHIP operate primari-ly the same way for ships that AALPS does for air-craft loads: The user loads the cargo, and thesystem validates the load against constraints.These programs are designed to be extremelyflexible in that they never know what kind ofship or load they might have to develop. Allthree are template based. CAEMS does have an AImodule that does autoproration (a term used bythe developers to describe how the modulecomputes the flow of cargo into a location),but ICODES is an AI agent-based application(originally built using CLIPS [C LANGUAGE INFER-ENCE PRODUCTION SYSTEM] and now being devel-oped in C++) that will automatically place car-

go items in a template developed by the user.These routines analyze the cargo to ensure itcan get to its designated cargo storage location(that is, can it fit through the hatch, make theturn onto a vehicle ramp) and assign specificcargo items to the template locations. The tem-plates act as “greedy attractors” (locations try-ing to pull certain types of cargo to them) tospecific cargo types, and individual serializeditems are then stowed. For example, if the tem-plate shows a position for an M1A1 tank forUnit A, any one of Unit A’s tanks could end upthere unless the user designates a specific one.Developing these templates is the most time-consuming operation of load planning; it is, ineffect, manual load planning.

Although TALPS will also support this manualcargo-placement method of operation, the sig-nificant difference with TALPS is that it can alsoplace the cargo automatically. With most ofthe other systems, a domain expert is doing thetemplate and load-plan development. Becauseof the unique mission of the T-AVB, all thetemplate knowledge for any type of load theship is capable of carrying is in the TALPS factand rule bases. Because of the unique function-ing provided by the ship, there are extremelyfew people with T-AVB load-planning exper-tise. The problem is that there are domainexperts for the ship (the TAVB itself), there aredomain experts for the cargo (mobile facilities),and there are experts in container ship loading,but there are extremely few experts in all threedomain areas. TALPS combines the expertisefrom all three domains for this application.

Articles

SUMMER 2002 81

Figure 6. Manual Load Tracking.

of Defense [DOD] ship-loading software systemand as such will be replacing both CAEMS andTALPS. Many of TALPS functions are being incor-porated into ICODES. All functions that ICODES

will absorb are expected to be completed by2005; however, there are functions that ICODES

will not pick up, that is, cargo preparationschedules, load-team assignments, cargo-flowschedules, load tracking) Figures 4 and 5 showsome of the old ways of managing the wholeload-planning and -execution effort.

The Evolution of TALPS

The TALPS efforts began in 1992 with a proposalfrom the Naval Aviation Maintenance Office toHeadquarters Marine Corps, Department ofAviation, Aviation Support: Logistics Office.From 1992 through 1997, the TALPS develop-ment team participated in every T-AVB trainingexercise as observers, interviewed all load plan-ners involved with each exercise, and extractedknowledge from the few load-planning manu-als that existed for the ships. From that effort,a T-AVB load-planning manual was written,and the TALPS software was produced.

During the initial development efforts, theload-plan generation routines went through acouple of revisions. As more and more knowl-edge was gathered about the process of devel-oping load plans for the TAVBs, the system wasmodified accordingly. Because the system wasrules and facts based, handling most new con-ditions was simply a matter of adding new factsand rules to cover the situation.

Early on, we knew that the system wouldneed to be flexible. A couple of differentapproaches were tried to give us the flexibilitywe needed. The most notable was the attemptto use a genetic algorithm (Goldberg 1989) togenerate a load plan and then have it evaluatedagainst the fact bases for fitness. This effort wasattempted, but the genetic algorithm wouldnever advance beyond 50-percent fitness; itwould reach that point in about 10 to 20 gen-erations. I tried many different approaches toget past the 50-percent problem (mutations;small, medium and large generations; differentrepresentations; different population sizes;fixed-length and variable-length chromo-somes; single- and multiple-crossover points;Monte Carlo selections, roulette, random), butI could never seem to find out why 50 percentwas the best it would do. I even rewrote the fit-ness routines from scratch. During the trou-bleshooting efforts, I even manually created afull generation of 100 entries, each having a fit-ness value in excess of 85 percent (at least 25percent had a fitness of 100). For about 5 gen-

The PROLOG development environment cho-sen for this expert system is PDC’s VISUAL PRO-LOG (latest version used for development is VIP

5.2). Prolog was chosen early on primarilybecause it allowed me to work directly towarda solution by taking advantage of its inherentbacktracking mechanisms, built-in string-han-dling features, built-in list handlers, goal-seek-ing structures, and internal and external factbase storage. Prolog allowed me to work outthe logic of the problem without regard to howto work out the implementation. I didn’t haveto worry about sequences as much as identify-ing the rules as they applied. I had consideredVISUAL BASIC and C++ as the implementationlanguage, but with each, it seemed I spentmore time trying to figure out how to code thesolution rather than work on the problemitself. Also, it seemed as though I had to gener-ate a lot more code in the other languages thanProlog to do the same job. A side benefit of theenvironment I chose was that I could developthe graphic user interface (GUI) directly in thesame language without the need for a multi-language application, thus avoiding the prob-lems associated with that.

The Advantages of TALPS

One important feature of TALPS is that it auto-matically considers the ship’s load and stabi-lization requirements. As such, the ship’s firstmate or master will not reject a load plan asbeing unsafe. CAEMS and ICODES must export theload to another application for trim, stress, andstability (TSS) verification, representing one ofthe single most significant benefit of TALPS: timesavings. With a manual load-planning time of8 to 10 hours a session (that could be rejectedas unsafe, thus restarting the 10-hour clock),the time to develop a load plan can be signifi-cant. In actual planning exercises, the time tocomplete a load plan with TALPS from start tofinish has been under one hour. (Note: Duringthe actual load-planning process, ICODES doescompute the TSS of the load as part of its agentprocessing, but it does not certify the load.)

Additionally, TALPS provides cargo-prepara-tion schedules, load-team assignments, cargo-flow schedules, power-distribution plans, andscaffolding and access plans. These additionalitems are by-products of the load-planningprocess within TALPS that normally would haveto be prepared manually after the plan isapproved. Each of these products would nor-mally take hours by themselves to produce. Allthese products increase the efficiency of theloading evolution. CAEMS and ICODES do notprovide these additional capabilities. (Note:ICODES has been designated as the Department

Articles

82 AI MAGAZINE

erations, it appeared as though the whole gen-eration’s population was approaching 100 per-cent, but then in a few more generations, itplummeted to close to what I previously hadbeen generating randomly (about 10 to 20 per-cent). Then, in less than 15 generations, I wasback at about 50 percent. After 6 months, theeffort was abandoned because of product-deliv-ery requirements and budgetary limitations.The lessons learned from developing the fit-ness function for the genetic algorithm werethen applied to the rule and fact bases. (Some-day I would love to go back and really find outwhat was going wrong).

In May 1997, TALPS 1.03c was certified by theAmerican Bureau of Shipping (ABS) as a safeloading instrument, and the software was dis-tributed to MALS. Even though target userswere involved during the development cycle,after distribution to the users, some negativefeedback was experienced.

During the development of TALPS 1.0, the pri-mary guideline for development was that thesystem had to support and be traceable toMarine Corps doctrine, which meant that ithad to be able to support the operations plan-ner doing deliberate planning using notionalassets. Simply put, load plans using genericassets (that is, notional) are generated to testconcepts and develop “on-the-shelf” plans thatcould be used in an emergency. TALPS 1.0 sup-ported this (notional planning), but a big prob-lem noted after fielding was that is not the waythe load planners worked most of the time. Indoing deliberate planning TALPS worked fine,but it was tedious to use for exercises whereload plans needed to be developed for trainingmissions. For loads less than a full ship, TALPS

was not very efficient. Planners had to manu-ally place most cargo items. Part of the issuehere was that during exercises, the ship israrely loaded to capacity, whereas in deliberateplanning, or “real-world operations,” the shipis fully loaded. The TALPS algorithms weredeveloped to support the fully loaded opera-tional scenarios. In training exercises, loadplanners would plan loads based on all the freespace available. The planners would place thecargos manually. In essence, for training exer-cises, TALPS was little more than an electronic“stubby pencil” that did TSS calculations.

In 1998, DCS Corporation was contracted toupdate the load-planning manual (USMC1998), and in 1999, DCS was again contractedto update the TALPS software, the user interface,and the rules and fact bases to account foradditional modifications made to the shipsafter the initial release of TALPS. TALPS is reviewedafter the annual T-AVB exercise and updated or

modified as required. TALPS 2.1 was fielded inNovember 2000 and was used to plan the 2001T-AVB exercise. TALPS 2.x still supports doctrine,but now it also supports the smaller size loadouts, as experienced in training scenarios. InDecember 2001, the annual user review of TALPS

was conducted, and several modifications weresuggested to further support T-AVB load plan-ning. Most of the suggestions submitted werepurely cosmetic, and a few submitted by shippersonnel were to add functions that are avail-able in other packages (or, in most cases, aprocess done manually) to ease their work.What follows is a discussion of the underlyingmethodologies of how TALPS works.

The Technology of TALPS

TALPS is primarily a constraint-based, expertscheduling system. TALPS is configured to recur-sively process all cargo items and assigns themto cargo locations. After each complete itera-tion of cargo assignments, the ship’s TSS char-acteristics are evaluated. If any safety parame-ters are exceeded, the plan is rejected, thesystem backtracks (using the internal Prologbacktracking mechanism), and the systemrecalculates the load. By incorporating domainknowledge into the rules that process the cargodata, many of the conditions that would causea plan to fail are avoided. By avoiding theknown unsafe conditions, safe load plans arealmost always generated correctly the firsttime.

As a result of the interviews during the ini-tial TALPS development efforts, certain patternsemerged that later became ironclad. Certainmobile facilities will always be combined andcolocated with particular other mobile facili-ties, and these “blocks” will almost always gointo a select few ship locations. A block is nor-mally made of two, three, or four mobile facil-ities. As a result, rules and facts were incorpo-rated to take advantage of these heuristics. Bybuilding a fact base of these standardizedblocks and their possible locations and addingrules to process them, blocks of mobile facili-ties can be assigned in seconds, leaving onlythe unattached mobile facilities to be dealtwith by the system. One of the biggest chal-lenges was to represent the knowledge anddata so the PROLOG engines could process it(Cerkez 1995). In TALPS, the block’s data are rep-resented as facts, each containing a singlepaired list that represents a block. An exampleof the data representation of a single prede-fined block and three of the legal cell block setsis shown in figure 7.

The top-level clause (autoload) controls the

Articles

SUMMER 2002 83

The previous steps are an application of theheuristics learned during the initial TALPS devel-opment efforts; the load planners always gotthese items out of the way first. By the time thesystem has to place individual cargo items, thesearch space has been reduced typically from350 items to about 180, or about one-half thesearch space.

Another example of the heuristics involvedis predefined blocks. The system reads in a pre-defined block, determines if all the necessarymobile facilities are available and awaitinglocation assignment (that is, not alreadyassigned), and verifies that the cargo locationsare available. If both are true, the block is thenloaded, and system-stored parameters areupdated to reflect the loaded cargo. If not, thesystem checks the next available set of pre-ferred cargo locations. Once all the locationsare exhausted, the current block is rejected,and the system backtracks and retrieves thenext predefined block starting the process allover. Structuring the rules and data in this for-mat allows the system to adapt to exceptionsto the rules should there ever be a mobile facil-ity block in excess of four mobile facilities. Theexception is then handled in data without hav-ing to change any code.

Once all the predefined types are assigned, thesystem then starts assigning cargo items individ-ually based on the parameters listed earlier. Ifany cargo item is placed that has a user-designat-ed partner, they are then treated similarly as apredefined block. If both cannot be placed, thena new set of locations is searched for.

The three facts shown in figure 8 show theinternal representation of a single cargo item.The serial number DRY006 is the link. The data

sequence of events, and cargos are assigned inan order that prunes the search space rapidly.Access modules are almost always placed in thesame 42 specific locations on the ship. Theautoload clause calls the subclauses that han-dle access modules early in the process, remov-ing 42 cargo items from the search space. Drystores and crew reefers (refrigeration contain-ers) are handled the same way, removinganother 10. Next come deep stow cargos. Theyrequire no access and are always put into thesame 54 cargo locations, thus further reducingthe count. The system then searches for prede-fined blocks, potentially removing another 50to 60 mobile facilities from the search space.

Articles

84 AI MAGAZINE

mf_blocks([“MV01B”,”2F32”,”MV02A”,”2F34”,”MV03”,”2A34”,”NA01”,”2A32”])mf_blocks([“MV01B”,”2F33”,”MV02A”,”2F35”,”MV03”,”2A35”,”NA01”,”2A33”])mf_blocks([“MV01B”,”3F32”,”MV02A”,”3F34”,”MV03”,”3A34”,”NA01”,”3A32”])

Figure 7. Data Representation of a Single Predefined Block.

cargo_item(1,”NONE”,”DRY006”,”TAVB”,”000”,”TAVB00”,”Z”,”0”,”DRY006”,”000”,ds,”AC”,”NA,”TAVB only”)cargo_params(“DRY006”,w(2500,2500,2500,2500,5000,5000,10000,”LBS”),d(240,”INCH-ES1”,96,”INCHES2”,98,”INCHES”,1306.67,37),b(120,58.8,48))cargo_info(“DRY006”,”Embark1”,”Debark1”,0,0,0,0,0)

Figure 8. Data Representation of a Single Cargo Item.

Figure 9. Data Representation Screen of a Single Cargo Item.

represented carry all the data needed not justby the system but also by the user before andafter loading. One task I had was to come upwith a user interface that made it easy for theuser to make changes in the data parametersand was easy for them to understand. Figure 9is an example of the GUI supporting the datain figure 8.

Ship cargo locations are defined internally, asshown in figure 10. The cell number 6F13 is theunique identifier. The two lists at the end of thefact contain constraint data and preferencedata. By expressing a preference for a particularset of cargo types ([“DS,” “SEAC”]) into a specif-ic location, the cell becomes greedy and tries toattract these types of cargo. The limitations list([“TEU,” “ISO”]) prevents unwanted cargos. Var-ious other data about the ship that affect loadplanning are also stored. As with the cargo, wealso had to allow the user the ability to modifythe cargo location data in easy-to-understandterms. Figure 11 is a sample of this GUI.

In all cases of cargo-to-location assignment,cargo-item and cell-location characteristics areevaluated. By structuring the facts and rules toaccount for cargo needs that matched cell facil-ities, I created a knowledge mapping that

Articles

SUMMER 2002 85

define_cell(“6F13”,6,”FWD”,1,3,”G”,0,0,0,0,0,”DSW”,1,[“TEU”,”ISO”],[“DS”,”SEAC”])

Figure 10. Data Representation of a Single Ship Location (Cell).

Figure 11. Data Representation Screen of a Single Ship Location (Cell).

Figure 12. Hold Representations.A (left). Hold schema screen. B (right). Hold load-planning screen.

Articles

86 AI MAGAZINE

ID load mix

ID operability requirements

ID offload priorities

Determine pierside facilities

Fixed wing only

Rotor wing only

Mixed bag

Each embark port

Each debark port

ProposedLoad Plan

Schedule Cargo

Predefined Cargos

Deepstow Cargos Fill all deep cells Excess becomes "other"

MF blocks

Access modules, etc

Operational Cargos

Access Required Cargos

"Other" Cargos

Special requirements

Air, water, 60

60 (200 amp) and 400

60 (100 amp) and 400 60 (100 and 200 amp) Operation support equipment

Accessable cargo item

Access modules (as required) Overflow from "deep"

Rolling stock

Break bulk

Scaffolding

All other "excess" cargo

Calculate Trim, Stress and Stability

ID ship

Determine/update ship facilities status

Availability date

Sail date

Embarkation port(s)

Hatches

Material handling equipment

IMA electrical system

IMA air, water, and ventilation

Space restrictions

Match Cargoto Ship Spaces

Ship Data File

Cargo Data File

Cargo Data File

Ship DataFile

Load Plan File

Figure 13. Simplified TALPS Flow Diagram.

allowed for direct pattern matches. The onlything I had to do extra was create a set of rulesthat handle the “don’t-care” situations (forexample, a cell provides 400-hertz power, butthe cargo item does not need it). The five posi-tions at the end of cargo_info (all zeros in thiscase) map directly to the five positions after theG in the cell location shown in figure 10. Thisparticular cargo item is a dry store container(cargo_item fact, fourth field from the end: ds),which maps directly to the preferred cargo typein cell 6F13, DS. In this case, the cargo itemand cell location would be a match.

Overall, the planning process allows the userto define the general concept of the ship’s load,which is accomplished by setting a hold’s para-meters. A schema was developed to maintainthe knowledge of the hold’s capabilities as wellas attributes of the hold in various configura-tions. Figures 12a and 12b show the holdschema screen representation and the resultingload-planning representation with cargoloaded.

In addition to the holds themselves, a sepa-rate schema was developed to maintain dataabout the cargo-handling equipment, accessports and hatches, and location usability basedon the status of same. The user sets these para-meters at any time during the planning evolu-tion to reflect the current condition of theship. Rules within the system act on these con-ditions and subsequently modify, as necessary,the cell-location parameters.

TALPS rules process all the facts, within con-straints set by the user and imposed by the sys-tem, and rapidly produce a certified safe loadplan. Figure 13 is a highly simplified drawingof the load-planning process. All the cargo dataare entered or updated, all the ship data areupdated, and then the cargo is scheduled intocargo locations. After the scheduling of the car-go, the load is validated for TSS. (The TSS sum-mary screen in figure 14 is one of the dialogsused by the ship’s first mate to verify the TSS ofthe vessel and to allow him/her to make fueland ballast corrections.) At any point of failure,the system backtracks and starts the processagain. The output is shown as a proposed loadplan only because the one constant in T-AVBload planning is change!

The Future of TALPS

TALPS was originally conceived as a tool tohelp the harried planner develop load plansfor the T-AVB class of vessels. Over time, itevolved into a repository to maintain thevolatile corporate knowledge of the T-AVBload-planning process. TALPS has currently

planned existence until 2005 atwhich time a DOD ship-loadingtool (ICODES) will be fielded. Thisnew tool is designed to incorpo-rate the knowledge and expertisethat currently resides in TALPS aswell as other ship-loading appli-cations.

AcknowledgmentsThis project was sponsored by theDepartment of Aviation, LogisticsSupport (ASL-34), at the Head-quarters, United States MarineCorps, Washington, D.C.

ReferencesCerkez, P. 1995. Knowledge Represen-tation: An Explanation for “Buddy,”Technical Report, CS5374, Depart-ment of Computer Science, FloridaInstitute of Technology.

Goldberg, D. E. 1989. Genetic Algo-rithms in Search, Optimization, andMachine Learning. Reading, Mass.:Addison-Wesley.

La Dage, J., and Van Germert, L. 1990.Stability and Trim for the Ship’s Officer.3d ed. Centerville Md.: Cornell Mar-itime.

USMC. 1998. Aviation Logistic Sup-port Ship (T-AVB) Logistic PlanningManual, Revision A. DCS Corporation,Lexington Park, Maryland.

USMC. 1983. Feasibility, Study of theAviation Logistics Support Ship. Wash-ington D.C.: United States MarineCorps.

Paul S. Cerkez iscurrently a softwaredeveloper and tech-nical adviser (in AI)for DCS Corpora-tion, with 22 yearsof naval aviationavionics experiencein the areas of gen-

eral aviation electronics support andautomated test equipment (ATE) and10 years computer experience in thedevelopment of custom, knowledge-based software. In addition to being aU.S. Marine (master sergeant, retired),he holds a B.S., in electronics manage-ment, from Southern Illinois Universi-ty at Carbondale, and an M.S., in com-puter information systems (AI), fromthe Florida Institute of Technology.Cerkez is the recognized subject mat-ter expert for the Marine Corps T-AVBships and performs training on T-AVBloading and load planning and TALPS

software operations and providesexpert advice to Marine Corps plan-ners on T-AVB use. His e-mail address-es are pcerkez@acm.org and pcerkez@dcscorp.com.

Articles

SUMMER 2002 87

Figure 14. Trim, Stress, and Stability Summary Screen.

Articles

88 AI MAGAZINE

Congratulations to the 2002 AAAI Fellows!

Each year a small number of fellows are recognized for their unusual distinction in theprofession and for their sustained contributions to the field for a decade or more. An offi-cial dinner and ceremony will be held in their honor at AAAI-02 in Edmonton, Alberta,

Canada.

Kevin D. Ashley University of PittsburghFor significant contributions in com-putationally modeling case-based andanalogical reasoning in law and prac-tical ethics.

Michael Gelfond Texas Tech UniversityFor significant contributions to thedevelopment of stable model seman-tics, answer set semantics, and workin cognitive robotics, logic program-ming, and nonmonotonic reasoning.

Eric HorvitzMicrosoft ResearchFor significant contributions to princi-ples and applications of probabilityand utility in computing, includingadvances in the control of problemsolving, decision making under limitedresources, human-computer interac-tion, and machine learning.

Henry E. Kyburg, Jr.University of Rochester and University of West Florida / Institutefor Human & Machine CognitionFor significant contributions to thestudy of probabilistic, statistical, andnonmonotonic inference.

Michael I. Jordan University of California, BerkeleyFor significant contributions to rea-soning under uncertainty, machinelearning, and human motor control.

Sarit Kraus Bar-Ilan University and University of MarylandFor significant contributions to model-ing of negotiation, collaboration, andnon-monotonic reasoning, includingtheoretical advances and applicationsin various computational domains.

Stephen H. Muggleton Imperial College of Science, Technology and MedicineFor significant contributions to thetheory and practice of inductive logicprogramming, especially applied tothe discovery of new biomoleculartheories from observational data.

Katia P. Sycara Carnegie Mellon UniversityFor significant contributions to case-based reasoning, autonomous agents,and multiagent systems.