# SUBSYSTEM OVERVIEW

IGES Entity Validation Manager (IEVM) Subsystem

The IEVM subsystem provides an application with validation of IGES entities. In most cases a fixup can be performed which will correct invalid entities so that they may be processed. Validations can be performed only on the model level and backpointers must be enabled. All explicitly defined semantics in the IGES specification are checked in addition to many implied restrictions. The results of the validation are stored in application data with the model. The application can query this data to determine if an entity failed any validations and which specific validations failed.

# VALIDATION TYPES

For the purposes of the IEVM subsystem, validations are categorized into 3 levels:

1) Trivial value checks requiring no computations 2) Checks requiring trivial computations 3) Checks requiring significant computations

Level 1 validations require little or no overhead beyond locking the entity and the overhead of a comparison. Level 2 validations require computations to perform the check. These computations are likely to be repeated in translating the entity to a native format so they must have reasonably low overhead. Level 3 checks require significant computations to perform the validation, often resulting in as much or more overhead than required to translate the entity to a native format. Examples of each level are:

1) Checking a 106:40 for at least one segment 2) Checking that the start and radii of a 100:0 are equal 3) Checking for discontinuities in a trimmed surface

Additionally there are three types of validations: explicit, implied, and application defined. Explicit validations are those documented in the IGES specification or the recommended practices guide. Implied validations are general assumptions which most developers make about the specification (they are likely to vary as different developers may have different interpretations). Application defined validations may be checks to handle restrictions imposed by a particular application or to validate that an entity conforms to a pre-defined subset (such as CALS x or VDA-IS).

# ENTITY CORRECTIONS

Entity corrections are also categorized:

1) Single field, IGES specified default 2) Single field, application specified default 3) Derivable field value(s) 4) Assumed information added 5) Missing, non-derivable information

Type 1 corrections occur when a field contains an invalid value and the IGES specification defines a default for that field (e.g. the font code field in a 212). Type 2 corrections are the same as type 1 except there is no IGES defined default (e.g. the box height field in a 212). In this case the application must specify a default. Type 3 corrections occur when one or more fields are in error but can be recalculated from other fields in the entity with little or no loss of information (e.g. the continuity flag in a 112). Type 3 corrections may require significant computations to correct. Type 4 corrections require assumptions to be made about the entity content and information to be added to make the entity valid (e.g. a non-contiguous 102 could be corrected by adding a line segment to join the non-contiguous segments). Type 5 corrections are the same as type 3 except that the information is not directly derivable from the remaining entity information (e.g. a 214 pointer is missing from a 216). The IEVM subsystem addresses types 1-4.

# SEVERITY LEVELS

The IEVM subsystem uses a set of arbitrary severity levels ranging from 0 to 4. If a 0 severity is encountered no validation failed or that a validation failed but a fix-up was applied to an entity. If a severity of 1 or 2 occurs the entity is considered invalid, but it still can be processed. If a severity of 3 or 4 occurs the entity is considered invalid and should be ignored. The severities 1 and 3 are considered warnings/errors that are not explicitly restricted by IGES but may causes problems if the entity is processed. The severities 2 and 4 are considered warnings/errors that are explicitly restricted by IGES and may cause problems if the entity is processed. The application developer can define the severity level at which errors start. Note that the IEVM subsystem will always issue messages as warnings, regardless of the severity level.

The following are predefined severity levels with special meaning:

0

No validations failed or that a validation failed but a fix-up was applied.

1

An entity has questionable data but it is not explicitly restricted by IGES (e.g. zero length line).

2

An entity has data that is explicitly restricted by IGES. A validation failed which should not cause a problem in processing the entity but some data may be lost (e.g. an entity with a color number of 100). If possible a correction will be made to fix the problem.

3

An error occurred that is not explicitly restricted by IGES (e.g. number of segments in a 112 equals zero). If possible a correction will be made to fix the problem and the entity will then be valid but the correction but may not convey the intended information.

4

An error occurred that is explicitly restricted by IGES (e.g. a conic entity with an incorrect form number). If possible a correction will be made to fix the problem and the entity will then be valid but the correction but may not convey the intended information.

Additionally, the predefined value IEVM_UNSUPPORTED indicates that the entity type is not supported by IEVM.

# PHYSICAL ENTITY RELATIONSHIPS

The IEVM subsystem defines two types of physical entity relationships. The first applies to cases where the physically subordinate children are used to define the parent entity. Examples of this case include the 102, 118, and 216. The second case applies when the parent can exist even if one or more of its children are invalid. Example of this case include the 308 and 404. Generally these two cases are processed in an application differently (the 118 would not be processed at all if any of its children are invalid while the 308 can be processed even if it has invalid children). Each entity of the first type has a special validation defined to handle constituent entities being invalid. The validation ID is of the form BAD_SUBENT_NNN where NNN is the entity type of the parent. This error will be generated whenever a subordinate entity fails a validation of severity 3 or 4.

# DE STATUS VALIDATIONS

Validation is performed on the DE Status Numbers (DE field #9). Range checks are performed on all of the status flags (i.e. blanking, subordinance, usage, and hierarchy) and then they are checked against values explicitly stated in the IGES specification. More detailed validation is performed on all but the blanking flag, if no IGES values are given (i.e. '??' specified in the status number).

For the subordinance flag, only independent entities are checked (i.e. entities with a subordinance value of 0). If these entities are referenced by a physical parent and/or logical parent, a message is issued. A parent entity is an entity that references other entities. A physical parent is a parent entity that is not a 402 or 410. A logical parent is a parent entity that is a 230, 402, or 410. The subordinance flag is changed to the correct value (i.e. 1 - physical parent, 2 - logical parent, 3 - physical/logical parent), if a fixup is specified.

For the usage flag, all parameter space curves of 141 and 142 entities should have a value of 5, all children of 404 entities should have a value of 1, and 128 entities referenced by 144 entities should not have a value of 5. If any of these rules are violated, a message is generated, and the flag is changed to the correct value, if a fixup is specified.

For the hierarchy flag, if the value is 2, then the entity should reference a hierarchy property entity (i.e. 406:10). If this rule is violated, a message is generated, and the flag is changed to the correct value, if a fixup is specified.

# CONFIGURATION

An external file is used to configure the subsystem. The format of this file is documented in the evm_intro man page. A default file is supplied with IGES/Lib called ievm.evt in the msg subdirectory. Modifications can be made to this file to disable or change various characteristics of each validation. This user supplied file is compiled with the vtc(1) command. The function evm_InitializeTable and ievm_MergeTable are then used to replace the default information with that specified in the user defined table. The IEVM usage of each keyword in the validation table is defined below.

Keyword

Purpose

sev

Severity level associated with the check. See the description of severity levels above.

fix

The type of fixup to be performed. Available fixups follow the definition in a comment. If specified as 0, no fixup will be performed. If not specified at all then no fixups are available for the check.

def

The default value to be stored in the field if it does not pass the validation check. Field can be specified as an integer, floating point, or text value.

type

Computational overhead of check:

0 Do not perform check 1 Trivial value checks requiring no computations 2 Checks requiring trivial computations 3 Checks requiring significant computations

This is mainly an informational field to convey how much overhead is involved in performing the check. An option to the model validator allows all type 3 checks to be skipped. To skip a check, change the type to 0.

An example of a user modified configuration file follows:

BAD_FONT_NUM | sev=2 | type=1 | fix=1 | def=2;
BAD_LEVEL_NUM | type=0;

The first entry changes the default font number to 2 (instead of 1). The second entry turns off the level number check. After using the vtc command to compile the table (which results in an include file called ievm_ValCfg.h), the following code will enable the user modifications:

       #include "ievm_Interface.h"
       #include "ievm_ValCfg.h"
          .
          .
          .
       evm_InitializeTable (EVM_NOOPT, ievm_CheckTable);
       ievm_MergeTable (IEVM_NOOPT, ievm_CheckTable);

# ERROR REPORTING

By default, the IEVM subsystem will issue messages whenever a validation fails. The message will consist of the text defined in the configuration file followed by some standard fields. If a fixup is performed, a message will be issued describing the fixup. An option (defined below) allows messages to be turned off.

# BINDINGS

The subsystem can only be called on the model level. The main interface binding is:

    int ievm_ValidateModel (long option, int model,
    IEVM_VAL_RESULTS *val_results)

The following options may be used with the ievm_ValidateModel function:

IEVM_NO_FIXUPS Don't do any fixups IEVM_NO_MSGS Don't issue messages IEVM_FAST_CHECKS Don't perform any type 3 validation checks IEVM_NO_SEV1_CHECKS Don't perform any severity 1 checks IEVM_NO_SEV3_CHECKS Don't perform any severity 3 checks IEVM_PRINT_SEVERITY Print severity number of failed validation IEVM_STORE_ERRS Store an OLM list of the failed validations with in the

returned application data" IEVM_DELETE_BAD Delete all entities that failed validation with a severity of 3 or 4 as well as the failed entity's children. The failed entity will be deleted if it exists in one of the following cases: independent or part of a 308:0, 320:0, 402:1, 402:7, 402:14, 402:16, 404:0 or 404:1. A child entity will be deleted if it has only one parent and is physically subordinate to that parent. If the child entity has only one parent and it is logically subordinate to that parent, the child is made independent. After the validation, it is up the application to find out if there are any entities left in the model. (see iges_DeleteEntity)" IEVM_NO_LOOP_CHECKS Don't do invalid pointer loop checks

The results of a ievm_ValidateModel call are returned in a IEVM_VAL_RESULTS structure which contains the application data pointer, results. The application data contains the maximum severity level which occurred for each entity and optionally the list of validations which failed. This information is stored in a structure of type IEVM_RESULT and can be retrieved using ievm_GetResults. Note if a correctable error was found, and the correction was made, the maximum severity level for the entity will not include the severity for the corrected error.

If the IEVM_STORE_ERRS option was specified, the Failures member of the results structure contains an OLM list of IEVM_FAILURE structures. Each of these contains the PDX_MSGT identifier of a failed validation and a flag indicating if the error was corrected. These can be retrieved using a loop such as the following (when passed as a function to mda_TraverseModel, which prints the name of each failed validation):

    IEVM_VAL_RESULTS *val_results;
    DumpResults (MDA_PTR db_ptr)
    {
    IEVM_RESULT result;
    IEVM_FAILURE *failure;
    DDF_TF tf;

    char *fixed;

    ievm_GetResults (val_results, db_ptr, &result);
      if (result.Failures != NULL) {
      mda_ReadTF(db_ptr, &tf);
    /*  Filter out global section errors  */
        if (tf != IGES_GLOBAL) {
          printf ("DE %d: MaxSev = %d, # of failures: %dn",
                   iges_GetDE(db_ptr), result.MaxSev,
                   olm_GetCount(result.Failures));
          while ((failure = olm_CycleList (OLM_NOOPT,
                  result.Failures)) != NULL) {
            fixed=(failure->fixed) ? "fixed" : "not fixed";
            printf("   %s (%s)n",mpm_GetMsgName(failure->msg),
                    fixed);
          }
        }
      }
      return (PDX_NOERR);
    }

When used within an IGES translator, the maximum severity of an entity can be queried to determine if the entity should be processed.

A summary of the validation results can be obtained from the following call to mpm_IssueError():

mpm_IssueMessage (MPM_NOOPT, IFMT_SECTION5, val_results);

The options supplied to ievm_ValidateModel() will determine the format of the summary. The summaries below where generated from a file that had two label justification errors in the DE section and two zero length line and the severity for the IEVM_ZERO_LENGTH_110 check was changed from 1 to 4. If no option are specified, a simple summary is printed providing a brief summary of the validation. The Number Valid Total subtracted from the Entity Count Total must equal the Entities with Errors Total.

Entity Validation Summary:
|  |  |  | Entities | Entities
|  | Entity | Number Valid | with | with |
Type | Form | Count | or Corrected | Warnings | Errors
– | – | – | – | – | – | –
Global Section |  | 1 | 1 | 0 | 0
110 | 0 | 8 | 6 | 0 | 2
– | – | – | – | – | – | –
| Totals: | 9 | 7 | 0 | 2

If the IEVM_STORE_ERRORS option is supplied to ievm_ValidateModel, more warning and error information for each entity can be displayed. Please note that one entity can have multiple warnings and/or errors. Because of this, the Number Valid Total subtracted from the Entity Count Total might not equal the Entities with Errors Total.

Entity Validation Summary:
|  |  |  | Number of |  | Number of
|  | Entity | Number | Corrected |  | Uncorrected
Type | Form | Count | Valid | Warnings | Errors | Warnings | Errors
– | – | – | – | – | – | – | – | –
GlobalSection |  | 1 | 1 | 0 | 0 | 0 | 0
110 | 0 | 8 | 5 | 2 | 0 | 0 | 2
– | – | – | – | – | – | – | – | –
| Totals: | 9 | 6 | 2 | 0 | 0 | 2

The IEVM_DELETE_BAD option is supplied to ievm_ValidateEntity(), the last column that contained the number of Entities with Errors is replaced with a Deleted Entities column. This column lists all of the entities that have been deleted from the model.

Entity Validation Summary:
|  |  |  | Entities
|  | Entity | Number Valid | with | Deleted
Type | Form | Count | or Corrected | Warnings | Entities
– | – | – | – | – | – | –
Global Section |  | 1 | 1 | 0 | 0
110 | 0 | 8 | 6 | 0 | 2
– | – | – | – | – | – | –
| Totals: | 9 | 7 | 0 | 2

The IEVM_DELETE_BAD and IEVM_STORE_ERRORS options are supplied to ievm_ValidateEntity(), the number of Entities with Errors column is replaced with the number of Deleted Entities column. This column lists all of the entities that have been deleted from the model.

Entity Validation Summary:
|  |  |  | Number of |  | Number of
|  | Entity | Number | Corrected |  | Uncorrected | Deleted
Type | Form | Count | Valid | Warnings | Errors | Warnings | Entities
– | – | – | – | – | – | – | – | –
GlobalSection |  | 1 | 1 | 0 | 0 | 0 | 0
110 | 0 | 8 | 5 | 2 | 0 | 0 | 2
– | – | – | – | – | – | – | – | –
| Totals: | 9 | 6 | 2 | 0 | 0 | 2

# RUN-TIME TABLE MODIFICATION

The following functions can be used to alter to the validation table at run time.

    ievm_SetFix
    ievm_SetType
    ievm_SetDefault
    ievm_SetSeverity