A Systems Engineering Approach to Information Architecture Design

Copyright © IFAC Integrated Systems Engineering. Baden-Baden. Germany. 1994

A SYSTEMS ENGINEERING APPROACH TO INFORMA TION ARCHITECTURE DESIGN A H. LEVIS and D. M. PERDU Dept. of Systems Engineering. George Mason University. Fairfax. VA 22030. USA

Abstract. Structured analysis and object oriented approaches to information system requirements analysis and design are discussed. It is argued that the design of an information architecture is an essential step in an uncertain environment, when the rates of external and internal change and the rate of technological change are high. Executable models based on Colored Petri Nets enhance the object oriented approach for use in systems engineering. Key Words: Structured analysis; Object oriented design, Petri Nets

The structured analysis approach is a mature methodology. supported by many computer aided systems engineering and software systems enginering tools . One of the problems is that none of them have a rigorous analytical foundation or can be used for all stages of the analysis, design, and evaluation process. For example, IDEFO is not executable and does not deal with the asynchronous and concurrent behavior of system components . However, its main advantage is that it is well focused and leads to a specific design. This is very useful and practical when the requirements are well understood and when the development cycle is relatively short or when only mature technologies are used. Unfortunately, this is not the case for information systems where requirements evolve rapidly as does technology. The incorporation of new technologies that provide alternative options in terms of task allocation, and the sharing of information or the modification of any generic model , requires restating and resolving the problem.

I. INTRODUCTION Developments in three different areas are providing the systems engineer with tools and techniques for the design of complex information systems. These areas are systems engineering, software systems engineering, and the mathematical theory of discrete event dynamical systems. The particular application that brings all together is the design and analysis of information system architectures. For the purposes of this paper, the problem can be partitioned into three stages : requirements generation, design to meet these requirements. and performance evaluation . Only the first two are considered. The requirements analysis and design processes have two main variants. The first one, well established in systems engineering practice, is structured analysis, where the emphasis is on system functionality. One of the first steps in structured analysis is a functional decomposition which is essentially a partition process. Functions are divided into sub-functions and the process continues until a sufficient level of detail is obtained. The use of IDEFO or similar techniques converts the functional decomposition into a diagram that shows relationships between functions . Four kinds of binary relationships are included: directed arcs that represent inputs, outputs, controls. and mechanisms or resources. It is then possible, using a sequence of formal steps to go from the IDEFO model to a Colored Petri Net model that is executable. The success of the conversion depends on the quality and detail of the data included in the IDEFO dictionary or glossary (a data base with the annotations of the IDEFO diagram and with activation rules).

The problem in the structured analysis approach is that the information system design is not evolutionary . Given that there is substantial investment in the existing infrastructure, it has become essential to consider approaches that allow for the graceful evolution of existing systems . Designs should be adaptable and be able to incorporate new technologies easily . Furthermore, radical changes in the scope of communications, from fiber optic networks to the proposed global satellite communications, the evolution of multinational corporations that market products produced by the integration of components manufactired in facilities across many national boundaries, and the increasing inter-relationaship of

131

financial markets, serve as examples the need for evolutianary designs of information architectures.

In section 2 of this paper. the structured analysis approach to the design of information architectures is described . In section 3, some of the issues in information architectures are described and a set of definitions is presented . In section 4, the object oriented approach is described. while in section 5 the illustrative application is described . Concluding comments are presented in section 6.

Designs are required that are readily adaptable, can incorporate easily , and at low cost, new technologies, can do so in a graceful way that does not limit functionality, and include reusable components in their software architecture. The methodology that is emerging to meet these goals is drawn from - or represents a generalization of - the object oriented analysis and design approach used in software systems engineering. Indeed, it has turned out that the object oriented approach can have a rigorous instantiation in the context of Colored Petri Nets . Furthermore, the structured analysis approach may be seen as a special case of the object oriented approach in which the objects are restricted to represent functions and where the hierarchical structure is restricted to aggregation.

2. ANAL YllCAL SYSTEMS ENGINEERING USING STRUCTURED ANALYSIS The approach most commonly used to design information architectures is shown on Figure I.

In object oriented analysis, classes are defined and an object is an instance of a class. An object is a complete entity: it has attributes. behavior. semantics, and defined relationships to other objects. In the object oriented paradigm, concepts such as abstractions, encapsulation, modularity and hierarchy are well defined. In particular, a hierarchy represents an ordering or ranking of abstractions. This ordering can be based on inheritance (simple or multiple) which allows for specialization/generalization, or aggregation which allows for decompositions.

Figure I Modeling Approach for Information Architecture Design

The difficulty with the object oriented approach as a systems engineering methodology comes in the handling of dynamics. While event traces represent specific sequences of events (a specific trajectory in engineering terminology) and state diagrams represent transitions between states, there is no equivalent to the dynamic model description of the system which allows for analytical as well as computational investigation of the properties of the modeled system. At best, simulation is used to understand behavior.

The first step is to generate the Operational Concept diat will drive the design. The Operational Concept specifies what the system is supposed to do, the type of tasks it will carry out, the missions it will execute and how it will do them . An Operational Concept corresponds to the most abstract articulation of the requirements. There is no systematic way to generate operational concepts. they are invented by humans. The second step of the approach is to perform a Functional Decomposition. Functions necessary for the execution of the tasks defined in the Operational Concept are identified and further decomposed into subfunctions that need to be performed for the execution of the function. This decomposition process can then be applied further to the subfunctions. The result of this process is a tree structure: each node represents a function and the children nodes represent the subfunctions necessary to execute the function . From this hierarchical functional decomposition, the Functional Architecture is derived by specifying the data exchanged between functions that have a common parent in the functional decomposition tree.

It is shown in this paper that this current limitation of the object oriented approach can be relaxed by using the mathematical model of Colored Petri Nets and the currently commercially available supporting software. An executable model of the information architecture can be obtained that can then be analyzed using both Petri net theory and the associated algorithms (e.g., invariant analysis and occurrence graph analysis) and simulation . The specific application that is used to illustrate the approach is the Copernicus information architecture for a Naval Task Force that wants to exchange timely and accurate information between ashore facilities and the afloat assets of the fleet. This model is currently operational and has been instrumented for experimentation and analysis ; several analyses have been conducted using it. However, only the methodological aspects of the development are relevant.

At the same time as the functional architecture is constructed. the Physical Architecture is designed . The Physical Architecture is the set of physical resources that constitute the system and their connectivity . The development of the Physical

132

Architecture is driven by the Operational Concept and has to take into account the existing hardware and human resources . It indicates what is possible but it does not show how a task is to be performed. Physical components are capable of carrying out processes. The interconnection between components indicates that a flow is possible.

Doctrine

Environment Mission -----4~

The last step is the derivation of the Operational Architecture . It is obtained by mapping the functional architecture onto the physical architecture for the given operational concept. It shows the allocation of resources to functions and the order in which functions are performed . - this is a generalization of the task allocation problem (Levis et al., 1994).

Figure 3 Top Level Function "Conduct Anti Air Warfare"

The function "Conduct Anti Air Warfare (AA W)" on Figure 3 has for input "Environment" and "Mission"; the execution of this function is controlled by the use of well-established doctrine or rules of engagement as represented by the control arrow "Doctrine" . Several resources, not detailed at this level of decomposition, are available for the execution of this function as represented by mechanism arc labeled "Assets". Finally, the execution of this function results in an enemy threat being engaged as shown by the output arc "Engage_Threats". At the top level,the context diagram or A-O level, these arrows define the interface with the external world. The decomposition of this function is shown on Figure 4. The function "Conduct AA W" has been decomposed into three subfunctions "Sense", "Command", and "Act". The labels of the incoming and outgoing arcs ("Doctrine", Environment", "Mission", "Assets" and "Engage Threats") of the top le vel function are reproduced at their corresponding location on the decomposition page and connected appropriately to the different subfunctions . One can see that these labels may be refined as required by the level of details of the decomposition : "Assets" are now discriminated between "Sensors" and "Weapons" through the use of "branching"; the fusion of two or more arrows into one is called a "join" in the IDEFO grammar.

The basic elements in IDEFO are boxes and arrows. As in many other systems engineering tools, boxes represent functions and activities. The function name inscribed in the box must start with a verb. Arrows or arcs represent flow of materials, flows of information, interconnections, interfaces or feedbacks. As shown in Figure 2, 1DEFO considers four types of arcs. Input arcs are incoming on the left edge of a box, control arcs on the top edge, mechanism on the bottom edge, and output arcs are going out the right edge. The peculiarities of IDEFO reside in this grammar related to the arcs. For the modeling of functional architectures. the mechanism arcs are ignored. However in the modeling of Operational Architecture , mechanisms , obtained from the Physical Architecture, are used to show to which resources a particular function has been allocated.

Once the mission has been defined, the "Command" function defines some surveillance directives that are sent as controls to the "Sense" function . According to these directives, the "Sense" function use sensor resources (mechanism arc "Sensors") to sense the environment to construct a tactical picture which is sent to the "Command" and "Act" functions . According to the tactical situation displayed on the Tactical Picture, the "Command" function generates orders that are sent as controls to the "Act" Function. This generation of orders will depend on the doctrines and rules of engagement as modeled by the control arc labeled "Doctrine". According to these orders, the "Act" function uses weapons to engage threats and reports its status to the "Command" function . which can then adapt the engagement according to the evolving tactical picture and the status of forces .

CONTROLS

Do Function

Engage_Threats

AO

Assets

One of the most widely used method to represent functional and operational architectures is Structure Analysis and Design Technique (SADT) (Marca and McGowan, 1987) and its computer implementation, IDEFO (e.g., DesignllDEF, 1993). Initially designed for manufacturing, IDEFO has transitioned to information systems.

INPUTS

Conduct AAW

~--. . OUTPUTS

AO

MECHANISMS

Figure 2 IDEFO Basics A box is decomposed in a set of new boxes laid out diagonally on a new page. A label is associated with each box to keeps track of its position in the decomposition. When a box is decomposed, the labels of its incoming and outgoing arcs are reproduced on the new page: their connections with the new boxes need to be defined. Figure 3 and 4 show an example of decomposition.

From this description of this simple example, one can see that a function will perform differently

133

--

Doctrine

Surveillance Directives

L Environmen t

r

r----,

Sense Al

Tactical ",Picture

.

~

~

Mission

,.-I

Command

~

Orders

"-

A2

. T Assets

Act

~~

Report~

Sensors-

1

Engage Threats

A3l

, Weapons

Figure 4 Decomposition of the Function "Conduct AA W" according to different instances of its inputs , controls, and mechanisms. IDEFO allow the definition of activation rules associated with functions at the lowest level of decomposition that allows to specify conditions on inputs, controls, mechanism s and outputs for the function to be activated.

allow to perform the tasks it is supposed to do in the desired range of performance? It will be too expensive to answer these questions a posteriori, once the system is developed and implemented. The design needs to be validated before implementation . The IDEFO model can of course be checked by inspection through the identification of key threads. Key threads are single lines connecting an input to an output with the functions in-between that participate in the generation of the output from the input. The sequence of functions of a key thread is called functionality . Theoretically, the analysis of the key threads allows to see whether the system will exhibit the desired functionalities . Practically, the problem is that models are often very large and result in too many key threads that can not be reviewed manually in an effective manner.

The modeling approach so far has focused on functional requirements . Another critical aspect is the definition and integration of performance requirements. Examples of such requirements are maximum delay to perform a function , rates of execution, size of messages being exchanged, ... The IDEFO software has a relational database engine, called a data dictionary, which allows to link a record to every graphical element of the model. All the performance requirements can be stored in this database as well as any other relevant information .

Information System s are dynamic in nature. Events occur that trigger the execution of functions and many functions can be executed concurrently . Therefore, an accurate representation of a system should be dynamic . IDEFO models are static models: they contain a lot of information needed for the development of the system , but they are not executable . There exist some graphical modeling approaches that allow a dynamic representation of a system . Colored Petri Nets and Behavior Diagrams are examples of such approaches. The problem is that they are more complex and can not be easily understood by the user. The solution is therefore to derive from the static representation a dynamic representation of the system . A methodology has been developed to convert 1DEFO diagrams into Colored Petri Nets. The basics of this methodology are the following . Each IDEFO box is converted into a transition ; each IDEFO arrow connecting two boxes are replaced by a set arc-place-arc and the label

One can see that this top-down approach, from the general to the detailed , allows for a progressive requirements elicitation. As the model is constructed , the user and the system engineer discover together the detailed functional and performance requirements of the system . The SADT methodology provides some ways to structure and order this complex requirements elicitation/discovery process . The obtained model is a documented representation of the system that is a translation of the requirements. This model is easil y understandable by the user. While changes in the arcs are easy, changes in the number and definition of activity boxes is not because they require revision of the functional decomposition. The problem of this approach is that the requirements focus essentially on the different components of the system. How to make sure that these well-defined components, when put together, will result in a system that exhibit the desired hehavior and

134

of the IDEFO arrow hecomes the color set associated with the place. All these derived names of color sets are gathered in the Global Declaration Node . From this point, an important modeling effort is required to make the Colored Petri Net model a dynamic representation of the system. The use of the information contained in the IDEFO data dictionary allows the engineer to define the different instances of the data exchanged hetween functions and to write the appropriate arc expression to apply the activation rules defined for each hox . Figure 5 shows the Colored Petri Net representation converted from the IDEFO representation of Figure 4. One can see that this model contains much more information than the IDEFO representation. Data exchanged between functions are more detailed . For example, surveillance directives are now differentiated between initial directives (InitDir), War Directives (WarDir) and Crisis Directives (CrisisDir) . The Arc Expression implements the activation rules associated with each function . Initial conditions have been specified : for example, the "Command" function needs to know the initial status of the forces before issuing any order: the initial marking of the place of color set "Report" is 'TInitStatus" ; without this initial marking, the transition "Command" does not fire .

measures of performance of the system. Performance requirements need to be included in the executable model , by associating delays with transitions for example, and realistic scenarios of inputs, consistent with the Operational Concept, need to be defined . The functional and performance requirements are validated, if the results obtained from the simulations show that the Measures of Performance of the system are within the required range . If not. the model has to be modified to address the issues that account for the encountered problems. Since Colored Petri Nets are not very easily understandable by the users, all the information gathered in the design and exploitation of the executable model need to be brought back into the static IDEFO representation , This annotated and validated representation constitutes a sound basis for the detailed specifications of the system from which it will be developed. The process just described is a sequential one that follows closely the waterfall model of software systems development. 3. INFORMATION ARCHITECTURES The traditional acquisition model. i.e., the process by which large scale systems are acquired. consists of the determination of requirements. evaluation of alternative options, selection of particular technological solutions. and system development. (Piotrowski et al.. 1994) This is shown schematically in Figure 6.

The process of deriving an executable model allows the refinement of the requirements to a greater level of detail. The executable model can be simulated in a first step to check the logical consistency of the model , that is to check whether the functions are executed in the appropriate sequence and that the diita needed by each function are appropriately provided. In a second step, the model can be used to derive

rCrisjs t rWar

D

The model for system development has changed to reflect uncertainty in requirements, changes in

trine

Surveillance_Directives

=

if d Crisis then 1' CrisisDir else 1' WarDir 1' d

=

if d Crisis then 1' Monitor else l ' Attack 1' m

1' lnitStatus

=

if sd InitDir then 1'initTP else TPupd

1'CurStatus Assets

1' Sensors

rWeapons 2' Sensorst2' Weapons

Figure 5 Colored Petri Net Model of the function "Conduct AA W"

135

if ordr = Monitor then 1' Deploy else 1' Fire

investment and acquisition philosophy, and the high rate of technological change . There are several models that attempt to capture the new paradigm: evolutionary acquisition ; build-a-little, test-a-little, field-a-little ; spiral development ; and others.

development from the beginning every time such a change occurs (Figure 9).

DESIGN

OPTIONS

Figure 6 Traditional process A particularly relevant approach to information system development and acquisition is the Technology Readiness Program in which a number of solutions are developed over time with some being shelved after a prototype is built, available as a starting point for future development and acquisition . This can be depicted schematically as shown in Figure 7.

Figure 9 Unacceptable approach to change What is needed is an approach that allows for the graceful migration from one option to another, in a rapid and low cost manner. One way of accomplishing this is to look for the things that do not change across the options, or that change in well understood ways. It is argued here that the Domain Information Architecture is the right invariant for information system design . This domain architecture may actually evolve slowly to incorporate corrections and omissions or to reflect new understandings. But what is a domain information architecture?

Figure 7 The new acquisition model First, an information architecture may be seen as repository of information about a system - it contains a data dictionary, depicts data and control flows, and describes system behavior. An information architecture (lA) consists of components (computer programs, data ensembles, hardware elements, human elements), connections (interrelatioships between pairs of components), and constraints (governing principles and shared assumptions across the architecture). (Druffel et al .• 1994). An information architecture - by definition since it represents a system - has a boundary and differentiates between internal and external flows . Furthermore, an lA can be shown at different levels of abstraction, which is not the same as different levels of detail. This is illustrated in Figure 10 where the same number of objects is used in all three levels.

The black nodes denote solution that have been prototyped and can lead to fielded designs; grey nodes reflect technical solutions that do not lead, for some reason or another, to acceptable designs, but are starting points for evolved designs. This process of inserting new technology and developing new solutions is a continuous one; at any given point in time, a solution is selected that meets the current requirements and is implemented. This is shown notionally in Figure 8.

The most abstract level of the information architecture is the Domain lA. A domain defines what information is to be used, by what applications, and by which users. It establishes the universe within which a certain level of interoperability is desired. Typical domains can be discrete part flexible manufacturing. payroll systems, health services delivery systems, personnel systems, financial systems, defense systems . The domain lA does not include in it an operational concept, a description of how the tasks are to be performed. The inclusion of an operational concept reduces the level of abstraction and leads to the Concept of Operations (or ConOps) lA. For example, while different banks

BUILD

AND RELD

Figure 8 Selection of option for implementation The real challenge arises when there is need to migrate from one option to another because of changes in the external environment, because of the commercial availability of a new technology, or because of a change in the structure of the organization (e .g ., through a merger or an acquisition) . What is unacceptable is to start the

136

Tom

Ranch

Red Apple

SPECIFIC USE DESCRIPTION

USE DESCRIPTION

GENERIC DESCRIPTION

Figure 10 Example of different levels of abstraction 4. OBJECT ORIENTED MODELING

may have the same domain lA. they may have different Conops IAs to reflect differences In corporate culture and operational philosophies.

There is extensive literature in Object Oriented Programming; more recently. the literature has began to address problems in Object Oriented Analysis and Design. as applied to software systems engineering. (Booch. 1994; Rumbaugh et aI., 1991; Berard. 1993). Even more recently. Sage (1993) reviewed the basic concepts of object oriented design and fonnulated a methodology for the design of decision support systems. There are several major ongoing efforts by industry to extend the software systems engineering constructs to a full scale systems engineering approach. particularly of software intensive systems. but they have not been documented yet in the open literaure.

When the generic entities or objects in a ConOps lA are associated with system components - generic ones - then an instantiated lA is obtained. It should be clear that there can be many instantiated IAs for the same ConOps lA. while there will be only few ConOps IAs for the same domain lA (Figure 11) ABSTRACT' GENERIC

t

,r-D9M--AI-N-IA-"

I ryw'W

I••

COWlfS

I CONOPSIA

CONCRETEf , . . . - - - - - - - - - - - - - , INSTANTIATED lA SPECIFIC

The fundamental notion in object oriented design is that of an object: an object is an abstraction of the real world that captures a set of variables which correspond to actual real world behavior (Sage. 1993). An object is a complete entity; it has attributes. behavior. semantics. and relationships to other objects. The boundary of the object is clearly defined. This boundary separates or hides the inner workings of the object from other objects . Interactions between objects occur only at the boundary through the clearly stated relationships with the other objects. The selection of objects is domain specific . In organization design. candidates for objects are decision makers (DMs). communication systems. data bases. workstations. etc.

TIME

Figure 1I Evolving lnfonnation Atchitectures Thus. a particular solution is a design based on an instantiated lA. When there is need to move to another design. much is preserved. because all instantiated IAs share the same domain lA and often the same Concept of Operations. but different resources. This leads to reuse of software components; it places emhasis on system integration rather than doing unique designs . The system engineering paradigm that is well suited for such an approach. i.e .• for the use of infonnation architectures in systems design. is object oriented analysis and design . The basic elements of the approach. from the point of view of systems engineering. are described in the next section .

A class is a template. description. or pattern for a group of very similar objects. namely. objects that have similar attributes. common behavior. common semantics. and common relationship to other

137

objects. In that sense, an object is an instance of a class. For example, "air traffic controller" is an object class ; the specific individual that controls air traffic during a particular shift at an ATC center is an object - an instantiation of the abstraction "air traffic controller" . The concept of object class is particularly relevant in the design of organizations, where specific organizational positions are defined , but a wide variety of individuals may serve in those positions over a period of time. Indeed. one of the requirements of organizations such as the retail operations of a bank is that they be robust with respect to individual differences.

The "line " organizations of the military are constructed in this way : the individual infantry man, a squad, a platoon , a company. a battalion. a regiment. a division. etc . This is a useful construct. even though it tends to oversimplify the organizational structure. As one moves up the hierarchy, the organizational units need to add components or sections that provide services across the organization (staff functions). The concept of aggregation provides the means of incorporating functional decompositions from structured analysis in the object oriented construct. The second concept, inheritance, has some interesting implications for organization design . Inheritance is the means by which an object acquires characteristics (attributes, behaviors, semantics, and relationships) from one or more other objects. (Berard, 1993) In single inheritance, an object inherits characteristics from only one other object; in multiple inheritance. from more than one object. Inheritance is a way of representing generalization and specialization. The "navigator" in an air crew inherits all the attributes of the "air crew member" object class, but has additional attributes that specialize the object class. The "pilot" and the "copilot" are different siblings of the air crew object class. The inheritance concept has not been explored fully in system design where specialization has been thought more in tenns of functional decompositions which are partitions of a function.

Encapsulation is the process of separating the external aspects of an object from the internal ones; in engineering tenns, this is defining the boundary and the interactions that cross the boundary - the old black-box paradigm. This is a very natural concept in organization design; it allows the separation of the internal cognitive processes of a decision maker from the interactions with other decision makers, either directly or through communication systems. Modularity is another key concept in object oriented design that has a direct, intuitive meaning in organization design. Modularity, according to Booch (1994) is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. Consider, for example, the corporate staff, the line organization, ' and the marketing organization of a company. Each module consists of objects and their interactions ; the assumption here is that the objects within a module have a higher level of interaction than there is across the modules.

There are additional concepts in object oriented design, such as polymorphism, persistence, reuse, message passing, and dynamic binding. These refer more to the software implementation aspects; they are not used explicitly in the example that follows, except perhaps reuse.

It is fairly clear that encapsulation, modularity, and object class are closely related concepts . Encapsulation is the process by which the boundary characterizing an object class is defined; the nature of the object classes leads to the identification of modules. This process can be top down (Zaidi and Levis, 1994) as well as bottom up (Remy and Levis, 1988).

The object modeling technique of Rambaugh et al. (1991) requires three views of the system: the object view, the functional view, and the dynamic view. The object view is represented by the object model that describes the structure of the system - it is a static description of the objects; it shows the various object classes and their hierarchical relationships. The functional view is represented in tenns of data flow diagrams that depict the dependencies between input data and computed values in the system. The dynamic view is represented in tenns of state diagrams. It shows the sequence of events that occur. All three views, which are interrelated, are needed to describe the system. As mentioned in section I, this representation. while adequate for object oriented software system design. is not sufficient for systems engineering. The executable model is needed to bring them all together and to provide a means for system perfonnance evaluation. This extended construct is shown in Figure 12. Note in the Figure the feedback loop and the need to compare predicted system behavior with the requirements. This is a two way process that may lead to some changes in requirements by the user.

The concept of hierarchy has its roots in organization theory. The meaning of the tenn itself refers to the rule of the high priest in ancient Greece and the tree-like organizational structure of the lesser priests below him . In the context of object oriented design, hierarchy refers to the ranking or ordering of abstractions, with the more general one at the top and the more specific one at the bottom . An ordering is induced by a relation and the ordering can be strict or partial. In the object oriented paradigm, two types of relations are recognized : aggregation and inheritance. Aggregation refers to the ability to create objects composed of other objects with each a part of the aggregate object. This concept is well known and understood in organization design and has been exploited as the means to design large organizations.

138

........... ...............

'.

OBJECT VIEW

:- ................... ...... :.

.: FUNCTlONA .:: VIEW BEHAVIORS

E X E C U

BEHAVIORS

T A B L .' DATA .: DICTIONARY :~:

E

........ ..................

Figure 12 Object Modeling Technique for Systems Engineering The main objective of the Copernicus Architecture is to provide to the commanders on a Battle Group at sea information that originates from a wide variety of sources and that can be useful for the execution of their missions. Every item of information available ashore can not be sent automatically (pushed) to the commanders afloat A phenomenon called Information Explosion would occur: the commanders would receive a very large amount of data that would be rarely relevant to their missions and that they would not have time or willingness to sort. A fundamental concept in the Copernicus Architecture is Information Pull. Instead of pushing afloat every piece of information, some information is provided only at the request of the commanders afloat (or their staff). A commander generates a query and sends it to an Anchor Desk ashore which has access to a wide variety of data; the Anchor desk formulates the response to the query and transmits it back to the commander. An alternate mode of Information Pull is Enhanced Pull where, in addition to the response to the query, the Anchor Desk takes advantage of the established communications path to send additional information that may be useful to the commanders afloat.

5. THE COPERNICUS ARCHITECURE The Copernicus Architecture is an information system currently being developed by the US Navy. It consists of four pillars, as shown in Figure 13: 1)

2)

3)

4)

The Global Information Exchange Systems (GLOBIXS) that are virtual wide area computer networks linking the commands and activities ashore that support the forces afloat; The Commander in Chief Command Complex (CCC), which is a virtual command center connected by a wide area network providing a means to manage information flow for the tactical commander afloat. This management of information flow is performed by Anchor Desks; The Tactical Data Information Exchange Systems (TADIXS) which are information networks establishing the connectivity between afloat and ashore centers. These networks share communications circuitry over a wide variety of bearer services; The Tactical Command Center (TCC) which is the nerve center of the afloat unit and is modeled on the Navy Tactical Command System Afloat (NTCS-A) architecture.

A model of the Copemicus Architecture using

DCSIFTS200 Network.

GLOBIXS

TADIXS

CCC

Figure 13 The Four Pillars of the Copemicus Architecture

139

TCC

Hierarchical Colored Petri Nets was developed to validate the concept of Enhanced Pull. As showrt below, Hierarchical Colored Petri Nets allow the use of an object oriented approach for the design . Hierarchical Colored Petri Nets are an extension of Colored Petri Nets to help deal with large scale systems. The basic idea is that a set of transitions and their interconnecting places can be replaced by a substitution transition, which then refers to a subpage containing the subnet. All the places connected to a substitution transition are called socket nodes and are reproduced in the page decomposition where they are called port nodes. A socket node is logically identical to the port nodes: the marking of a socket node is equal to the marking of the corresponding port node(s). This substitution process preserves the logical consistency and the dynamic behavior of the system model. An interesting feature of Hierarchical Colored Petri Nets is that different substitution transitions can refer to the same subnet. Each of these substitution transitions corresponds to a different instance of the subnet that behaves independently of the other instances. The development of a Hierarchical Colored Petri Net model can then be done through the development of independent and reusable modules arranged in a hierarchical structure which looks like a lattice. Any change in a subpage affects all its instances, but does not affect the rest of the model. One can see that many features of Object Oriented design are imbedded in this modeling approach: model pages correspond to classes, instances of a model page correspond to objects of the class.

Figure 14 Model Structure sents the class structure of the object model. The type of hierarchy shown here is aggregation : classes are composed of other classes which are part of the aggregate class. In the top-level node that represents the Copernicus Architecture, substitution transitions representing the different elements of the system refer to different pages. A model page has been developed for the TCe, the CCC, the external sources, the communications networks, and the organic and non-organic sensors. From the "Copernicus" page, two substitution transitions representing the T ADIXS and the GLOBIXS refer to the same model page called "Comms" and indicate that two objects of the class "Comms" have been created. In the same way, from the "ccc" page, substitution transitions modeling the different Anchor Desks refer to the same model page called "Anchor" in which the activities performed by an Anchor Desk are fully modeled. Finally, in the model page of the TeC, substitution transitions represent the different commanders afloat and refer to a single page called "Commander" that models generically the activities performed by a commander. To each Anchor Desk present in the CCC corresponds an object of the class "Anchor" represented by an instance of the model page "Anchor", and to each commander in the TCC corresponds an object of the class "Commander" represented by an instance of the model page "Commander" .

The model was constructed by considering each pillar of the Copernicus as an object and decomposing each object into more detailed objects until the desired level of details was obtained. The resulting hierarchical structure of the Copernicus Architecture model is given in Figure 14, where each node corresponds to the different pages of the model. This figure repre

5. I Top-Level Model The top-level page of the Copernicus model is dis

Messsge

Message

Message

Message

Figure 15 Top-Level Model

140

played in Figure J5. It shows the different interfaces between the page models at the lower level. that is the exchange of messages between the different objects at this level of aggregation. As indicated by the substitution transitions. the aggregate object "Copemicus" is composed of one object of the class "EXTERNAL SOURCES". one object of the class "CCC". one object of the class "TCe". one object of the class "Non-Organic Sensors" , one object of the class "Organic Sensors" and two independent objects of the class "Comms" that represent the TADIXS and the GLOBIXS . The substitution transition "organic sensors" provides sensor updates to the TCe. The TCC can have access to the T ADIXS through the places with color set "Message" . The CCC is the central point of the model. It can communicate with the TCC through the T ADIXS and with the external sources through the GLOBIXS . FinalIy, gateways allow the TCC and the External Sources to communicate directly, bypassing the CCe. This indicates that the object "Copernicus" has its own internal methods not shared with the other objects.

The model page of the TCC is displayed on Figure 16 and is instantiated only once. The place with color set "Grid" represents the tactical grid, the data base which contains the information shared by the commanders afloat. Organic data are updated by the firing of the transition "Organic Sensing" . Nonorganic data on the tactical grid can be updated either automaticalIy with updates pushed from ashore (transition "Automatic Push") or through the intervention of a commander (see description of the Commander model that follows) . The model of the TCC offers eight slots for commanders which are represented by eight substitution transitions referring to eight instances of the model page called "Commanders" described in the next section. 5. 4 Model of the Commander The model of the Commander, along with the model of the Anchor Desk, displays the key aspect of representing the modes of information pull. The generic model for the activities performed by a commander is displayed in Figure 17. This page model is instantiated eight times to represent the Figure 16 Model of the TCC

5.2 Model of the TeC

Grid

Figure 16 Model of the TCC

141

Actor

IBJACT askquery

IBJ Tl'

Into

In/odsl

Figure 17 Model of the Commander Afloat particularities of each commander. It models only the activities needed to handle infonnation and does not address any operational activities. These activities are encapsulated from the other objects of the model and each object of the class "Commander" behaves independently of the others.

(if non-outdated infonnation IS In it), or as a response to a query that he sends to the C2W Anchor. Forty (40) is the usable life span of the shore C2W data from the time of its creation. Note that Design/CPN, the Colored Petri Net Editor and Simulator, does not allow to access the different instances of a page model in its editor state. The marking of the appropriate places in each instance has to be done manually just after entering the simulator state when the instances have been created. However, this cumbersome process of entering data and parameters can be automated by creating additional socket places for the substitution transitions representing the different objects. In the "TCC" model page, one could add two socket places of color set "Actor" and "askquery" to each substitution transitions and declare in the model page "Commander" the places of color set "Actor" and "askquery" as port places. Attributes specific to each object commander can then be specified in the model page "TCe" through the initial markings of the input socket places with color set "Actor" and "askquery" of the different substitution transitions corresponding to the different "Commanders" . When entering the simulator, the initial marking of the corresponding places in each instances of the model page "Commander" is automatically filled. Doing so does not lead to a rigorous Object Oriented representation since infonnation that should have been encapsulated in the object representation of each commander is not hidden from the rest of the model

The setting of the attributes of each object "Commander" is done by specifying the initial marking of specific places in each instance of the model page "Commander" : the identity of the commander is specified by the marking of the fusion place of col or set "Actor" , and the data manipulated by the commander are specified by the marking of the place of color set "askquery" which is the input place of the transition "init TP" . Each token in this last place specifies the type of data handled by the commander, the life span of this type of data and the rate for asking information ashore . For example, for the Command and Control Warfare Commander (C2WC), the initial marking of the place "askquery" IS :

1'("C2W",0,0) + 1' ("shC2W",40,12) + 1'("CSO",40,15) meaning that the C2WC deals with the organic data C2W and with the non-organic data shore_C2W and CSO. 0 in r("C2W",0,0) means that he will get every update for the C2W data , 12 in 1' ("shC2W",40,12) means that every 12 units of time he needs infonnation about shore C2W. He can get this infonnation either from the local data base

142

but, as long as no transition can put tokens in these socket places, the properties of modularity and abstraction are preserved.

When a commander receives infonnation from ashore, the transition "receive info" fires. The tactical picture of the commander is updated and put on the tactical grid if the infonnation provided is complete. The latter is done by firing the transition "update grid."

Each Commander has a local tactical picture represented by the place named ''Tact Pict" which is a part of every process represented in this page model. At the beginning of the simulation, the tactical picture is initialized when the transition "Init TP" fires, putting in the place "Tact Pict" tokens of the color set "Info" that represents the initial values of the data displayed on the tactical picture. The transition "Init TP" also puts in the place with col or set "askquery" the tokens defining, for each type of nonorganic data the Commander is interested in, the rate for the need of infonnation and the life span of this data.

When a commander has a specific problem that can be solved by another commander, the transition "initiate problem solving" is enabled by putting a token in its input place with color set "DataType". The place with color set "Directory" indicates which commander is the most qualified to solve the problem. When the transition fires, a local message addressed to the commander is fonnatted and put on the tactical grid. The addressee receives the message when the appropriate instance of the page "Receive loc msg" fires. This message is first analyzed (transition "analyze msg") by checking whether any infonnation related to the problem is present in the local data base. If not, a query is formatted (transition "fonnat query" and sent to the appropriate Anchor Desk as specified by the place with color set "Directory." A response to this type of query is received in the same way as the other responses. In addition, a local message is sent to the commander who initiated the problem solving (transition "send loc message").

Each time an update to a type of data relevant to the activity of the Commander appears on the tactical grid, the tactical picture is updated by firing the transition "update tact. pict". The guard function of this transition specifies that this update may occur, if the data present on the tactical grid is more recent than the one contained in the tactical picture. The expression associated with the arc connecting this transition to the place representing the tactical picture ensures that it contains the five most recent updates of each type of data handled by the commander.

The same modeling approach was used to model the CCC ashore and the Anchor Desks residing in the CCC and is not described in this paper. This model was instrumented and simulated to assess the effectiveness of enhanced pull. A full description of the model and of the results obtained from its simulations can be found in Perdu et a/. (1994).

Queries to the CCC are generated when the transition named "fonnat query" fires. This transition is enabled when a timed token in the place "askquery" is available indicating that the Commander has need for infonnation from ashore. The expression on the arc connecting this transition to the output port place "msg to transmit" implements the mechanism for generating a query: a query is generated if the infonnation on the tactical picture is incomplete, or if it is complete and outdated. This arc expression fonnats the query message, indicating to whom the query is addressed (obtained from the place with color set "Directory" which defines where to address a query regarding a type of data), who is generating the query, the type of message, the type of data this query requests, and the time of generation.

5.5 Remarks on CPN One can see from this partial description of the Copernicus model that Colored Petri Nets allow to conduct an object-oriented design of the system that leads to an executable model that can be used to derive measures of perfonnance and of effectiveness. Colored Petri nets address most of the key concepts in the object-oriented paradigm. Abstraction: Objects are differentiated by the structure of the model page to which they refer and by the data specifying the characteristics of each instance.

The commander receives messages from ashore when a token appears in the input port place with color set "message." The reception of a message is done through the firing of either the transition "reply to query" or "receive info." These transitions fire only if the first element of the transmitted message matches the actor token in the place "Actor" to ascertain that the messages are for the commander under consideration. When a commander receives a query from ashore, the transition "reply to query" fires and a response message is fonnatted, filling the content field with incomplete infonnation from the tactical picture. It takes one unit of time to fonnat this message.

Encapsulation : The property of local execution of Colored Petri Nets allows to separate the external aspects of an object from the internal ones. The interface between objects are specified by the ports of the page models. Modularity: Each instance of a page model behave independently of the other instances. Any structural change in the page model affects all its instances but does not interfere with the remaining of the model. The model of the commander described above could be replaced by another one as long as the interfaces through the ports are preserved. A library of reusable

143

model can be easily constructed. Design/CPN allows the saving of pages that can be included in other models.

Booch, G. (1994) . Object-Oriented Analysis and Design . 2nd . Ed ., The Benjamin/Cummings Publishing Co., Redwood City, CA.

Hierarchy: Colored Petri Nets allow an aggregation type of hierarchy in which pages are composed of other pages which are part of the aggregate page.

Druffel , L. , N.E. Loy , R.A . Rosenberg, T.F. Saunders, R. Sylvester, and D. Volz (1994). Information architectures that enhance operational capability in peacetime and wartime. Report SAB 94-002, AF/SB , Washington DC, January 1994

Colored Petri Nets do not address the two following concepts:

Levis, A.H., B. Hu, and N. Morey (1994). Task Allocation Models and Discrete Event Systems,". Automatica, Vol. 30, No. 2.

Inheritance: Colored Petri Net do not support an inheritance hierarchy . Methods of a higher level class can not be inherited by a class of lower level.

Marca, D.A. and C.L. McGowan (1988). SADT Structured analysis and design technique . McGrawHill, New York.

Dynamic creation and deletion of objects: the number of instances of model page is preset by the number of substitution transitions that refer to this model page. An instance can be left unused but remains in memory.

Meta Software, Corp. (1993) Design/IDEF Mac Version 3.0 Reference Manual. Cambridge, MA.

However, these two concepts are not as critical in Systems Engineering Design as they are in Software Engineering. Inheritance is used essentially for economy of coding. Dynamic creation and allocation of objects is not required for systems engineering design .

Perdu, D.M., S. L. Hearold, and A.H. Levis (1994) . Effectiveness of two modes of information pull in the Copernicus Architecture. In: The Science of Command and Control Part Ill, Coping with Change, (A.H. Levis and I.S . Levis, Eds.) AFCEA Press, Fairfax, VA (to appear).

6. CONCLUSION

Piotrowski, J .L., A .H . Levis , and R.F. Phelps (1994). Report on the role of an object oriented information architecture in NMD. BDM Federal Systems, McLean, V A.

Object oriented approaches, originally developed for software enginering applications can be extended to systems engineering, especially when the domain of application is information systems. It was argued that an executable model is needed and that model can be expressed in terms of Colored Petri nets.

Remy P. and Levis A.H. (1988). "On the Generation of Organizational Architectures Using Petri Nets." in Advances in Petri Nets 1988, G . Rozenberg, Ed. Springer-Verlag, Berlin, Germany.

While structured analysis also leads to a Colored Petri Net executable model, the approach is not well suited to the design of systems that must evolve rapidly due to uncertainties in the requirements, the environment, or the available technology . The use of the domain information architecture creates a construct that accommodates change and enhance resuse of already developed components and architectural modules.

Rumbaugh, J., Blaha, M ., Premerlani, W ., Eddy, F. , and Lorensen , W . (1991). Object-Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs, NJ. Sage, A. P. (1993). "Object Oriented Methodologies in Decision and Information Technologies, "Information and Decision Technologies. Vol. 19, No. 1, pp. 31 -54.

REFERENCES

Zaidi , S . A . K., and Levis , A . H. (1994) . "Algorithmic Design of Distributed Intelligence Systems," in Intelligent Control Systems: Theory and Practice, M. M. Gupta and N. K. Sinha, Eds., IEEE Press, New York.

Berard, E .V . (1993) .Essays on Object-Oriented Software Engineering. Prentice-Hall, Englewood Cliffs, NJ .

144