MultiPerspective Hierarchical Model Data Framework

1
Multi-Perspective Hierarchical Model Data
Framework
Bob Hamber Very few slides have speaker notes
yet.

• Bob Hamber
• Naval Facilities Engineering Service Center
• 1100 23rd AvePort Hueneme, California 93043-4370
• 805-982-1583, DSN 551-1583
• hamberra_at_nfesc.navy.mil , to be
  robert.hamber_at_navy.mil circa June
• Presented to
• Analysis Forum Logistics Forum
• Spring 2003 Simulation Interoperability Workshop
• 1 3 April 2003
• Orlando, FL

2
Introduction Background

Back to Table of Contents
Skip to Additional Topics Index
3
What is It

• Model Data Framework
• A schema or methodology for organizing model data
• Hierarchical
• Having many levels
• Outline, tree charts
• Multi-perspective
• Understandable by multiple classes of users

A systematic, hierarchical, framework for
organizing input, output, and metadata from the
differing perspectives of analysts, the decision
makers, sponsors, system analysts, and
programmers.
4
Goals of Presentation

• Introduce the idea
• Show five generic perspectives
• Clarify by examining the third and fourth levels
  of the taxonomy
• Show how the framework can be applied
• Solicit comparisons to other metadata frameworks
• conceptual models of mission space (CMMS)
• simulation object models (SOM)
• base object models (BOM)
• unified modeling language (UML)
• battle management language (BML),
• other schemas that we have little understanding
  of.
• If the framework has sufficient merit, promote
  its maturation into a standard

5
Need

• Complex models have lots of parameters
• Input
• Current state
• Output
• Control
• Metadata
• Challenges
• Managing parameters developers
• Navigating parameters - analysts
• Understanding parameters decision makers
• Appreciating parameters -- sponsors

6
Scope

• By taxonomy level
• Framework broadly applicable to most models
• Second level classes should apply to almost all
  models
• Many third level classes will apply to many
  models
• By model characteristics
• The more complex the model, the more worthwhile
• Good framework for new models
• Probably not worthwhile to reorganize the actual
  data structures of existing models
• Just document as a useful reference

7
Benefits

• Easier to find data
• by being able to view the data from the
  perspective(s) most natural for them.
• Easier to learn the parameters
• Facilitates understanding of a model (and models
  in general)
• by seeing how the same data is organized
  differently from different perspectives.
• Fosters understanding and communication between
  different kinds and levels of users
• decision makers, analysts, sponsors, system
  analysts, programmers
• different levels of decision makers, analysts,
  developers
• Easier for potential analysts and sponsors to
  understand the scope and sophistication of a
  model
• Helps with model marketing

8
Benefits Developers

• Facilitates generating and managing the metadata
  table lists to
• support configuration management
• facilitate organization of model output
• create the table lists which allow easy import
  and export of various categories of data
• drive the many data input wizards used in setting
  up the model
• create the organized tabs of tables in the
  database viewer module
• Facilitates further model development
• including reorganizing the fields among different
  tables
• Facilitates organizing the data structure of new
  models, federations, or object models

9
Our Impetus

• TLoaDS Database Viewer
• Multiple Custom tabs
• Custom table indices
• Custom Groups

10
TLoaDS

• Type - discrete event simulation
• Scope - current or future tactical distribution
  systems
• Uses
• projecting distribution throughput and
  sustainability of scenario
• allocating logistic resources
• assessing proposed doctrine, distribution
  techniques, unit organizations and equipment
  concepts,
• all for a wide variety of scenarios
• Attributes - fast, powerful, flexible, low cost
• application suite
• based upon commercial MS software
• GUI intensive

11
TLoaDS Input Screens (4 of dozens)
12
TLoaDS Output Screens (4 of dozens)
Back to SBS Conf Brief
13
General Framework Principles

• Ambiguity is the focus
• Usually the bane of taxonomy and object oriented
  thinking
• Put each item in every bin it deserving
  itinstead of only one best bin
• Good balance between
• Including data everywhere possible,
• Awkwardly large lists to sort thru, or number of
  hierarchies tedious to navigate
• Allow flexibility
• Dont be a slave to rigorous class criteria
• Allow distinctions (to create additional
  subclasses)
• Allow special combinations (to avoid additional
  subclasses)

14
Framework Taxonomy

Back to Table of Contents
Skip to Additional Topics Index
15
Top Two Levels
16
The Five Perspectives

• System character
• denotes the 'level' at which parameters affect
  the system
• System elements
• the temporal and tangible things that make up the
  system being modeled
• System processes
• groupings of process steps the model simulates
• Modeling character
• grouped by attributes pertaining to MS
  operations and constructs, and not attributes of
  the system under study
• Modeling control and metadata
• all the model data that does not represent the
  system under study (e.g. run control, GUI,
  metadata, usage information, miscellaneous
  tables, and obsolete tables)

system-under-study input and output tables
17
Top Two Levels - Reprise

• Same boxes as before, just rearranged

18
Top Three Levels
19
3rd Levels of System Character Perspective

• Scenario external parameters affecting the
  system under study
• the operation and environment the system under
  study is responding to.
• Concept of Operation internal system parameters
  having the broadest impact upon its performance,
  or constrain the choices of techniques
• the domain of strategy and tactics
• typically the responsibility of the officer of
  the system under study.
• Techniques internal system parameters defining
  how processes are done
• most likely to be changed during a run to reflect
  a changing scenario or as a result of system
  feedback loops
• typically decided by lower level managers or
  workers
• Process Rates -- internal system parameters
  specifying how long it takes to do something
• or how many cycles can be done is a certain
  amount of time.
• Resource Characteristics internal system
  parameters specifying the characteristics of the
  resources
• resources are what the system has to perform its
  function.

hamberra Increase font size?
20
Development of System Character Perspective

• Straightforward
• Except for distinguishing between concepts of
  operation and techniques
• Process rates deserve 3rd level if
• Enough process rate parameters relate to more
  than one of the other 3rd level classes
• Have enough process rate parameters
• Resources characteristics
• Internal to system since part of the system being
  studied
• External to system since generally the managers
  in the system cant/dont affect the parameters
  over the time period modeled
• Process rates and resource characteristics can be
  adjusted to reflect changes in parameters under
  the other 3rd level classes

21
3rd Levels of System Elements Perspective

• Time intervals -- equal or unequal length
  subdivisions of the whole span of time covered in
  one simulation run
• Organizational units groups of people
  organized by function
• e.g. companies, departments, divisions, platoons.
• Facilities or nodes aggregations of
  organizational units, resources, and maybe
  materials
• at a known (fixed, movable, or moving) location
• where system processes are performed, and linked
  by connections to transfer organizational units,
  material, resources, or information between them
• Zones two or three-dimensional subdivisions of
  the scenario physical space
• distinguishable by one or more modeled
  parameter(s) that affect(s) at least one other
  type of system element in some way
• Intra-node space resources two or
  three-dimensional subdivisions of the space
  within a node
• e.g. work, staging, or storage areas

22
3rd Levels of System Elements Perspective 2

• Connections one dimensional spaces that connect
  facilities/nodes
• Durable equipment equipment, other than those
  that are resources for the system modeled
• that consume consumable commodities or occupy
  other resources
• Equipment resources durable equipment that are
  resources for the system being studied.
• e.g. containex, handlers, trans-orters, and
  adjuncts.
• Aggregated resources -- groupings of other
  resources with their own attributes
• e.g. convoys aggregate transporters, their
  crews, and adjuncts.
• Labor resources the individuals within
  organizational units that are resources for the
  system being modeled
• e.g. troops, drivers, crews, teams, detachments..
• Financial resources monetary entities
• e.g. cash accounts, demand deposits, credit
  accounts, loans, and debit accounts

23
3rd Levels of System Processes Perspective

• Consuming What scenario, unit and equipment
  characteristics, methods, affect how much
  organizational units and their durable equipment
  consume consumable materials
• including repair parts and durable equipment if
  so desired.
• Ordering What scenario, unit and equipment
  characteristics, methods, affect the process of
  deciding when and how much consumable materials,
  spare parts, equipment, or troops to request for,
  go get for themselves, or send to an organization
  unit(s)
• Planning What affects the process of
  processing, prioritizing, aggregating how
  multiple orders are managed, coordinated, and
  scheduled
• Shipping -- What affects the how consumable
  commodities are picked from stocks, packaged for
  shipment, built into chalks, loaded on to
  transporters, and how transporters and adjuncts
  (like escorts) are grouped (formed) into convoys

24
3rd Levels of System Processes Perspective 2

• Transiting What methods and factors affect
  transiting in general including - movement
  categories, control, tactic, formation and
  method- distribute path, route, seam, convoy,
  escort, piggyback, synchronize and release -
  hauling type, hauling method, and relay method -
  tracking methods, techniques and procedures -
  equipment characteristics and scenario factors
• Receiving What methods and factors affect
  receiving in general including - rendezvous,
  replenish, restock, limit, deal with surpluses,
  - transfer, air-drop or unload- equipment and
  scenario factors affect how long it takes to
  offload materials, approach, arrest, shutdown,
  and strike - how many transporters can occupy
  loitering, unloading, and berthing or bed-down
  spots

25
3rd Levels of System Processes Perspective 3

• Storing What methods and factors affect storing
  in general including - type, location, -
  sheltering, care-in-stores, rotation, - security
  
• Controlling Facilities What methods and factors
  affect facilities in general including - what
  facility is selected - facility footprint,
  clockprint- level of service, scope of service
  - location, operating times, and general queuing
  tactic
• Networking What methods and factors affect the
  distribution network in general including- what
  network pattern is selected - supply chain
  method - echelonment, alignment, handoff -
  support method, orientation

26
3rd Levels of Modeling Character Perspective

• Element Data input tables that are parent
  tables for the discretely modeled system elements
• for models using Simulation Dynamics Incs
  Industry database.
• other modeling environments may have a comparable
  set of tables worthy of giving the model user or
  developer ready access to
• Stochastic any table with a randomized
  parameter
• makes it easy to revise them
• makes it easy to compare this aspect of different
  models
• Reports output tables useful in producing
  reports
• Run Time output tables who have one or more
  parameters that can change during the middle of
  the run
• Inventory Specs These tables have many
  parameters of inventories and resource pools
• an inventory is one kind of material at one node
  a resource pool is one kind of equipment
  resource at one node
• unique to the Simulation Dynamic Incs Supply
  Chain Builder modeling environment.
• include user set inputs, run-time data, and
  end-state data

27
3rd Levels of Modeling Character Perspective 2

• Submodel Parameters input and output tables
  which are only used by optional submodels
• our CLoaDS submodel provides detailed intra-node
  material handling, and treats storage and working
  space as a constrained resource
• Sim Level tables that correspond to each level
  in a hierarchy of simulation supported analysis
• study gt experiment gt excursion gt case gt tune gt
  run
• Reference input tables of notional reference
  data used to build the study databases the model
  actually uses when it runs
• This group is the one exception to the
  description of Modeling Character data
  specifically this is not the same data found in
  the 3 System perspectives
• not shared by many modeling environments
• It is a subset of the system input tables, with a
  twist. Instead of being the actual input tables
  used by model during the study simulations, these
  reference input tables contain notional data.
  A TLoaDS module helps the user build the study
  database from this notional reference data.

28
3rd Levels of Mg Control Metadata Pve

• Classifications -- classes, types, kinds and
  options.
• tables that define both system element class
  relationships, and the options for qualified
  (non-quantified) system and model states
• Database Structure tables specifying the
  relationships among database tables and fields
• in TLoaDS this also controls how tables appear in
  the database viewer
• Animation tables that control the animator
  module
• Views Tables that control GUI views which can
  be named, saved and recalled
• Wizards tables with lists of forms (tables or
  screens) that define which, and in what order,
  those forms appear in wizards
• Import Export tables that list groups of
  tables to import or export together
• Security -- control or metadata related to
  security features
• Other control or metadata related to
  monitoring, persistency, communication, and other
  categories we are not familiar with.
• any of these can be a third level category if
  desired.

29
3rd Levels of Mg Control Metadata Pve 2

• Model Structure specifications on
• In TLoaDS is covers current modules, extensions
  (dynamic data library files), library files
  (collections of blocks), block list, block
  hierarchy, dialog settings, dialog options,
  equations, algorithms, and processes
• Sim History information on how the model is
  used by the analyst
• tracks selected simulation runs, tunes, cases,
  excursions, experiments, and studies. Can also
  keep track of the existence and usefulness of
  reports, plots, Gantt charts, and measures of
  performance.
• Modeling History Information on the development
  of the model
• tracks selected model versions, library versions,
  extension versions, module versions, and other
  application files
• Parking -- tables waiting placement elsewhere
• create new groups, add or delete from existing
  groups, and add or delete from the model.
• tables for future use can go here, or in their
  own third level class
• Obsolete tables from earlier versions no longer
  used

30
New Database Viewer Tabs Left Half
31
New Database Viewer Tabs Right Half
32
TLoaDS Input Table Distribution Matrix
33
Future Work

• Compare to other metadata frameworks
• Data Model Framework and Taxonomy
• Wizard of Wizards
• Conceptual Framework

34
Compare to Other Metadata Frameworks

• How does this compare to other metadata
  frameworks?
• Duplicate, obfuscate
• Complement, augment
• Other frameworks to compare to
• conceptual models of mission space (CMMS)
• simulation object models (SOM)
• base object models (BOM)
• unified modeling language (UML)
• battle management language (BML)
• other schemas that we have little understanding
  of
• Invite others with expertise in the above to
  compare

35
Data Model Framework and Taxonomy

• While there is no need for users to learn the
  rationale of more than one perspectives
  taxonomy, some may find the large number of tabs
  in our database viewer daunting. A control to
  hide other perspectives in the viewer may be
  appropriate.
• Some users may be adept at remembering the best
  location for a given table and lament that it
  appears in other places, with the aggregate
  effect of many database viewer tabs having
  unneces-sarily long index lists to scroll
  through.
• In our model, some tables have a second
  classification because of just one or two fields.
  Moving this field to a more appropriate table
  can eliminate these exceptions.
• Class terminology and taxonomy should be revised
  in accordance with official, de-facto, or
  emerging standards where available.

36
Wizard of Wizards

• An interface that takes the user step by step
  through the whole modeling and simulation process
• scope gt preprocess, setup gt run gt tune gt manage
  cases, excursions and studies, post process gt
  analyze
• while the existing TLoaDS GUI is set up to
  facilitate this, and there are some next step
  features within individual modules, we are a long
  way from a wizard of wizards or EZ step GUI

37
Conceptual Framework

• Different classes of users (doctrine developers
  force structure developers technology and
  equipment developers educators and students
  contingency and operational planners) tend to
  have different sets of inputs they accept as
  given, different inputs they want to vary and
  different outputs to examine.
• Therefore, the steps in setting up, running, and
  analyzing TLoaDS needs to be tailored to
  different classes of users.
• We believe there is a useful degree of
  correlation between these classes and subclasees
  of users, the simulations levels, and of this
  data frameworks perspective classes and their
  third level subclasses.

38
Summary

• Necessity is the mother of invention
• improve the ease of use
• for different classes of users
• Taxonomy is basis for the metadata that drives
• the models import-export data subsets,
• setup wizards,
• database viewer tab indexes.
• In the future the taxonomy will be the basis for
• verification, validation,
• simulation object model,
• documentation, training.
• multi-user hierarchical model graphical user
  interface.
• Feedback from the MS community is welcome

39
The End
Back to Table of Contents