Modeling Time in DoDAF Compliant Executable Architectures

Paper #56

Modeling Time in DoDAF Compliant Executable Architectures1 Ashraf AbuSharekh 2 , Smriti Kansal, Abbas K. Zaidi, Alexander H. Levis System Architectures Laboratory, ECE Dept., MS 1G5 George Mason University, Fairfax, VA 22030 , , , @gmu.edu

Abstract The paper describes some challenges and pitfalls in the derivation of the executable model from the DoDAF products, especially when temporal and queuing issues are involved. The presence of ambiguities or lack of information in the architecture description may result in different modeling assumptions for the executable model being constructed. These assumptions – untraceable to the information contained in the DoDAF products – are shown to yield models with a variety of behavioral properties. The paper describes some of these cases with the help of an illustrative example. (Prior knowledge of DoDAF and Colored Petri Nets is required to fully understand the material in this paper.)

Introduction The architectural models must be capable of providing insight into the logical and behavioral aspects of the architecture and the performance aspects of systems that are to be designed and built conformant to the architecture. This important criterion influences the process and the techniques for developing an architecture of a system.

Systems Architecting (Rechtin, 1991, 1992; Rechtin and Maier, 1996) is part of the systems engineering process and relies on many of the methodologies that have been developed over time. The architect has many tools and techniques available to describe the architecture. Two fundamental approaches for designing architectures that are conformant to the DoD Architecture Framework (DoDAF), one based on structured analysis and one on object orientation, have been proposed by Levis and Wagenhals (2000), Wagenhals et al. (2000, 2003), and Bienvenu et al. (2000). The end product in both cases is an executable model derived from information contained in the DoDAF’s artifacts. It must be noted that the derivation of this executable model is not mandated by the framework. The artifacts (or products) in DoDAF describe the structure, data and rules that manipulate the data to accomplish tasks. However, the analysis of the logic, behavior and performance of the architecture cannot be done on the framework products since these are mere static representations of a dynamic system; the derived executable model is required for the analyses. An executable model of the operational view, when derived from these products in a traceable way, can enable logical and behavioral analyses: it can help verify if the combination

1

The work was carried out with support provided by the Office of Naval Research under contract number N00014-06-1-0081.

2

Corresponding author

CSER 2007, Stevens Institute of Technology , ISBN - 0-9787122-1-8 PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

1

of rules, data, and structure works. The executable model of the systems view enables, in addition, performance analyses. The derivation of either executable model from the architectural products reveals the fact that the model requires more specific and comprehensive information than is available in the products, especially concerning temporal aspects. The derivation of the executable model, therefore, cannot be made fully automatic or algorithmic when only the DoDAF products are used. This results in a number of additional modeling assumptions, decisions taken, and modeling artifacts added to the partial model that is directly derivable from the information available in the DoDAF products. These issues are described with the help of an executable architecture developed for an illustrative Air Interdiction (AI) system (Levis and Wagenhals, 2006). In this system, shown in Fig. 1, an ISR node is tasked with sensing/detecting incoming, engaged, and killed threats. The ISR node generates a tactical picture according to the threat status and sends it to the other nodes in the system. The incoming threats move at different speeds according to the type they are and raise issues regarding time-sensitive targeting. Because the DoDAF products do not include explicitly temporal specifications, the rules do not specify if these threats are queued for processing at the ISR node or mention anything regarding concurrency and asynchronous behavior, e.g., what is the ISR node’s response should an unknown incoming threat and a report on an old killed threat arrive at the same time?

Figure 1. Operational Concept Graphic.

To cite another example, in the AI architecture, a Control node is shown to schedule interceptors to engage threats. The available information in the products does not specify the order, if any, in which an interceptor is selected among several to engage the threat. A modeler, on the other hand, needs to decide on these issues, e.g., assign priorities to the threats, implement priority queue(s), and/or determine some selection criterion for the interceptors, before compiling the executable model. The choice of decisions or assumptions is shown to yield executable models with drastically different behaviors and performance results, thus compromising the entire effort of architecting. The next section describes the process of synthesizing an executable model from DoDAF artifacts. The following two sections describe the AI system in greater detail and give a step-by-step process to generate the DoDAF products and finally the executable model. Finally, examples are used to discuss possible ways to address temporal challenges and avoid the unintended propagation of modeling assumptions throughout the architectural products.

Synthesis of Executable Model from DoDAF Information Systems are dynamic in nature. Events occur that trigger the execution of functions; many can be executed concurrently. An executable model of an information architecture enables the architect to analyze its dynamic behavior, identify logical and behavioral errors not easily seen in the static descriptions, and demonstrate to the customer or user the capabilities that the architecture enables. The executable model can be used to carry out state space analysis and to conduct computational experiments using different simulation scenarios. DoD Architecture Framework. The Framework represents a different perspective from that of a traditional structured analysis approach. The DoDAF products are grouped into four views: All View (AV), Operational 2

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

Architecture View (OV), Systems Architecture View (SV), and the Technical Standards View (TV). Each view describes a particular characterization of the architecture using a set of products that are graphical, tabular, or textual. A detailed formal description of these products is given in Volume II of the DoDAF. Fig. 2 shows the template for the architecture design process (Wagenhals et al., 2003). An executable model can be derived from the Operational Architecture View alone. Such a model can only address logical and behavioral issues. To address performance questions, the System Architecture View is required. Generation of DoDAF Artifacts. A sixstage process has been developed to generate the Framework products using the structured analysis approach (Wagenhals et al., 2000). These stages are briefly described here. Stage 1: The first step of any architectural effort involves the collection of domain information. This includes Problem Definition (AV-1), Operational Concept Narrative, Universal Joint Task List (UJTL), Description of Organizational Relationships, etc. Stage 2: This uses the operational concept narrative and the problem definition to generate the High Level Operational Concept Graphic. Stage 3: This stage uses the UJTL and the operational concept to determine the functions that need to be performed. It also processes the list of potential organizations and their relationships to generate the Organizational Relationships Chart, OV-4.

Stage 4: The architect performs the bulk of the architecture design in this stage. He creates a functional architecture, composed of the activity model (OV-5), the logical data model (OV7) and the rule model (OV-6a). The desired behavior is captured in state transition diagrams (OV-6b). An initial system view of the architecture is also generated composed of system nodes, components and elements. Stage 5: The remaining OV products are created in this stage using the information and models created in Stage 4. Important analysis needed to create the SV products is also done. Stage 6: This stage is dedicated to completing the SV products using information from both Stages 4 and 5. Executable Model. An executable model of the architecture can be derived using the information and models produced during Stage 4 of the process. The executable model is derived from four models of the architecture: the activity model (IDEF0), the data model (IDEF1X), the rule model and the state transition diagram. These four models are tightly coupled and need to be consistent with one another. Elements from each are transferred to the Colored Petri (CP) Net model. It is very important that no extra information be added to the Petri net that is not contained in one of the models. Any changes made to the Petri net must be reflected back in the models and the Framework products derived from them.

Figure 2. Architecting Process 3 PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

Synthesis of an executable model from a structured analysis process is explained in detail in Wagenhals et al. (2000). The activity model forms the basis of the Petri net models as each IDEF0 activity is converted into a transition and each IDEF0 arrow is replaced by an arc-place-arc combination. The information in the data model (IDEF1x) is used to specify the color sets and their respective domains while the rules in the rule model result in arc inscriptions, guard functions and code segments. Finally the state transition diagram reflects the initial conditions of the CP Net and the states the model should progress through from the initial state. It is used to verify that the model executes properly.

Air Interdiction Example The challenges faced in transitioning from DoDAF products to the executable model following the steps outlined in the previous section are now explained using the illustrative Air Interdiction (AI) System example. The operational concept description of the problem (Fig. 1) is given as follows: The AI system will protect a restricted area against intruders (threats). When an intruder is detected, an aircraft is sent out to intercept it. According to the level of hostility, the rules of engagement take different forms; during wartime, the interceptor shoots at the intruder without any warning. During peacetime the interceptor attempts to contact the intruder and signals it. The interceptor will then shoot at the threat if there is no reply. The threat must be destroyed within a specified time else it will be termed a leaker. The operational concept graphic (OV-1) that goes with this description was shown in Fig. 1. AI – DoDAF Artifacts. Based on this information, the Framework products and subsequently the executable model are derived for the AI System using the 6-stage structured analysis process. In the second stage, a

list of required functions and the corresponding decomposition are prepared with the help of UJTL and the operational concept. Figure 3 presents the functional decomposition for the AI System. The activity model (OV-5), derived directly from the functional decomposition in Fig. 3, is shown in Fig. 4 as IDEF0 diagrams describing different levels of the decomposition. The other OV products developed in Stage 3 are the logical data model (OV-7), the rule model (OV-6a), and state transition diagrams (OV6b). For the AI System, these products are shown in Figs. 5-7. Conduct AI

Sense

Command

Act

Control

Engage

Figure 3. Functional Decomposition. Since the synthesis of an executable only requires the four products that have already been presented, the other products in the 6stage process are not described here.

Purpose: Conduct the operations of the AI System. Viewpoint: System Architect (a) Context Diagram

(b) First Level of Decomposition.

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

4

(c) Act Page Diagram

Figure 4. Activity Model (OV-5). DoDAF Artifacts to Executable Model. Following the approach of Wagenhals et al. (2000), an executable model for the AI System is derived from the following models: 1.Activity Model (IDEF0), shown in Fig. 4. 2.Data Model (IDEF1x). 3.Rule Model, shown in Fig. 5. 4.State Transition Diagram, shown in Fig. 6. A step-by-step description of the Colored Petri net construction from the four models is presented in Fig. 7. The conversion of the activity model, Fig. 4, to a corresponding hierarchical CP Net is straightforward, as described in Step 1, Fig. 7. Fig. 8 shows the three pages of the CP Net corresponding to the three IDEF0 diagrams in Fig. 4. The color sets associated with places in the CP Net (Fig. 8) are derived from the logical data model . The net in Fig. 8 requires further work to execute. Each transition in the net needs to be linked to a sub-page with detailed implementation of the function depicted by the transition. In most cases, a fully executable implementation can be derived with the help of rules in the rule model (Fig. 5); however, in some instances this implementation requires more specific and comprehensive information than is available in the products. This is usually the case when temporal issues associated with system functions and synchronization of time-sensitive information/processes are of importance.

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

Figure 5. Rule Model (OV-6a)

Figure 6. State Transition Diagram (OV-6b).

5

1. Start with IDEF0 (OV-5) 1.1.The hierarchical structure of IDEF0 diagrams becomes the hierarchical structure of the CP Net. Each leaf node in the functional hierarchy in IDEF0 becomes a sub-page CP Net with detailed implementation of the corresponding function. 1.2.Each IDEF0 activity is converted to a Transition on the corresponding page in the CP Net hierarchy. 1.3.Each IDEF0 link connecting two activities is converted to an arc-place arc combination in the CP Net. 1.4.The label of IDEF0 link in 1.3 becomes the Color Set associated with the Place in the arc-place arc combination. 2. Use IDEF1x (Logical Data Model, OV7) 2.1.IDEF1x entities are used to derive the names and elements of Color Sets in the Global Declaration Node. 3. Use Rule Model (OV-6a) to construct Arc Expressions, Guard Functions, and Code Segments in the CP Net. 4. Use State Transition Diagram (OV-6b) to validate key-threads and behavior of the system as described in the state transition diagrams. Figure 7. Steps in Construction of CP Net. For example, if the CP Net is to be populated with service time delays associated with system functions and/or the communication delays associated with synchronization of information in the system, then the information in the four products used to derive the CP Net does not readily map to the time constructs in the CP Net formalism. There exists formal constructs in CP Nets for incorporating different notions of time required to model discrete-event systems: An item of information, or token in CP Nets can carry a time stamp depicting the time of its availability in the system. A time delay can be assigned to a transition representing

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

its processing time, i.e., any token that is processed by the transition gets its time stamp updated by an amount determined as a function of this delay. Similarly, an arc connecting a transition to one of its output places can also be modeled with a delay assigned to it. The notion of input/output buffers attached to system functions and to record the time it might take a token to reside in one require special CP modeling artifacts in addition to the one described here. Rules_of_Engagement R_O_E1

Threat

1`peace

Not Engaged

Threat

Threat

Threat

Conduct AAI

Killed

CondAAW

Threat Leaked

(a) CP Net for Context Diagram Rules_of_Engagement R_O_E1 SurveillanceDirective 1`(0,0,default) Surveillance Directive

In

Threat Threat I/O

Sense Sense

TacticalPicture Tactical Picture1 Order Report

Command

Report

Order

Threat

Command

Not Engaged Out

TacticalPicture Tactical_ Picture2

Threat Act

Killed Out

Act

Threat Leaked Out

(b) Conduct AAI Subpage CP Net (see Fig. 4b) Order In

Order

TacticalPicture

Report

Tactical_ Picture2 In

Issue Controls

Report Out

Control

InterceptorID InterceptorID

ControlToInterceptor

ControlTo 1`1++1`2++1`3++1`4 Interceptor Threat Not Engaged Out

Threat Threat I/O

Threat Engage Engage

Out

Killed

Threat Leaked Out

(c) Act Page CP Net

Figure 8. CP Net Derived from the Activity Model. 6

The time it takes a system function to execute, or the time it takes an item of information to go from one function to another, or the time it takes a function to sequence and service multiple inputs is not explicitly modeled in the four products used to derive the executable CP Net (i.e., there are no formal requirements/constructs in the modeling approaches used to develop the products, and the need to incorporate this information is often overlooked.) Although the synthesis approach presented in Fig. 7 employs state transition diagrams (OV-6b) for validating some of the key-threads obtained after the executable is constructed, some (not all) of the sequencing information can be extracted for constructing the CP Net from the state transition diagrams for the input scenarios for which such diagrams are available. The state-space analysis of the CP formalism allows one to generate a state-transition diagram for a CP system (i.e., a CP Net with an input scenario.) Incidentally, a statetransition diagram (state-space) generated from a CP Net with temporal parameters contains more information than the statetransition diagrams used to construct OV-6b. For example, a node in a state-space contains time of its creation and depicts time stamps on state variables. The time of a transition between two states is also recorded in this state-space. With no clear mapping to/from the architectural products to this temporal information, it becomes necessary to add a number of modeling assumptions, decisions, and modeling artifacts to the CP Net. We now illustrate a couple of such cases for the AI System under consideration. These cases are encountered while an attempt is made to construct a detailed implementation for the transition ‘Sense’ in Fig. 8b. A CP Net constructed for this function is shown in Fig. 9. The four transitions in the CP Net of Fig. 9 correspond to the four rules in the rule model for the ‘Sense’ function (Fig. 5.) For the sake of brevity, we do not

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

present detailed implementations for the other transitions in Fig. 8. SurveillanceDirective Surveillance I/O Directive

SENSE #4

(tid,iid,assess_kill) (tid,iid,track_interc) (tid,iid,track_interc)

(0,0,default)

(tid,iid,track_interc) (0,0,default) (tid,incoming,0,tsd,te)

TacticalPicture (tid,0,new)

Rule_S1

Tactical Picture1 (tid,0,new) Out

@+5 Threat Threat I/O

1`res

(tid,sensed,0,Inttime(),te) (tid,sensed,0,tsd,te)

1`res

(tid,sensed,iid,tsd,te)

1`res

@+2

(tid,engaged,iid,tsd,te) (tid,engaged,iid,tsd,te)

Resources

1`res

Associate tracks

Rule_S2 @+5

(tid,destroyed,iid,tsd,te)

Resources

1`res

1`res

1`res

1`res TacticalPicture 1`res Tactical_ (tid,iid,infiringrange) Picture2 Out

Rule_S3

(tid,iid,killed)

@+7

Figure 9. Detailed Implementation for ‘Sense’ Transition.

Temporal Challenges and Problems Temporal aspects of the AI system were modeled using token timestamps to represent inter-arrival delays, transition delays to represent processing delays and arc delays to represent communication and propagation delays. A scenario driver was used to generate a variable number of INCOMING Threats with constant inter-arrival time using the Threat token timestamp. Processing delays were modeled using transition delays; Table 1 shows the processing delays of the ‘Sense’ node. Arc delays were only used to model the return delay of an interceptor after engaging a Threat in the ‘Engage’ node. All other communication and propagation delays are assumed negligible. Table 1: Delays Function Delay Rule_S1 5 Rule_S2 5 Rule_S3 7 Associated tracks 2 Case #1: An initial marking of the CP Net for the AI System consists of multiple tokens representing as many INCOMING

7

threats. These tokens are sensed/processed by the ‘Sense’ function. The DoDAF products do not include specification of a scenario that would generate timed state transition diagrams. The following is an illustration of the diversity in simulation results when different assumptions are made. In the first case, it is assumed that the ‘Sense’ function randomly chooses one of the INCOMING threats (available at a given simulation time) at the Threat place. Three interceptors are available and ten threats are input to the system with a constant interarrival time of 3 time units, as shown in the first two columns of Table 2. The times at which these inputs are sensed by the system, are listed in column 3 of the table. Results from the simulation are shown as follows: the interval between the arrival time and sensed time is plotted in Fig. 10, while the arrival time and end-to-end processing time taken by the threats is listed in Table 2. Table 2: Input and Simulation Results Threat ID 1 2 3 4 5 6 7 8 9 10

Incoming at 0 3 6 9 12 15 18 21 24 27

Sensed at 0 5 45 10 15 20 40 35 25 30

In the simulation result (Table 2) a threat with ID 3 arrives at time 6, but gets processed (i.e., Command and Control nodes were notified of the threat through a new tactical picture) at time 45, while all threats that arrived after it are processed earlier. A delay in processing at the input may inadvertently result in a leaked threat at the output. This might result in an un-realistic estimate for the number of leaked threats. A possible suggested solution for this problem

is to assume a strict first come first serve (FIFO) selection policy at the input. Figure 11 shows the plots for simulation results for the AI System run with the FIFO policy at the input.

Figure 10. Simulation Results for Random Selection Policy. The point, however, is that this information is not provided by any of the architectural products developed for the AI System. The absence of this information may not be realized by an architect until he tries to construct and/or simulate the executable model.

8 PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

the lack of a well-specified selection policy may also result in run-time choices that do not make any sense in the real-world. For example, if two threats are available at the input of the ‘Sense’ function, one is a new INCOMING threat, and the other is a KILLED threat, a random selection policy in this situation may prefer the KILLED threat over the INCOMING for further processing. A possible suggested solution here is to assign some priority based scheme for the threats to be processed. While such a priority scheme could be incorporated in the rule model, it rarely is because the DoDAF does not address concurrency and resource contention issues. Our suggestion is to embed these decisions in the rule model as shown in Table 3. Table 3. Queuing Disciplines

Figure 11. Simulation Results for FIFO Selection Policy. Case #2: In addition to INCOMING threats at the ‘Sense’ function, there are SENSED, ENGAGED, and KILLED inputs to the function as well. For each type of input, the rules in the rule model describe the corresponding processing required for the input: for an INCOMING threat, a new tactical picture is sent to Command and Act functions; for a SENSED threat, Associate Track function is called; for an ENGAGED threat, the firing range tactical picture is sent to Act; and for a KILLED threat, a kill tactical picture is sent to Act. Similar to the sequencing problem for the INCOMING threats illustrated in Case #1, there is no information available in the architectural products on any selection criterion for the four types of inputs. In case the executable model is implemented with a random selection policy, we encounter the same problem of over-estimating the leaked threats, as discussed in Case #1. In addition,

PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA

Function: Sense Function Discipline S1 FIFO S2 FIFO S3 FIFO S4 FIFO

Priority 1(highest) 3 4 2

In general, we suggest that all architecture specific assumptions should be made either a part of the operational concept narrative or an extension to the rule model needs to be defined that can incorporate them.

Conclusions DoDAF products describe the dynamics of the architecture using static representations. To evaluate the logical, behavioral and performance aspects of the architecture an executable model is required. The earlier work on derivation of an executable model from the DoDAF artifacts has claimed that the architecture products provide sufficient information for determining the structure and the information flows in the executable model of the architecture. In this paper, we have illustrated cases where the derivation 9

of a fully executable model requires more specific and comprehensive information than is available in the products, especially concerning temporal aspects. The derivation of the executable model, therefore, cannot be made fully automatic or algorithmic when only the DoDAF products are used. This paper has addressed a few of the specific issues; more focused research is needed to address the more general cases for codifying the information needed for a more comprehensive derivation of the executable model, and to exploiting the analysis and simulation opportunities provided by the executable models. A more challenging situation arises when the executable model based on the system view is developed. In that case, the performance parameter description (SV-7) can be used to record processing and communication delays. If the executable model is used in simulation mode to obtain performance metrics, then the following data sets need to be added to the DoDAF description of the architecture: (a) Sets of initial conditions; (b) scenarios that characterize changes in the performance parameters over time (scenario), and (c) an additional set of rules that addresses concurrency and asynchronicity.

References Bienvenu M.P., Shin, I and Levis, A.H., "C4ISR Architectures III: An Object Oriented Approach for Architecture Design." Systems Engineering, Vol. 3, No. 4, December 2000, pp. 288-312. DoDAF V.1 Vol.II, DoD Architecture Framework Version 1.0. Volume II: Product Descriptions, February 9, 2004. Levis, A.H. and Wagenhals, L.W., “C4ISR Architectures I: Developing a Process for C4ISR Architecture Design.” Systems Engineering, Vol. 3, No. 4, December 2000, pp. 225-247.

Levis A. H. and Wagenhals, L. W., “DoD Architecture Framework Implementation” class notes published by AFCEA, Fairfax, VA May 2006. Rechtin E., “Systems architecting: Creating & building complex systems”, Prentice Hall, Englewood Cliffs, NJ, 1991. Rechtin E., “The art of systems architecting”, IEEE Spectrum (October 1992), pp. 66–69. Rechtin E. and Maier M., “The art of systems architecting”, CRC Press, Boca Raton, FL, 1996. Wagenhals L.W., Shin, I, Kim, D and Levis, A.H., “C4ISR Architectures II: Structured Analysis Approach for Architecture Design.” Systems Engineering, Vol. 3, No. 4, December 2000, pp. 248-287. Wagenhals, L.W., Haider S. and Levis, A.H., “Synthesizing Executable Models of Object Oriented Architectures.” Systems Engineering, Vol. 6, No. 4, December 2003, pp. 266-300.

Biographies Ashraf Abusharekh is a PhD student in the ECE Department at George Mason University and, since January 2006, a graduate research assistant in the System Architectures Laboratory. Smriti Kansal is an Assistant Research Scientist in the ECE Dept. at George Mason University and is associated with the System Architectures Laboratory. Dr. Abbas K. Zaidi is Research Associate Professor with the System Architectures Laboratory, ECE Dept., George Mason University. Dr. Alexander H. Levis is University Professor of Electrical, Computer, and Systems Engineering and heads the System Architectures Laboratory at George Mason University.

10 PROCEEDINGS CSER 2007 , March 14-16, Hoboken, NJ , USA