c4isr architectures: i. developing a process for c4isr architecture design

C4ISR Architectures:I. Developing a Process forC4ISR Architecture DesignAlexander H. Levis* and Lee W. Wagenhals

System Architectures Laboratory, C3I Center, MSN 4D2, George Mason University, Fairfax, VA 22030

C4ISR ARCHITECTURES. I

Received April 25, 2000; accepted July 14, 2000

ABSTRACT

The C4ISR Architecture Framework document issued by the Department of Defense specifiesthree views of an information architecture and defines a set of products that describe eachview. These architecture views are to serve as the basis for C4ISR system development andacquisition. The Framework does not provide a process for architecture design. In this paper,information architectures are described in the context of Structured Analysis, and then thearchitecture views of the Framework and the related products are interpreted in that context.A methodology for architecture design is developed that is then implemented using Struc-tured Analysis and object orientation in two companion papers. © 2000 John Wiley & Sons,Inc. Syst Eng 3: 225–247, 2000

1. INTRODUCTION

In a changing world, the Department of Defense has tocope with increased uncertainty about requirements,rapid changes in technology, changes in organizationalstructures, and a widening spectrum of missions andoperations. One way to deal with these uncertainties isto be able to rapidly mix and match organizations with

composite capabilities to suit a particular situation. Todo this requires an unprecedented level of interoperabil-ity in information systems. To achieve this flexibility,DoD has looked to information architectures that canprovide current or future descriptions of a “domain”composed of components and their interconnections,actions or activities those components perform, andrules or constraints for those activities. These architec-tures, while they will change over time, will change ata much slower rate than the actual systems they repre-sent. Because of their stability, they can act as importantguides to acquisition decisions as well as defining op-erational concepts. One domain of information systemsthat directly supports military operations is Command,Control, Communications, Computer, Intelligence,Surveillance, and Reconnaissance (C4ISR). The goal isto describe architectures using multiple views that an-

Regular Paper

*Author to whom all correspondence should be addressed.Grant sponsor: Office of Naval Research; grant number: N00014-00-1-0267.Grant sponsor: Air Force Office for Scientific Research; grant num-ber: F49620-95-0134

Systems Engineering, Vol. 3, No. 4, 2000© 2000 John Wiley & Sons, Inc.

225

swer operator’s questions regarding the operational ca-pability that systems built conformant to the architec-ture can provide. Another goal is to support theacquisition community in its efforts to acquire interop-erable system. A seamless process from knowledgeelicitation to architecture design and evaluation is de-sired.

In December 1997, the Office of the Secretary ofDefense published the C4ISR Architecture Framework,Version 2.0. [C4ISR, 1997].1 On February 23, 1998, theUnder Secretary of Defense (Acquisition and Technol-ogy), the Assistant Secretary of Defense (Command,Control, Communications, and Intelligence), and theJoint Staff Director for Command Control Communi-cations and Computers (C4) issued a memorandum thatstated:

We see the C4ISR Architecture Framework as acritical element of the strategic direction in the Depart-ment, and accordingly direct that all on-going andplanned C4ISR or related architectures be developedin accordance with Version 2.0. Existing C4ISR archi-tectures will be re-described in accordance with theFramework during appropriate revision cycles.

The Architecture Framework provides commondefinitions, data, and references, and describes a set ofproducts that comprise three views of an architecture.The Framework provides little guidance on how toproduce those products. To comply with the directive,organizations must develop their own process, andmany of them have done so. This poses a challenge forat least two reasons. First, the three architecture views(Operational, Systems, and Technical Architectureviews) and their products are new constructs that are notsupported directly by existing systems engineering for-malisms and tools. Second, while the products providea great deal of information, it is not clear that, in theabsence of a well-thought-out process, they will bemutually consistent so that they can be used to answerquestions about the capabilities that systems built inconformance with the architecture will provide.

One of the issues is that the C4ISR ArchitectureFramework, Version 2.0, makes a number of assertions(Section 1.1 of the Framework) regarding its purposethat are hard to justify in view of the community’sexperience in the last 3 years and the analysis of theconstructs that has been carried out. While the applica-tion of the Framework does enable architectures to

contribute to building interoperable and cost-effectivemilitary systems, and does have the potential for archi-tectures developed by different organizations to be in-terrelatable and possibly comparable, it is hard toimagine how they would be integratable. The Frame-work does not provide guidance regarding these latteraspects.

One of the premises of the work presented in this andthe two companion papers is that the derivation of anexecutable model of the architecture from the threeviews and the associated integrated dictionary providesa basis for understanding the interrelationships amongthe various architecture products and establishes thefoundation for implementing a process for assessingand comparing architectures. The paper does not advo-cate that the creation of an executable model be man-dated as part of the Architecture Framework. Rather, itargues that given the particular form of the Frameworkproducts and the absence of well-established processesfor developing a set of consistent and coherent products,architects may be well advised to create an executablemodel as a means analyzing the characteristics of theirarchitecture and ascertain whether behavioral require-ments are met.

This article describes the role of the architect, estab-lishes the criteria for determining the data needed in aninformation architecture to support the role of the archi-tect, examines the C4ISR Framework products, andprovides a mapping from the Structured Analysis prod-ucts to the Framework products. This mapping formsthe basis for two alternative approaches documented inthe companion papers, one based on Structured Analy-sis [Wagenhals et al., 2000] and one based on ObjectOrientation [Bienvenu, Shin, and Levis, 2000].

To address these issues, the remainder of this articleis divided into five sections. Section 2 describes thefundamentals of architectures and the role of the archi-tect. Section 3 presents a generic process for creatingan architecture of an information system that is capableof describing behavioral and performance aspects of thearchitecture to the customer. Section 4 describes theC4ISR Architecture Framework construct, including abrief description of the three architecture views andtheir products. Section 5 shows the mapping from theStructured Analysis products to the Framework prod-ucts; this mapping sets the basis for the alternativeapproaches.

2. ON ARCHITECTURES

2.1. Architects and Architectures

The concept of architectures and the business of creat-ing them have been around for millennia. Indeed, the

1The C4ISR Architecture Framework, Version 2.0, documentcan be found in a number of DoD and non-DoD websites that requiredifferent forms of access. The System Architectures Lab maintains acopy in .pdf format at Http://viking.gmu.edu/http/ c4isrmay2000/in-dex.html.

226 LEVIS AND WAGENHALS

Greek word architecton means master builder or mastermason. The term describes one who designs and buildsstructures whose form and function are both appealingand useful. Today, when we think of architectures, wethink of buildings and monuments that are the creationof named architects. The main contribution of the archi-tect is the conceptualization and design of a uniquestructure to meet the client’s needs. The architect hasthe special role of eliciting and converting the needs anddesires of the customer that commissions him into adesign that will be especially satisfying to that cus-tomer.

In a modern context, we think of hiring an architectwhen we want to create a structure that is both unprece-dented and complex, particularly if our needs are in-itially ill structured. [Rechtin, 1991, 1992] An exampleis the building of a custom house. Assuming that one isinterested in more than just a house whose plans can bedownloaded from the Internet or a “standard” houseoffered by a national or local building company, onemay decide to hire an architect to create the descriptionof the house. The architect will elicit needs and desiresfrom the customer and, using a combination of engi-neering and art, will create a series of models (drawings,scale replicas, 3D visualizations) of the house. Themodels are abstract at first and become more specific asthe customer provides feedback to the architect. Oncean architecture that is satisfactory to the customer hasbeen created, the architectural models are convertedinto a set of blueprints that are provided to a generalcontractor, who is responsible for building the house inaccordance with the blueprints that have been derivedfrom the architectural drawings. Note also that theactual construction must be compliant with the buildingcodes that apply to that type of structure in that particu-lar locality.

From this example and by analogy, it is possible toderive several characteristics of system architects andthe architectures they produce. The first is that an archi-tect is needed only if the system is unprecedented andcomplex. [Rechtin, 1991, 1992] If satisfactory workingsystems have already been built and the designs exist,there is no need for an architect. An architect is notneeded if the system is very simple and can be con-structed directly by a contractor. The architect’s respon-sibility is different from the general contractor’s. Thearchitect is driven by the special needs of the customerand tends to develop the architecture in a top-downmanner. [Rechtin, 1991, 1992] Indeed, the task of thearchitect is to elicit those needs and to produce a de-scription that can demonstrate to the customer that thesystem to be produced in conformance with the archi-tecture will satisfy the customer’s wants and needs. This

means that the architecture does not include the detailsof the final system designs.

A key issue in the above description is where thearchitect’s work in describing the architecture ends andthe system design begins. The blueprints are usuallythought as the representation of a design—the imple-mentation of an architecture, not as a description of anarchitecture. In the Framework, the architecture de-scription is referred to as a blueprint that then enters thedesign, development, and acquisition process. Theproblem of demarcation between architecture and de-sign (never an easy one to determine) is especiallydaunting in the case of C4ISR systems where any futurearchitecture will be populated in the design phase byexisting systems, the so-called legacy systems. So,while the architecture definition process is thought ofas being top-down, the presence of so many legacysystems introduces constraints in the design of thearchitecture that are best addressed in a bottom-upapproach. This particular issue is one of the drivers forthe approach presented in this paper and forms the basisfor some of the conclusions drawn.

The architect develops and presents the architectureas a set of abstract views or models. The abstractionoccurs in two dimensions, generalization and composi-tion. The architect begins with a very general descrip-tion of the system. Based on discussions with thecustomer, the architect arranges and specializes thesecomponents to suit the customer’s needs and desires.Note that the number of components in the architecture,and, thus, its complexity, do not need to increase sub-stantially in this specialization process. The number ofcomponents does increase as more detail is incorpo-rated in the architecture. Adding detail is generallyaccomplished by decomposing the basic components ofthe architecture into their constituent parts. Decompo-sition can significantly increase the number of compo-nents of the architecture and thus its complexity.Because of this, the architect should use decompositiononly as necessary to address the questions and concernsof the customer. The customer and the architect assumethat these components will work properly because theywill be constructed and installed in accordance withestablished codes and guidelines. The actual systemdesign and implementation will involve the specializa-tion of the architecture and the addition of all of thedetails of the design so that the system can be manufac-tured. This specialization process is the task of thegeneral contractor or system engineer. The actual sys-tem will be the most specialized version of the architec-ture. There can be many ways of specializing a singlearchitecture into actual systems. The selection of theactual design can be determined by cost and technologyfactors. Thus, an architecture can be a valid description

C4ISR ARCHITECTURES. I 227

of a way of satisfying a customer’s need over a longperiod, even as the specific techniques for implement-ing the architecture change.

The concepts and characteristics applicable to ar-chitecting buildings also apply to architecting informa-tion systems. One thinks of an architecture as beingimplemented by many diverse interacting systems. Thearchitect needs to be knowledgeable not only about theindividual systems, but also about the interrelationshipsamong them. Furthermore, the architect must use crea-tivity and vision because of the unprecedented andcomplex nature of the design and the lack of an initialclear definition of the needs and requirements for thesystem [Levis, 1999]. It is important that the architectbe able to show and discuss with the customer whatproperties the architecture will have. This means thatthe architectural models must be capable of providinginsight into the logical and behavioral aspects of thearchitecture and the performance aspects of systemsthat are conformant to the architecture. This importantcriterion influences the process and the techniques fordeveloping an architecture of a system.

Systems Architecting [Rechtin, 1991, 1992; Rechtinand Maier, 1996] is part of the system engineeringprocess and relies on many of the methodologies thathave been developed over time. The architect has manytools and techniques available to describe the architec-ture. Two major paradigms that are appropriate are thetraditional Structured Analysis and Design Technique(SADT) and the Object-Oriented approach that origi-nated with software systems. Both offer advantages andboth are discussed at length in this and the two compan-ion articles [Wagenhals et al., 2000; Bienvenu, Shin,and Levis, 2000]. Both approaches can fall short of therequirement of being able to convey the logical, behav-ioral, and performance properties of the architecture.This is because both approaches rely on static pictures,diagrams, and textual descriptions to define the archi-tecture. However, an architecture is instantiated withdynamic systems that interact with their environmentover time. To fully describe and understand the dynamicaspects of the system requires an executable model.

2.2. System Architecting Using StructuredAnalysis

In the basic systems engineering approach using Struc-tured Analysis, an architecture is composed of twoconstructs: the Functional Architecture (view) and thePhysical Architecture (view).2 The Technical Architec-

ture view in the Framework, while not part of theStructured Analysis approach, corresponds, in broadterms, to the building code that any architect must takeinto consideration. The technical architecture view isincluded in the discussion because of its relevance tothe DOD goal of acquiring interoperable systems. Theterm view is used to emphasize that there is a singlearchitecture of the system. The complete representationof that architecture requires different views. Theseviews can be categorized by their perspective.

In defining an architecture, several perspectives needto be described. First, since the architecture will becreated so that the systems that populate it will performsome useful function, we need to describe the processor activities that need to take place in order for thesystems to accomplish their purpose. In an informationsystem, the processes receive and transform data that“flow” between them. These processes or activitiesfollow rules that determine the conditions under whichthey occur and the type of outputs they produce. Inaddition, the processes should occur in some orderbased on the initial conditions of the system, and severalprocesses may occur concurrently and asynchronously.In addition to the processes or activities, it is necessaryto describe the components that will implement thedesign: the hardware, software, personnel, and facilitiesthat will comprise the C4ISR system and perform theprocesses.

This fundamental notion leads to the definition ofthe two basic architectural constructs in StructuredAnalysis. A Functional Architecture is a set of activitiesor functions, arranged in a specified partial order that,when activated, achieves a set of requirements. Simi-larly, a Physical Architecture is a representation of thephysical resources, expressed as nodes, that constitutethe system and their connectivity, expressed in the formof links. Both definitions should be interpreted broadlyto cover a wide range of applications; furthermore, eachmay require multiple representations or views to de-scribe all aspects.

Before even attempting to develop these repre-sentations, the operational concept must be defined.This is the first step in the architecture developmentprocess. An Operational Concept is a concise statementthat describes how the goal will be met. There are noanalytical procedures for deriving an operational con-cept for complex, unprecedented systems. On the con-trary, given a set of goals, experience, and expertise,humans invent operational concepts. It has often beenstated [Rechtin, 1991] that the development of an archi-tecture is both an art and a science. The conceptualiza-tion of an operational concept falls clearly on the artside. A good operational concept is based on a simpleidea of how the over-riding goal is to be met. For

2In the systems engineering literature, the term system archi-tecture has often been used to denote the physical architecture. Thishas been the source of much confusion because the term systemarchitecture used in the C4ISR Architecture Framework denotes adifferent construct.


example, “centralized decision making and distributedexecution” represents a very abstract operational con-cept that lends itself to many possible implementations,while an operational concept such as the “client–serv-er” one is much more limiting. As the architecturedevelopment process unfolds, it becomes necessaryto elaborate on the operational concept and make itmore specific. The clear definition and understandingof the operational concept is central to the develop-ment of compatible functional and physical architec-tures.

Analogous to the close relationship between theoperational concept and the functional architecture (tothe extent that often a graphical description of theoperational concept is improperly presented as thefunctional architecture) is the relationship between thetechnical architecture and the physical one. A TechnicalArchitecture (TA) view is a minimal set of rules govern-ing the arrangement, interaction and interdependenceof the parts or elements whose purpose is to ensure thata conformant system satisfies a specified set of require-ments [C4ISR, 1997]. It provides the framework uponwhich engineering specifications can be derived, guid-ing the implementation of the system. It can be com-pared to that part of the building code that providesguidance for the new building to be able to connect tothe existing infrastructure of its planned location bycharacterizing the attributes of that infrastructure, aswell as the exceptions to the code.

It is the Technical Architecture that provides theconnection between the abstract descriptions of Physi-cal and Functional Architecture views and the imple-mentation of the detailed system design. Whenarchitects define the Technical Architecture view, theyare providing guidance on the further specialization anddecomposition of the components of the Physical andFunctional Architecture that will be accomplished inthe detailed engineering design of the system.

All of these representations of the architecture, evenwhen they describe the dynamic behavior of the archi-tecture, are static. They are inadequate for analysis ofthe behavior and performance aspects of the architec-ture. In the next section, the details of the models usedin these representations are described. They contain agreat deal of information, but, in general, are ill-suitedto answering the main concerns of the customer. Inorder to analyze the behavior and performance of thearchitecture and address the concerns of the customer,an executable model is derived from them. After all, thesystems to be designed are dynamic systems. An ex-ecutable model is a dynamic model; it can be used toanalyze the properties of the architecture, and it can beused to carry out simulations. However, it also serves ina subtler, but very important role. It becomes the litmustest by which one can determine whether the descriptionof the system architecture, as given by a set of staticrepresentations or models, is sufficient with respect tothe set of questions to be asked of the architecture whenthese questions involve the dynamic behavior of theC4ISR system.3 Indeed, the methodologies, whetherStructured Analysis based or Object-Oriented based,become rigorous when an executable model is derivedand the condition is imposed that all information con-tained in the executable model must be traced back toone or more of the static views.

The architecture development process can be char-acterized as consisting of three phases: the Analysisphase in which the static representations of the Func-tional and Physical Architecture views are obtainedusing the operational concept to drive the process andthe Technical Architecture view to guide it, the Synthe-sis phase in which these static constructs are used,together with descriptions of the dynamic behavior ofthe architecture (often referred to as the Dynamicsmodel), to obtain the executable model of the architec-

3Further discussion on this issue appears in Section 5.

Figure 1. The three phases of architecture development.


ture, and the Evaluation phase in which measures ofperformance (MOPs) and measures of effectiveness(MOEs) are obtained. This three phase process is shownschematically in Figure 1.

A key use of the executable model is to allow thearchitect to shift the locus of discourse with the cus-tomer or user from the architecture views to the behav-ior and performance that the architecture enables. Thisconcept is shown in Figure 2. The figure points out thatthe static descriptions of the architecture are a means toan end; the end is to provide the C4ISR system userswith capabilities that support their missions. Note thatwhile a number of questions can be resolved with theuse of only of few of the static products, experiencewith a number of DoD organizations has shown thatcommunicating with users via these constructs is notan effective process, even though these constructsmay contain within them all the data needed to pro-vide the answer.

The next section describes the first of the two para-digms for the architecture development process: Struc-tured Analysis and its tools. The reason is that theC4ISR Architecture Framework, as currently de-scribed, has a strong Structured Analysis flavor. WhileObject Orientation is not excluded explicitly, the lan-guage, terminology, and examples used all are based onStructured Analysis. However, while the two ap-proaches are conceptually different, many of the sametools can be used to construct the various repre-sentations that comprise each approach. Furthermore,once the executable model is obtained, whether throughStructured Analysis or Object Orientation, the evalu-ation phase is the same. After discussing the evaluationphase, we will show in Section 5 how to map theinformation contained in the Structure Analysis prod-ucts into the C4ISR Architecture Framework Version 2essential products. It will be clear that these productscan be derived from a well-defined description of the

architecture regardless of the approach used to createthe architecture; two equivalent but not identical sets ofsupporting products can also be derived.

3. STRUCTURED ANALYSIS APPROACH

The Structured Analysis approach has its roots in theStructured Analysis and Design Technique (SADT) thatoriginated in the 1950’s [Marca and McGowan, 1987]and encompasses Structured Design [Yourdon andConstantine, 1975], Structured Development [Wardand Mellor, 1986], the Structured Analysis approach ofDeMarco [1979], Structured Systems Analysis [Ganeand Sarson, 1978], and the many variants that haveappeared since then, often embodied in software pack-ages for computer-aided requirements generation andanalysis. This approach can be characterized as a proc-ess-oriented one [Solvberg and Kung, 1993] in that itconsiders as the starting point the functions or activitiesthat the system must perform. A second characterizingfeature is the use of functional decompositions and theresulting hierarchically structured diagrams. However,to obtain a specification of the architecture that allowsthe derivation of the executable model, in addition tothe process or activity model, a data model, a rulemodel, and a dynamics model are required. Each one ofthese models contains interrelated aspects of the archi-tecture description. For example, in the case of aninformation system, the activities or processes receivedata as input, transform it, and produce data as output.The associated data model describes the relationshipsbetween these same data elements. The activities takeplace when some conditions are satisfied. These condi-tions are expressed as rules associated with the activi-ties. But for the rules to be evaluated, they require datathat must be available at that particular activity withwhich the rule is associated; the output of the rule alsoconsists of data that control the execution of the process.

Figure 2. Behavior as the locus of discourse.


Furthermore, given that the architecture is for a dy-namic system, the states of the system need to bedefined and the transitions between states identified todescribe its dynamic behavior. State transition diagramsare but one way of representing this information. Un-derlying these four models is a data dictionary or, moreproperly, an integrated system dictionary, in which alldata elements, activities, rules, and flows are defined.The construct that emerges from this description is thata set of interrelated views, or models, is needed todescribe an architecture using the structured analysisapproach.

In an ideal world, a tool would exist that wouldsupport all these models of an architecture and generatea consistent data dictionary. While the four types ofmodels exist in many forms and software tools for theirgeneration are available, they have been developedindependently from a different starting point: It is pos-sible to approach the problem by starting with a datamodel (data-oriented approach) or with a rule model(rule-oriented approach). At this time, the architectmust use a suite of tools and, cognizant of the interre-lationships among the four models and the features ofthe tools chosen to depict them, work across models tomake the various views consistent and coherent. More-over, he or she must obtain a single, integrated systemdictionary from the individual dictionaries generated bythe various tools.

The Activity model, the Data model, the Rule model,and the supporting Integrated System Dictionary, takentogether, constitute the Functional Architecture view ofthe system (Fig. 3). The term Functional Architecturehas been used to describe a range of representations—from a simple activity model to the set of modelsdefined here. What a Functional Architecture does notcontain is the specification of the physical resourcesthat will be used to implement the functions or thestructure of the human organization that is supported bythe information system. These descriptions are con-tained in the Physical Architecture.

3.1. Functional Decomposition and ActivityModel

In a process-oriented approach such as structured analy-sis, the architecture development process can start witha very abstract operational concept. As the analysisevolves, the operational concept becomes more spe-cific. The operational concept is often described picto-rially with an associated narrative that explains how theoperation is to take place. Cartoons and clip art are oftenused in the graphical representation. This depiction isoften inappropriately referred to as an architecture. It isnot. It is equivalent to a sketch that an architect maymake of a house, how it sits on the land, and where themain functional areas are. It is not the model of thehouse itself or the schematics that would allow someoneto build this house.

Given an operational concept at some level of ab-straction, the first step in the development of the func-tional architecture is the Functional Decomposition.Starting with a verb or verb phrase that articulates thefunction of the system, a first level decomposition isdone into functions that are part of the top level func-tion. These first level functions are mutually exclusiveand could be totally exhaustive. Each of these functionscan be decomposed further into level two functions thatare parts of it, and so forth. This decomposition can beshown in outline form or graphically as a tree structure.In various approaches, specific names are given to thedecomposition levels: for example, “mission – function –task” is one set of labels (Fig. 4). The decomposition iscarried out to as many levels as is necessary, alwaysguided by the operational concept. However, keepingthe levels as few as possible is recommended for tworeasons: Each additional level increases substantiallythe complexity of the problem (and may not be support-able by the other parts of the architecture process), anda multilevel decomposition may introduce implicitly aphysical architecture—the way the functions are parti-tioned may specify prematurely implementation solu-tions. One useful rule is to decompose until eachfunction can be assigned to a single physical resource.To achieve that, it is implied that the physical architec-

Figure 3. Components of the functional architecture.


ture is available. This is usually not the case; the twoshould be developed in parallel with much interactionbetween them. Indeed, the functional decomposition isan iterative process and should be done with care; it isdifficult to go back to the higher levels and makechanges to them—the lower levels and everything re-lated to them will have to be re-examined.

There are two primary methods in wide use for therepresentation of an Activity Model. The first, IDEF0,4

has systems engineering roots, while the second, DataFlow Diagrams, has its roots in software systems engi-neering. The National Institute of Standards and Tech-nology (NIST) has published Draft Federal InformationProcessing Standard #183 for IDEF0; this is not the casefor DFD. There are various variants and extensions ofthe Data Flow diagramming approach. Each of theapproaches has advantages and disadvantages; choos-ing one of them depends on the features of the problemto be addressed. For the history of IDEF0, see Marcaand McGowan [1987], and, for Data Flow Diagrams,see Yourdon [1989] or Rumbaugh et al. [1991]. IDEF0is described briefly in this section.

IDEF0 is a subset of the Structured Analysis andDesign Technique (SADT). It is a modeling languagefor developing structured graphical representations ofthe activities or functions of a system. It has beendesigned to describe and aid in understanding complexsystems. It is a static representation, designed to addressa specific question from a single point of view. It hastwo graphical elements: a box, which represents anactivity, and a directed arc that represents the convey-ance of data or objects related to the activity. A distin-guishing characteristic of IDEF0 is that the sides of theactivity box have a standard meaning, as shown inFigure 5. Arcs entering the left side of the activity boxare inputs, controls enter the top side, and mechanismsor resources used to perform the activity enter thebottom side. Arcs leaving the right side are outputs—the data or objects generated by the activity. WhenIDEF0 is used to represent the activity model in aFunctional Architecture, mechanisms are not needed;they are part of the Physical Architecture.

Verbs or verb phrases are inscribed in the activityboxes to define the function represented. Similarly, arcinscriptions are used to identify the data or objectsrepresented by the arcs. There are detailed rules forhandling the branching and the joining of the arcs [FIPS183].

A key feature of IDEF0 is that it supports hierarchi-cal decomposition. At the highest level, the A-0 level,there is a single activity that contains the root verb ofthe functional decomposition. This is called the contextdiagram and also includes a statement of the purpose ofthe model and the point of view taken. The next leveldown, the A0 level, contains the first level decomposi-tion of the system function and the interrelationshipsbetween these functions. It is a single page. Each oneof the activity boxes on the A0 page can be furtherdecomposed into the A1, A2, A3, ... page, respectively.A typical IDEF0 diagram of the first two levels—A-0and A0—is shown in Figure 6. There are two inputs,one control, and three outputs.

Associated with IDEF0 is a data dictionary whichincludes the definitions and descriptions of the activi-ties, listing and description of the inputs, controls, andoutputs, and, if entered, a set of activation rules of theform “preconditions postconditions.” These are the

Figure 6. First two levels of an IDEF0 Model.

Figure 5. Box and arrow semantics in IDEF0.Figure 4. The tree structure of the functional decomposi-

tion.

4 IDEF0 stands for ICAM (Integrated Computer Aided Manu-facturing) Definition Language 0.


rules that indicate the conditions under which the asso-ciated function can be carried out. In using IDEF0 torepresent an information system (a class of systems notwell suited to an IDEF0 representation when one con-siders the origins of the language) it is appropriate tocharacterize or type the data elements contained in thearcs. This is better done, however, in the data model.

3.2. Data Model

The arcs in the activity model of an information archi-tecture represent data or objects. The purpose of a datamodel is to analyze the data structures and their rela-tionships independently of the processing that takesplace, already depicted in the activity model. There aretwo main approaches with associated tools for datamodeling: IDEF1x and Entity–Relationship (E-R) dia-grams. Both approaches are used widely. The NationalInstitute of Standards and Technology has publishedDraft Federal Information Processing Standard #184[FIPS 184] in which IDEF1x is specified. There aremany books that describe E-R diagrams: Sanders[1995], Yourdon [1989], and McLeod [1994].

IDEF1x (IDEF1 extended) is a modeling languagefor representing the structure and semantics of theinformation in a system. The elements of IDEF1x arethe entities, their relationships or associations, and theattributes or keys. An IDEF1x model is comprised ofone or more views, definitions of the entities, and thedomains of the attributes used in the views.

An entity is the representation of a set of real orabstract objects that share the same characteristics andcan participate in the same relationships. An individualmember of the set is called an entity instance. An entityis depicted by a box; it has a unique name and a uniqueidentifier. If an instance of an entity is identifiable withreference to its relationship to other entities, it is calledidentifier dependent. A slightly different form of thebox is used to distinguish identifier-independent and-dependent entities. The box depicting the entity in-stance is divided into two parts: The top part containsthe primary key attributes; the lower one the nonpri-mary key attributes. Every attribute must have a name(expressed as a noun or noun phrase) that is uniqueamong all attributes across the entities in the model. Theattributes take values from their specified domains—this automatically establishes the type of the attribute.This formalism is shown in Figure 7.

Relationships between entities are depicted in theform of lines that connect entities; a verb or verb phraseis placed beside the relationship line. The connectionrelationship is directed—it establishes a parent-childassociation—and has cardinality. Special symbols areused to at the ends of the lines to indicate the cardinality.

The relationships can be classified into types such asidentifying or nonidentifying, specific and nonspecific,and categorization relationships. The latter, for exam-ple, is a generalization/specialization relationship inwhich an attribute of the generic entity is used as thediscriminator for the categories. A simple example isshown in Figure 8 in which three types of vehicles aredefined as categories of vehicles.

3.3. Rule Model

In a rule-oriented model, knowledge about the behaviorof the architecture is represented by a set of assertionsthat describe what is to be done when a set of conditionsevaluates as true. These assertions, or rules, apply tospecific functions defined in the activity model and areformulated as relationships among data elements. Thereare several specification methods that are used depend-ing on the application. They include Decision Trees,Decision Tables, Structured English, and Mathematical

Figure 7. Independent and dependent entities with PrimaryKey and Non-Primary Key attributes.

Figure 8. Example of generic and category entity specifica-tion using a discriminator.


Logic. Each one has advantages and disadvantages; thechoice often depends on the way that knowledge aboutrules has been elicited and on the complexity of therules themselves.

A Decision Tree is most appropriate when each rulehas as a consequent a single action, the execution of anactivity. A Decision Tree has a single root that repre-sents the first decision. Subsequent decisions are de-picted as branches and leaves of the tree. Each node ofthe tree represents a decision, while the leaves indicatethe resulting actions. A Decision Table is more usefulwhen a set of conditions that evaluates as true results inmultiple actions. The table is partitioned in four sec-tions as shown in Figure 9. The Condition stub containsthe list of the decision variables, while the Action stubcontains the list of actions. The Condition matrix con-sists of columns with each column depicting a combi-nation of conditions. The columns of the Action matrixshow which actions are to take place when the condi-tions in the corresponding condition column evaluate astrue.

Both Decision Trees and Decision Tables show onlyselection or decision constructs; they do not show se-quencing or repetition and iteration. Structured Englishshows all three control structures. In Structured Eng-lish, the rules are expressed using nested patterns of theform “if-then-else-so.” The action that results when theconditions evaluate as true is expressed in the form ofa command: Then do this.

Of course, mathematical logic can be used (whetherSymbolic logic or Predicate logic) to represent the setof rules. This is a very general representation that allowsfor the modeling of very complex rules.

3.4. Dynamics Model

The fourth type of model that is needed is one thatcharacterizes the dynamic behavior of the architecture.This is not an executable model, but one that shows thetransition of the system state as a result of events thattake place. The state of a system can be defined as allthe information that is needed at some time t0 so thatknowledge of the system and its inputs from that timeon determines the outputs. The state space is the set ofall possible values that the state can take.

There is a wide variety of tools for depicting thedynamics, with some tools being more formal thanothers: state transition diagrams, state charts, eventtraces, key threads, etc. Each one serves a particularpurpose and has unique advantages.

A State Transition diagram is a representation of asequence of transitions from one state to another—as aresult of the occurrence of a set of events—when start-ing from a particular initial state or condition. The statesare represented by nodes (e.g., a box) while the transi-tions are shown as directed arcs. The event that causesthe transition is shown as an arc annotation, while thename of the state is inscribed in the node symbol. If anaction is associated with the change of state, then thisis shown on the connecting arc, next to the event. Therules that enable the event to effect the transition fromone state to another can be shown also on the connectingarc in brackets. An example is shown in Figure 10.

Note that the Dynamics model is not an executablemodel. It characterizes in a static manner aspects of thedynamic behavior of the model. Furthermore, since aState Transition diagram represents the transitions froman initial condition and a sequence of events, it followsthat, to characterize a system’s behavior, many suchdiagrams are needed.

3.5. Integrated Dictionary and ModelConcordance

Underlying all these four models is the Integrated Sys-tem Dictionary. Since the individual models containoverlapping information, it becomes necessary to inte-grate the dictionaries developed for each one of them.Such a dictionary must contain descriptions of all thefunctions or activities including what inputs they re-quire and what outputs they produce. These functionsappear in the activity model (IDEF0), the Rule model(as actions), and the State Transition diagrams. Therules, in turn, are associated with activities; they specifythe conditions that must hold for the activity to takeplace. For the conditions to be evaluated, the corre-sponding data must be available at the specific activ-ity—there must be an input or control in the IDEF0diagram that makes that data available to the corre-sponding activity. Of course, the system dictionarycontains definitions of all the data elements as well asthe data flows that appear in the activity model.

Figure 10. A transition from State 1 to 2.Figure 9. The four parts of a Decision Table.


The process of developing a consistent and compre-hensive dictionary provides the best opportunity forensuring concordance among the four models. Sinceeach model has different roots and was developed toserve a different purpose, together they do not constitutea well-integrated set. Rather, they can be seen as a suiteof tools that collectively contain sufficient informationto specify the architecture. The interrelationshipsamong models are complex. For example, rules shouldbe associated with the functions at the leaves of thefunctional decomposition tree. This implies that ifchanges are made in the IDEF0 diagram, then the rulemodel should be examined to determine whether rulesshould be reallocated and whether they need to berestructured to reflect the availability of data in therevised activity model. A further implication is that thefour models cannot be developed in sequence. Rather,the development of all four should be planned at thebeginning with ample opportunity provided for itera-tion, because if changes are made in one, they need tobe reflected in the other models.

Once concordance of these models has beenachieved, it is possible to construct an executablemodel. Since the physical architecture has not beenconstructed yet, the executable model can only be usedto address logical and behavioral issues, but not per-formance issues.

3.6. Conversion to the Executable Model

Information Systems are dynamic in nature. Eventsoccur that trigger the execution of functions, and manyfunctions can be executed concurrently. An executablemodel of an information architecture enables the archi-tect to analyze the dynamic behavior of the architecture,identify logical and behavioral errors not easily seen inthe static descriptions, and demonstrate to the customeror user the capabilities that the architecture enables.There exist some graphical modeling approaches thatallow a dynamic representation of a discrete event sys-tem. Colored Petri Nets, Finite State Machines, andBehavior Diagrams are examples of such approaches.They can be used directly to model a discrete eventdynamical system representation of an information ar-chitecture. The problem, however, is that they are muchmore complex than the four models already describedand require substantial experience and expertise to en-sure that they include all relevant system aspects. Thesolution is, therefore, to derive the executable modelfrom the static representations. A methodology hasbeen developed that allows the derivation of a ColoredPetri Net model of an architecture that can be tracedback to the four models. Note that the discrete eventsystem representation is not suitable for representing

many physical systems that are best characterized bytime-driven processes as described by differential ordifference equations. The logical and decision proc-esses of a C4ISR system supporting the Command andControl process are an appropriate domain for discreteevent modeling since the hardware consists primarilyof computers and the overall system is software inten-sive.

Colored Petri Nets [Jensen, 1992] are a generaliza-tion of Petri Nets. The latter are bipartite directed mul-tigraphs that are executable. In Petri Nets, two types ofnodes are defined: Places and Transitions. The arcs thatjoin two nodes are directed; furthermore, arcs can con-nect only nodes of different types. Directed arcs con-necting places to transitions establish the inputs to thattransition, while arcs connecting transitions to placesestablish the outputs. The arcs can have inscriptions thatdefine the degree of multiplicity of that arc. An illustra-tive Petri Net is shown in Figure 11.

In order for the Petri Net to execute and be a dynami-cal model, another element needs to be introduced. Thisis the token. A token is an indistinguishable marker thatresides in places. The distribution of tokens in the placesof a Petri Net is called a marking and defines the stateof the system or net. Markings enable transitions thatcan then fire. The execution rule is as follows: A tran-sition is enabled if every one of its input places has atleast as many tokens as the multiplicity inscribed on thearc connecting the place to the transition. An enabledtransition can fire. When it fires, the tokens used tosatisfy the enablement condition are removed from thenet; new indistinguishable tokens are generated in theoutput places of the transition. The number of tokensgenerated depends on the multiplicity of the outgoingarcs. Figure 12 shows an initial marking for the net ofFigure 11 that enables the transition and the results ofthe transition firing.

In Colored Petri Nets, the tokens are distinguishable;they are characterized by their color: An attribute vectoris associated with each token. The assignment of valuesto the attributes from their respective domains specifiesthe color of the token. Color sets are associated withplaces; they specify which tokens can reside in thatplace. Instead of a simple multiplicity number inscrip-

Figure 11. A Petri Net.


tion that was allowed on the arcs, now complex enable-ment conditions can be specified. Each input arc in-scription specifies the number and type of tokens thatneed to be in the place for the transition to be enabled.The output arc inscriptions indicate what tokens will begenerated in an output place when the transitions fires.Furthermore, guard functions associated with transi-tions are allowed. These guard functions specify addi-tional conditions that must be satisfied, i.e., in additionto those inscribed on the arcs, for a transition to beenabled. Code segments can be associated with transi-tions. These code segments can represent the functionmodeled by the transition and complement the outputarc inscriptions.

Each Colored Petri Net model has associated with ita Global Declaration node that contains the definitionsof all Color Sets and their associated domains and thedefinition of variables. It becomes apparent then thatmuch of the data in the data dictionary appears in theglobal declaration node of the Colored Petri Net model.

The use of Colored Petri Nets to develop an ex-ecutable model from the Structured Analysis modelscan be described as follows. One starts with the activitymodel. Each IDEF0 activity is converted into a transi-tion; each IDEF0 arrow connecting two boxes is re-placed by an arc-place-arc combination (Fig. 13), andthe label of the IDEF0 arc becomes the color set asso-ciated with the place. All these derived names of colorsets are gathered in the Global Declaration Node. Fromthis point on, a substantial modeling effort is requiredto make the Colored Petri Net model a dynamic repre-sentation of the system. The information contained inthe data model is used to specify the color sets and theirrespective domains, while the rules in the rule modelresult in arc inscriptions, guard functions, and codesegments.

The process of deriving the executable model invari-ably leads to some revision of the static models. It ismost important that discipline be exercised so that anychange introduced at the executable model level isreflected back in the static models. Only this way adocumented and easily reviewed representation of thearchitecture can be maintained.

The executable model becomes the integrator of allthe information; its ability to execute tests some of thelogic of the model. Given the Colored Petri Net model,a number of analytical tools from Petri Net theory canbe used to evaluate the structure of the model, e.g.,determine the presence of deadlocks, or obtain its oc-currence graph. The occurrence graph represents a gen-eralization of the State Transition Diagram model. Byobtaining the occurrence graph of the Petri Net model,which depicts the sequence of states that can be reachedfrom an initial marking (state) with feasible firing se-quences, one has obtained a representation of a set ofState Transition Diagrams. This can be thought as a firststep in the validation of the model at the behaviorallevel. Of course, the model can be executed to check itslogical consistency, that is, to check whether the func-tions are executed in the appropriate sequence and thatthe data needed by each function are appropriatelyprovided. Performance measures cannot be obtaineduntil the physical architecture is introduced; it providesthe information needed to compute performance meas-ures.

Since Colored Petri Nets with their dense annotationare not very easily accessible to the information systemusers, all the information gathered in the design andexploitation of the executable model need to be broughtback into the static models. This annotated and vali-dated representation now constitutes a sound basis forsystem development.

3.7. The Physical Architecture

To complete the Analysis phase of the procedure (Fig.14), the Physical Architecture needs to be developed.

Figure 13. From IDEF0 to a Colored Petri Net repre-sentation.

Figure 12. Enablement and firing of transition.

Figure 14. The analysis phase.


There is no standardized way to represent the physicalsystems—existing ones as well as planned ones thatwill be used to implement the architecture. They rangefrom wiring diagrams of systems to block diagramrepresentations to node models to organization charts.While there is not much difficulty in describing in aprecise manner physical subsystems using the terminol-ogy and notation of the particular domain (communica-tion systems, computers, displays, databases), aproblem arises on how to depict the human organizationthat is an integral part of the information system. Thehumans in the organization cannot be thought simplyas users; they are active participants in the workings ofthe information system and their organizational struc-ture that includes task allocations, authority, responsi-bility, reporting requirements, etc., must be taken intoaccount and be a part of the physical model description.This is an issue of current research, since traditionalorganizational models do not address explicitly theneed to include the human organization as part of thephysical system description.

Once the physical architecture is available, then anExecutable Model that can be used for performanceevaluation can be obtained. The Synthesis phase isdescribed in Figure 15. In this phase, the informationand knowledge generated in the Analysis phase aresynthesized into the Executable Model. As Figure 15shows, this can be viewed as a two-stage process. First,an executable model can be created based on the Func-tional Architecture View. This Executable model canreveal logical and behavioral properties of the architec-ture that can be the focus of discourse with the customer

or stakeholders. Once satisfactory behavior has beendemonstrated, the information contained in the Physi-cal Architecture View can be incorporated in the Ex-ecutable Model for performance evaluation. Thisrequires an interrelationship between the Functionaland the Physical architecture views as shown by thebold two-way arrow. It is critical that the granularity ofthe two architecture views be comparable and thatpartitions have taken place in the hierarchical decom-positions in a manner that allows functions or activitiesto be assigned unambiguously to resources and viceversa. Once the parameter values and properties of thephysical systems have become part of the database ofthe executable model, performance evaluation can takeplace.

Figure 15. The synthesis phase.

Figure 16. An iterative process.


3.8. Logical, Behavior, and PerformanceEvaluation

Measures of Performance (MOPs) are obtained eitheranalytically or by executing the model in simulationmode. For example, if deterministic or stochastic timedelays are associated with the various activities, it ispossible to compute the overall delay or to obtain itthrough simulation. Depending on the questions to beanswered, realistic scenarios of inputs need to be de-fined that are consistent with the Operational Concept.This phase allows for functional and performance re-quirements to be validated, if the results obtained fromthe simulations show that the Measures of Performanceare within the required range. If not, the systems mayneed to be modified to address the issues that accountfor the encountered problems.

This is actually an iterative process, as shown inFigure 16. The Executable model can be used both atthe logical and behavioral level as well as the perform-ance level. The latter requires the inclusion of the Physi-cal architecture. In one consistent architecturalframework supported by a set of models, requirementsanalysis, design, and evaluation can be performed. Thecreation of the Executable Model allows the focus ofdiscourse to be on the behavioral and performanceaspects of the architecture. Furthermore, the processprovides a documented set of models that collectivelycontain all the necessary information.

4. C4ISR ARCHITECTURE FRAMEWORK,VERSION 2 PRODUCTS

Having reviewed the traditional systems engineeringprocess from creating system architectures, we nowturn our attention to the C4ISR Framework Version 2.We start with a brief review of the products that arespecified by the Framework. This will be followed bythe description of a process for generating these prod-ucts after the architecture has been created using thesystems engineering process.

The C4ISR Framework presents four views: Theseare All View, Operational Architecture View, SystemsArchitecture View, and the Technical Architecture View.Each view describes a particular characterization of thearchitecture using a set of products that are graphical,tabular, or textual. The Framework characterizes eachproduct as either essential or supporting. This is anunfortunate terminology because it has the connotationthat the supporting views are secondary. As we shall see,this is not the case. Most of the supporting products arenecessary to produce a consistent and coherent descrip-tion of an architecture and validate the essential prod-ucts. The intent of the characterization is to identifythose products that are the minimum essential for pre-senting or delivering an architecture to the DoD. It isnot intended to mean that the supporting products arenot necessary for describing an architecture. The prod-ucts are listed in Tables I–IV.

For completeness, the next section provides a briefdescription of each of the products of the Framework.

4.1. Architecture Views and Products

As shown in Table I, the All View is comprised on twoproducts, both essential. The Overview and SummaryInformation Product, AV-1, contains summary textualinformation that will allow quick reference and com-parison among architectures. This information includesthe name of the architecture and the architect, its pur-pose, scope, and context. It also describes major find-ings and recommendation that are based on thearchitecture. The Integrated Dictionary is AV-2. At aminimum, it is a glossary with definitions of terms usedin every product in the architecture description. TheIntegrated Dictionary is essential for allowing the archi-tecture to stand alone, without reference to any otherdocuments.

The Operational Architecture view is a descriptionof the tasks and activities, operational elements, andinformation flows required to accomplish or support amilitary operation. It is composed of seven products.OV-1, the High Level Operational Concept Graphic is

Table I. All View Products


the most flexible of all the products designed to conveya high level description of the operation that the archi-tecture supports. It is generally composed of nodes, inthe form of icons, and connectors. The icons representorganizations, assets, missions or tasks, and the connec-tors show information flows or connectivity. Thegraphic can also show the relative geographic positionof assets and tasks. OV-1 must be accompanied with atextual description of the operational concept depictedin the graphic, even though this is not specified in theFramework document.

OV-2 is the Operational Node Connectivity Descrip-tion. This essential product is a directed graph, whosenodes are operation nodes or elements and whose arcs,called need lines, show necessary connectivity and theflow of operational information elements between thenodes. Each node is annotated with the activities itperforms and each need line is annotated with theoperational information element that flows from oneoperational node to another.

OV-3 is the Operational Information Exchange Ma-trix, an essential product. It contains, in tabular form,information about each Operational Information ele-ment that is contained in the Operational Node Connec-tivity Description. For each element it lists theproducing and consuming operational node and activityas well as general information including a description,

size, composition, frequency of occurrence, timelinessrequirements, throughput, security level, and interoper-ability requirements.

OV-4 is the Command Relationship Chart. This sup-porting product describes a key organizational aspect ofthe operational concept that the architecture supports.In its most basic form it is the standard organizationalchart common to all DoD organizations. Its intent is toillustrate important relationships between organiza-tional elements in the architecture. Such relationshipsinclude command, control, and coordination. OV-4shows an operational perspective of fundamental rolesand management relationships between entities in thearchitecture. These relationships typically form the ba-sis of some of the connectivity requirements in thearchitecture.

OV-5 is the Activity Model. In its illustrations of theactivity model, the Framework uses the Integrated Defi-nition 0 (IDEF0) as the modeling technique. IDEF0 hasbeen standardized in Federal Information ProcessingStandard (FIPS) Publication 183. It is a hierarchicalstructure of activities, represented by boxes, and data orinformation exchanged between activities shown asarrows between the boxes. The Framework states thatthese arrows include inputs, controls, outputs, andmechanisms (ICOMs) that is standard in the IDEF0formalism. The Framework does not mandate IDEF0

Table II. Operational Architecture View Products


for the activity model and states that other modelingtechniques may be used. This is important because itallows some of the techniques used in object orientationto be used for OV-5.

OV-6 is called the Operational Activity Sequenceand Timing Descriptions. It is composed of three sup-porting products, the Operational Rule Model (OV-6a),

the Operational State Transition Description (OV-6b),and the Operational Event/Trace Description (OV-6c).These products are used to describe the architecture’sdynamic properties. The Operational Rule Model cap-tures business requirements and concept of operationinformation. The rules must be consistent with theactivity and logical data models (OV-7) as well as the

Table IV. Technical Architecture View Products

Table III. System Architecture View Products


State Transition Diagrams (OV-6b). The rules are ex-pressed in a formal language, e.g., Structured English,Decision Trees and Tables, or Mathematical Logic. TheOperational State Transition Description (OV-6b) mod-els the architecture’s response to specific stimuli. StateTransition Diagrams are the modeling technique that isused. The Operational Event/Trace Description (OV-6c) trace sequence of events between operational nodes.In general they have not been used in Structured Analy-sis approaches; however, they are one of the standardmodels of object orientation.

OV-7 is the Logical Data Model (LDM). It is usedto describe the data requirements that comprise theoperational information exchange elements. It showsdata entities with their attributes and relationships be-tween those entities. The Framework does not specifya specific modeling technique for the LDM, leaving theselection up to the architect depending on the purposeof the architecture. The Framework illustrates the datamodel using the FIPS 184 IDEF1X as an example of aformal data model.

The System Architecture View is a description, in-cluding graphics, of systems and interconnections pro-viding for, or supporting, war-fighting functions. It iscomposed of one essential product and 12 supportingproducts. SV-1, the System Interface Description, is theonly essential product in the System Architecture View.It is similar to the physical architecture of the StructuredAnalysis approach. It is a graphic consisting of nodesand connecting links. The nodes are called systemnodes and should map to the operational nodes of theoperational node connectivity description, OV-2. Thesystem nodes represent the physical implementation ofone or more operational nodes. The System InterfaceDescription identifies interfaces between system nodes,systems within system nodes, and system components.The interfaces are in the form of communications linksor paths. The System Interface Description has fourvariants. The architect selects the variant(s) needed tosupport his architectural effort. These variants are theInternodal Perspective–Node Edge to Node Edge inter-faces, the Internodal Perspective–System-to-SystemInterfaces, the intranodal perspective that shows theinterfaces between systems within a system node, andthe intrasystem perspective that shows the interfacesbetween the components that comprise a system withina system node.

SV-2 is the Systems Communication Description. Itprovides more detail of the system interfaces. It focuseson the physical implementation aspects of the needlinesin the Operational Node Connectivity Description andalso depicts pertinent information about the communi-cations elements and services. It has two variants, aninternodal perspective and an intranodal perspective.

SV-3 is the Systems2 Matrix. It is similar to an N2matrix where the systems are listed in both rows andcolumns and each cell provides a description of theinterface between the systems if one exists. Charac-teristics of the interface include status (existing,planned, etc), category (C2, intelligence, etc.), classifi-cation level and means (specific network).

SV-4 is the Systems Functionality Description. It isan activity model based on the notion of Data FlowDiagrams (DFDs). The activities, called transforma-tions in DFDs, represent the system functions that areperforming the operational activities described in theActivity Model of the Operational Architecture View(OV-5). Its purpose is to depict data flows and datastores within system perspective.

SV-5 is the Operational Activity to System FunctionTraceability Matrix. It is a link between the Operationaland System Architecture Views. It reflects the result ofthe allocation the activities in the Operational Architec-ture View to the system functions in the System Archi-tecture View.

SV-6 is the System Information Exchange Matrix. Itis similar to and complements the Operational Informa-tion Exchange Matrix. It is tabular in form and describesthe information exchanges between systems within anode and from systems to systems between nodes.Associated with each system information element is asystem function that either produces or receives thesystem information element. The focus of this matrix isto describe the implementation of the information ex-changed between systems (and their functions). There-fore, the matrix contains descriptions of characteristicsof each element such as content, media, format, securitylevel, frequency of exchange, timeliness requirements,etc.

SV-7 is the System Performance Parameters Matrix.This product provides current and predicted or requiredfuture performance characteristics for each systemcomponent and element in the system architecture view.This information is essential for the executable modelif Performance Evaluation is to be accomplished.

SV-8 is the System Evolution Description. It is atimeline type of depiction of plans for modernizing orevolving the system over time.

SV-9 is the System Technology Forecast. It is adetailed description of emerging technologies that canimpact the architecture. It contains predictions aboutthe availability of the technology and the potentialimpact the technology can have on the architecture.

SV-10a, 10b, and 10c comprise the System ActivitySequence and Timing Descriptions. They were in-tended to describe the dynamic behavior of the archi-tecture. Recent discussions between the DoD and theauthors reveals that the System Rules Model (SV-10a)


and the System State Transition Description (SV-10b)are no longer included as products in the System archi-tecture View. The Systems Event/Trace Description(SV-10c) is a construct used in Object-Oriented meth-odologies. Like its counterpart in the Operational Ar-chitecture View, it is intended to show the sequence ofmessages that are sent between System Nodes for agiven initial situation. Thus they present a static viewof dynamic behavior.

SV-11 is the Physical Data Model. It is used todescribe how the information represented in the LogicalData Model (OV-7) is implemented in the SystemsArchitecture View. There is a mapping between theLogical Data Model and the Physical Data Model.There is considerable flexibility as to the form that thePhysical Data Model may take. Typical descriptionsinclude message formats, file structure descriptions andphysical data schema representations.

The Technical Architecture View conveys the set ofrules that governs system implementation. As discussedbefore, it is analogous to the building code that anarchitect invokes in creating the architecture for a houseor building. This view is composed of two products, oneessential and the other supporting. The Technical Archi-tecture Profile (TV-1) is the essential product. Thisproduct references the technical standards that apply tothe architecture and how they need to be implemented.A typical Technical Architecture Profile is a table thatlists Service Areas (e.g., operating system, Data man-agement, etc.), the Service (Kernel, Data Interchange,etc.), and the Standard to be applied (FIPS Pub 151-1,FIPS Pub 127-2, etc.). TV-2 is the Standards Technol-ogy Forecast. It extends the information contained in

TV-1 to list anticipated updates and changes in applica-ble standards for the architecture.

5. DEVELOPING A PROCESS FORCREATING THE FRAMEWORK PRODUCTS

The C4ISR Framework Version 2.0 products representa different perspective from that of the traditional Struc-tured Analysis that has orthogonal Functional andPhysical Architecture views. Traditional tools and tech-niques support the Structured Analysis approach, andresearch has shown [Levis and Wagenhals, 1999] thatthis approach is complete only in the sense that itcontains all the information and data needed to producean executable model. Actually, the Structured Analysisapproach underlies the Framework products. Several ofthe Framework products are identical to those used inStructured Analysis.

The only guidance provided by the Frameworkdocument is shown in Figure 17. Six steps are definedfor the development of an architecture. These are fun-damental steps; it is the responsibility of the (chief)architect that they be followed in every architecturedevelopment effort. The first step reinforces the ideathat architectures must be designed for a purpose, toaddress a particular set of problems. This purpose andthe associated problems must be articulated before thedevelopment of the architecture and the production ofproducts begins. The next step is the determination ofthe scope of the architecture. In systems engineeringterms, this corresponds to determining the systemboundary, i.e., determining which elements are going tobe considered within the architecture and which will be

Figure 17. Universal guidance for Architecture development.


considered as part of the environment. The third step isclosely related to the first one: The choice of attributesthat are to be included is directly dependent on thequestions to be answered. At this point, the architect isready to determine which supporting products areneeded in addition to the essential products. Note thatthe first four stages require the involvement of fewpersons—the architect, the users, and a small staff thatsupports the architect. The fifth step is the labor-inten-sive one in which the architecture is designed and theproducts are developed. This step is guided by theprevious four steps; failure to do that may easily resultin a set of products that will be unable to address thelast, and most critical step, the use of the architecturefor the intended purpose, i.e., to provide answers to theoriginal questions. The development of the executablemodel could be included either in step 5 or 6. Note thatthe first four steps are really the responsibility of theDoD organization that is developing the C4ISR archi-tecture while the fifth and sixth steps can be done byindustry; the first fours steps set up the requirementswhile the last two are the actual design.

The steps addressed by this and the two companionpapers [Wagenhals et al., 2000], [Bienvenu, Shin, andLevis, 2000] are step 5 and part of step 6. The two stepscan be decomposed as shown in Figure 18. First, thearchitect and his team develop the architecture using theStructured Analysis tools and techniques that were de-scribed in Section 3, or any other approach such asobject orientation. If the architecture representation iscomplete in the sense that the executable model isobtainable, then the C4ISR Architecture Frameworkproducts can be derived. This statement requires clari-fication. It is possible to derive an executable modelfrom the Operational Architecture view alone. Such amodel can only address some logical and behavioralquestions. To address performance questions, the Sys-tem Architecture view is needed. If the architecture hasbeen defined and all the information resides in an inte-grated database, then one can see the products as noth-

ing else but a set of reports drawn from the database.Indeed, this is the concept that allows the use of alter-native methodologies for the design of the architectureand forms the theoretical justification for a softwareproduct such as JCAPS [2000].

The executable model requires some additional in-formation not specified explicitly in the Framework: Itneeds timing information and it needs a set of scenariosto run simulations and collect data for the Measures ofPerformance and the Measures of Effectiveness.

Given this design process, the next step is to developspecific procedures that realize the functions indicatedin each one of the boxes. Two different procedures havebeen developed, one based on Structured Analysis[Wagenhals et al., 2000] and one on object orientation[Bienvenu, Shin, and Levis, 2000]. The process thatfollows the lower branch of Figure 18 is straightforwardand well understood for a number of years [Levis,1999]. However, one may think of the upper branch asa constraint on the lower one: It is not sufficient toobtain any design and any executable model; the designshould produce the products specified by the C4ISRArchitecture Framework. To achieve that, a reverseengineering procedure was followed.

Each one of the Framework products was considereda data entity composed of other data entities and aformal IDEF1x data model of the set products wascreated. This model contained over 100 entities. Ofthose 100 entities, 16 were identified a key entities thatare necessary to understand the mapping between theStructured Analysis products and the Framework prod-ucts. These entities and their relationships are shown inFigure 19 in the form of an Entity–Relationship dia-gram.

In this E-R diagram, the entities are partitioned intotwo categories: entities associated with the operationalarchitecture view and entities associated with the sys-tems architecture view. This partition is indicated by thehorizontal line in Figure19.

Figure 18. Template of the Architecture design process.


Starting with the operational view, the key entitiesare the operational nodes and operational elements.The operational nodes are the graphic constructs thatappear in the Operational Node Connectivity Descrip-tion (OV-2). The operational elements are specified inthe Operational Information Exchange Matrix (OV-3).Each graphical operational node in OV-2 represents oneor more operational elements, and, therefore, can con-tain one or more operational elements. These nodes andthe elements they represent do not have to be realphysical facilities. Instead they can represent notionalor “virtual” nodes and elements based on the operators’view of operational roles. These roles are normallyassociated with organizations that have assets that com-prise the systems that ultimately perform the activitiesof the architecture. Thus each operational node repre-sents or contains operational elements that performactivities and receive and produce operation informa-tion elements. The Operational Node Connectivity De-

scription also has directed arcs between the operationalnodes that are called needlines. The needlines indicatethe need for connectivity between operational nodes.The need for the connectivity is based on the opera-tional information elements that must flow between theactivities that are performed at the operational nodes.

There are several mappings between key entities ofthe Operational Architecture View and Systems Archi-tecture View. The operational nodes map to systemsnodes that are graphical constructs in the System Inter-face Description (SV-1) and the Systems Communica-tions Description (SV-2). Each system node representsor contains systems. Systems, in turn, are composed ofsystem components that are, in turn, composed of sys-tem elements. These are also part of SV-1 and SV-2.These systems, components, and elements perform sys-tem functions that are the physical implementation ofthe activities described in the operational architectureview. Because they represent real physical entities, each

Figure 19. Key Entities.


system, component, and element has performance pa-rameters associated with it. The systems, components,and elements are connected together via communica-tions assets such as Local Area Networks (LANs) andWide Area Networks (WANs). These networks provideinterfaces between the systems, components, and ele-ments. These networks provide communications linksbetween the systems that implement the needlines ofthe Operational Architecture View. System informationelements, which are the physical implementation of theoperational information elements flow over the linksbetween the systems, component, and elements as thesystem functions are performed.

Together, these key entities support the creation ofmost of the Framework products. For the operationalarchitecture view, in addition to OV-2 and OV-3, theorganizations are represented in the Command Rela-tionship Chart (OV-4), the activities and their relation-ships are specified in the Activity Model (OV-5), andthe Operational Information Elements are described in

the Logical Data Model (OV-7). For the Systems Archi-tecture View, in addition to SV-1 and SV-2, the systemfunctions and their relationships are expressed in theSystem Functionality Description (SV-4), the relation-ship between system functions are described in theSystem2 Matrix (SV-3), the allocation of the activitiesto system functions is defined in the Operational Activ-ity to System Functions Traceability Matrix (SV-4), thecharacteristics of the system information elements aredescribed in the Physical Data Model (SV-11), therelationship between system information elements andsystem functions are specified in the System Informa-tion Exchange Matrix (SV-6), and the system perform-ance parameters are described in the SystemPerformance Parameter Matrix (SV-7).

Given the understanding of the key entities of theFramework products and the formal procedure for cre-ating an architecture using Structured Analysis, it ispossible to show the relationship between the elementsof the Structured Analysis descriptions of the architec-

Figure 20. Relationship between analysis phase and Framework Key Entities.


ture and the Framework products. Recall that the struc-ture analysis process begins with the description of theoperational concept for accomplishing a mission that isused to guide the development of both the functionalarchitecture and the physical architecture views. Thelatter also includes organizational models. Throughoutthe Structured Analysis process, the functional andphysical architecture views are balanced. This processwas depicted in Figure 15 of Section 3.

Figure 20 shows the Analysis phase of Figure 15overlaid on the model of the Key Entities. The impliedprocess begins with the creation of the operationalconcept. Note that this can be defined in the OperationalConcept Graphic (OV-1). The operational conceptguides the development of the functional decomposi-tion, the physical architecture composed of systemnodes and links, and the organization model. It alsoguides the selection of the operational nodes.

The functional decomposition contains the activitiesand is used to guide the development of the functionalarchitecture. This is composed of the activity model,that is, OV-5, the Logical Data Model, OV-7, and therule model, OV-6a. The dynamics model (OV-6b) iscreated in the form of a State Transitions Diagram. Thearrows between these models reflect the need to ensureconcordance between the models. Implied, but notshown, is the Integrated Dictionary, AV-2. Figure 20also depicts the physical architecture view as the systemnodes with systems, system elements, and system com-ponents, and the links that connect them.

These fundamental relationships among the key en-tities induce a partial ordering of them and of theFramework products. This partial order forms the basisfor a process for creating the architecture. The processcan be based either on Structured Analysis constructs,as is done here, or on Object-Oriented ones [Bienvenu,Shin, and Levis, 2000].

Note that this is not presented as a recommendedprocess to use in developing a C4ISR architecture.Rather, it is a reverse-engineered process, based onStructured Analysis constructs, that identifies the inter-relationships among products. Organizations involvedin the design of architectures often have their ownapproach or process for developing architectures but areuncertain whether their process will meet the C4ISRArchitecture Framework requirements. We have beensuggesting to these organizations (both military andindustrial) that they compare their process to the onedescribed here as a means of assessing whether theyhave covered all the aspects they need and whether theyneed to modify or enhance their process by recognizingsome interrelationships between products at an earlystage. For example, this process identifies InformationExchange Requirements, an essential product, as one of

the outputs of the process, not one of the inputs. This isnot to say that such data need not be collected—rather,the final list is the result of the analysis embedded in theexecution of any thorough process.

7. CONCLUSIONS

We have discussed the creation of architectures forinformation systems in general and explored a processfor creating the Essential and Supporting Products ofthe DoD C4ISR Architecture Framework Version 2.0.The Framework, by its depictions of example products,has a Structured Analysis bias in its representation ofthe products that represent three views of an architec-ture. It does not provide or recommend a process forcreating these products, but only some universal guid-ance. In this paper, we have shown using StructuredAnalysis that it is possible to develop a process thatgenerates these products and also provides the neces-sary information for the derivation of an executablemodel. In the two companion papers, explicit processesare described, and the same example is used to showhow these processes can be implemented.

REFERENCES

M.P. Bienvenu, I. Shin, and A.H. Levis, C4ISR architectures.III: An Object-Oriented approach to architecture design,Syst Eng 3, 288–312 (2000).

C4ISR Architecture Framework Version 2.0, C4ISR Architec-ture Working Group, Department of Defense, Washington,DC, December 18, 1997.

T. DeMarco, Structured analysis and systems specification,Prentice Hall, Englewood Cliffs, NJ, 1979.

FIPS 183, Federal Information Processing Standard # 183:Integration definition for function modeling, National In-stitute for Standards and Technology, Gaithersburg, MD.

FIPS 184, Federal Information Processing Standard # 184:Integration definition for information modeling, NationalInstitute for Standards and Technology, Gaithersburg,MD.

C. Gane and T. Sarson, Structured systems analysis: Tools andtechniques, Prentice Hall, Englewood Cliffs, NJ, 1978.

K. Jensen, Coloured Petri nets, Springer-Verlag, Berlin, 1992.JCAPS, Joint C4ISR Architecture Planning/Analysis System,

Status and Future Directions briefing, OASD(C3I), April2000.

A.H. Levis, “Systems architectures,” Handbook of systemsengineering and management, A.P. Sage and W.B. Rouse(Editors), Wiley, New York, 1999, pp. 427–456.

A.H. Levis and L. W. Wagenhals, Architecting informationsystems, GMU/C3I-165-R, C3I Center, George MasonUniversity, Fairfax, VA, 1999 (also at http://viking.gmu.edu/http/syst621/Syst621.htm).

D.A. Marca and C. L. McGowan, Structured analysis anddesign technique, McGraw-Hill, New York, 1987.


R. McLeod, Jr., Systems analysis and design, Dryden, FortWorth, TX, 1994.

E. Rechtin, Systems architecting: Creating & building com-plex systems, Prentice Hall, Englewood Cliffs, NJ, 1991.

E. Rechtin, The art of systems architecting, IEEE Spectrum(October 1992), pp. 66–69.

E. Rechtin and M. Maier, The art of systems architecting,CRC Press, Boca Raton, FL, 1996.

J. Rumbaugh, M. Blaha, W. Premerlani, F, Eddy, and W.Lorensen, Object-oriented modeling and design, PrenticeHall, Englewood Cliffs, NJ, 1991.

G.L. Sanders, Data modeling, Boyd & Fraser, Danvers, MA,1995.

A. Solvberg and D.C. Kung, Information systems engineer-ing, Springer-Verlag, Berlin, 1993.

L.W. Wagenhals, I. Shin, D. Kim, and A.H. Levis, C4ISRarchitectures. II: A Structured Analysis approach to archi-tecture design, Syst Eng 3, 248–287 (2000).

P. Ward and S. Mellor, Structured development of real-timesystems, Yourdon Press, New York, 1986.

E. Yourdon, Modern structured analysis, Yourdon Press,Englewood Cliffs, NJ, 1989.

E. Yourdon and L. Constantine, Structured design, YourdonPress, New York, 1975.

Alexander H. Levis is University Professor of Electrical, Computer, and Systems Engineering. He isassociated with the C3I Center, where he heads the System Architectures Laboratory. He served as Chairof the Systems Engineering Department in 1992–1994, and then again in 1996–1997. He was educatedat MIT, where he received the B.S. (1965), M.S. (1965), M.E. (1967), and Sc.D. (1968) degrees inmechanical engineering with control systems as his area of specialization. He also attended Ripon Collegewhere he received the A.B. degree (1963) in mathematics and physics. He taught systems and controltheory at the Polytechnic Institute of Brooklyn from 1968 to 1973 and, for the following 6 years, he waswith Systems Control, Inc. of Palo Alto, California, where he was manager of the systems researchdepartment. From 1979 to 1990 he was a Senior Research Scientist at the MIT Laboratory for Informationand Decision Systems. He joined George Mason University and the C3I Center in 1990. In 1992, hereceived the Distinguished Faculty Award. Dr. Levis is a Fellow of the Institute of Electrical and ElectronicEngineers (IEEE) and past president of the IEEE Control Systems Society from which he received in 1987the Distinguished Member Award. He is also a Fellow of the American Association for the Advancementof Science (AAAS), a member of AFCEA, and a senior member of AIAA. Dr. Levis’ research interestsfor the last 15 years include architectures for command and control, organization theory and design, humandecision making, and distributed intelligence systems. He has published over 13 papers and many bookchapters and has coedited three volumes on The Science of Command and Control published by AFCEA.

Lee W. Wagenhals is a Research Associate Professor with the Center of Excellence Command, Control,Communications, and Intelligence at George Mason University in Fairfax, Virginia. He is associated withthe System Architectures Laboratory. His education includes the B.S. in electrical engineering from LehighUniversity (1965), the M.S. from the Air Force Institute of Technology (1971), and the Ph.D. inInformation Technology from George Mason University (2000). He has taught graduate and undergradu-ate System Engineering courses in modeling and analysis of dynamic systems at George Mason University(1996-98). Dr. Wagenhals has over 20 years of experience with the U.S. Air Force where he served onseveral assignments in area of both the operations and the research and development of C3 systems. Heserved for 5 years with the secretariat of the Air Force Scientific Advisory Board and participated in fivesummer studies on topics ranging from integrated avionics, to Global Reach Global Power. He joinedGeorge Mason University in 1992 where he has worked on a variety of research tasks related to C3 ofBallistic Missile Defense and the design and analysis of information systems architectures for the IRS.He was selected for the Army Summer Faculty Research Program in 1995 and performed research ondigitization of the Battlefield for the Army Operational Test and Evaluation Command. Dr. Wagenhals’research interests include the design and evaluation of C3 and information systems architectures todistributed decision-making systems.


c4isr architectures: i. developing a process for c4isr architecture design

Documents