Extending DoDAF To Allow Integrated DEVS-Based
Extending DoDAF to Allow IntegratedDEVS-Based Modeling and SimulationSaurabh MittalArizona Center of Integrative Modelingand Simulation (ACIMS)ECE Department, University of ArizonaTucson, AZ 85721saurabh@ece.arizona.eduA recent DoD mandate requires that the DoD Architecture Framework (DoDAF) be adopted to express high-level systemand operational requirements and architectures. DoDAF is the basis for integrated architectures and provides broad levelsof specification related to operational, system, and technical views. The combination of DoDAF operational views, whichcapture the requirements of the architecture, and systems views, which provide its technical attributes, forms the basisfor semi-automated construction of the needed simulation models. Unfortunately, DoDAF doesn’t mandate any simulationmethodology to analyze the system or perform any pre-design feasibility studies. In this paper, we describe an approachto support specification of DoDAF architectures within a development environment based on DEVS (Discrete EventSystem Specification). The result is an enhanced system life cycle development process that includes both developmentand testing in an integral manner. We introduce two new operational views (OVs) in the current DoDAF making way formodeling and simulation as a part of the design process. We illustrate the process to build these new OVs from the existingOVs and their impact on the overall DoDAF system development process. We discuss automated model generation usingXML through the introduced OVs, which paves the way for OVs to become service-providing components in the webservices architecture.Keywords: DoDAF, simulation-based design, DEVS, bifurcated development process, operational view, model continuity,SOA1. IntroductionA recent DoD mandate requires that the DoDArchitecture Framework (DoDAF) be adopted toexpress high-level system and operational requirementsand architectures [1]. DoDAF is the basis for theintegrated architectures mandated in DoD Instruction5000.2 [2] and provides broad levels of specificationrelated to operational, system, and technical views.Integrated architectures are the foundation forinteroperability in the Joint Capabilities Integrationand Development System (JCIDS) prescribed in CJCSI3170.01D and further described in CJCSI 6212.01D [3,4]. DoDAF and other DoD mandates pose significantchallenges to the DoD system and operationalarchitecture development and testing communitiessince DoDAF specifications must be evaluated tosee if they meet requirements and objectives, yetJDMS, Volume 3, Issue 2, April 2006 Pages 95–123 2006 The Society for Modeling and Simulation Internationalthey are not expressed in a form that is amenable tosuch evaluation. However, DoDAF-compliant systemand operational architectures do have the necessaryinformation to construct high-fidelity simulations.Such simulations become, in effect, the executablearchitectures referred to in the DoDAF document.DoDAF is mandated for large procurement projectsin the Command and Control domain but its use inrelation to modeling and Simulation (M&S) is notexplicitly mentioned in the documentation [5, 8]. Thusan opportunity has emerged to support the translationof DoDAF-compliant architectures into models thatare of sufficient fidelity to support architecturalevaluation in capable simulation environments.Operational views capture the requirements of thearchitecture being evaluated and system viewsprovide its technical attributes. Together these viewsform the basis for semi-automated construction of theneeded simulation models.DoDAF is a framework prescribing high-level design
Mittalartifacts, but leaves open the form in which the viewsare expressed. A large number of representationallanguages are candidates for such expression. Forexample, the Unified Modeling Language (UML)and colored Petri nets (CPN) are widely employed insoftware development and in systems engineering.Each popular representation has strengths thatsupport specific kinds of objectives and cater to itsuser community needs. By going to a higher level ofabstraction, DoDAF seeks to overcome the plethoraof “stove-piped” design models that have emerged.Integration of such legacy models is necessary fortwo reasons. Firstly, as systems, families of systems,and systems-of-systems become more broad andheterogeneous in their capabilities, the problems ofintegrating design models developed in languageswith different syntax and semantics has become aserious bottleneck to progress. Secondly, anotherrecent DoD mandate also intended to break downthis “stove-piped” culture requires the adoption ofthe Service Oriented Architecture (SOA) paradigmas supported in the development of Network CentricEnterprise Services (NCES) [6]. However, anecdotalevidence suggests that a major revision of the DoDAFto support net-centricity is widely considered tobe needed. Indeed, under DoD direction, severalcontractors have begun to design and implementthe NCES to support this strategy on the GlobalInformation Grid (GIG). The result is that systemdevelopment and testing must align with this mandate(requiring that all systems interoperate in a net-centricenvironment), a goal that can best be done by havingthe design languages be subsumed within a moreabstract framework that can offer common conceptsto relate to. However, as stated before, DoDAF doesnot provide a formal algorithmically-enabled processto support such integration at higher resolutions.Lacking such processes, DoDAF is inapplicable tothe SOA domain, and GIG in particular. There havebeen efforts, such as those by Dandashi et al. [7], thathave tried to map DoDAF products to SOA, but as itstands there is no clear-cut methodology to develop anSOA directly from DoDAF, let alone their testing andevaluation.Our earlier work [8] and that of Zeigler et al. [9]described the bifurcated model continuity–basedsystem lifecycle process. In this paper we will exploreit in more detail with respect to technologies like XMLand UML with their application to DoDAF. Our earlierwork [8] also explored the possibility of application ofDEVS to the DoDAF design process and developeda mapping between various UML elements and theDEVS formalism. It considered all three elements ofthe DoDAF, viz., operational view (OV), system view(SV), and technical view (TV), and their mapping with96 JDMS Volume 3, Number 2DEVS components. In this paper we will establishthat enhancing DoDAF would require extendingthe DoDAF with more information. We will focuson the proposed extension of DoDAF and examinethe information needed to execute the developmentprocess. We will demonstrate the procedure and theway in which M&S can be applied with the help of anexample. We will also discuss the application of theproposed views. This discussion will show how theenhanced DoDAF can effectively support developmentof services in SOA environments.Sections 2 and 3 provide some background onDoDAF views and DEVS specifications, respectively.Section 3 also discusses the key component technologiesinherent in DEVS and principles of model continuity.Section 4 describes the idea behind mapping DoDAFinto DEVS framework. Section 5 throws light on theprior efforts to employ M&S as an integrated solutionto evaluate architectures, and highlights some problemareas encountered. It also discusses the current M&Ssituation and how DEVS provide solutions to theseproblems. Section 6 describes the bifurcated modelcontinuity process, the basis for our approach. Section7 discusses some gaps in DoDAF and proposessolutions on how to fill them. Sections 8 and 9 presentthe detailed methodology on how to transition fromUML description to DEVS specifications. Section 9also provides the justification of this mapping process.Section 10 provides a full example on how the proposedviews are constructed and their significance to M&Sareas. Section 11 leads the present discussion towardthe benefits of this work in immediate future, followedby conclusions in section 12.2. DoDAF SpecificationsThe Department of Defense (DoD) ArchitecturalFramework (DoDAF), Version 1.0 (2003), defines acommon approach for DoD architecture descriptiondevelopment, presentation, and integration. Theframework enables architecture descriptions tobe compared and related across organizationalboundaries, including joint and multinationalboundaries.DoDAF is an architecture description, and itdoes not define a process to obtain or build thedescription. The Deskbook [1] provides one methodfor development of IT architectures that meet DoDAFrequirements, focusing on gathering informationand building models required to conduct design andevaluation of an architecture. The DoDAF definesthree elements for any architecture description:1) Operational View (OV) - The OV is a descriptionof the tasks and activities, operationalelements, and information exchanges required
Extending DoDAF to Allow Integrated DEVS-Based Modeling and SimulationFigure 1. Linkages among viewsto accomplish DoD missions. DoD missionsinclude both war-fighting missions and businessprocesses. The OV contains graphical andtextual products that comprise an identificationof the operational nodes and elements,assigned tasks and activities, and informationflows required between nodes. It defines thetypes of information exchanged, the frequencyof exchange, which tasks and activities aresupported by the information exchanges, andthe nature of information exchanges.2) System View (SV) - The SV is a set of graphicaland textual products that describes systems andinterconnections providing for, or supporting,DoD functions. DoD functions include bothwar-fighting and business functions. The SVassociates systems resources to the OV. Thesesystems resources support the operationalactivities and facilitate the exchange ofinformation among operational nodes. Withinthis view, how the functionalities specified in OVwill be met is elaborated.3) Technical View (TV) - The TV is the minimal setof rules governing the arrangement, interaction,and interdependence of system parts or elements,whose purpose is to ensure that a conformantsystem satisfies a specified set of requirements.Within this view, the delivery of systems andfunctionalities is ensured along with theirmigration strategies toward future standards.These views provide three different perspectives forlooking at an architecture. The emphasis of DoDAF . Operational node: A node specified in OV that performs oneor more operations; a functional entity that communicates withother functional entities to implement a collective functionality ora capability.lies in establishing the relationship between these threeelements ensuring entity relationships and supportinganalysis; see Figure 1. The DoDAF approach isessentially data-centric rather than product-centric.The OV, SV, and TV are further broken down intospecialized views whose brief description can be seenin column 3 in Table 3 ahead, as well as in the appendix.A complete description can be see in [1, 14].3. DEVS System SpecificationsIn this section, we review some of the backgroundrequired for discussion DEVS support of DoDAF.3.1 Hierarchy of System SpecificationsSystems theory deals with a hierarchy of systemspecifications, which define levels at which a systemmay be known or specified. Table 1 shows thishierarchy of system specifications (in simplified form,see [10]). At level 0 we deal with the input and outputinterface of a system. At level 1 we deal with purely observationalrecordings of the behavior of a system. This is anI/O relation that consists of a set of pairs of inputbehaviors and associated output behaviors. At level 2 we have knowledge of the initial statewhen the input is applied. This allows partitioningthe I/O pairs of level 1 into non‑overlappingsubsets, each subset associated with a differentstarting state. At level 3 the system is described by state spaceand state transition functions. The transitionVolume 3, Number 2JDMS 97
Mittalfunction describes the state-to-state transitionscaused by the inputs and the outputs generatedthereupon. At level 4 a system is specified by a set ofcomponents and a coupling structure. Thecomponents are systems on their own with theirown state set and state transition functions. Acoupling structure defines how those interact.A property of a coupled system, which is called“closure under coupling,” guarantees that acoupled system at level 3 itself specifies a system.This property allows hierarchical constructionof systems, i.e., that coupled systems can beused as components in larger coupled systems.Table 1. Hierarchy of system specificationsLevelNameWhat we specify at this levelCoupledSystemsSystem built up by severalcomponent systems that arecoupled togetherI/O SystemSystem with state and statetransitions to generate thebehavior2I/OFunctionCollection of I/O pairs constitutingthe allowed behavior partitionedaccording to the initial state thesystem is in when the input isapplied1I/OBehaviorCollection of I/O pairs constitutingthe allowed behavior of the systemfrom an external black-box view0I/O FrameInput and output variables andports together with allowed values43As we shall see in a moment, the system specificationhierarchy provides a mathematical underpinning todefine a framework for modeling and simulation. Eachof the entities (e.g., real world, model, simulation, andexperimental frame) will be described as a systemknown or specified at some level of specification. Theessence of modeling and simulation lies in establishingrelations between pairs of system descriptions. Theserelations pertain to the validity of a system descriptionat one level of specification relative to another systemdescription at a different (higher, lower, or equal)level of specification.Based on the arrangement of system levels asshown in Table 1, we distinguish between vertical andhorizontal relations. A vertical relation is called anassociation mapping and takes a system at one level ofspecification and generates its counterpart at anotherlevel of specification. The downward motion in thestructure-to-behavior direction formally represents98 JDMS Volume 3, Number 2the process by which the behavior of a model isgenerated. This is relevant in simulation and testingwhen the model generates the behavior which thencan be compared with the desired behavior.The opposite upward mapping relates a systemdescription at a lower level with one at a higher levelof specification. While the downward associationof specifications is straightforward, the upwardassociation is much less so. This is because in theupward direction information is introduced whilein the downward direction information is reduced.Many structures exhibit the same behavior, andrecovering a unique structure from a given behavioris not possible. The upward direction, however, isfundamental in the design process where a structure(system at level 3) has to be found that is capable ofgenerating the desired behavior (system at level 1).3.2 Framework for Modeling & SimulationThe framework for M&S as described by Zeigler et al.[10] establishes entities and their relationships that arecentral to the M&S enterprise; see Figure 2. The entitiesof the framework are source system, experimental frame,model, and simulator; they are linked by the modelingand the simulation relationships. Each entity is formallycharacterized as a system at an appropriate level ofspecification within a generic dynamic system. See[10] for detailed discussion.3.3 Model ContinuityModel continuity refers to the ability to transition asmuch as possible of a model specification throughthe stages of a development process. This is theopposite of the discontinuity problem where artifactsof different design stages are disjointed and thuscannot be effectively consumed by each other. Thisdiscontinuity between the artifacts of different designstages is a common deficiency of most design methodsand results in inherent inconsistency among analysis,design, test, and implementation artifacts [11]. ModelFigure 2. Framework entities and relationships
Extending DoDAF to Allow Integrated DEVS-Based Modeling and Simulationcontinuity allows component models of a distributedreal-time system to be tested incrementally, and thendeployed to a distributed environment for execution.It supports a design and test process having four steps;see [11]:1) Conventional simulation to analyze the systemunder test within a model of the environmentlinked by abstract sensor/actuator interfaces;2) Real-time simulation, in which simulators arereplaced by a real-time execution engines whileleaving the models unchanged;3) Hardware-in-the-loop (HIL) simulation, in whichthe environment model is simulated by a DEVSreal-time simulator on one computer while themodel under test is executed by a DEVS real-timeexecution engine on the real hardware; and4) Real execution, in which DEVS models interactwith the real environment through the earlierestablished sensor/actuator interfaces that havebeen appropriately instantiated under DEVSreal-time execution.Model continuity reduces the occurrence of designdiscrepancies along the development process, thusincreasing the confidence that the final system willrealize the specification as desired. Furthermore,it makes the design process easier to manage sincecontinuity between models of different design stagesis retained.4. Motivation for DoDAF-to-DEVS MappingThe DoDAF suffers from following shortcomings:1) Although there is mention of “executablearchitectures” in DoDAF, there is no methodologyrecommended by DoDAF that would facilitatethe development of executable DoDAF models.2) It has completely overlooked the model-drivendevelopment approach. Consequently, there isno formal M&S theory that DoDAF mandates.3) DoDAF fails to address performance issues at theOV level.4) DoDAF fails to include measures of effectiveness(MoEs) that can be evaluated at the OV stage. Ifany performance measures are considered at all,they are at the SV level. System parameters andperformance is at a totally different resolutionthan MoEs.5) There is no mechanism to perform verificationand validation (V&V) at the OV stage.6) It fails to address M&S as a potent evaluation andacquisition tool.We propose a mapping of DoDAF architecturesinto a computational environment that incorporatesdynamical systems theory and an M&S framework.The methodology will support complex informationsystems specification and evaluation using advancedsimulation capabilities. Specifically, the Discrete EventSystem Specification (DEVS) formalism will providethe basis for the computational environment withthe systems theory and M&S attributes necessary fordesign modeling and evaluation. We will see in theforthcoming sections that the proposed mapping willrequire augmentation of current DoDAF with moreinformation set that is far from any duplication of theavailable DoDAF products.We will demonstrate how this information isadded and harnessed from the available DoDAFproducts toward development of an extended DoDAFintegrated architecture that is “executable.” This kindaugmentation has been attempted earlier by Lee et al.[12] using CORE of the Vitech Corporation as a tool todevelop the executable architecture. They developed“architectural templates” that elicit information forboth the operational and system views that containedadditional information than the usual DoDAFproducts. In another effort, Rosen et al. [13] proposeda new model called the Rosen-Parenti model that addsanother layer of abstraction to the existing DoDAF,augmenting the model with various user-orientedperspectives. Going further, they developed theexecutable architecture with their proposed modeland showed how V&V is applicable in their domain.Their model unearthed a shortcoming of DoDAF:it fails to address the performance issue at the OVlevel, which the Rosen-Parenti model addressed inone of their perspectives. In our attempt to augmentthe current DoD
enhanced DoDAF can effectively support development of services in SOA environments. Sections 2 and 3 provide some background on DoDAF views and DEVS specifications, respectively. Section 3 also discusses the key component technologies inherent in DEVS and principles of model continuity. S
The Department of Defense Architecture Framework (DoDAF) defines a standard way to organize an enterprise architecture (EA) into complementary and consistent views and models. TONEX DoDAF training boot camp covers both DoDAF 1.5 and migration to DoDAF 2.0. In our hands-on 3 day DoDAF training you will use our
IBM Software Group Rational software 2009 IBM Corporation 5 DoDAF 2.0 Ju n e 2 0 0 9 2 0 0 2 C4ISR Framework 1 9 9 9 DoDAF 1.0 2 0 0 7 DoDAF 1.5 2 0 0 8 MODAF 1 .
DoDAF 2.0 elaborates on this definition, defining “integrated” to mean that “data required in more than one instance in architectural views is commonly understood across those views” (DoDAF v2.02008) . One intended application for this research is
architectures, such as captured in DoDAF or comparable frameworks, it becomes ob vious that the objective of these efforts is the use of dynamic simulation software to evaluate architecture models [5]. However, the current research is more concerned about concrete methods and tools, like the use of DEVS and DoDAF, the use of CPN
process, abstrated products and tailored meta-models based on DoDAF Meta Model (hereafter, DM2). 1The Department of Defense Archit ecture Framework (DoDAF) is an architecture framework for the United States Department of Defense, that provides structure for a specific stakeholder concern through viewpoints organized by various views. (quoted from
Views. However, other regulations and instructions from the DoD and the Chairman, Joint Chiefs of Staff (CJCS) have particular presentation view requirements. The architect and stakeholders select views to ensure that the Architectural Descriptions will support current and future states of the process or activity under review. Selecting
work/products (Beading, Candles, Carving, Food Products, Soap, Weaving, etc.) ⃝I understand that if my work contains Indigenous visual representation that it is a reflection of the Indigenous culture of my native region. ⃝To the best of my knowledge, my work/products fall within Craft Council standards and expectations with respect to
Abrasive Jet Machining INTRODUCTION Abrasive water jet machine tools are suddenly being a hit in the market since they are quick to program and could make money on short runs. They are quick to set up, and offer quick turn-around on the machine. They complement existing tools used for either primary or secondary operations and could make parts quickly out of virtually out of any material. One .
