Next: 5 The RASSP Reuse Data Manager Architecture Up: Appnotes Index Previous:3 Design Reuse Methodology

Reuse Methodology and Implementation Appnote

4.0 The RASSP Reuse Classification Hierarchy

The RASSP Reuse Classification Hierarchy (RRCH) was initially developed using Rumbaugh's Object Modeling Technique (OMT). This preliminary version of the RASSP Reuse Classification Hierarchy (RRCH) is documented in [Lockheed Martin_1996b]. On review of the integration requirements for the program, however, it became clear that the computer aided software engineering (CASE) tools available in the marketplace, including OMT, were inadequate to model the distinctions among the diverse, complex sources of engineering data in the RASSP environment.

Two key issues led us to move from a traditional CASE-based modeling approach to a knowledge representation approach:

1. a requirement to capture the semantic and syntactic differences among terms -- to model the constraints on attributes in a formal way (e.g., numeric precision, translation of units of measure, handling issues such as global pricing that require input from multiple external systems on demand)
2. the need to resolve communications issues among organizations with distinct cultural heritage (i.e., organizations that have been brought together as a result of mergers and acquisitions that have differing engineering practices and use distinct terminology to refer to the same or similar practices and data).

Ontolingua [KSL_ 1996a] was selected as the appropriate representation environment from several knowledge representation approaches due to the level of formality that it provided, accessibility of the tool environment on the Stanford web site, and the availability of support from key Stanford Knowledge Systems Laboratory (KSL) researchers.

An important development goal for the RASSP Reuse Classification Hierarchy was that it should be general enough to be adopted, ultimately, as an industry standard, either in part, or in its entirety. Thus, it should lend itself to extension without requiring destructive changes. Destructive changes include deletion of classes in the hierarchy, deletion of attributes, relationships or constraints, or moving classes within the hierarchy. Adding new classes to the hierarchy and adding attributes, relationships and constraints to existing classes should be allowed. These restrictions enable upward compatibility with previous releases (i.e., previous integration of CAD tool libraries with the RRCH will continue to be valid). The International Electrotechnical Commission Draft International Standard 1360-1 for classifying electric components [IEC_1994] was adopted as a baseline for quantitative and qualitative attribute definitions as an initial step towards achieving this goal. Other standards for domain-specific information have been integrated throughout the modeling process.

The salient features of the ontology development methodology for an individual class of design objects are as follows:

• select the type of reuse data to model
• source standard taxonomies from the various standards organizations
• source data from vendors, government and commercially available libraries, the RASSP Enterprise team
• determine the set of potential attributes based on RASSP requirements, user input, analysis of products output by the CAD tools, the standards sourced
• specify the semantics and legal values for each attribute
• review the draft data dictionary and related ontology with local experts in the domain as well as with Stanford KSL modeling experts
• publish the data dictionary for comment within the program
• demonstrate the Ontolingua implementation to solicit feedback
• iterate through the process until consensus is reached

For all classes defined in the RRCH, a certain number of common attributes are defined. These attributes include information required to identify an individual information asset that may be distributed in an enterprise, regardless of where it resides or what its functional characteristics are. The baseline used for this purpose is the Global Information Locator Service standard, developed by the National Archives and US Geological Survey based on the ISO 10163 (ANSI Z39.50) standard, which specifies how electronic searches should be expressed and how results are returned to enable international access to diverse, distributed data [OIW/SIG-LA_1997].

This standard has been extended for use in the RASSP environment to include information required to launch CAD tools or access distributed databases, for example. Additional requirements were derived from the latest release of the Meta-data Interchange Standard developed by the Meta-data Coalition [MDIS, 1997], a consortium of data warehousing vendors. Other standards for the representation of specific types of information were incorporated as appropriate. The current version of the ontology that models the Global Information Locator Service is called Network-Based-Information-Asset, and is available on-line through the Stanford Knowledge Systems Laboratory (KSL) Ontolingua server at http://www.ksl.stanford.edu.

Figures 4 - 1 and 4 - 2, below, show subsets of the current Space-Systems design object and Engineering-Data data object hierarchies, respectively. The RRCH models the common vocabulary for the domain, including descriptive meta-data for the design and data objects that may be created or used within the RASSP environment. The interior nodes of the hierarchy are abstract classes, and leaf nodes are concrete classes that may be populated with real objects.

Additionally, individual classes in the Engineering-Data and Space-Systems ontologies include attributes that are specific to the domain. Examples of these kinds of attributes include size, weight, and power characteristics, performance characteristics, and so forth, depending on the asset type. An example class definition, extending the baseline information asset attributes to include those relevant to a Simulation Model is given in Tables 4 - 1 through 4 - 8. Many of the attributes described in the figure are inherited from the Network-Based-Information-Asset ontology. Those that are specific to the Engineering-Model class or its children, including the Simulation-Model class, are marked with an asterisk.

Note that a Data Type may be a primitive type, such as an integer, real-number, pointer (reference) or string, or may be composed of other definitions. Data types may be defined recursively, and may include semantic as well as syntactic information. The data types shown in the example are relatively simple, however, as our intent here is to show both the use of the Global Information Locator Service definitions and to highlight the Simulation Model class.

Field Name	Data Type	Description
Abstract	structure	Specifies information relating to the general nature and scope of the asset
Asset-Creation-Date	Time-Point	Date and time of asset creation
Date-of-Latest-Revision	Time-Point	Date and time of most recent asset revision
Version	string	Revision or Version number for the asset
Brief-Description-of-Asset	string	Brief narrative description providing sufficient detail about the asset to identify its general nature in summary presentations to users
Long-Description-of-Asset	string	Narrative description of asset relating to its general nature and scope; description may include a discussion of the content (e.g., data coverage, persons, events, and topics), time span, and geographic coverage if relevant (500 words or less)
Access-Constraints	structure	References any known accessconstraints for this asset
Legal-Access-Restrictions	string	Specifies any legal restrictions that may limit the user's right to examine material, such as proprietary or classified information
Physical-Access-Limitations	string	Specifies any physical access limitations, such as off-line archival

Field Name	Data Type	Description
Additional-Documentation	list of refs.	Specifies any additional documentation that contributes to the identification, selection, and manipulation of the information, in particular for documentation related to the use of an automated information system
Agency-Program	reference	References the project or program(s) for which the asset was originally developed
Availability-Of	list of refs.	References information regarding the availability of the asset from a particular distributor
Control-Identifier	string	Specifies a unique identifying number for each information asset, consisting of an acronym followed by the control number
Controlled-Vocabulary	structure	References specific controlled vocabulary elements (such as keywords) that can assist in automated searching when a large number of assets are available
Index-Terms-Controlled	list	Specifies a grouping of descriptive terms drawn from a controlled vocabulary source to aid users in locating entries of potential interest
Controlled-Term	string	Identifies multiple topics within a given controlled vocabulary
Thesaurus	reference	Provides a reference to a formally registered thesaurus or similar authoritative source of the controlled index terms (e.g., the RASSP VHDL Model Taxonomy)
Cross-Reference	list of refs.	Provides for the description of related information resources, links to additional Thesauri, etc.

Field Name	Data Type	Description
Date-Of-Last-Modification	Calendar-Date	Specifies the date that the meta-data entry for a particular information asset in the knowledge base was last modified
Local-Subject-Index	list of strings	Augments information provided in thesauri, or can be used in the absence of an acceptable thesaurus
Methodology	list of structs	Identifies any specialized tools, techniques, or methodology used to produce an information asset
Methodology-Description	string	Identifies a particular methodology used, through a textual description
Methodology-Documentation	list of refs.	Reference to one or more documents that pertain to the methodology used
Model-Abstract*	structure	Provides a means to categorize models according to a set of attributes that are useful in distinguishing models intended for distinctly different purposes
External-Resolution	structure	Describes how a model describes the interface of the modeled device to other devices
Temporal-Resolution	string	Represents the resolution of events that are modeled in terms of their time scale
Data-Resolution	string	Defines the resolution with which the format of values are specified
Functional-Resolution	string	Refers to the level of detail with which a model describes the functionality of a component or system
Structural-Resolution	string	Refers to the level of detail a model provides about how the modeled component is constructed out of constituent parts

Field Name	Data Type	Description
Internal-Resolution	structure	References how a model describes the timing of events, functions, values, and structures that are contained within the boundaries of the modeled device
Temporal-Resolution	string	Represents the resolution of events that are modeled in terms of their time scale
Data-Resolution	string	Defines the resolution with which the format of values are specified
Functional-Resolution	string	Refers to the level of detail with which a model describes the functionality of a component or system
Structural-Resolution	string	Refers to the level of detail a model provides about how the modeled component is constructed out of constituent parts
Model-Class*	string	Describes the class of model as an enumerated string from the following list: Behavioral Model, Functional Model, Structural Model, Performance Model, Interface Model, Mixed-Level Model, Virtual Prototype
Model-Maturity*	structure	States the maturity level of the model in terms of the engineering design information available to work with, test-bench availability, and so forth
Source-Maturity	string	Specifies the level of maturity of the source code for the model as an enumerated string: "Exists - completely models all capabilities", "Exists - partially models some capabilities", "Source-code" available / may be licensed / not-available, "Proposed / needed"

Field Name	Data Type	Description
Documentation-Level	string	Specifies the level of maturity of the documentation: "Complete user documentation available", "Design intent available", "Diagrams Only", "No documentation available"
Test-Data-Maturity	string	Specifies the test-bench maturity level, as follows: "Full test-bench exists", "Stimulus (test vectors) exists", "Expected outcome exists (test results)", "None"
Validation-Level	string	Specifies the level to which a model has been validated: "Compiles", "Runs", "Tested", "Verified", "Validated", "Mature / In Use"
Reusability-Level	string	Specifies the level of generality of the model from a reusability perspective: "Application-specific, single purpose", "Somewhat reusable - some functions generalized", "General-purpose"
Support-Level	string	Specifies the level of support by the originators: "Unsupported", "Partially supported", "Fully supported"
Model-Year-Architecture-Support*	structure	Describes the extent to which the model supports the RASSP Model- Year Architecture (MYA) methodology
Type-Of-Encapsulation	string	Specifies the type of MYA encapsulation (i.e., SVI, simple RNI, complex RNI)
Maturity-Of-Encapsulation	string	Provides an indication of the level of maturity of the encapsulation (i.e., Model Text Exists, Interfaced, Synthesized, Targeted)

Field Name	Data Type	Description
Original-Control-Identifier	string	Provides a means through which users can determine that while the descriptions of two assets may differ, one is a derivative of the other
Originator	reference	References the organization or agency that created and maintains the information asset
Point-of-Contact-For-Further-Information	reference	Identifies an organization or individual where appropriate responsible for the content of the information asset
Programming-Characteristics*	structure	Describes general programming characteristics of a model
Programming-Level	string	Describes the Programming Level for the model as an enumerated string, including: Object-Code, Micro- Code, Assembly-Code, High Level Language (HLL) Statements, DSP Primitive Block-Oriented, Major Modes
Programming-Language	string	Describes the language in which the model is written (e.g., C, PCL, various graphing languages)
Is-Synthesizable	string	Indicates whether or not the model is synthesizable (yes/no)
Execution-Scripts-Available	string	Specifies whether or not execution scripts ("run files") are available for the model (yes/no)
Standards-Compliance	string	Specifies the modeling language compliance, and to which standard (e.g., Verilog, VHDL-93)
Test-bench-Available	string	Specifies whether or not a test bench is available for the model (yes/no)
Test-Vectors-Available	string	Specifies whether or not test vectors are available for the model (yes/no)

Field Name	Data Type	Description
Purpose	string	Specifies why this information asset is offered; identifies other programs, projects, and legislative actions wholly or partially responsible for the establishment or continued delivery of this resource; may include origin, lineage, related asset inf.
Record-Source	structure	Specifies the organization that created the meta-data descriptor for this asset, which may or may not be the same as the originator, depending on circumstances
Department/Agency	reference	Refers to the umbrella organization or corporate entity responsible for the creation of this meta-data record (e.g., Department of Defense, Lockheed Martin Corporation)
Major-Organizational-Subdivision	reference	Refers to the major subdivision, sector, or strategic business unit responsible for the creation of this meta-data record (e.g., US Army, Electronics Sector)
Minor-Organizational-Subdivision	reference	Refers to the relevant minor subdivision, sector, or organization (e.g., Advanced Technology Laboratories)
Name-Of-Unit	string	Refers to the specific organization that create the meta-data record (e.g., Embedded Systems Laboratory)v
Sources-Of-Data	string	Provides information about the primary sources or providers of the data to the system
Spatial-Reference	structure	This element is a grouping of subelements that together provide the geographic reference for the information resource.

Field Name	Data Type	Description
Supplemental-Information		This element may be used to for other descriptive information
Time-Period-Of-Content	structure	Specifies the time frames associated with the information asset
Time-Period-Structured	Time-Range	Specifies a time range as defined in the USMARC prescribed format, derived from the ANSI X3.30 standard
Time-Period-Textual	string	Specifies a time range as a free text string
Title	string	Provides the name of the asset as assigned by the originating agency or organization
Use-Constraints	string	Specifies any constraints or legal prerequisites for using the asset or its component products or services

The ontology for the Simulation-Model class of data objects leverages work performed on the program by a number of members of the VHDL users' community. The RASSP VHDL Modeling Terminology and Taxonomy Specification documents their work and provides additional technical details regarding certain aspects of the ontology.