DoD Architecture Research Articles

Case Study: Application of DoD Architecture Framework to Characterizing a Hospital Emergency Department as the Intended Use Environment for Medical Devices

AbstractThis paper presents a case study by the Biomedical‐Healthcare Model‐Based Systems Engineering (MBSE) Challenge Team in response to inputs received during workshops held at the 2015 and 2016 INCOSE International Workshops. At IW2015 and IW2016, the Challenge Team held workshops, including clinicians and systems engineers, to assess potential contributions of systems engineering, and MBSE, to clinical operations. At these workshops it was claimed that clinical operations were too complex to be modeled with existing MBSE tools from defense and aerospace. It was further claimed that there would be very limited value to MBSE products. Based on these claims, the MBSE Challenge team undertook several case studies to evaluate the ability of MBSE tools to represent clinical operations and to address problems relevant to healthcare. This paper describes the outcomes of applying one MBSE tool, the DoD Architecture Framework, to characterize clinical operations as the intended use environment for medical devices.

Based on Capability of C4ISR Architectural Modeling and Analysis

C4ISR system is complex system. Such systems architecture and complex needs of many. Then complex system’s capability requirements are difficult to catch. Description of capability requirements are usually imprecise and do not support architecture analysis. The paper uses an extended UML modeling technique to analyzing the requirements of C4ISR capabilities. It also introduces a new model convert domain model into the Description Logic ontology. Use Description Logic ontology description the standard DoD Architecture Framework, the proposed method may populate C4ISR architectural analysis.

A Methodology for Making Services and Systems Equal and Combinative in DoD Architecture Framework 2.0

A Methodology for Making Services and Systems Equal and Combinative in DoD Architecture Framework 2.0

Exploiting Architectural Communities in Early Life Cycle Cost Estimation

System architectures evolve over time. Accordingly, the dynamic properties of architectures reflect how systems respond to change, and this response ultimately impacts cost. In prior work we make an explicit connection between the architectural diagrams of Model-Based Systems Engineering (MBSE), parametric cost estimation, and network science. Specifically, by treating the DoD Architecture Framework (DoDAF) Systems View 3 (SV3) as an adjacency matrix, we assess how the addition of a new subsystem to an immature architecture might grow the existing network. With the subsequent application of parametric cost modeling, we translate anticipated growth into expected cost, thereby quantifying the impact of change. This paper refines that approach. In particular, by using the Girvan-Newman algorithm, the SV3 is initially divided into groups of subsystems such that the number of interfaces is dense within and sparse between groups. Based on this division into “architectural communities” and the prevalence of bridging ties, interfaces generated by the addition of a new subsystem can be faithfully integrated into the existing architecture, adding validity to our growth mechanism. This procedure is illustrated in detail with an example that highlights the importance of this refinement, and it is incorporated within a Monte Carlo simulation that allows the distribution of future costs to be estimated and assessed.

A Novel Approach for C4ISR Requirements Elicitation

The capability-oriented requirements elicitation is an emerging research topic of requirements engineering, especially for complex system such as the C4ISR system. One of the problems is that the capability requirements are usually articulated in natural languages and need to be formally specified to support enterprise architecture analysis. The paper proposes a framework for modeling the domain requirements of C4ISR capabilities and suggests an extended UML modeling technique. As the modeling framework accords with the standard DoD Architecture Framework, the proposed method may populate C4ISR architectural analysis.

Systems Architecting and Program Management with the Design Structure Matrix (DSM)

AbstractThe design structure matrix (DSM) is a powerful tool for visualizing, analyzing, innovating, and improving system architectures, including those of products, processes, and organizations. The DSM helps to confront and manage system complexities and their implications. Akin to a traditional N2 chart and the System‐System matrix in the DoD Architecture Framework (DoDAF), the DSM is a square matrix showing relationships between system elements. These elements can be components, teams, activities, or others. By analyzing the DSM, one can prescribe a better (e.g., more modular) system architecture. Adding a time‐basis enables one to prescribe a faster, lower‐risk process. Because the DSM highlights process feedbacks, it helps identify iterations and rework loops—key drivers of cost and schedule risk. The DSM is concise and visually appealing and is used in many organizations across diverse industries. Users have found the tool extremely useful for fostering architectural innovation and enabling the situation awareness and empowerment that motivates people executing complex processes. This tutorial introduces the DSM and three distinctive applications useful to product developers, system architects and engineers, and project and program managers. Real‐life examples are presented from the aerospace, automotive, semiconductor, and other industries. Participants will engage in hands‐on exercises (building DSM models) and come away with a clearer understanding of the drivers of critical, emergent behaviors in systems and how to identify these using a DSM. Participants will receive a copy of the presentation materials and access to free tools that can be applied immediately to systems for quick results and insights.

Network Science Enabled Cost Estimation in Support of MBSE

As Model-Based Systems Engineering (MBSE) continues to mature, additional analyses can be performed to understand the relationships between a system's cost, schedule, and performance. The DoD Architecture Framework (DoDAF) is one of many approaches for representing the relationship between system components. If DoDAF diagrams - such as those provided in the Systems View - are treated as networks, they can be mathematically analyzed, providing additional summary metrics that might yield valuable insight into the degree of effort (i.e., cost) required to bring a system to fruition. For instance, if we view the addition of a new subsystem to the system's architecture abstractly as the addition of a vertex to a network, we can apply contemporary methods from network science to grow the network and estimate its cost. Unlike rules of thumb, this approach provides us with an objective way to quantify and assess change. The objective of this work is to turn MBSE knowledge into computational knowledge in order to support tradeoffs, change impact analysis, and related approaches early in the life cycle.

Domain-specific modeling and verification for C4ISR capability requirements

An approach was proposed to specify the C4ISR capability of domain-specific modeling language. To confine the domain modeling within a standard architecture framework, formally a C4ISR capability meta-ontology was defined according to the meta-model of DoD Architecture Framework. The meta-ontology is used for extending UML Profile so that the domain experts can model the C4ISR domains using the C4ISR capability meta-concepts to define a domain-specific modeling language. The domain models can be then checked to guarantee the consistency and completeness through converting the UML models into the Description Logic ontology and making use of inference engine Pellet to verify the ontology.

The Process of Information Systems Architecture Development

The DoD Architecture Framework (DoDAF) provides the guidance and rules for developing, representing, and understanding architectures based on a common denominator across DoD, Joint, and multinational boundaries. In this paper, the process of DoDAF development is brought forward based the Activity-based Methodology (ABM). Information systems architecture development should consist of five steps, such as Planning and Design Phase, Operational Analysis Phase, Requirements Analysis Phase, Function Analysis Phase, Physical Synthesis Phase.

Systems Architecting and Program Management with the Design Structure Matrix (DSM)

AbstractThe design structure matrix (DSM) is a powerful tool for visualizing, analyzing, innovating, and improving systems, including product architectures, organizational structures, and process flows.Akin to a traditional N2 chart and the System‐System matrix (SV‐3) in the DoD Architecture Framework (DoDAF), the DSM is a square matrix showing relationships between system elements. These elements can be product components, teams, activities, etc. By analyzing the DSM, one can prescribe a better (e.g., more modular) system architecture or organization. Adding a time‐basis enables one to prescribe a faster, lower‐risk process. Because the DSM highlights process feedbacks, it helps identify iterations and rework loops—key drivers of cost and schedule risk.The DSM is concise, visually appealing, and used in many organizations across diverse industries. Users have found DSM extremely useful for fostering architectural innovation and enabling the situation awareness and empowerment that motivates the people executing complex processes. This tutorial introduces the DSM and three distinctive applications useful to product developers, systems engineers, and project and program managers. Real‐life examples are presented from the aerospace, automotive, semiconductor, and other industries. Participants will engage in hands‐on exercises (building DSM models) and come away with a clearer understanding of the drivers of critical, emergent behaviors in systems. The methods can be applied immediately to projects for quick results and insights.

Architecture Frameworks & Modeling

AbstractArchitecture provides the unifying structure (or roadmap) for exploration of the problem space and for characterization of the solution space such that better decisions can be made. Architecture is an arrangement of feature and function that maximizes some objective. This tutorial will describe fundamental concepts used in architecture modeling that will assist you in developing and using your own architectures.The use of an architecture framework leads to a more model‐driven systems approach and allows you to “discover” the essential attributes of the problem space that must be addressed by the system solution. Architecture models are where these essential attributes are defined and evaluated. This approach to architecting will be described within the context of the DOD Architecture Framework (DODAF) and other frameworks like the Federal Enterprise Architecture Framework (FEAF) and the Zachman Framework.There can be a hierarchy of architectures that helps focus the architecture team on the right level of abstraction. One common hierarchy starts at the top with National level architectures and works down to the levels of Department/Federal, Service/Agency, Mission Area/Cross‐Mission Area, Program/Node, and so on. The architecture you develop will have impacts above and below you in the hierarchy. The notion of levels in a hierarchy will be discussed along with how to use this to structure your modeling and simulation activity. The differences between enterprise architectures and system architectures will also be discussedSeveral examples of architecture frameworks will be discussed along with application guidance for each: Zachman, Gartner Group, The Open Group, Reference Model of Open Distributed Processing, Federal Enterprise Architecture (US), and Department of Defense (US). The various modeling constructs within the DOD Architecture Framework will be described so that you can see how a framework can integrate the overall systems architecting and engineering activities.

Architecture Frameworks & Modeling

AbstractArchitecture provides the unifying structure (or roadmap) for exploration of the problem space and for characterization of the solution space such that better decisions can be made. Architecture is an arrangement of feature and function that maximizes some objective. This tutorial will describe fundamental concepts used in architecture modeling that will assist you in developing and using your own architectures.The use of an architecture framework leads to a more model‐driven systems approach and allows you to “discover” the essential attributes of the problem space that must be addressed by the system solution. Architecture models are where these essential attributes are defined and evaluated. This approach to architecting will be described within the context of the DOD Architecture Framework (DODAF) and other frameworks like the Federal Enterprise Architecture Framework (FEAF) and the Zachman Framework.There can be a hierarchy of architectures that helps focus the architecture team on the right level of abstraction. One common hierarchy starts at the top with National level architectures and works down to the levels of Department/Federal, Service/Agency, Mission Area/Cross‐Mission Area, Program/Node, and so on. The architecture you develop will have impacts above and below you in the hierarchy. The notion of levels in a hierarchy will be discussed along with how to use this to structure your modeling and simulation activity. The differences between enterprise architectures and system architectures will also be discussedSeveral examples of architecture frameworks will be discussed along with application guidance for each: Zachman, Gartner Group, The Open Group, Reference Model of Open Distributed Processing, Federal Enterprise Architecture (US), and Department of Defense (US). The various modeling constructs within the DOD Architecture Framework will be described so that you can see how a framework can integrate the overall systems architecting and engineering activities.

SEAS ISR Architect: Mapping Department of Defense Architecture Views to Military Outcome

The SEAS ISR Architect maps Department of Defense Architecture Framework (DoDAF) views to military outcome and demonstrates a quick turnaround tool for the Initial Capabilities Document (ICD) phase of the Joint Capabilities Integration and Development System (JCIDS) process. The SEAS ISR Architect allows the user to reconfigure intelligence, surveillance, and reconnaissance (ISR) architectures within the DoD Architecture Framework, to parameterize a Systems Effectiveness and Analysis Simulation (SEAS) with a pre-loaded scenario and present a comparison of the warfighting effectiveness of a range of architectural alternatives based on multiple simultaneous theater simulations.

A Conceptual Model for Interoperable Command and Control Acquisition

Interoperability is a hard problem and there has been no shortage of searches for quick fixes. Comparatively easy problems are fixed as “proofs of concept,” which then wither when unable to scale up to the huge size of the DoD enterprise. In order to perform a meaningful analysis of individual interoperability tools, we developed a methodology (the Rosen-Parenti Model) and analyzed the domain against which the tools were to be evaluated. We next mapped the Joint Capabilities Integration and Development System against that domain. The results were and are instructive. The research team determined that in many cases, the tools themselves were driving processes. In our view, tools should be developed to support processes, not drive processes. First, we will describe the methodology developed and then move into the domain analysis. Although we will briefly report the results of our tool analysis, we stress that our findings indicate that the tools themselves are not terribly important. What is important is the domain model itself. The domain model provides an effective means of developing useful DoD Architecture Framework-compliant architectures. Most importantly, the domain model addresses the very real differences in perspective when implementing a DoDAF-compliant architecture.

Extending DoDAF to Allow Integrated DEVS-Based Modeling and Simulation

A recent DoD mandate requires that the DoD Architecture Framework (DoDAF) be adopted to express high-level system and operational requirements and architectures. DoDAF is the basis for integrated architectures and provides broad levels of specification related to operational, system, and technical views. The combination of DoDAF operational views, which capture the requirements of the architecture, and systems views, which provide its technical attributes, forms the basis for semi-automated construction of the needed simulation models. Unfortunately, DoDAF doesn't mandate any simulation methodology to analyze the system or perform any pre-design feasibility studies. In this paper, we describe an approach to support specification of DoDAF architectures within a development environment based on DEVS (Discrete Event System Specification). The result is an enhanced system life cycle development process that includes both development and testing in an integral manner. We introduce two new operational views (OVs) in the current DoDAF making way for modeling and simulation as a part of the design process. We illustrate the process to build these new OVs from the existing OVs and their impact on the overall DoDAF system development process. We discuss automated model generation using XML through the introduced OVs, which paves the way for OVs to become service-providing components in the web services architecture.

8.4.3 What Question are You Trying to Answer? Identifying the Right Products for an Architecture Effort

AbstractDetermining what architecture products are needed to support systems development within a Systems Engineering process is a challenge. Existing documents, such as DoD's Architecture Framework Document, provide some guidance, but no defined product identification process. The method proposed in this paper provides a repeatable process for selecting the architecture products required to support a systems engineering lifecycle, defining the content of each product, and identifying each product's customer. The method has been successfully used by several DoD programs over the past five years.

Architectures in the Analysis of Requirements and Design of Simulation Systems

The paper presents authors' experience in developing and using archi- tectural descriptions, following the US DoD Architecture Framework, to the analy- sis and the design of an Air Situation Simulator (ASS). The publication describes how the use of C4ISR architectures in the definition of requirements and analysis of complex systems provides for a conventional description of the domain and for de- tailed study of the processes in the investigated system. The steps and stages in the description of operational, systems, and technical views of the simulation system are presented. The requirements for the system's software development are defined on that basis.

5.4.1 The Use of Integrated Architectures to Support Agent Based Simulation: An Initial Investigation

AbstractArchitecture descriptions following the Department of Defense Architectural Framework (DoDAF) will be used to aid in the acquisition of all major defense information systems. One of the primary purposes of these architectures is to help conduct military‐worth analysis. Recent work in operations analysis of information driven combat is showing that agent based simulation technology is needed to understand the military value of Command, Control, Communications, Computers, Intelligence, and Reconnaissance (C4ISR) systems. This paper investigates the utility of architecture descriptions based on the DoDAF to provide the needed data for agent based simulation. This is accomplished by means of a case study where data from a DoD architecture is used in the combat model System Effectiveness Analysis Simulation (SEAS). The research concludes that the DoDAF, if implemented properly, does provide the needed information. A process for taking information from a DoDAF architecture and importing it into agent based simulation is proposed.

국방아키텍처프레임워크의 개발

미군의 아키텍처프레임워크는 3원화관점에 의해서 산출물을 정의하였으나, 관점간의 전환과정이 불명확하고, 개발절차가 미흡하여, 아키텍처개발자가 아키텍처를 개발하기 어렵다. 그리고, 개발하더라도 독립적인 방법으로 산출물을 작성하여, 개발된 산출물의 수준이 상이하고 일관성이 없는 경우가 많다. 따라서, 본 논문에서는 우리 군 실정에 맞추어 산출물간의 연계성과 일관성을 유지시키기 위한 신규 산출물을 추가로 정의하였고, 아키텍처 개발절차를 보다 상세히 제시하였으며, 정보체계 수명주기별로 아키텍처 활용 용도를 제공하는 국방아키텍처프레임워크(MND AF)를 개발하였다. 이를 통하여 아키텍처산출물의 일관성과 추적성을 제공할 수 있게 되고, 체계통합 및 상호운용성 기반을 구축하게 되었으며, 아키텍처 개발자가 좀 더 쉽게 아키텍처를 개발할 수 있도록 하였다. The US DoD architecture framework defines architecture Products according to three viewpoints : operational view, system view, and technical view. But, its coarse-grained development process causes leakage of the details In transforming among different views. It also uses different methods for architecture products development, so that the levels of those products are not consistent. So. we propose MND AF(Ministry of National Defense Architecture Framework) for military environment to solve those problems. We propose additional architecture products to achieve consistency, including “architecture disciplines definition description,”“organization-to-activity relationships matrix,” “system definition description,” and “technical reference model,” etc. We also propose the architecture development process in more detail through seven steps. In addition, we propose the applicability of those products to the life cycle processes of the acquisition management. MND AF can provide consistency and traceability of architecture products, provide the basis for sl·stem integration and interoperability. Also, architecture developers can construct architecture in a more effective and efficient way through MND AF.

Development of the DoD protocol reference model

The Department of Defense has embarked on a Protocol Standardization Program aimed at the development of high-level protocol standards for the DoD internetwork environment. A major piece of this standardization program involves the development of the "DoD Protocol Reference Model" [1], which will serve to describe a basic framework for future DoD protocol standardization activities. The DoD Reference Model is in many respects similar to the ISO Reference Model [2]; in other respects, there are major differences between the two models. This paper discusses the issues faced during the development of the current draft of the DoD Reference Model. There are four fundamental differences between the DoD and ISO Reference Models: (1) the meaning of "layer"; (2) the importance of internetworking; (3) the utility of connectionless services; and (4) the approach to management functions. It has been found that well-designed computer networks have their protocols organized hierarchically. By this we mean that one protocol interpreter provides a communications service to its users by adding value to the services provided by one or more other protocols; and "good engineering practice" dictates that at no point should one protocol be implicitly using its own services, i.e. the protocols form a hierarchy. Within the ISO Model, however, this requirement for protocol hierarchies is strengthened into a requirement that protocols fit into "layers". This is the origin of a major disagreement between the ISO and DoD Reference Models. Within the ISO Model, the concept of layer has become of paramount importance, overshadowing the more fundamental notion of protocol hierarchy. Good protocol engineering does not require that protocols fit into layers; it is only required that protocols be arranged hierarchically. This latter principle is the basis of the DoD Reference Model. The second fundamental difference between the ISO and DoD Models is the relative importance given to the problems of internetworking. This is most easily seen by considering that the DoD Reference Model has explicitly identified an "Internet Layer". Although many efforts based on the ISO work are now taking the Network Layer to include an Internet Sublayer, this seems to confuse rather than clarify the issue (since it raises questions as to the meaning of sublayers). It is also difficult to correctly present the DoD approach to internetting within the confines of the ISO Model due to the ISO Model's lack of emphasis on "connectionless" services. This is the third of the fundamental differences between the two models. The primary use of connectionless service within the DoD architecture is for internetting - IP [3] being the paradigm. However, connectionless services are of great utility in other contexts as well. For example, interactions with a Name Server may involve the use of a connectionless protocol within the Transport Layer. The final fundamental difference between the ISO and the DoD Models is the manner in which various management - related functions are treated. Here we refer to functions such as the naming of resources, the control of access to resources, and the accounting for resource and network usage. Many of these functions are most naturally handled via connectionless services, they typically involve entities which are only involved at the initiation or termination of a sequence of data transfers, and many communicants may be involved besides the "users". The DoD Model identifies such protocols as typical of " session" services. Such protocols are placed within the session layer by virtue of their use of " transport layer" services and their common features. Of course, there will be many protocols defined which sit at other locations within the protocol architecture which may play a role in the management of the network and of network resources. It is not implied that all such protocols are most appropriately defined as "session" protocols. These are the differences between the two developing Models which are currently identified. Both Models will continue to evolve, most likely in directions which differ in important respects.