Comments on the MICANTS maintenance scheduling scenario

			      Jon Doyle
			    April 4, 2000

The scenario seems good in many respects, and a good base on which to
build.  This note lists some additions that may prove necessary and
comments on selected aspects.

1.  The main thing missing in this scenario, at least as far as I
    understand the new domain, is any representation of units and
    their missions, whether ongoing or specific.  The aim of
    maintenance, and the guidance to scheduling it, comes from trading
    off these missions to achieve readiness for different tasks as it
    is needed.  The current scenario lists only maintenance tasks, and
    leaves all the mission information unrepresented.

    Presumably the collection of agents should be expanded to include
    Mission Agents and Unit Agents, in addition to the Maintenance
    Task Agents.  Mission and Unit agents will provide the guidance
    needed for the negotiation of maintenance tasks.  There may also
    be direct negotiation among the mission agents when resource
    degredation prevents all missions from being carried out.

    I can't tell if the Maintenance Supervisor Agent or one of the
    Resource agents is supposed to embody mission information and
    tradeoffs.  If they are, I suggest we break out these separable
    bodies of information, especially as we will have to consider
    tradeoffs among separate missions.

2.  The "criticality curve" concept offers an illustration of the lack
    of mission information.  Presumably "criticality" is a more
    general concept that depends on mission and other factors.  The
    temporal information described here might better be called an
    "urgency curve".  Nomenclature aside, it isn't clear why this
    temporal factor in utility is separated out at this level.
    Presumably the temporal factor depends on the mission, along with
    other mission-specific factors, and so can't be associated with an
    action independent of the mission; instead, one must get the
    urgency curve for the action from the mission.

3.  From some points of view we may need to break resources down
    hierarchically.  The main case has to do with facility scheduling,
    in which one may wish to treat particular time slots on the bay or
    tool as the resources for negotiation, not the bay or tool
    itself.

That's it for the substantive comments at present.

One additional but minor bug is that the scenario document itself
prints out improperly under both Solaris and Windows.  The symptom is
that some words get run together or even partially superposed.  I
first suspected some error connected with linefeeds on whatever
machine the document is being prepared, but am less sure of that since
the same thing happens on platforms with different line-ending
conventions.