Architecture Descriptions Nasa Descriptions

We indicated in Chapter 8, "Requirements Analysis and Allocation,'' that the requirements for a system are almost always delineated by system function. Therefore, more often than not, the system functions, at least at the top level, are an input to the systems engineering team.

In many cases, the architectural description of the system consists of the reiteration of the given system functions, along with the way in which those functions, and the subsystems representing those functions, are interconnected. As examples, Figures 9.1 and 9.2 show system architectures defined by NASA for the EOSDIS and the EDOS systems [9.3, 9.4]. Both figures are from the requirements specifications for the two systems, as defined by NASA. We note the implicit emphasis on interconnections between functions, extending as well to the physical locations of the functional capabilities. In some cases, the architecture description is supplemented by the identification of functional interfaces between a given system and other systems with which it must interoperate. This is illustrated by Figure 9.3 for a NASA system known as the PDSS (Payload Data Services System [9.5]). Types of data and information flow in terms of functional interfaces are emphasized in this description.

Although the previously cited functional architectures provide valuable information to the systems engineering team, the position taken here is that this information is only an input to the true architecting of a system. System

Eos Platform(s)

Space Station Freedom

CDOS

FDF

POIC

ESA

EOSDIS Comm & 1ST toolkits

= Local connections

I I Shaded areas are responsiIiIity of EOSDIS Note: Investigator facilities, SCFs and users may be located at a single site

EOSDIS Comm & 1ST toolkits

EOSDIS comm. IMC & data access toolkits

Figure 9.1. Illustrative architecture description—EOSDIS.

EOSDIS comm. IMC & data access toolkits

Figure 9.1. Illustrative architecture description—EOSDIS.

Figure 9.2. Illustrative architecture description—EDOS.

architecting takes several steps beyond this type of description, the key element of which is to define a technical approach for the implementation of each of the defined functions as well as an overall selection of the best approach (most cost-effective system) for the combination of functions. Such a selection defines the preferred system architecture. This position is made more concrete in the sections that follow in this chapter as well as in the Appendix.

9.4.2 Department of Defense Descriptions

The Department of Defense (DoD) has formulated a framework for Command, Control, Communications, Computer, Intelligence, Surveillance, and

Figure 9.3. PDSS functional interfaces.

Reconnaisance (C4ISR) architecture, development and integration [9.6]. This C4ISR Architecture Framework is an attempt to:

• Ensure that architectures developed by different parts of the DoD are interrelated

• Set forth uniform methods for describing various types of information systems

• Provide guidance on describing architectures

The last point is of particular importance. In fact, the Framework is built largely upon the idea that there are three major perspectives on how to describe an architecture, namely:

• The operational view

• The systems view

• The technical view

These views can be thought of as giving us different types of information about the same architecture, rather than being different architectures themselves. The most useful architecture description is one that consists of multiple views, providing an ''integrated'' notion of the architecture. The more precise definitions of the above three views of an architecture are [9.6]:

The operational architecture view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation

The systems architecture view is a description, including graphics, of systems and interconnections providing for, or supporting, warfighting functions

The technical architecture view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements

The Framework also provides a detailed explanation of the roles of each of these architectural views. Of special importance is the notion that an architecture description must provide explicit linkages between these various views. This leads to an integrated view as well as supporting the notion of interoperability, which has been a problem for DoD systems for many years. The Framework also shows a six-step process for building an architecture as follows:

Step 1: Articulate the intended use of the architecture. Step 2: Establish the scope, context, environment (and any other assumptions) of the architecture. Step 3: Determine which characteristics the architecture needs to capture. Step 4: Establish which architecture views and supporting products should be built.

Step 5: Build the needed products.

Step 6: Use the architecture for its intended purpose.

Steps 4 and 5 above suggest that each architectural view is supported by several products. That indeed is the case. In fact, there are a series of ''Essential Framework Products'' and also a set of ''Supporting Framework Products.'' These products are intended to convey critical information about the architecture. The reader is referred to the reference for the C4ISR Architecture Framework [9.6] in order to gain a fuller understanding of the nature and structure of this work.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment