Fault Reporting in KID

<<< Picking

Chapters

KID Class Structure >>>

Contents

• 15.1 Introduction
• 15.2 Fault types
• 15.3 Fault isolation and simplification

[back to top]

15.1 Introduction

One of KID's important functions is as a medium in which to report back any suspected faults in PARASOLID in a consistent and system (both hardware and software) independent manner and in a form which makes it easy for the fault to be investigated. If it is possible to demonstrate the absence or presence of the fault using a KID journal file, there is the additional benefit that the KID journal file can be incorporated into regression tests.

[back to top]

15.2 Fault types

In general, faults fall into two categories:

• Faults which generate an error message. These can normally be reproduced with a journal or KID file.
• Faults which generate a visual error, or no system error message. These require careful description and an accompanying picture, if appropriate, for diagnosis.

[back to top]

15.3 Fault isolation and simplification

It is of considerable help if the user can isolate the fault occurrence to the shortest possible KID journal file. In many cases it is possible to trim out irrelevant operations that are not implicated in the fault and this should be done. For example, if a fault is found in the process of building a large model, it may be possible to reproduce the fault with a much simplified version of the model.

• The journal file should not contain all the operations necessary to create the bodies involved in demonstrating the fault. These should be transmitted and the transmit files sent along with the KID journal file, which should contain appropriate receive statements:

• Frequent use of (modeller mark) aids debugging.
• It helps to understand a fault, and therefore enables a quicker fix to be produced, if the following is completed:
• whenever possible simplify the fault
• keep the KID journal file, that is required to reproduce the fault, as short as possible

[back to top]