presentation from june 12, 2006 dinner meeting

8/9/2019 Presentation from June 12, 2006 Dinner Meeting

1/29

Strategy For the Composition and

Development of the Authoritative SystemRepresentation (ASR)

Robert Clayton

Booz Allen Hamilton

June 12, 2006


2/29

2

Strategy For the Composition and

Development of the Authoritative

System Representation (ASR)

Necessity of Representation

Representation

Authoritative System Representation

ASR Structural Alternatives

ASR Evolution

Boundaries & Definitions

System Requirements

Categorize & Correlate

Analysis, Engineering, Test

Details

Ancillary Considerations

Refinement

Conclusion


3/29

3

Famous Quote

Insanity is doing the same thing, in

the same way, under the same

conditions, and expecting the

results to be different.

Paraphrased from

Albert Einstein


4/29

4

Not-So Famous Quotes

In My 25+ years of Combat Development, MaterielAcquisition, Systems Engineering, and Modeling &Simulation The Same Issues/(Mis)Statements

Reappear Test My System Using M&S

Model My System So I Can Solve My EngineeringProblems

Your Model Says The System Cant Achieve This Level, But

We Are Sure It Can So Your Model Must Be Wrong Change It (The Model) Until The System Succeeds

We Do Not Consider Communications As Part Of TheSystem So You Dont Have To Model It


5/29

5

Simple Example: GIG


6/29

6

Challenge Parallels

ID Scope Of The System

Integrate Parts Of The System

Emphasis On The System

Engineer For System Success

ID Parts Of The System

ID Parts Not Of The System

ID Affecting Entities To The System

ID Effects Of The System

SE

M&S

Respond to (Model & Data,

System) Requirements

Build and Deliver

(System or M&S)


7/29

7

DA PAM 512

Simulation Support Planning and Plans

dated 2 March 2005

69. Authoritative system representation

a. Authority and distribution.An authoritative system representation (ASR) is the description of a

systems performance and behavior and its interaction with the environment. This section will alsoprovide information and procedures for obtaining ASR data. The PM approves the ASR and is

responsible for maintaining and updating it. Upon request, the PM will provide the ASR to other

organizations that represent the system in models or simulations. These organizations will use theASR as a specification for building composable models of the system. How the organizations

implement the ASR will not be constrained.

b. Description and documentation. The ASR will describe the system requirements and capabilities in

a standard manner to facilitate model and simulation reuse. The ASR can be described in a text

document, spreadsheet, or distributed product descriptions (DPD) as appropriate to the system. The

ASR should address certain areas to ensure that a complete and consistent system specification is

identified for the modeler. These common areas are critical to accurately model the systems

performance and behavior and its interaction with the environment. The following areas should bedescribed for the system, as appropriate: physical characteristics; reliability, availability, and

maintainability; survivability; lethality; behavior; and expected interaction with the threat, terrain and

weather. The PM will ensure that the ASR is based on data and products provided by the responsible

authoritative data source agency in accordance with applicable DOD and Army regulations. Estimated

data in the ASR will be replaced with actual data as the system matures. As this occurs, the PM will

maintain complete documentation of the sources and methods of acquiring the actual system data, to

support accreditation of the ASR for use. For a more detailed description of the ASR, refer to the SPG.


8/29

8

DA PAM 512


dated 2 March 2005



















An authoritative system representation (ASR) is the

description of a systems performance and behavior

and its interaction with the environment.


9/29

9

DA PAM 512


dated 2 March 2005



















The ASR is a PM Data Product

PM is responsible for approval, update, provision of

ASR to other organizations.

These organizations will use the ASR as a

specification for building composable models of the[ir]

system [of interest].

How the organizations implement the ASR will not be

constrained.

Use of the ASR by others is equivalent to our own.

The ASR must be multi-echelon, multi-fidelity, and

have a spectrum of abstraction.


10/29

10

DA PAM 512


dated 2 March 2005



















On the one hand, the ASR is a compilation of

requirements for the system.

The following areas should be described for the

system, as appropriate: physical characteristics;

reliability, availability, and maintainability; survivability;

lethality; behavior; and expected interaction with the

threat, terrain and weather.

On the other hand, the ASR goes beyond

requirements by specifying objects/conditions outside

the system which affect/are affected by the system.

Together, these reflect what is required for portrayal

within the M&S.


11/29

11

ASR Policy vs. Need

The ASR When Fleshed Out With System Requirements AndInteraction Information

Suffices To Describe The System And Hints To Its Operational Concept

Fails To Provide Ready-to-use Or Ready-to-implement Capabilities

Good Representation Of A Given System

Provides Consistency In Implementation and Portrayal of System

Provides Visibility In Verification & Validation

Requires Following Standardized Techniques Reflecting Best Practices

In M&S

Current Policies Regarding ASRs, Dissuade Achievement of

Desirable Benefits of Good Representation


12/29

12

DA PAM 512


dated 2 March 2005




















13/29

13

Decomposing The Definition of An Authoritative System

Representation

Authoritative

Having or arising from authority; official

Of acknowledged accuracy or excellence; highly reliable

Wielding authority; commanding System

A group of interacting, interrelated, or interdependent elementsforming a complex whole

A set of objects or phenomena grouped together for classificationor analysis

Representation Vehicle To Manifest or To Convey Technical, Practical, and

Conceptual Notions For The Better Understanding, ImprovedPortrayal of A Concept, Phenomenon, Condition, Object, orProcess


14/29

14

Four General Forms of Presenting ASR

Information

Descriptive Format

Graphics, Spreadsheet, Distributed Product Description

(DPD), Narrative

Identification of Model-Ready Informational Packages

Code/Algorithm Descriptions*

Module-Level Conceptual Models

Prescribed Algorithms

Plug-n-Play APIs, Widgets, etc.

* Some Consider Synonymous or Related To DPD


15/29

15

ASR Evolution Scheme

Give Overarching Definitions and Terms

Define System Boundaries

Configuration

Hardware/Software

Capabilities/Services

Processes

Decomposition of System

By Design Echelon (Enterprise, System, Component, Module/Algorithm)

By Partition (External, Innate, Transitional)

Associate System Requirements

Identify Categories, Correlate To Design Echelons/Partitions Flesh Out Details

Recurring Refinement


16/29

16

ASR Matrix: Example Entries

Define System Boundaries Configuration

Hardware/Software

Capabilities/Services

Processes

Site Hardware: Server 1, Server 2, Server3, Workstation(x3), Router 1, Router 2,

Cat 5E cabling, WAN PoP, 30m UHF Dish

Site Software: Windows XP Server, MS Internet Explorer, Oracle DBMS

Site Capabilities: Image Database, COP Fusion, Local System Management

Site Processes: Image Storage, Image Archive, Sub Image Interpolation


17/29

17


Decomposition of System

By Design Echelon (Enterprise, System, Component, Module/Algorithm)


1. Enterprise: The Enterprise representation portrays the capabilities and

performance of the System in the context of its role vis--vis other C2 and C4I

Community Operations. On a broader scale, the context would include theremainder of the Global Information Grid (GIG).

2. System: The most-likely to be scrutinized will be the System representation

portraying System capabilities as it relates to other parts of itself, often on a location

by location basis.

3. Component: Engineering level portrayal of Gozintas and Gozoutas from the

individual physical/functional entities that comprise any System location.Components include displays, keyboard, databases, memory,

routers/hubs/switches, etc.

4. Module/Algorithm: Pseudocode or actual code; this will likely remain the least

populated portion of the ASR most often listing only the most significant functions

or procedures.


18/29

18


Decomposition of System By Design Echelon (Enterprise, System, Component, Module/Algorithm)


Enterprise: The Enterprise representation of the SYSTEM portrays the

capabilities and performance of the SYSTEM in the context of its

role vis--vis other C4 and ISR Community Operations. On a

broader scale, the context would include the remainder of the

Global Information Grid (GIG).

Enterprise:Innate: the SYSTEM SystemTransitional: All Communications

External: Other Systems

System: The most-likely to be scrutinized representation of the SYSTEM, the

System representation will be used to portray the SYSTEM as it

relates to other parts of itself, often on a location by location basis.

System:Innate: Site Hardware, UserTransitional: All Comms (Incl Within the SYSTEM)

External: All Other ISR Assets

Component: Engineering level portrayal of Gozintas and Gozoutas from

the individual physical/functional entities that comprise any the

SYSTEM location. Components include displays, keyboard,databases, memory, routers/hubs/switches, etc.

Component:Innate: Server, CPU, or Keyboard

Transitional: All I/O Between ComponentsExternal: Any Agent outside the Component

Module/Algorithm: Pseudocode or actual code; this will likely remain the

least populated portion of the ASR most often listing only the

most significant functions or procedures.

Module/Algorithm:Innate: The CodeTransitional: Input and Output DataExternal: Any Component or Datapath

External

Transition Innate

Universe


19/29

19


Associate System Requirements

Requirement 1: The System shall enable

Requirement 2: The System shall monitor

Requirement 3: The System shall display

Requirement N: The System shall

Each System Requirement Will be associated with appropriate

Design Echelon and partitions.


20/29

20


Identify Categories, Correlate To Design Echelons/Partitions

Each System Requirement Will be Categorized and listed in a

comprehensive, structured fashion.

Requirement: The System shall

Category: Volumetric, Threat Situational Awareness (Within Area of

Interest)

Applicable Design Echelon/Partition: System/Transition;

Enterprise/Innate


21/29

21


Elaborate on Analysis/Test Issue

Map Requirement to Evaluation Scheme

Requirement: The System shall

Metric: Demand/Response Ratio (DRR)

Prediction/Hypothesis: DRR will be >45%, Error +/- 2%

Evaluation Scheme: Demand will be recorded at Component X input as

quantity of Type A messages. Response will be recorded at

Component Y output as quantity of Type B messages having values

within +/- 3 of corresponding Type A message.


22/29

22

Graphically Depicted Hypothesis

Prediction

2

3

4

2 3 4 7 8

Demand

Response


23/29

23

Prediction-vs-Results

0

10

20

30

0

50

60

0 1 2 3 5 6

Demand

Response

response = .9 demand + 1 .65

error of +/- 2.59


24/29

24


Flesh Out Details

Descriptive text, specific parameters, methodological description, or

specified code/process is provided

Modeling Issues:

External: Generation of Demand.

Transitional: Adequately Reflecting Degradation By Weather.

Innate: Representing system response to demand, composing Type Bmessage.


25/29

25

ASR Purpose

The ASR Matrix is designed to allow distribution of

multi-fidelity definitization of expressions of systems

capability

Sufficient detail to adequately portray the system within a

simulations environment

Allows the model developer the maximum flexibility in

constructing their tool

Reminder: The ASR is designed to convey how to portray the

system. It is not a detailed description of the system and the

resulting models developed from its contents are not the system but

an abstraction.


26/29

26

Challenge of Representation Beyond Hardware and

Software

Many Net-Centric Systems Embody A SOA Basis

Overlayed On Hardware & Comm Infrastructure

Hardware Representation Is Most Straight-forwardlyImplemented by Physical Prototype or Empirical

Methods

Software Representation Requires Actual Code or A

Fidelity-Appropriate Abstraction

Representing the Soft Portions (Services,

Processes, etc.) Requires More Elaboration


27/29


28/29

28

ASR Matrix (Workbook) to Database Transition

Workbook Configuration Will

Migrate To Database

Configuration Over Time

Long-term Objective Would Be

To Become A Service Offering

In A SOA Both Within And

External To The System


29/29

29

Conclusion

The ASR Is Fundamentally An Extension Of The

System Requirements

Conveyed In Terms Of M&S Requirements

Augmented With Modeling Needs Reflecting Entities,

Processes, And Conditions That Affect Or Are Affected By

The System

The Selection Of One Or More Of The Modeling

Strategies Is Dependent On The Specific Needs OfThe System Developer Over The Long Term

(Program Requirements)

presentation from june 12, 2006 dinner meeting

Documents