Knowledge Representation and Reasoning in the Design of Composite Systems

Transcription

1 470 IEEE TRANSACTIONS ON, SOFTWARE ENGINEERING, VOL. 18, NO. h, JUNE 1992 Knowedge Representation and Reasoning in the Design of Composite Systems Stephen Fickas and B. Robert Hem Abstract- Our interest is in the design process that spans the gap between the requirements acquisition process and the impementation process, in which the basic architecture of a system is defined, and functions are aocated to software, hardware, and human agents. We ca this process composite system design. Our goa is an interactive mode of composite system design incorporating deficiency-driven design, forma anaysis, incrementa design and rationaization, and design reuse. We discuss knowedge representations and reasoning techniques for the product (composite system) that we are designing, and for the design process, which support these goas. To evauate our mode, we report on its use to rationay reconstruct the design of two existing composite systems. Index Terms-Automated anaysis, composite systems, knowedge-based design, rationa reconstruction, software specification. 0 I. INTRODUCTION UR group s historica interest has been in knowedgebased software deveopment (AI and SE). However, in the course of our research, we found that we coud not formay expain or reproduce the features of standard software designs, such as those of eevator controers and ibrary databases [24] by focusing soey on the software and its immediate interface to human and hardware systems. Further evidence of this diemma was found in human systems anaysts in the domains we studied [16]; they focused on poicies and concerns that cut across human, hardware and software components. This has ed us to an interest in the design of composite systems, ones that encompass mutipe agents invoved in ongoing, interactive activities [13]. In composite systems, software agents are treated the same as human and physica agents, as components to be integrated together to sove arger system constraints. We have deveoped an interactive design mode, caed Critter, for producing composite systems. The mode is founded on an earier design too caed Gitter [15], which used automated probem-soving techniques to assist a human in impementing a forma specification. We have tested Critter by attempting to rationay reconstruct or reproduce existing we-documented composite system designs, some containing no software components (e.g., pre-computer transportation systems), some containing a mixture of software, human, and physica components (e.g., the canonica eevator system [24]), Manuscript received October 1, 1991; revised February 11, Recommended by M. Jarke and A. Borgida. This work was supported by the Nationa Science Foundation under Grant CCR The authors are with the Department of Computer Science, University of Oregon, Eugene, OR IEEE Log Number and some containing software components soey (e.g., emai transport systems). Our work on Critter is tied to the specia issue as foows. Software engineering goa: We wish to address the stage between the requirements acquisition process and the impementation process, in which the basic architecture of a system is defined, and functions are aocated to software and hardware components, or to the users. For the design process, in particuar, we are interested in representations that promote deficiency-driven design, forma design anaysis, incrementa design and rationaization, and design reuse. Knowedge content: There are two types of knowedge we must address in designing composite systems: 1) the knowedge of the artifact (composite system) that we are designing, and 2) the knowedge we use in designing the artifact. Our knowedge of an artifact is a forma mode of its behavior and the constraints it ives under. For design knowedge, we have focused on the knowedge necessary 1) to decompose a goba specification into specifications of its components, and 2) to modify the goba specification so that reaistic impementations can be found. We introduce the notion of a minimay restricted design step as a means to effectivey pay out a compex design. We aso discuss the form of anaysis our toos produce. In particuar, we want our anaysis toos to output not ony correct design or incorrect design, but the pans/counterexampes/scenarios that ed to such a judgement. Our goa is to use this information in formuating the next step in the design process. Knowedge representation and reasoning: We are most concerned with representing the design process. In contrast, for representing the artifact (i.e., the design state) we have chosen off-the-shef forma anguages (a form of tempora ogic to represent design constraints, and a form of Petri net to represent artifact behavior). Our representation of the design process is based on a traditiona AI paradigm, that of state-based search. It has two parts: 1) a representation of the design operators, heuristics, and anaysis toos necessary for a design (search) to incrementay progress, and 2) a representation of the search manager, the component that keeps track of aternative search states and paths, aows browsing, exporation, etc. Our focus is on the first component, which Section III discusses in more detai. We wi argue for the strength of our knowedge content and knowedge representation choices through two exampes in Sections IV and V. We wi discuss the weaknesses of our choices, in the context of these two exampes and other arger /92$ IEEE

2 FICKAS AND HELM: KNOWLEDGE REPRESENTATION AND REASONING Fig. 1. Critter and its associated deveopment processes. Fig. 2. Critter state-based search mode of composite system design. exampes we have begun, in Section VI. Section VII discusses work reated to the Critter mode. II. OUR PLACE IN THE LIFECYCLE Fig. 1 paces Critter in the more genera system ifecyce we envision. To briefy summarize the figure, the requirements acquisition process invoves anaysts acquiring informa requirements from users and other concerned parties, in the form of diagrams, text documents, interview transcripts, and so on. The output of this process typicay remains informa. We have incuded a conditioning process in Fig. 1 to map the requirements produced by requirements acquisition toos to a form acceptabe by our design toos. Ceary, this conditioning process may be a major effort given the ack of consistency in the requirements engineering fied, where formaity, representations, and even definitions may vary from organization to organization. The composite system design process, the center of our research interest, decomposes formay specified goba constraints and infrastructure into a specification of a composite system, a set of components or agents which interact to satisfy the goba constraints. For exampe, the input to composite system design might be a forma version of the foowing: Infrastructure = Internet Constraint 1 = given an emai message of form M, deiver M to its recipient Constraint 2 = given an emai message of form M, notify the sender when it is deivered.... The output of the composite system design process woud be the specification of a set of emai agents running on the Internet that took responsibiity for satisfying the set of constraints. The informa SMTP specification (the standard emai system on the Internet) is an exceent rea ife exampe of what we are trying to produce formay. The focus of this paper is on a too, Critter, that supports the interactive design of such systems. The bottom three processes impement each agent cass according to the composite system specification. A singe composite system specification may require that each impementation process be appied: producing software, acquiring or manufacturing hardware, and writing ega statutes or training manuas which prescribe the actions of human workers taking the roe of an agent. The first exampe we describe, that of a train management system, has forced us to ook, at east superficiay, at the hardware and rue-writing processes. Our second exampe, that of an emai transport system, is principay composed of software. The next section introduces composite system design in more detai, and the Critter toos that support it. III. THE CRI-ITER MODEL The Critter design mode (Fig. 2) heps a human designer deveop a composite system design using the paradigm of state-based search. Starting from an initia probem state, Critter heps an anayst appy design operators unti he arrives at a composite system design state that soves the probem. The Critter mode is the sum of the foowing components: a design state representation, a soution state or eaf-node checker, a set of move or design operators, a set of heuristics for seecting design operators, a search management component that manages the design space, aows browsing, etc. We discuss the knowedge content, representation, and reasoning toos of each of these components in turn Design States Each design state in our search space represents a singe composite system design. A state in Critter has two components: 1) The generative or system portion of a design state denotes a set of possibe behaviors. A behavior is a sequence of events that coud occur in the composite system. In our mode, the system is represented by a specification in a anguage we have adapted for composite system specification as expained beow. 2) The constraining portion of a design state consists of a set of constraints, i.e., constraints on behavior. Constraints are expressed decarativey in terms of systemwide properties. They are forma versions of statements such as Trains get to their destinations, or Trains don t crash into each other. The overa goa of the search is to bring the two into consistency in a singe state-the behaviors produced by the system shoud satisfy the constraints. As this impies, the system and constraint components may be misaigned in any one state, i.e., the system may generate behavior that breaks the constraints. Be aware that this is a twist on most state-

3 472 IEEE TRANSACTIONS ON, SOFFWARE ENGINEERING. VOL. 18. NO. 6, JUNE YY2 based probem soving where the goas of the system are the goas of the search. The goas of our system are the constraint portion of the design state. The goa of the search is to find a match between the two state components. The probems that we have focused on can be characterized as iveness-safety probems [28]. Typicay, they invove constraints of two genera forms. Liveness: For each behavior B, find some state JJ in B s.t. io satisfies Cachieurment. Safety: For each behavior B, no state p in B shoud satisfy Gnsa,e. In toy words we may be abe to drop one cass of constraints amost entirey, or pretend that a constraints can be met stricty. In the rea word there is often an intricate baance between the two casses. The system portion of a design state is further divided into two parts. First, there is what we ca the infrastructure. Exampes of an infrastructure are the rai-ines of a rairoad system and the communication-ines of a network system. The system portion aso incudes a set of agents. Agents use the infrastructure of the system and interactions with each other to produce behaviors. In genera, an agent is a component of a composite system that can sense a portion of the system s state, make decisions, and perform or prevent actions of the system that the agent contros. An agent cass in our representation thus has the foowing attributes. 1) A set (possiby empty) of the system state an agent can directy observe. 2) A set (possiby empty) of actions an agent can perform that affect the system state. 3) A set (possiby empty) of oca state information. 4) A set (possiby empty) of responsibiities for achieving a constraint or goa of the system. Assigning responsibiity for a constraint to a cass of agents requires that a agents in that cass imit their actions so the constraint is achieved. Ony those agents responsibe for a constraint are expected to imit their own behavior to ensure satisfaction of that constraint. For exampe, if a train engineer/agent is soey responsibe for keeping her train from coiding with another, then she must imit her actions accordingy, and in particuar, cannot rey on other agents to constrain their actions to avoid coision. An agent may be overoaded in our representation: It may have more than one responsibiity in any singe composite system, and it may have separate responsibiities in two or more different composite systems. It may aso share responsibiity for a constraint with another agent in the same system or a different system. Both the constraining and system portions are represented in notations we have adapted from existing work in forma specification. No existing notations had exacty what we need, so we have foowed the approach of Feather [12], who shows how to extend the Gist anguage to support composite system design. We have adopted ess powerfu anguages than Gist, however, so that we can use the automated reasoning techniques we introduce in ater portions of the paper. Our constraint anguage is a stye of moda, tempora ogic roughy simiar to that of that of the ERAE anguage [o], and is very simiar to the tempora-causa ogic independenty deveoped by Castro [5]. It aows expression of both safety and strong iveness requirements [28]. The anguage for the system portion can be viewed, aternativey, as a subset of Gist [30] or a superset of Numerica Petri Nets (NPN) [46] that adds the notion of agents. We wi use the Petri net view in this paper for presentation purposes Leaf Node Checkers The overa goa of the Critter search is to bring the system and constraint portions into consistency in a singe design state. A consistent state is caed a eaf or soution state. Our mode semi-automaticay checks design states for consistency (eafhood) using three toos. Anaysis Too 1: A panner or scenario generator caed OPIE [2]. In genera, OPIE attempts to show that a state is not congruent by showing that safety or iveness constraints are not met. OPIE does this by finding a pan that vioates the constraints, in effect producing a counterexampe for the constraint. For exampe, it might prove that the constraint no two trains are ever in the same bock of track is vioated by generating a pan for putting two trains in a bock. As we discuss beow, we beieve generating counterexampes to constraints, rather than verifying constraints are met, can give the designer usefu guidance on the operators to appy to a state if it is not a eaf (soution). However, in addition to testing eafhood, we aso use OPIE to show that a set of constraints coud be met if agents cooperated in the right way. OPIE does this by producing a pan that satisfies the set of constraints, effectivey proving the existence of a correct behavior. As with counterexampes, an existence pan may provide insight into what operators to appy to a noneaf state to transform it into a soution. Anaysis Too 2: An NPN simuator. We have impemented an NPN simuator that runs an NPN forward. At nondeterministic choice points, aternatives can be either presented to the human designer for seection, or controed by simpe rues, e.g., aways choose transition A over transition B. For exampe, we might run the NPN simuator on a test case that attempts to put two trains into the same bock of track to show that a safety constraint is not satisfied in the current state. The detais of this too, and a semi-automated means of seecting appropriate test cases to feed it, is discussed in [16]. Anaysis Too 3: A reachabiity-graph (RG) too. The too first produces a reachabiity graph from a static anaysis of the NPN, and then aows queries about reachabe states. For exampe, the too can repy to queries such as, Is it possibe for a train to fai to reach its destination? It uses omega vaues [23] to represent infinite pans/behaviors. As with OPIE, these queries can be used to provide existence proofs Search Operators Search operators (henceforth, design operators) are what transform one composite design state into another, and may appy to either the constraint or the system part of the state. They are appied to a noneaf node N to remedy a deficiency found in N. Hence, we oop through the se-

4 FICKAS AND HELM: KNOWLEDGE REPRESENTATON AND REASONING 473 quence anaysis+deficiency+remedy in Critter unti the ana- toos [18], in this paper we wi focus on the more genera ysis toos report success. mode of composite system design. Because our interest is in composite system probems, our design operators are taiored to muti-agent distributed-action IV. APPLYING THE CRIITER MODEL: THE MCGEAN DESIGN concerns. Among the types of design operators we use are the We have tested the Critter mode described above by a foowing. methodoogy of rationa reconstruction. In genera, this means Introduction of agent casses. There are operators for using our design mode on a study probem for which there are introducing new types of agents, or for spitting existing aready we-documented designs, preferaby designs that have types. For exampe, an operator might spit a cass of evoved over time and that have we-known strengths and protoco entities into cients and servers. weaknesses. We beieve the rationa reconstruction method- * Assignment and merging of responsibiity. As described oogy provides a usefu check on the sufficiency of our above, agents can be given responsibiity for constraints. mode, i.e. can we generate interesting, existing designs? They can share their responsibiities with one or more Moreover, appying the methodoogy to we-understood enother agents. They can aso be overoaded; each agent gineering probems heps identify the knowedge our too can have mutipe responsibiities. woud need to automate the now manua heuristic evauation Communication and synchronization among agents. of designs. We have used the Critter mode to rationay Critter incudes operators which introduce simpe reconstruct severa designs, two of which we wi summarize communication and synchronization protocos (such as in the remainder of the paper. The success criterion for our request-repy interactions) between agents. rationa reconstructions is the abiity to mode the origina in- Weakening of constraints. In many rea-word probems, frastructure and reproduce the fina responsibiity assignments we may find it necessary to achieve consistency not by through the use of our design operators. changing the system, but by changing the constraints. In A word of motivation on our choice of the two study particuar, the initia constraints may be ideaized and open for modification and compromise. In these cases, a constraint may be weakened to make iega behaviors ega ones Heuristic Evauation There is a reativey sma number of design operators that are abe to produce the composite systems we have studied. However, they are capabe of producing a arge set of aternative designs, enough so that bind search becomes intractabe. We currenty rey on the user to provide the necessary domain knowedge to guide the search. From our study of composite system design heuristics [14],[17], we suspect that the human designer wi continue to be the main source of heuristic evauation in Critter for the foreseeabe future Impementation Critter is partiay automated. The toos that make up the eaf-node checker are automated, athough they require some set up as expained above. The design space is represented in an extended form of IBIS [7] that provides for separate deveopment states. Each deveopment state represents the current design state and the current set of design issues. Design operators are represented by positions attached to an issue, and design heuristics as arguments attached to a position. In the current impementation, the user manuay appies design operators by attaching the appropriate positions and updating the agents and infrastructure using a Petri net editor. The user aso must attach any seection heuristics as arguments to the positions. Critter then automaticay generates a new deveopment state (a new IBIS state) after the operator has been appied. In this way, the entire design space is maintained, aowing a designer to move to any node and expore aternatives. Whie there are interesting issues on the use of an IBIS stye framework for impementing incrementa design probems is in order. The first exampe we present in this paper is a train management system described in McGean [32]. The system, known as manua absoute bock cearing, originated in the 19th century; we wi refer to it as the McGean design for brevity. We arrived at this probem after work on the canonica eevator probem [12],[24], which in turn derives from [25]. Our switch from the eevator probem was motivated by the foowing. We found it difficut to evauate the eevator designs that we produced. Whie there are eevator guideines, books, and journas pubished, we faied to find enough detaied design rationae to evauate our resuts. We did, however, find intricate and detaied evauation criteria for train systems [32], incuding a history of major train accidents and their causes [42]. A train system is a more interesting composite system probem. There are more agents invoved and more ways to spit responsibiity among them. This same domain has been studied for its connection to network protocos by [22]. This eads ceany into our second exampe. The second probem we have chosen is a simpe networking probem, that of fow contro during emai transport. In particuar, our target is the reconstruction of the OS1 MOTIS (aka MHS) P protoco design. This exampe has two usefu properties. Its design can be vaidated at a production eve. That is, we can impement a MOTIS emai transport design eaf node produced by our mode as a network appication and run it under production conditions (abeit, OS1 production conditions). This is a feature of ony one of the four canonica IWSSD probems, namey the text editing probem. It is certainy not a feature of the eevator or train probems, at east for our group.

5 474 IEEE TRANSACTIONS ON, SOFTWARE ENGINEERING, VOL. 18, NO. 6, JUNE 1992 Fig. 3. Simpified McGean design. Fig. 5. Initia state D of the McGean exampe Fig. 4. Excerpt of the McGean exampe design space. MOTIS, and network appications of its ik, have westudied and forma evauation criteria [44]. Many network appications aso have a written chronoogy of their design (see, for instance, the RFC s maintained by the Internet NIC). Taking up the McGean design first, Fig. 3 shows the target of our design process. This design attempts to prevent coisions of trains by aocating regions of track of 5- to 15-mi engths (caed bocks) to a singe train at a time. Looking at the fina soution from a composite system view, the design designates Engineer agents as responsibe for entering a bock between stations ony if the signa for that bock reads cear (vertica). Station Operator agents are given the responsibiity of 1) setting the distant and home signas for a bock to occupied (horizonta) when a train enters a bock, 2) resetting the signa to cear when notified that a train has eft a bock, and 3) notifying other station operators when a bock becomes cear. Finay, Dispatcher agents (not shown in Fig. 3) are responsibe for making sure trains enter a system in a safe fashion. Fig. 4 summarizes the first part of the path Critter takes to arrive at the target design in Fig. 3; it roughy represents the IBIS form of search tree we maintain as part of Critter. As in Fig. 2, arcs coming out of a design state (node) represent aternative design moves out of that node. In the initia state D, the system has one iveness and one safety constraint: Trains shoud get to their destinations, and trains shoud not coide. In the exampe, we show how these constraints are decomposed into a set of agents and inter-agent protocos that interact to satisfy the constraints The Initia State Critter s search process requires an initia design state. We rey on the anayst to produce this initia state for the McGean design, guided by some considerations we describe in this section. This section aso introduces the notation we use for design states throughout the paper. The initia state of the train exampe is shown in Fig. 5. We use an enhanced version of an NPN [46] to represent both infrastructure and agents of a system. The initia constraint portion appears at eft, the system portion at right. There are two constraints in state D: two trains shoud never be at the same ocation (safety); trains shoud eventuay get to their destination (iveness). We can paraphrase the specification of the system portion in this figure as foows. Trains can be created. The transition (drawn as a box) enter in the upper eft corner can fire nondeterministitay, since it has no input arcs; when it fires, it introduces a train token t (drawn as a train icon) on the pace (drawn as a circe) abeed Ready(t) at the end of the arrow. The Readypace denotes the reation Train t is ready to start. A train t for which Ready(t) hods can be assigned a destination bock by the assign - destination transition. The arc between the transitionassign - destination and Ready(t) is doubed-headed. This means that the transition needs a token (i.e., a train t) from Ready(t) to fire, but the token is simpy repaced in Ready(t), unmodified, on firing. In contrast, the move transition changes a train s ocation; hence, we have drawn two separate arcs between move and Location(t, b). If a train t is Ready, has a Destination, and has an avaiabe Bock to start in (shown as bocks 1,2,3 in the Bock pace), it can start (transition start can fire). Starting puts t at a ocation bock b, denoted by the pace Location(t, b). Trains for which Location(t. b) hods can move to Adjacent bocks (shown as bock numbers connected by ines) by firing the transition move, which paces them at a new ocation adjacent-to their origina ocation. Trains at their Destination ocation can eave the system by firing the eave transition. The initia state D represents the train management system that immediatey preceded that of McGean-a schedue-based system that reied on cever timing of trains to avoid coisions. As noted in [42], the schedue-based design had its probems, causing an unacceptabe number of accidents. This, aong with the invention of teegraph, sparked an interest in finding a new design. More generay, we view the initia state as the infrastructure that is aready in pace when design commences (or what we ater refer to as brownfied constraints). Typicay, the infrastructure represents the piece of the system that has the greatest modification cost, and hence, is the piece one tries to design around, or in a more positive ight, on top of.

6 FICKAS AND HELM: KNOWLEDGE REPRESENTATION AND REASONING As for the actua construction of the initia state, we assume that it is the output of a requirements acquisition process, possiby aided by a system such as the KAOS [45] assistant discussed in Section VII Deficiency-Driven Composite Design Our genera stye of design is deficiency-driven. We use the automated anaysis toos of Critter to identify deficiencies, i.e., behaviors of the system that vioate the constraints. We then appy design operators to overcome those deficiencies. This section iustrates this process and our representations in more detai. The designer uses the panner-based eaf-checker OPIE (described in Section 3.1) in state D to see whether the safety constraint is met. OPIE cannot verify systems written in the fu NPN anguage, but ony a subset that is roughy equivaent to the anguage of STRIPS [2]. We rey on the designer to restrict the system to this subset. OPIE returns a pan in which two trains coide at start-up. The constraint ProtectTrains is vioated by scenario S in state D: 1. given Bock(h1); 2. enter(ttrain) produces Ready(t1); 3. enter(t2itrain) produces Ready(t2); 4. assign - destination(t1, b) produces Destination(t1, b) 5. assign - destination(t2, h) produces Destination(t2, b) 6. start(t1, b) produces Location(t1, b); 7. start(t2. b) produces Location(t2, b); Vioation: ProtectTrains in D To eiminate a negative scenario such as S, the designer can choose among three compementary strategies. 1) Modify the infrastructure. The designer coud decide to provide separate arriva points for each train, making it impossibe to generate the crash on arriva scenario of S. 2) Weaken the safety constraint. Some train systems take this approach by aowing more than one train in a bock [Q. 3) Assign responsibiity for the safety constraint to a cass of agents. This requires agents in the cass to contro their actions so that the constraint is met. The designer chooses the third option. Critter has severa operators that coud accompish this. 1) Never aow a specific condition in the constraint to be true (e.g., never aow trains in the system). 2) Ensure that two conditions in the constraint are mutuay excusive (never aowing more than one train in the system). 3) Manipuate transitions so that some but not a the constraint conjuncts are aowed to become true at the same time. The designer chooses 3), whose genera cass we ca brinkmanship. The set of brinkmanship operators modify the system so that an agent assigned to the constraint prevents transitions that are the ast step in breaking the constraint. The outcome of this in our exampe is that a designated agent wi never aow a train to start at the same ocation as another train. Before we describe the brinkmanship operator in detai, we describe Critter design operators in genera. Design operators take a cooperative form. The operator contains the framework of a composite system design strategy, for instance, the means of dividing responsibiity among agents in a particuar setting. This is represented by a matching pattern that estabishes the right setting and a repacement pattern that introduces the concept into the design. A design operator may aso introduce domain assumptions and faiure modes. These are discussed in more detai in the next section. The human designer 1) suppies important pieces that fi out the matching and repacement patterns, 2) either confirms each assumption the operator makes, or decides that an assumption is uncertain enough to ca for further remedia design, and 3) attempts to mitigate any troubesome behavior introduced by the operator. A of these actions typicay require the designer to suppy domain-specific knowedge to the design process. In summary, the designer uses her knowedge of the domain to seect operators and guide their appication to the current state. The operators add the necessary components to the system description and track open assumptions for the designer. In this way, our design operators are much ike the skeeton pans of the MOLGEN system that addressed the strategic aspects of a design, reying on the user to suppy the domain-specific detais and fix the pan when probems were discovered [19]. The particuar brinkmanship operator we wi empoy matches on constraints of the form where P is a reation (or pace in NPN form), 2, y, z are vectors, and there is an impicit for a behaviors quaifier on the front. This pattern, aong with the agent A assigned to the constraint, is shown as part of the brinkmanship operator in Fig. 6. The resut of appying the operator is a new system where a brink transition (T in the figure) is controed by the agent A. The appication of the brinkmanship operator is interactive. 1) The designer factors the constraint into a controed condition and a brink condition. In our exampe, P is the Location reation, and the controed and brink conditions are both partia instantiations of P. 2) The designer chooses an agent cass A to be responsibe for the factored constraint. In this case, the designer chooses a train Dispatcher agent to be the responsibe, hence controing, agent. 3) The designer identifies a transition T that can produce the controed condition when the brink condition is true, vioating the constraint. The agent responsibe for the constraint wi contro T so that it cannot fire when the brink condition is true, preventing T from pushing the system over the brink by producing P(x, 2) A P(y, 2). In our exampe T is the start transition.

7 476 IEEE TRANSACTIONS ON, SOFTWARE ENGINEERING, VOL. 18, NO. 6, JUNE 1992 Fig. 7. System state 02 (excerpt): Appication of brinkmanship operator to start transition. Fig. 6. Brinkmanship operator 4) The designer defines how contro begins and ends. The designer must identify some pace that triggers an agent in A to take contro. The designer aso identifies a condition under which that agent can reease contro. In our exampe, a Dispatcher agent takes contro of a train t when Ready(t1) is true. The dispatcher reeases contro of t when start fires. As can be seen in Fig. 6, the resut of appying the operator is that the T in the top pattern is spit into two parts, one that is controed (T - c) and one that is uncontroed (T - u). The controed transition T - c has a new piece of subnet associated with it that aocates (and potentiay oses) contro. T - c aso has a not-arc (represented as a ine ending in a circe) attached to it from the pace P. This represents the brink check: if the brink condition exists aready (e.g., there is another train at the same starting ocation), then bock any firing of T-c that woud cause the contro condition to become true (e.g., a second train woud end up at the same starting ocation). Fig. 7 shows the parts of the McGean design state affected by the brinkmanship operator. Paces and transitions drawn with short, nondirected arcs designate eision; we have eft off either incoming or outgoing arcs that have no bearing on the current figure. We can paraphrase Fig. 7 as foows. Trains ready to start are assigned a dispatcher. More than one dispatcher can be assigned to contro the same train, either simutaneousy or after oss of contro. However, a singe train cannot be under the contro of the same dispatcher more than once simutaneousy. Trains under the contro of at east one dispatcher do not start unti their starting bock is cear. If no dispatcher is in contro of a train then it is possibe for the train to start unrestricted via the transition start-u (incuding cases where a train starts before contro can be assigned). The brinkmanship operator has aso introduced a set of domain assumptions (not shown in the figures), and has added two faiure mode transitions (start-u. and ose - contro - start). Deaing with these is the next step in the McGean deveopment Vaidating Operator Appication: Dismissa and Certification Critter design operators do not guarantee a provaby correct design by themseves. This is a major and conscious departure from the work in forma transformation systems. Instead of concentrating on tighty restricted correctness-preserving operators, we have focused on genera operators that incorporate knowedge to vaidate their use in a particuar probem setting. The next two sections iustrate and defend this strategy. Critter attempts to vaidate the changes an operator makes to the specification by two means. First, design operators incude domain assumptions, conditions that must hod in the design domain for the operator to be effective. When an operator is appied, Critter records its domain assumptions as open issues. For instance, in Fig. 7, the domain assumptions of brinkmanship are that dispatchers can be found, that they can gain contro of a train, that they have direct access to the start transition, and that they can see or sense that a starting ocation is cear or occupied. Each of these assumptions wi remain open unti actuay vaidated by the designer. Second, design operators incude faiure modes, representing behaviors that have been found to cause troube for the systems where the operator was appied. For exampe, the ose - contro - start and start-u transitions of Fig. 7 represent undesirabe behavior which may occur if the contro regime for starting trains fais. The designer can address open domain assumptions by dismissing them, or by adjusting the composite system to satisfy the assumptions. The McGean design we are reproducing assumes that a of the new contro components (transitions, arcs, and paces) added by the brinkmanship operator are vaid. We assume the designer certifies them as such (not shown in Fig. 7). Simiary, the designer can address faiure modes in a design by certifying they wi not occur, or by redesigning the system to toerate them. The McGean design we are reproducing does

8 FICKAS AND HELM: KNOWLEDGE REPRESENTATION AND REASONING 477 In summary, our approach is to use a minima set of preconditions to get a genera design strategy (as represented by an operator) into pay, incuding stereotypica issues and bugs associated with the strategy. We then use anaysis toos and the human designer to point to paces where further design is necessary. In essence, we promote a stye of design that aows a designer to test drive a strategy before committing enormous energy into making it work at a detaied eve. Fig. 8. Design state 03: Appication of certification operator not address either the ose - contro - start or the start-u transition, i.e., there are no new agents in the target design that are introduced to overcome either probem. Hence, we wi aow the designer to certify that uncontroed entry (start-u) and oss of contro (ose-contro-start) can be ignored from a composite system design viewpoint. The resut, design state 03, is shown in Fig. 8. The certification token, c, can be paraphrased as a scenarios invoving uncontroed train arriva have been considered and dismissed as either preventabe at the impementation eve or unikey to occur in the rea word. The certification token c2 works in a simiar fashion for oss of contro. The certification tokens provide a hook where the designer can insert data backing their caims, such as standards, or court cases setting imits on what negative impact must be considered in designing artifacts. If these standardsf ater become fase, or if we want to experiment in a hypothetica word where they are fase, the certification tokens can be removed and the corresponding transitions wi become unbocked. In genera, dismissa and certification act as an escape when our toos ack the knowedge to reason formay about the subsequent impementation process or the domain in which the system wi reside. They provide two crucia pieces of information: 1) they record that a negative outcome has been considered, and 2) they often point to a body of reevant domain knowedge for which we currenty ack a forma representation. The previous step aso iustrates the phiosophy underying Critters design operators. Appying an operator got us a itte bit further toward a safe design, but was not provaby correct, even with respect to the oca goa for which it was appied. We have de-emphasized provaby correct design in Critter for severa reasons. First, provaby correct operators woud have a engthy set of operator preconditions that a) might require a arge up-front theorem proving effort, and b) woud narrow operator appication to a sma cass of settings, and hence, require a arge subgoaing or jittering effort before the operator is ever attempted. In our experience with Gitter, both of these probems ed to much wasted design effort-it wasn t unti an operator/transformation had actuay put a concept in pace that it coud adequatey be judged. Second, vaidation of an operator frequenty reies on domainspecific knowedge unavaiabe to Critter. Again, we prefer to postpone this vaidation process unti after the operator has put the concept in pace within the system Reuse of Operators: Spitting Contro Critters operators are intended to provide reusabe strategies for composite design. The next step of the McGean rationaization suggests how reuse occurs within a particuar design probem, and how an incrementa approach can rationaize features of a muti-agent design. The design state 03 incudes an agent cass, Dispatcher, which wi ensure that trains do not vioate the safety constraint at start-up. However, design state 03 is not a eaf node-opie generates a scenario 5 2 in which two trains enter the system safey, but sti end up at the same ocation. Instead of crashing on start, they crash by moving (firing the move transition in Fig. 5) into the same bock. The steps the designer takes to counter the S2 scenario are simiar to those taken to counter S: the same brinkman- ship operator is appied (Fig. 9). As with start-c, the new move-c transition can ony occur when an agent (Engineer) is controing the train. As before, the new system retains both a move-u transition that can fire for uncontroed trains, and a transition for osing contro. The combination of the brinkmanship appications to Dispatcher and Engineer gives us a sequentia spit of responsibiity, a common cooperative probem soving approach: break the probem into pieces (tempora in this case) and assign separate agents to each piece. However, this division of abor was constructed incrementay, by a sequence of deficiencydriven steps. The design history thus rationaizes the sequentia division of abor in terms of a specific goa (ProtectTrains), probematic scenarios (S, S2) encountered during design, and the design steps taken to address them Vaidating Operator Appication: Adjusting the Design When the domain assumptions or faiure modes of an operator cannot be certified away, the designer adjusts the design to address them. The next deveopment sequence shows how this adjustment activity can naturay rationaize supporting services such as inter-agent communication protocos within a design. Given the second appication of brinkmanship, the designer is eft with the task of verifying the domain assumptions as they now appy to engineers controing the movement of trains. 1) Can the Engineer directy contro train movement (move-c), i.e., does she have direct access to the throtte? Whie the answer obviousy seems to be yes if one uses on-board humans as Engineer agents, vehices such as unmanned spacecraft are controed remotey by an engineer, and require sophisticated twoway communication devices to bring about contro.

9 478 IEEE TRANSACTIONS ON. SOFTWARE ENGINEERING, VOL. 18, NO. 6, JUNE 1992 Fig. 9. System state 04 (excerpt): Appication of brinkmanship to train movement. More down to earth, some recent transportation systems rey on cooperation between an onboard computer agent and a remote human agent to contro vehices. 2) Can the Engineer directy access whether an adjacent bock is occupied? (Is the not-arc between move-c and Location vaid?) The sensing technoogy of the day was human vision. As before, the Brinkmanship operator aso introduces two potentia faiure modes. 1) Can uncontroed movement (move-u) occur? 2) Can oss of contro (ose - contro - move) occur? The history of train system design has shown that a of these questions has eventuay required attention. However, the design we are reconstructing ony addresses the second question (access to an adjacent bock); hence, as with Dispatchers, we wi mark the arc between Contro - move and move-c as vaid, answering question 1. We wi aso certify that oss of engineer contro and uncontroed train movement can be ignored, certifying yes to questions 3 and 4. This eaves us with question 2-tan Engineers see into adjacent bocks, i.e., is the not-arc between move-c and Location vaid? This was not reaistic in McGeans domain: bocks were 5 to 15 mi ong and Engineers coud not directy sense the entire ength of bocks adjacent to them. Fortunatey, a standard composite system soution is avaiabe: specify other agents to act as intermediaries, manipuating a fag or spin ock that reays the vacancy information to the Engineer. To seect this joint probem-soving protoco, the designer appies an operator from a cass we ca set/ reset. As with brinkmanship, the designer must guide the operator to the appropriate ocation in the current state, in this case, to the notarc that bocks movement in Fig. 9. Fig. 10 shows the effects of this decision on the design state: the not-arc between move-c and Location is repaced with a more eaborate mechanism for maintaining a fag on the bock. Besides pinpointing the ocation of appication for the operator, the designer must specify which agent casses wi contro the actions of setting and resetting. Set/reset cas for two sets of agents (A to contro reset and A2 to contro set ) to cover bocks, but the designer decides that the same agent that manages set - Bock-c (sets the home signa) can aso manage reset - Bock-c (cear the signa), and appies a merge-agent operator to agent casses. Whie this is ceary more economica (and foows the McGean design), it aso Fig. 10. System state D.5 (excerpt)-resut of set/reset introduces a risk: in a particuar impementation of the agent cass (now caed Operator), an agent may not have sufficient time to carry out both of its responsibiities (set and reset) for a of the bocks it is tracking-overoading may ead to overcommitment. In the McGean design, this is partiay addressed by assigning ony one bock to each Operator. Appying the set/reset operator raises its own domain assumptions and faiure modes (not shown in the figure). Two of the domain assumptions are of particuar interest here. 1) Can the controing agent sense whether a bock it contros is occupied? (Is the arc between set - Bock-c and Location vaid?) 2) Can the controing agent sense when the bock is cear? (Is the not-arc between Location and reset - Bock-c vaid?) The designer decides that the Operator can directy sense that a train is in its bock simpy by seeing the train pass by the station. The second access question is simiar to one that surfaced with Engineers: an Operator woud have to see into the adjacent bock (to see a train eaving the Operators bock) in order to determine whether the bock it contros is, in fact, empty. Again, this is not practica given the ength of bocks. The soution adopted here is to repace the not-arc between reset - Bock-c and Location by the appication of an operator from the cass we ca report/note. The resut is shown in Fig. 10. With the guidance of the designer, a report/note operator spices in an agent that monitors a state, and reports when the enabing condition is true, in this case that no train is in the preceding bock. The recipient consumes ( notes ) the report when it acts on it. In Fig. 10, the recipient is the adjacent Operator, and she uses the report to reset the signa for her bock. As with set/reset, the designer merges the functions of the reporting agent A3 with those of the operator (merged from A and A2). In addition to monitoring their own bocks, operators now wi monitor the bocks from which trains arrive. When a train enters a bock, that bock s Operator wi notify the previous Operator that her bock is now cear. The previous Operator wi receive the report and reset her signa. There are a number of remaining issues in state D6, generated by the appication of set/reset and report/note. Can we certify that oss of contro and uncontroed actions (not shown in Fig. 10) can be ignored? Can we hande the race conditions between movement and setting/reporting? Can we contro report - Bock so that it does not produce redundant

10 FICKAS AND HELM: KNOWLEDGE REPRESENTATION AND REASONING 479 reports? Shoud we change the arc between report - Bock and Location from a not-arc to a positive arc to better refect the McGean protoco? More design effort is needed to address these probems if we are to accuratey reproduce the McGean design. However, no new Critter components are highighted, so we wi omit the remaining design steps necessary to compete deveopment of the safety constraint. Before eaving our deveopment of the safety constraint, we note that we have highighted OPIE as the too to check for vioations of this constraint. However, the NPN simuator too is aso avaiabe, and at times may be more effective. The NPN simuator aows the designer to guide its anaysis. Interactive anaysis can often quicky expose fauts which woud take OPIE much onger to discover, abeit automaticay. However, the NPN simuator requires that we have a ibrary of test cases for the train domain. The designer must hep adapt these test cases to the current design and then guide the simuation. These issues are discussed in more detai in [ Liveness We summarize the remainder of the McGean deveopment, which is guided by vioations of the iveness constraint. This section briefy indicates how such vioations can be discovered. It aso iustrates the precarious baance between safety and iveness in composite system design probems. In genera, modern transportation designs trade off these two casses of constraints in compex ways that we do not address in the McGean design [37]. In the McGean design, the anayst uses the reachabiity anaysis eaf-checker (RG) to disprove the iveness constraint. The RG too, unike OPIE, can generate an infinite counterexampe in which C never becomes true, disproving a constraint that C eventuay is satisfied. However, the RG too generates what is effectivey an exhaustive reachabiity graph for the system, whereas OPIE generates seected behaviors guided by goas. The RG too aso operates on a smaer subset of the NPN anguage than OPIE. We can see one way in which iveness can fai by ooking back at Fig. 9, in which Engineers were assigned contro of trains after being started by Dispatchers. This hand-off error may ead to a scenario in which a train starts, but no Engineer is ever assigned to contro it, thus preventing the train from moving to its destination. In essence, designing to meet the safety constraint has introduced a probem with iveness. The designer coud address this probem in a number of ways. She coud patch the appication of Brinkmanship so that Engineers are assigned to trains before the trains start; this woud ead to a harbor piot form of contro in which two agents (a Dispatcher and an Engineer) are responsibe for a vehice to a certain point, at which point a singe agent takes over. Instead, the designer keeps the current division of abor, which more cosey resembes vaet parking ; one agent passes the vehice to another. Whie there are interesting detais of how the fina McGean design fas out of this, at a high eve it is more of the same: Engineer agents are made responsibe for controing their actions so that the train progresses. In particuar, no new Fig. 11 MOTLS r----- Fig. 12. System state DG (excerpt)-insertion of report/note _ MTS ( MOTIS messaging system and P protoco. inter-agent protocos are added to the system. This assumes that we can reaisticay certify away oss of contro as we did in a design subsequent to this state. If any of these assumptions change, e.g., if we remove c2 in Fig. 8, not ony might safety constraints be in jeopardy, but iveness constraints as we; ony controed trains can move in the McGean design. V. APPLYING THE CRI~ER MODEL: THE MOTIS DESIGN To suggest the generaity of our design mode, we next summarize a different rationa reconstruction. The particuar exampe we wi discuss is the design of the fow contro of the MOTIS P e-mai transfer system discussed in [44]. The MOTIS mode is shown in Fig. 12. The P fow contro protoco, depicted in Fig. 13, transfers mai messages over a communication ink between message transfer agents at different sites on a network. The protoco transfers messages one at a time. As in the McGean exampe, the fow contro aspects of this protoco must satisfy a iveness constraint (get messages to their destination) and a safety constraint (do not send a message unti the previous one has arrived). We can reproduce P fow contro using composite system operators. We summarize the steps beow, using (reusing) the McGean design as a foundation. 1) The designer assigns the safety constraint to a message transfer agent at each site. In contrast to the McGean design, the agent responsibe for safety in MOTIS/P does not foow a message through the system, but is instead associated with a fixed ocation in the network. This is anaogous to doing away with engineers, and having station operators drive trains that are in their bocks. 2) The designer appies the brinkmanship operator to unfod the safety constraint onto each nodes send operator. The resut, as in the McGean design, is that the message transfer agent that sends a message is required