Highlevel Inspection Process Plans HIPP

1
High-level Inspection Process Plans (HIPP)

• Thomas R. Kramer
• Guest Researcher, Knowledge Systems Group
• National Institute of Standards and Technology
• April 24, 2007

2
Introduction

• Presenting the inspection aspects of the
  Feature-Based Inspection and Control System
  (FBICS).
• FBICS
• is a fully automated research-grade system for
  inspection and machining (not discussing
  machining today)
• was built at NIST between 1996 and 2003
• illustrates a method of using a HIPP in a
  hierarchical planning and control system
• does both planning and execution
• has depth but not breadth (i.e. handles few
  features and operations at each level)
• This presentation includes answers to the
  questions for speakers, but I do not expect to
  have time to get to them

3
FBICS Overview (1)

• deals with dimensional properties of solid parts
• was used at NIST as the top three levels of a
  7-level hierarchical controller system for a
  Cordax CMM
• uses STEP methodology
• EXPRESS for information models
• Part 21 for files
• uses 13 types of data modeled in EXPRESS
• is based on STEP AP224 features (from the ARM
  model).
• deals with AP224 round holes, rectangular
  pockets, and counterbore holes
• uses only tolerances from Numeric_parameter_with_t
  olerance (although AP224 includes many tolerance
  types)

4
FBICS Overview (2)

• uses the Parasolid modeler to build a Brep,
  generate graphics, and answer questions about the
  workpiece
• uses NML communications (a NIST system)
• uses HOOPS graphics
• produces a lot of data
• simplest inspection job (hole in block) 18
  part-specific files
• TEAM part (machining and inspection) several
  hundred files

5
FBICS Architecture
USER
CELL controller plan generator plan executor
WORKSTATION controller plan generator plan
executor
TASK controller DMIS generator DMIS executor
FILE SYSTEM (database)
6
CELL

• Takes commands from user
• Focuses on inspecting whole part
• Decides
• how many fixturings are required
• what AP224 features should be inspected in each
  fixturing
• in what partial order fixturings should occur
• Generates Files
• plan for itself
• AP224 features to inspect in each fixturing (a
  file for each fixturing)
• setup file for each fixturing (specifies
  locations and base names)
• Totally orders fixturings to make linear
  "stage-two" plan
• Executes stage-two plan, giving commands to
  Workstation
• commands alternately tell Workstation to plan or
  to execute plan
• commands tell Workstation which files to read and
  what base names to use for the files the
  Workstation writes

7
WORKSTATION (HIPP level!)

• Takes commands from Cell
• Focuses on inspection done in one fixturing
• Decides
• how to locate part exactly
• what type of tool to use to inspect each AP224
  feature
• how intensively to inspect each AP224 feature
• in what partial order to inspect AP224 features
• Generates Files
• plan for itself that says locate part exactly
  then inspect features
• Totally orders feature inspections to make linear
  "stage-two" plan
• Executes stage-two plan, giving commands to Task
• first command is open, last is close
• other commands tell Task to write DMIS or to
  execute DMIS
• commands consist of files and messages

8
TASK

• Takes commands from Workstation
• Focuses on inspecting one feature (or other
  inspection operation)
• Decides
• which particular tool to use for inspecting each
  feature
• what DMIS features to construct and inspect for
  each AP224 feature
• what points to touch
• what toolpath to use
• Generates section of DMIS code
• Executes section of DMIS code
• uses DMIS interpreter
• gives commands to Prim using canonical inspection
  commands
• (similar to I DME commands)
• gets data from prim

9
FBICS Process Plans (1)

• FBICS uses two-stage process plans at cell and
  workstation levels
• Stage-one plans
• based on ALPS, a general-purpose discrete event
  process planning language (ALPS A Language for
  Process Specification)
• ALPS is extended with subtypes of
  primitive_task_node
• steps are only partially ordered
• may omit steps such as tool changes that may or
  may not occur
• Stage-two plans
• totally ordered
• include all steps

10
FBICS Process Plans (2)

• Plans use other part-specific files by reference
  (i.e. HIPP requires data not in plan file)
• setup
• part
• features to inspect
• fixture
• Plans use options files indirectly
• rules for constructing plans
• not part-specific

11
FBICS Options Files (1)

• option items might be put in process plans,
  instead
• options files specific to one or more subsystems
• Shop (two or more subsystems)
• Workstation
• Task
• inspection options include the following
• choice of rules for deciding what to inspect
  (Cell and Workstation)
• inspect all features
• inspect no features
• inspect features with any tolerance
• inspect features with tight tolerances
• let user decide which features to inspect

12
FBICS Options Files (2)

• choice of inspection intensity (Workstation)
• high
• medium
• low
• how many points to use for each of 5 DMIS feature
  types at each of three levels of intensity (Task)
• line
• plane
• cylinder
• cone
• sphere
• size of tolerance regarded as tight (Cell and
  Workstation)

13
Simple Example - Part
14
Simple Example - Part file

• ISO-10303-21 HEADER FILE_DESCRIPTION ((),'1')
• FILE_NAME ('out.stp','2003-01',('TK'),('NIST'),'ha
  nd-written','NA','OK')
• FILE_SCHEMA (('ARM224')) ENDSEC
• DATA 1 DIRECTION_ELEMENT ((0.0, 0.0, 1.0))
• 2 DIRECTION_ELEMENT ((1.0, 0.0, 0.0))
• 3 LOCATION_ELEMENT ((50.0, 50.0, 0.0))
• 4 ORIENTATION (1, 2, 3)
• 5 NUMERIC_PARAMETER ('block Y dimension',
  100.0, 'mm')
• 6 NUMERIC_PARAMETER ('block X dimension',
  100.0, 'mm')
• 7 NUMERIC_PARAMETER ('block Z dimension',
  50.0, 'mm')
• 8 BLOCK_BASE_SHAPE (7, 4, 5, 6)
• 11 FLAT_HOLE_BOTTOM (.T.)
• 21 NUMERIC_PARAMETER('hole diameter', 50.0,
  'mm')
• 22 CIRCULAR_CLOSED_PROFILE (21)
• 23 NUMERIC_PARAMETER ('hole depth', 25.0,
  'mm')
• 24 LOCATION_ELEMENT ((50.0, 50.0, 50.0))
• 25 ORIENTATION (1, 2, 24)
• 26 ROUND_HOLE (25, 'top_hole', 11, , 22,
  23)
• 27 SHAPE_ASPECT ((), (), 26) 110 SHAPE
  ((27), 8, ())

15
Simple Example - Plan file

• ISO-10303-21
• HEADER
• FILE_DESCRIPTION((''), '21')
• FILE_NAME('iplans_1_1work','2003-12-02T153549-05
  00',
• (''), (''), 'ST-DEVELOPER v8', '', '')
• FILE_SCHEMA (('FBICS_COMBO','FBICS_ALPS'))
• ENDSEC
• DATA
• 10END_PLAN_NODE(16,4,,,(),())
• 11INSPECT_FEATURE_GEOMETRY(16,3,'inspect
  top_hole',,(10),(),1,
• .MEDIUM.,(),'PROBE-20.0-4.0',0,1000.)
• 12LOCATE_PART(16,2,,,(11),(),0,.MEDIUM.,(),'
  PROBE-20.0-4.0',1000.)
• 13START_PLAN_NODE(16,1,,,(12),())
• 14INTERNAL_STRING(16,'length_units',.T.,'mm')
• 15INTERNAL_STRING(16,'setup_file_name',.T.,'ise
  tups_1.stp')
• 16PLAN('iplans_1.stp','version 1',(),(14,15),
• 'WORK','a part','generated by FBICS',(13,12,11
  ,10))
• ENDSEC

16
Simple Example - Plan Meaning

• plan identifies
• own name, version, name of setup file, length
  units of plan, hierarchical level, nodes, etc.
• each node identifies
• plan it belongs to, node number, node name,
  successors (for ordering), etc.
• feature inspection node identifies also
• inspection intensity level, type of tool to use,
  feature index, feed rate

17
Simple Example - Setup file

• ISO-10303-21
• HEADER
• FILE_DESCRIPTION((''),'21')
• FILE_NAME('isetups_1','2003-12-02',(''),(''),'ST-D
  EVELOPER v8', '','')
• FILE_SCHEMA (('SETUP'))
• ENDSEC
• DATA
• 10SETUP_SPEC(11,21,22,23,24,12,.T.,'mm')
• 11FILE_NAMES('isetups_1.stp', 'out.stp',
  'small_vise_half.stp',
• 'iplans_1.stp', 'ifeats_1.stp', 'out.stp')
• 12BOX_SETUP(25,26)
• 13DIRECTION_SETUP(1.,0.,0.)
• ...
• 20DIRECTION_SETUP(0.,0.,1.)
• 21AXIS2_PLACEMENT_SETUP(27,14,13)
• ...
• 24AXIS2_PLACEMENT_SETUP(30,20,19)
• 25CARTESIAN_POINT_SETUP(0.,0.,0.)

18
Simple Example - Feature file

• ISO-10303-21 HEADER FILE_DESCRIPTION((''),'21')
  
• FILE_NAME('ifeats_1','2003',(''),(''),'ST-DEVELOPE
  R v8', '', '')
• FILE_SCHEMA (('ARM224')) ENDSEC
• DATA 10MATERIAL('aluminum','soft
  aluminum',,(),())
• 11BLOCK_BASE_SHAPE(14,24,15,16)
• 12NUMERIC_PARAMETER('hole diameter',50.,'mm')
• 13NUMERIC_PARAMETER('hole depth',25.,'mm')
• 14NUMERIC_PARAMETER('block Z dimension',50.,'mm'
  )
• 15NUMERIC_PARAMETER('block Y dimension',100.,'mm
  ')
• 16NUMERIC_PARAMETER('block X dimension',100.,'mm
  ')
• 17CIRCULAR_CLOSED_PROFILE(12)
• 18FLAT_HOLE_BOTTOM(.T.)
• 19LOCATION_ELEMENT((50.,50.,50.))
• 20LOCATION_ELEMENT((50.,50.,0.))
• 21DIRECTION_ELEMENT((0.,0.,1.))
• 22DIRECTION_ELEMENT((1.,0.,0.))
• 23ORIENTATION(21,22,19)
• 24ORIENTATION(21,22,20)
• 25ROUND_HOLE(23,'top_hole',18,,17,13)

19
Questions and Discussion
20
1A. Define a high-level inspection process plan,
generally.

• A high-level inspection process plan focuses on
  the dimensional inspection of a part done in
  single continuous session on a single inspection
  machine. Usually, the part is not moved during
  the session. The plan says what features of the
  part to inspect, how intensively to inspect each
  of those features, and what tolerances to apply.
  The plan specifies methods to use to establish
  coordinate systems. The plan may also specify
  what feature-fitting and tolerance-computing
  algorithms to use and how to report the results
  of inspection.
• The level of abstraction of a HIPP should be
  about the same as the level of abstraction of
  machining process plans in ISO 14649, the basis
  for STEP-NC.
• It will probably be useful if the HIPP model
  includes a method of specifying tool paths. This
  is really a low-level item, but if it is not
  included at the HIPP level, it will be necessary
  to have a user interface to low-level inspection
  process planning that allows the manual insertion
  of tool paths. ISO 14649 machining plans include
  methods of specifying tool paths.

21
1B. Is it (a HIPP) metrology equipment
independent?

• A HIPP should be usable with all metrology
  equipment of a specific type (e.g. scanning CMMs)
  that has the required inspection volume and
  accuracy. Some HIPPs may be usable with different
  types of metrology equipment, but that is not
  normally expected to be possible. For example, a
  HIPP for a standard CMM would not normally be
  expected to be executable using a laser tracker.
• The HIPP model must include some method of
  specifying the sort of DMEs that will be able to
  execute the plan.

22
1C. Since the HIPP will input to a low-level
process planner, what information will that
planner need?

• The HIPP will not necessarily be input to a
  low-level process planner. The HIPP may be
  executed directly by a control system at the same
  level as the planner that makes the HIPP. In this
  type of system, commands derived from the HIPP
  are generated by the high-level planning and
  execution system and sent to a low-level planning
  and execution system.
• If the HIPP is passed as a whole to a low-level
  planner, the low-level planner will need at
  least
• 1. The HIPP
• 2. A representation of the part being inspected
  that a solid modeler can deal with.
• 3. A file of geometry referenced by the HIPP (but
  only if the HIPP itself does not incorporate the
  required geometry and does not point to
  components of the representation of the part).
• 4. A catalog and/or inventory of inspection
  tools.
• 5. A representation of the geometry of items in
  the DME's workspace to be used for collision
  checking.
• 6. Knowledge of the inspection policies to be
  used. Policies might be included in the HIPP
  itself, or they might be specified for a shop or
  workstation.
• 7. A representation of key parameters of the
  machine which is to execute the low-level plan.

23
2. What existing data formats (either proprietary
or non-proprietary) define the upstream
information needed for generating a HIPP, e.g.,
STEP AP203e2, DML?

• The upstream information need for generating a
  HIPP is very diverse. I am not familiar with many
  of the formats.
• Certainly a CAD model of the part to be inspected
  is required. The CAD model must include
  dimensions, tolerances, and materials STEP
  AP203e2 may be adequate for that (I have not
  studied the second edition).
• Information about the class of machines expected
  to be able to execute a low-level process plan
  generated from a HIPP is required. I do not know
  of any defined formats for such information.
• One objective in deciding what to inspect is
  often to inspect as little as possible, only
  enough to be confident that products are being
  produced with the required functionality and an
  acceptable failure rate. Thus, the data required
  to make a HIPP may include items such as
  statistical information from past inspections,
  knowledge of the state of product development,
  informal reports on what features tend to be out
  of spec, and company inspection policies or legal
  requirements. I do not know of any defined
  formats for such information.

24
3. What existing data formats (either proprietary
or non-proprietary) define a HIPP?

• FBICS provides an example. The data formats used
  in FBICS define a HIPP.
• The modeling methodology used is important. A
  good methodology includes two parts (1) a
  meta-model (in some formal language) and (2) a
  method of recording instances of things defined
  by the meta-model. The method of recording
  instances may be a file format or an application
  programming interface (API)). Typically,
  methodologies of this sort are accompanied by a
  tool kit. One of the tools will read the
  meta-model and build computer code in some
  standard computer language or other. The code
  will include structures based on the structures
  in the meta-model, and will include methods for
  manipulating the structures. Another tool will
  read the meta-model and be able read and write
  files based on the meta-model.
• Two examples of this methodology are provided by
  STEP and OMG. In STEP, the meta-modeling language
  is EXPRESS, and the file format is STEP Part 21.
  Toolkits are provided by several vendors, a
  prominent one being the STEP Tools ST-Developer
  (see http//www.steptools.com). FBICS was built
  using ST-Developer. In OMG, the meta-modeling
  language is MOF, the file format is XMI, and I do
  not know where to get toolkits, but several are
  said to be available (see http//www.omg.org/mof).

25
3. Continued

• In my view, it would be a bad idea not to use
  this methodology if a HIPP is defined.
• Based on my experience with FBICS, I also think
  that it might be useful for a HIPP to be built by
  starting with a general-purpose discrete event
  process planning language, such as ALPS, and
  extending the language with the additional
  constructs required for inspection. That way,
  half of the work is already done (if an existing
  language such as ALPS is used) or needs to be
  done only once (if a new language is developed).

26
4. Would a standard (i.e., non-proprietary)
definition of upstream information (needed for
making a HIPP) increase interoperability?

• Yes. The most important type of upstream
  information to make standard is geometry and
  topology with dimensions and tolerances included.
  It seems unlikely that other types of required
  information will be standardized.

27
5. Would a standard data definition of a HIPP
increase interoperability?

• Yes. Definitely.

28
6. What information is needed to generate a HIPP,
e.g., GDT, surface properties, equipment
constraints, and part characteristics?

• See answer to question 2.

29
7A. Who will join a group and remain active to
promote standard interface development for
high-level inspection process planning?

• I do not know who will join the group. To be
  effective, the group must include mostly users
  and vendors. A minority of academic and
  government representatives can be useful. It
  seems likely that it will be difficult to get
  adequate vendor involvement.

30
7B. If a group is formed, what should be the
group's scope, goals, and objectives?

• Scope Focus on high-level inspection process
  plans for dimensional
• measurement equipment
• Goals/Objectives Develop an international
  standard for high-level
• inspection process plans for dimensional
  measurement equipment

31
7C. Would you invest time and resources to make
this happen?

• I would be willing to invest some time working
  with such a group. I have no resources other
  than time, but NIST might provide other
  resources.