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.

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

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:

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 are also categorized:

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.

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:

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

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.

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.

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.

An example of a user modified configuration file follows:

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);

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.

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:

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.

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.

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.

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.

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

ievm_SetFix
ievm_SetType
ievm_SetDefault
ievm_SetSeverity