1

AP210 Edition 2 Concept of Operations

Jamie Stori

SFM Technology, Inc. 

Urbana, Illinois 

Kevin Brady 

National Institute of Standards and Technology

Electronics and Electrical Engineering Laboratory

Thomas Thurman

Rockwell Collins, 

Cedar Rapids, Iowa 

NISTIR 7677
2

NISTIR 7677

AP210 Edition 2 Concept of Operations

Jamie Stori

SFM Technology, Inc. 

Urbana, Illinois 

Kevin Brady 

National Institute of Standards and Technology

Electronics and Electrical Engineering Laboratory

Thomas Thurman

Rockwell Collins, 

Cedar Rapids, Iowa 

April 2010

 U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, Director
3

AP210 Edition 2 Concept of Operations

This document provides information to support organizations wishing to develop data exchange and 

sharing implementations using AP 210. 

Contents

1. Background.....................................................................................................................................5

2. Product types that are supported by AP 210.....................................................................................6

3. Life cycle stages that are supported by AP 210 ................................................................................7

4. Disciplines that are supported by AP 210 ........................................................................................8

5. Product data types that are supported by AP 210 .............................................................................9

5.1 Information Rights Data ............................................................................................14

5.2 Requirements Data ....................................................................................................14

5.3 Functional models......................................................................................................15

5.4 Physical Models.........................................................................................................16

5.4.1 Product Shape Models for complete definitions..................................................16

5.4.2 Design Constraint Shape Models........................................................................17

5.4.3 Assembly Models for layered products...............................................................17

5.4.3.1 Assembly joints..............................................................................................19

5.4.3.2 Connection zones...........................................................................................19

5.4.4 Assembly models for mechanical products.........................................................20

5.4.5 Layered interconnect models..............................................................................20

5.4.5.1 Footprint definition ........................................................................................23

5.4.5.2 Land and Trace templates...............................................................................24

5.4.5.3 Printed components........................................................................................24

5.4.5.4 Microwave templates .....................................................................................25

5.4.5.5 GD&T............................................................................................................25

5.4.6 Material models .................................................................................................25

5.4.7 Material conductivity models.............................................................................25

5.4.8 Stackup Models for layered products..................................................................27

5.5 Design Rules .............................................................................................................27

5.5.1 User defined design rules ...................................................................................27

5.5.2 Predefined design rules ......................................................................................27

5.6 Simulation models.....................................................................................................27

5.7 Fabrication technology process capabilities................................................................28

5.8 Assembly technology process capabilities..................................................................28

5.9 Component Specifications .........................................................................................28

5.9.1 Component Functional Specifications ................................................................29

5.9.2 Component Physical Specifications....................................................................29

5.9.3 Component Functional and Physical Integration.................................................30

5.9.4 Connectors.........................................................................................................30

6. Business Cases for Implementation of AP 210............................................................................... 30

6.1 Enterprise designs and builds its own products...........................................................30

6.2 Enterprise subcontracts to manufacture products........................................................31

6.3 Enterprise archives its designs for future reference.....................................................31
4

6.4 Enterprise develops its own EDA/ECAD/MCAD libraries.........................................31

6.5 Enterprise uses externally defined libraries ................................................................32

6.6 Use Cases..................................................................................................................32

6.7 Using Systems...........................................................................................................32

6.8 AP Investigation sequence .........................................................................................32

7. The Different Roles in AP 210 Implementations............................................................................ 33

7.1 Systems Integrator's Role...........................................................................................33

7.2 Application Developer's Role.....................................................................................34

7.3 End-User's Role .........................................................................................................34

8. Components of AP 210 and Their Use in Exchange Implementations ............................................ 35

8.1 Scope.........................................................................................................................35

8.2 ARM .........................................................................................................................35

8.3 AIM...........................................................................................................................36

8.4 The mapping from ARM to AIM ...............................................................................37

8.4.1 Conformance requirements ................................................................................38

9. Implementation Forms .................................................................................................................. 38

9.1 File Exchange ............................................................................................................39

9.2 Shared Database ........................................................................................................39

9.2.1 Native EXPRESS database.................................................................................40

9.2.2 Working with other database technologies .........................................................40

9.2.3 Working with STEP based data hubs..................................................................40

9.3 Hybrid (File Exchange and Shared Database) ............................................................41

10. AP 210 Implementation Assistance & Support .......................................................................... 41

10.1 ISO............................................................................................................................41

10.2 PDES, Inc..................................................................................................................41

11. Electrical and Electronic Standards Comparison........................................................................ 42

12. References................................................................................................................................ 45
5

1. 0BBackground 

One of the most prevalent requirements of manufacturing industries today is the need to exchange and 

share product information within and between enterprises. This becomes almost impossible without a 

standardized, computer-interpretable method of representing and communicating the data. STEP provides 

a common way of defining product data, so it can be easily interpreted and used by application processors 

throughout the life cycle of the product. STEP is suitable for the standardized exchange of product data 

through files, as well as the sharing and archiving of product data in databases. 

Since the area of application of the STEP standard is so broad, it is issued in sections, called Parts. The 

Parts known as Application Protocols (APs) define the information requirements for exchange in a 

designated application area, based on: 

the type of product, 

the supported stages in the life cycle of the product, 

the disciplines that create and use the product data, 

the required types of product data.

In addition, an AP specifies the conformance requirements that must be met when validating an 

implementation of the AP.

The vision behind development of AP 210 is that artifacts that are important in the design process should 

be captured in a computer interpretable model so that the assertion made by the product development 

Figure 1-1. Design artifact traceability supports assertion based design. 

[Source: AP210 training, Ashville, North Carolina, 2003, PDES Inc.]

Requirements

Decomposition

Requirement

occurrence

Function to

Physical

Map

Functional

Path

Subset

(Single

Node)

Physical Unit

Network 

Subset

(Single Node)

Physical

Unit

Network

Omitted for Clarity:

1. Recursive definition; test benches

2. “Pin Mapping” in library

3. Simulation model library and associativity aspects.

Functional 

Decomposition

(Network)

Requirement

To Function

Function

Definition

Function

Occurrence

“Library”

“Design”

Requirement

To Assembly

Physical

Assembly

Decomposition

Physical Macro &

Component

Definition

Physical

Occurrence

Functional

Path Subset

To Assembly

Requirement

To Interconnect

Assembly to

Interconnect

Layout

Network

Subset to

Implement

Node Function to

Layout

Physical 

Interconnect

Decomposition

Layout

Occurrence

Layout

Macro &Template

Definition

Simulation 

Model

Definition

Requirement 

Verification 

Model

Simulation 

Model

Definition

Requirement 

Verification 

Model

AP210-based Multidisciplinary Model Associativity

Application: Requirements & Functions Allocation Traceability

Each column is a 

typical “stovepipe”

(a CAx tool island 

of automation)

Each yellow bubble is a 

typical associativity gap 

(problem area)

Requirements Functions (Abstract Design Intent) Physical Netlists Assemblies Interconnect 

Generic Electrical/Mechanical Engineering Layered Domain Model
6

team (during the design to manufacturing transition) that the design is mature enough for production may 

be validated by comparing details extracted from those artifacts with requirements assigned to the 

product..

Mature engineering organizations follow disciplined design processes that are amenable to the approach. 

For an example of a mature approach to electronic design in the US, the DO-254 standard "is intended to 

help aircraft manufacturers and the suppliers of aircraft electronic systems assure that electronic airborne 

equipment safely performs its intended function U[1]U. AP 210 is focused on domain specific modeling in 

the layered product model, a multi-level hierarchical continuity model, requirements, and multi-domain 

engineering integration. The remainder of this document focuses on the specific details of the various 

product models supported by AP 210 and highlights a few of the modeling structures used to facilitate 

multi-domain engineering integration. 

2. Product types that are supported by AP 210 

AP 210 is intended to support product development and transition to manufacturing for products that 

contain electronic content, whether it be a packaged semiconductor, a printed circuit card, a module, a 

black box or a server rack in a compute farm, or the compute farm itself. 

Firmware that is considered part of the configuration of the item is supported. The second edition 

supports firmware that is managed as part of the contents of the product version. The STEP technology 

EXAMPLE: A designer chooses a component based on value, tolerance, power rating and 

surface mounting style. When the schematic is saved, all one hundred fifty 

properties of that component in the master component information management system 

become requirements because the design system did not record the properties used to 

select the component. When a redesign is needed due to part obsolescence, it is 

more expensive to replace that component because of the uncertainty as to which 

properties were actually the required properties. In a mature enterprise, the 

design system would capture the properties that were used to select the specific 

component.

Figure 2-1. AP 210 Product Domain. 

[Source: AP210 training, Ashville, North Carolina, 2003, PDES Inc.]

Product Enclosure

External Interfaces

Printed Circuit Assemblies

(PCAs/PWAs/Modules)

Die/Chip Package

Packaged Part

Interconnect

Assembly

Interconnect 

Substrate (PCBs/PWBs/Cables)

Die/Chip

AP 210 

Domain: Electronic Design

Configuration Controlled Design and Use of Electronic Assemblies,

their Interconnection and Packaging
7

can support software managed at the serialized item level and will be considered as part of a future edition 

upon request to the committee. 

Current implementations focus primarily on printed circuit cards, although only the layered layout model 

is domain specific to layered products. Application of cables, wire harnesses, and wires in an assembly is 

supported. The layered layout model supports lumped element based layouts as well as microwave 

designs and combinations thereof. Tooling is included (e.g., panels, test coupons, solder paste stencils, incircuit test fixtures). Mechanical products are included (e.g., chassis, brackets, fasteners..)

Connectors are explicitly modeled. Cables, wire, and wire harnesses are modeled to the extent necessary 

to apply them to a product design but are not modeled at a level sufficiently detailed to manufacture the 

item.

All forms of interconnect substrates (e.g., rigid, flex, flex-rigid, MCM-D, molded interconnect device) are 

supported. If desired, ribbon cable could be supported with recommended practices All forms of assembly 

(e.g., single-chip package, PCA, module, black box) that exhibit electrical behavior are supported. Note 

that AP 210 supports separate product models for the interconnect and for the assembly. Assemblies and 

interconnects may be used as components in a higher level assembly or interconnect. The information

provided in AP 210 is sufficient to support the manufacture of assemblies, interconnects, and mechanical 

parts. The information provided in AP210 is sufficient to apply the various forms of discrete parts and 

material. The application of bulk material (e.g., glue pattern deposition) is supported.

A discrete part may be a physical part needed for either the assembly or interconnect (e.g., a lead frame). 

Information about bulk material (e.g., composition) is supported. The ability to unambiguously identify 

standard reference documents is supported. Consequently, Manufacturing Resource Planning (MRP) 

systems may exchange material data automatically through application of AP210 interfaces. 

3. Life cycle stages that are supported by AP 210 

The life cycle stages supported by AP 210 are: 

requirements capture; 

conceptual design; 

preliminary design; 

detailed design; 

transition to manufacturing; 

manufacturing support related to: 

NOTE: Managing calibration parameter updates in a product support environment is 

within the scope of AP 239. Establishing the data slots for those calibration 

parameters would be a joint AP application to ensure data consistency throughout 

the life cycle.

NOTE: AP 210 edition 2 is a superset of AP 203 edition 2 so any product definition 

that is supported by AP 203 will be supported by AP 210.

NOTE: Certain assumptions exist regarding the layered nature of the stackup model 

for interconnect which may need modification to support wire embedded in a truly 

circular dielectric matrix.
8

process changes; 

component obsolescence; 

customer driven change requests; 

enterprise driven change requests; 

regulatory driven change requests. 

customer support related to: 

failure analysis; 

other activities requiring detailed design data. 

4. Disciplines that are supported by AP 210 

Figure 4-1 illustrates the multiple disciplines involved in a single node of the supply chain. When one 

considers that a device may be a module which may contain one or more printed circuit cards, the 

explosion in complexity due to proprietary encodings and tailoring of formats becomes clear. AP 210 

provides a single unified model across the electronic supply chain which is compatible with other supply 

chain models, making it less costly for 2nd and 3rd tier suppliers to participate. 

Disciplines that may find AP 210 useful to facilitate the exchange or sharing of data include but are not 

limited to: 

Systems engineering, 

Electrical engineering, 

Mechanical engineering, 

Manufacturing planning, 

Manufacturing engineering for fabrication, assembly, test 

Producibility engineering, 

Reliability and maintainability engineering, 

Test engineering, 

Industrial engineering. 

Figure 4-1. AP210 Supply chain team. 

[Source: AP210 training, Ashville, North Carolina, 2003, PDES Inc.]

Device

Supplier

Design Hub

System Engineer

Simulation Model 

Supplier

Assembly Supplier

Customer

Package Data

Supplier

Requirements

Disciplines Supported by AP 210

Product Definition Team

MCAD

ECAD

Analyst

Fabrication Supplier
9

5. 1BProduct data types that are supported by AP 210 

Historically, each type of product data required it's own syntax and interpretation. Figure 5-1 shows 

typical files that are generated or consumed in a PCA design process that could be mapped to AP 210. 

The files are industry specific like Gerber or are vendor proprietary. In the case where these files are used, 

there is another set of activities that are manual in nature: tool setup and execution, results interpretation 

and decision making. These manual steps take considerable effort and when done on an ad-hoc basis lead 

to inconsistent product development life cycles across an enterprise. 

Engineering Information Integration Using 

Enterprise Proprietary Formats

PWA/PWB Design Tool Mech Design Tool

Enterprise System 

Integration 

Specifications

Enterprise

Proprietary PWA

Encoding s/w

Enterprise

Systems

Enterprise

Proprietary ME

Encoding s/w

PC

DESIGN

Database

ME

DESIGN

Database

Proprietary

Encoded

Data

Proprietary

Encoded

Data

Figure 5-2 Engineering Information Integration using proprietary formats.

Figure 5-1 Electronic Product data types supported by AP 210.

[Source: AP210 training, Ashville, North Carolina, 2003, PDES Inc.]

Product Data Types in Electronics

PWA/PWB Design Tool

Mfg Analysis

Analysis

Thermal EMC

Producibility Durability

In-Circuit Test

PWB Fabrication

CAM Tools

Text requirements

Nodal Analysis

Sneak Circuit Analysis

EDIF Functional Analysis

results

Gerber, ODB++

GenCAM, Vendor

Proprietary

Vendor

Proprietary

results

Vendor

Proprietary

results

Flying Probe

Bed of Nails

Function Test

results

Gerber 

ODB++

GenCAM

PWB

PWA

Vendor

Proprietary

GDS II

Mech Design Tool

IDF/DXF

results

Enclosure

Design

Design Capture

PWA/PWB Design

PWB Warpage/Stackup

Assembly Simulation

Component Footprint

Artwork

results

FAB

MRP
10

In many cases, enterprises using Lean(TM) or other principles learn best practices workflow and gravitate 

to a small number of design flows to reduce design cycle time. When the workflow is supported by 

engineering tool automation, the information generated and consumed by the workflow needs to be 

integrated into data generated and consumed by design tools. In some cases enterprises accomplish this 

integration by tailoring industry specific or CAD vendor specific files with user defined properties and 

structures to satisfy the enterprise internal data exchange requirements. Figure 5-2 illustrates this case 

when the task being facilitated is transfer of e.g., reference designators between an ECAD and an MCAD 

tool. 

Device

Supplier

Design Hub

System Engineer Simulation Model 

Supplier

Assembly Supplier

Customer

Package Data

Supplier

Requirements

Data Flow in The Supply Chain

Product Definition Team

MCAD

ECAD

Analyst

Fabrication Supplier

Figure 5-3 Supply chain team data flow.

[Source: AP210 training, Ashville, North Carolina, 2003, PDES Inc.]

Figure 5-4 Supply Chain Integration using proprietary formats.
11

NOTE: A reference designator is a string attached to an instance of a component in 

a design so that an engineer can relate a component instance on a printed circuit 

card to the representation of that component instance in a schematic, netlist or 

simulation. ECAD design systems enforce creation and management of reference 

designators while MCAD tools do not. Consequently when a designer wants to review a 

design in an MCAD tool, the reference designator data must be transmitted to the 

MCAD tool. The data transmitted would include the part number of the component 

instance, the component instance reference designator, and the location and 

orientation of the component instance. In addition, if the MCAD tool uses its own 

library of component models, the ECAD and MCAD libraries for that interaction must 

be coordinated since the 2D system may orient the x axis along the pin 1-pin 2 

direction or it may orient the y axis along the pin 1 - pin 2 direction. In legacy 

situations, this library orientation is defined in departmental exchange agreements 

and then the pre-processor or post-processor does any orientation corrections that 

are necessary.

EXAMPLE 1: A processor has a reference designator of U1 early in the design cycle. 

This reference designator plus the relevant information described above is 

transmitted to the MCAD system. Later in the design, the board component placement 

is updated with the processor designator being changed from U1 to U14. The updated 

information must be sent to the MCAD system.

EXAMPLE 2: A shield must be placed over a clock circuit. The shield is a mechanical

part but must be included in the electrical design for production release. The MCAD 

system does not maintain an internal reference designator so must send the data to 

the ECAD system and the ECAD system assigns a reference designator and sends the 

information back to the MCAD system.

EXAMPLE 3 : Neither the ECAD system nor the MCAD system have the feature 

classification included that will allow a designer to specify a fiducial, but the 

CAM system does have a manufacturing rule that a fiducial must be separated from 

other reflective objects by 3 mm. The solution for enterprises that have toolsmiths 

is to a: instruct PCB designers to code a metal feature in the ECAD system as a 

fiducial using whatever user-defined property mechanism the ECAD system provides; 

and b: write a ECAD post-processor that extracts the fiducial from the ECAD output 

file into the encoding needed by the CAM system. This example follows that shown in 

Figure 5-2 as well.

NOTE: Feature identification is another problematic area for multi-domain 

integration. ECAD systems enforce identification of features that are classified 

as terminals on electrical components but do not identify the geometric elements in 

the layout in most cases (microwave design systems may be the exception since each 

feature in a microwave design is a component instance and the port instances may be 

identifiable). The only identification most ECAD systems make is to identify the 

signal that the geometry is associated with. When the feature is part of a 

footprint instance and that knowledge is available to the pre-processor, some 

minimal identification information may be applied. With recent activities in 

implementation of GD&T by MCAD suppliers, feature identification is starting to 

make inroads in the MCAD area, but there is still progress to be made.

EXAMPLE 4: In an interaction between ECAD and MCAD designers, it is decided to move 

one edge of a PCB so as to make the PCB smaller. The number of vertices in the 

outline of the PCB remains constant. In order to communicate the design change from 

the MCAD system to the ECAD system, the entire outline must be sent to the ECAD 

system. Upon receiving the new outline model, the PCB designer has to review the 

entire outline to ensure that no unanticipated changes occurred in areas not under 

discussion. When the PCB designer saves the updated design, the fact that the only 

change that caused that design revision was the movement of one edge of the PCB is 

lost.
12

When the enterprise chooses to participate in a joint venture or supply chain, the data exchange and 

sharing procedures are formalized. Figure 5-3 illustrates a group of partners at one node of a supply chain. 

Since the encoding is proprietary, individual organizations will likely have chosen incompatible encoding 

structures and symbols even when the base file format is compatible. Exchange agreements have to be 

executed and mapping software created and maintained for the duration of that joint venture or supply 

chain. Most organizations participate in multiple joint ventures and supply chains further exacerbating the 

issue. Figure 5-4 illustrates this case. 

Figure 5-5 Supply Chain Integration using compatible APs.

When the joint ventures or supply chains are based on APs that have a core common model the result is 

significantly higher flexibility and responsiveness of the enterprise to new opportunities. The following 

APs are based on a common harmonized core: AP 203 2nd edition, AP 209 2nd edition, AP 210 2nd 

edition, AP 233, AP 239 2nd edition. Figure 5-5 illustrates this case. 

CAD

TOOL

Departmental 

Specific Encoding of 

Domain Specific Features

in CAD

Domain Specific

Features Data

(Out of Scope of

CAD Tool)

Native

CAD To

AP 210

Mapper

Departmental 

Encoding To 

AP 210

Mapper

Design Intent

CAD

Native

Data

Model

CAM

TOOL

CAM

Native

Data

Model

AP 210

To CAM

Mapper

Domain Specific

Features Data

(In Scope of 

CAM Tool)

AP 210 Data Set

Figure 5-6 Design to CAM Integration using AP 210.

[Source: Thurman, T., Benda, M., "From Paper Based Analysis to Model Based Analysis: 

Applications of AP 210 at Rockwell Collins", April 29, 2009, NASA-ESA PDE 2009]

An example of design to manufacturing integration is illustrated in Figure 5-6. In this case, manufacturing 

features that are in the scope of AP 210 (i.e., a Fiducial) are encoded using user-defined properties in an 
13

ECAD system. The mapping from the departmental encoding to AP 210 populates the correct entity in the 

AP 210 data set with the result that the receiving system only needs one mapper to populate the CAM 

tool, and no user interaction is required to hand-select the fiducials for planning or further processing. 

Design Intent

CAD

TOOL

Departmental 

Specific Encoding of 

Filled_via, material

Departmental 

Encoding To 

AP 210

Mapping

Analysis

TOOL

AP 210

To Analysis

Mapping

Analysis Results

AP 210 Data Set

Material

Property

Database

Native

CAD To

AP 210

Mapper

Filled_via

Classes

Filled_via

Material

Figure 5-7 Design to Analysis Integration using AP 210.

An example of design to analysis integration is illustrated in Figure 5-7. In this case, material features that 

are in the scope of AP 210 (i.e., a Filled_via) are encoded using user-defined properties in an ECAD

system. The mapping from the departmental encoding to AP 210 populates the correct entity in the AP 

210 data set with the result that the receiving system only needs one mapper to populate the engineering 

analysis tool, and no user interaction is required to hand-select the filled vias for analysis. 

Relationships Between Design Definition and

“Published Library Data” May be Established

and Managed Under Configuration Control.

Details are Invisible to Customer.

Design

Archives

Published

Library

Data

Customer

Accessible

Data

(Interfaces,

Pin Maps,

Behavioural

Models,

Organizational

Ownership

Declarations,

Parameters...)

Configuration

Managed

High Accuracy Models, Relationships

Design Definitions

Figure 5-8 AP 210 Design and Usage Views.

[Source: AP210 training, Asheville, North Carolina, 2003, PDES, Inc.]

Many users of electronic data require information on a product that conveys form, fit, function, and 

interface specifics, but does not include internal design details. AP 210 supports such exchanges of data 

for selection, installation, or interfacing the product. This is defined in the AP 210 Application Reference 

Model (ARM) as a usage view. Usage views may include functional and physical definitions and pin 

mapping between them. AP 210 may be used to support an electronic Interface Control Drawing (ICD) 

through the use of the "usage view" for a black box or module definition. A design view incorporates 

sufficient information for design disclosure or to manufacture an item. Figure 5-8 illustrates the case 
14

where a component supplier publishes library or "usage view" data on the web while maintaining design 

data in an internal repository. 

5.1 9BInformation Rights Data 

Support is provided to capture the producer and consumer rights for intellectual property and to assign 

rights to individual aspects of product data to the level of granularity specified by the supply chain 

agreement. Predefined filters are provided to relate producer and consumer views for product types and 

product data types commonly encountered in electronic industry. 

5.2 10BRequirements Data 

AP 210 provides capability to exchange the following data related to requirements: 

Requirements that flow down from higher levels in the product structure; 

Requirements that are based on enterprise or regulatory policies; 

Requirements that are externally defined (e.g., performance requirements); 

Requirements that are pre-defined in AP 210 

assembly spacing requirements; 

layout spacing requirements; 

mating feature requirements; 

fabrication requirements; 

connectivity requirements; 

interface requirements. 

The following structural capabilities are provided for requirements: 

Requirements may be decomposed in a tree structure; 

Requirements may be derived from other requirements; 

Requirements may be logically combined to compose new requirements; 

Requirements may be extracted from documents whose identification may be preserved. 

Requirements may independently exist and be managed to ensure the data is available for future 

product development; 

Non-conforming items and data may be specified; 

Interface signals; 

Mating connector relationships; 

Envelope shape the product is required to fit into; 

Electrical spacing requirements; 

Thermal spacing requirements. 

Association of requirements data with product data is accomplished explicitly in AP 210 by allocation 

relationships. These allocation relationships may become part of the design release package for a product. 

The separate storage of requirements supports trade off studies when design changes are requested 

because it removes the need to derive original requirements from released product data. 

Requirements are closely tied to performance characteristics. Performance characteristics are user-defined 

properties allocated to a particular aspect of product data. They may be “as required”, “as planned”, or, 

“as evaluated”. 

“As required” is the original requirement received and allocated to a particular aspect of product 

data. 

“As planned” is the characteristic value set planned by the design organization and includes 

appropriate design margin based on the as required" data. 
15

“As evaluated” is the characteristic value set experimentally determined during the design process 

for the “as planned” data. The “as evaluated” data may be the result of a Monte-Carlo prediction 

of production variability. 

5.3 1BFunctional models 

AP 210 provides capability to exchange these functional models: 

Hierarchical network decomposition. Each level includes functional elements and their 

interconnection. The representation is recursive, ending at a “primitive" (e.g., resistor, inductor, 

capacitor, AND element, ALU, etc.). 

o The interface to a function is represented in AP 210 by a usage view. 

o The definition of a network is represented in AP 210 by a design view. 

A flattened network is a representation of a network that is not hierarchical. The flattened 

network is usually the result of what is commonly known as a packaging process wherein the 

abstract functionality is assigned to individual physical parts, but no knowledge of layout is 

included. This is typically the input data to the interconnect substrate layout activity. A synonym 

for flattened in the context of VHDL is elaborated. The flattened network supports delay property 

assignment and hi-speed layout constraint definition. Data may be extracted from a flattened 

network to support in-circuit testing or functional testing, or to evaluate the design for compliance 

with design rules (e.g., are the power pins correctly separated from ground pins). 

A partitioned network is a data set that relates multiple flattened networks that are derived from 

one hierarchical network. Partitioned networks are used where multiple physical products are 

derived from one original functional network. For instance, a transmitter may need multiple 

interconnects (flex and ribbon cables), as well as several printed circuit assemblies and modules 

to perform the overall intended function. The mapping data needed to maintain integrity of the 

overall network is typically managed at a project level and not directly input to layout tools. In a 

traditional drawing based design methodology, a system wiring diagram would be used as a 

mapping between elements of the partitioned network. 

A simulation model is an encapsulation of the interface to, and optionally the source or 

executable code of, a simulation model defined in a computer interpretable modeling language. 

The usual purpose is to evaluate the capabilities of the product model in computer based 

experimentation. Support is provided for network definitions that are idealizations of actual 

product models for simulation purposes. 

A physical network is a predefined data set in AP 210 that maps the connection requirements for 

an interconnect substrate (as specified in a flattened network) onto the geometric domain in the 

layout of that interconnect substrate. The physical network references connectivity required 

between layers (as implemented for instance by a via) and connectivity required on a physical 

NOTE: This is a representation using STEP technology of the industry standard 

hierarchical decomposition.

NOTE: Properties may be assigned to topographic elements of flattened networks to 

use as input to layout routing tools or more detailed analysis tools.

In some cases, analysis tools may provide the data following typical parasitic 

extraction patterns.

NOTE: Partitioned networks are a powerful tool in validating that the physical 

design meets the functional requirements as they contain the maps from individual 

connection requirements back to the authoritative source.
16

layer (as implemented for instance by a trace). Data may be extracted from a physical network to 

support bare board testing and in-process fabrication testing. 

5.4 12BPhysical Models 

5.4.1 37BProduct Shape Models for complete definitions 

The shape models described in this section are a complete shape of the product. They may be composed 

of other shapes or may be one shape, depending on the application details. 

Two dimensional and three dimensional models of the supported products are included, with the added 

capability to specify the context for the model shape. The models typically are 2D wireframe, 2D csg, 3D 

manifold surface models, 3D advanced brep. Csg, manifold surface models and advanced brep models are 

commonly used where model quality is of importance. 

There are multiple purposes for shapes that are supported: 

analysis input; 

analysis output; 

shock analysis input; 

shock analysis output; 

design; 

vibration analysis input; 

vibration analysis output; 

electromagnetic compatibility analysis input; 

electromagnetic compatibility analysis output; 

thermal analysis input; 

thermal analysis output. 

The GD&T defined material condition may be specified (i.e., least, nominal, maximum material 

condition) The centroid may be specified. The application environment for the shape may be specified 

(i.e., manufacturing environment, end-user) 

The detail level of the shape is up to the implementation but explicit support for terminals is provided to 

enable hierarchical extraction of continuity for validation. 

The class of 3D shape may be specified as: 

extrusion, 

manhattan_block, 

other, 

is_unknown. 

A 3D shape extent property is provided for application to components targeted to be attached to layered 

interconnect: 

an overall shape including terminals with minimal details; 

a shape that includes only the body and not terminals; 

a shape that includes the shape of the mating lands; 

a shape that includes the lands and the associated breakout pattern. 

A 3D shape approximation level is provided for classification of shape model fidelity to actual product 

shape (i.e., coarse, detailed or unknown may be indicated). This is primarily used when the centroid is 

provided. In the case where there are several shapes provided, one shape may be designated as the master 

shape representation. 
17

For 2D shapes, the ability to provide intersections with planes parallel to the seating plane but at different 

locations is provided. 

5.4.2 38BDesign Constraint Shape Models 

Two dimensional and three dimensional models of design constraints (i.e., keepout/keepin regions) that 

limit the geometric solution space are included. Capability is provided to support total or partial keepout 

use cases with partial use case being based on the height of other components that would otherwise be 

located near the component specified by the shape constraint. Constraints may be applied on the same or 

opposite side of a thin or thick substrate. Components may be grouped and that group assigned to a 

region. An overall manhattan style shape for the interconnect substrate is provided. 

5.4.3 39BAssembly Models for layered products 

Specific modeling is provided to support the highly complex assembly structures for layered products 

(i.e., an assembly that contains one or more PCB/PWB or other interconnect substrate). Because 2D 

design tools use textual properties to represent some 3D assembly information, predefined models are 

provided to allow specification of: 

embedded discrete components; 

components mounted in cutouts; 

stacked components; 

components whose mechanical properties are finalized at assembly (e.g., transformers with wire 

leads); 

assembly specific connector pin-signal definitions (some connectors are too small to have easily 

identifiable pin numbers so the pin number is applicable only in the context of the assembly); 

complex component grouping that are placed with constraints; 

complex application of bulk bonding, coating, or reel material at assembly time using CAD 

geometry for installation shape

in order to support 2D CAD exchange and data achiving.

In the case of complex design requiring details of connection areas in order to support continuity studies, 

the ability to exchange/share those connection areas is provided. With the advent of robust GD&T 

modeling incorporated in translators, there is finally the ability to seriously consider replacing drawings 

with an AP 210 product model in an assembly context. Much of the detailed modeling in the standard is 

focused on replacing data currently provided on assembly drawings. Bill of Material related items like 

item find numbers, component substitution, raw material callouts, etc. are supported. Research conducted 

by Peak et al on information capture gaps in CAD design capture were followed by pilot projects that 

proved AP 210 addresses the majority of the gaps U[2]U.

For assemblies created using 3D design tools, AP 210 provides the ability to have reduced complexity 

models used in the assembly design tool to reduce memory footprint while allowing other tools to 

substitute needed component models with fidelity appropriate to their application. 

Some examples of component grouping that are supported by AP 210: 

EXAMPLE 1: A 1000 pin BGA could be modeled in an MCAD tool as a flat box, while a 

DFM application might use a model with a hierarchical representation (to reduce 

file size) of the pins while retaining the accurate location and shape information 

of the pins.
18

A critical item to note in the AP 210 assembly models in both 2D and 3D is the availability of 

information that specifies the actual mating features of the components. This permits continuity checks at 

any level of the product hierarchy by extracting "as designed" continuity information from the electrical 

or mechanical design system. 

Figure 5.4.3-1 Printed circuit card design visualization created from AP 210 data.

[Source: Thurman, T., Benda, M., "From Paper Based Analysis to Model Based Analysis:

Applications of AP 210 at Rockwell Collins", April 29, 2009, NASA-ESA PDE 2009]

EXAMPLE 2: The collection of components necessary to satisfy the functional 

requirement for a power supply.

EXAMPLE 3: The collection of components necessary to satisfy the functional 

requirement for a digital signal processor.

EXAMPLE 4: The collection of components with a case temperature greater than 55 

degrees Centigrade. The associated area would be a rectangle all of whose inner 

points are within 6 cm of the cooling unit.

EXAMPLE 5: Figure 5.4.3-1 illustrates the ease of visualizing a signal traversing 

multiple layers in a printed circuit card while also showing the component 

instances. In this example, the dielectric layers have been rendered invisible.
19

Figure 5.4.3-2 Assembly joint illustration in AP 210. 

[Source: ISO 10303-210:2001, ©ISO, used with permission]

5.4.3.1 Assembly joints 

Assembly joint is a term unique to AP 210 that captures mating relationships in an as-designed 

mechanical definition so as to support design rule checking and netlist design verification applications 

wherein the mechanical design is compared against the electrical netlist to ensure conformance to the 

netlist. 

AP 210 provides capability to exchange and share definition of assembly joints based on: 

classification of the bond that creates the joint; 

material composing the joint; 

types of joined features; 

bond wires. 

Experimental results may be captured. This capability extends the ability of organizations to reuse 

experimental results from one design to another. 

5.4.3.2 Connection zones 

Figure 5.9.2-1 illustrates a lower level concept that is sometimes critical in physics based product 

evaluation, a connection area or zone. This originated in the AP 210 project because of the need in legacy 

electronic design to validate that component applications in PWA design were correctly following the 

constraints of the component physical characteristics, namely lead length. The model in AP 210 is 

generalized from this legacy requirement and permits the specification of e.g., an area on a feature that is 

EXAMPLE: A connector that is placed in an assembly using a coordinate 

transformation that is a geometric representation of the relationship between the 

connector as a whole and the assembly it is helping to compose.

The transformation makes no assertions about the detailed relationships between the 

features of the connector and the other item or items in the assembly that it is 

mated with during the assembly realization process.

AP 210 provides the ability to assert the relationship of each feature of that 

connector to a corresponding feature on a printed circuit board.

An application may use that set of asserted relationships to verify the connector 

actually connects what it is intended to connect.
20

the specific region for energy or material transport through the surface of the feature. It could also 

commonly be used for areas to be spot finished (e.g., for bonding).

5.4.4 40BAssembly models for mechanical products 

Figure 5.4.4-1 multi-level product visualization supported by AP 210.

[Source: Thurman, T., Benda, M., "From Paper Based Analysis to Model Based Analysis:

Applications of AP 210 at Rockwell Collins", April 29, 2009, NASA-ESA PDE 2009]

AP 210 supports the simple AP 203 style assembly model when continuity is not of interest and the more 

complex part occurrence model when continuity is of interest, even though the assembly may not contain 

a PCB. When continuity is of interest, even though the model may be created by an MCAD system, 

wires, cables, connectors and assembly joints are still of interest and the more complex modeling will 

provide a benefit. 

Figure 5.4.4-1 illustrates a case where visualization aids product review. Signal tracing based on a 

common model is more easily integrated into a visualization environment than product technology 

specific ad-hoc approaches. 

5.4.5 Layered interconnect models 
21

Figure 5.4.5-1 Layered interconnect illustration of a PCB design represented with AP 210 data.

Figure 5.4.5-2 AP 210 stratum includes each material item in the stackup regardless of its 

electrical role. [Source: ISO 10303-210:2001, ©ISO, used with permission]

Layout data types to support the domain specific layered interconnect model are many, but the most 

important include the fact that the requirements for the interconnect are included separately from the

interconnect definition. This model is different from current CAD system practice wherein the 

connectivity definitions for assembly and interconnect are combined in one product model with the result 

that it is difficult to have more than one interconnect for an assembly and conversely more than one 

assembly reference the same interconnect (without copying the product model). Solutions to this problem 

tend to be vendor specific as the industry standards all assume one substrate per assembly. The 
22

application of an explicit interface definition (the usage view concept) to the interconnect and specifying 

externally the connectivity implemented by the interconnect is a step forward in design re-use capability.

Interconnect substrates are composed of layers of physical material referred to in AP 210 as stratum. Each 

stratum in AP 210 may be composed of stratum features or it may be a generic stratum (e.g., dielectric). 

Each stratum is defined by a technology that includes numerous properties necessary for accurate physicsbased predictive modeling as well as for material selection purposes. Stratum are assumed to have as least 

one surface (e.g., in the case of molded interconnect, there may not be a second surface). Each surface 

may have it's own set of properties so as to support sophisticated design requirements. Stratum may be 

represented by manifold surface geometry in which case the traces may follow complex 3D paths U[3]U. 

Support is provided for simplified stratum views based on ECAD abstractions and for PCB fabrication 

engineer more sophisticated needs, such as material composition, and the need to specify sequential 

laminate construction.

Figure 5.4.5-3 AP 210 stratum feature examples. [ISO 10303-210:2001, ©ISO, used with 

permission]

Each stratum feature is a contiguous area of material and may be modeled with advanced geometry (e.g., 

manifold surface model) to simplify geometric processing. Top level stratum features are disjoint and 

most often if they are on the electrical layers are tied to a signal. Some predefined stratum feature 

classifications are provided in the standard. Each stratum feature is defined by a combination of one or 

more lower level features (e.g., a stratum feature may consist of one or more lands and traces). 
23

The Layer_connection_point Application Object is an intersection concept between the topology 

requirements specified by the physical network, the point domain that satisfies those requirements in a 

geometric coordinate system specified by the stratum feature and the Stratum material definition that has 

the proper domain specific conductivity. The result is a realized shape that supports the topology 

requirements. 

Features that impact physical layers in a vertical context (manufactured by cutting, drilling, etc.) are 

positioned in the context of the interconnect substrate, as are the laminate components contributing to 

stratum features. Because some ECAD systems model certain layers with negative geometry, AP 210 

provides the ability to capture a representation of the original geometry even though the representation in 

AP 210 is always a positive material model. AP 210 also provides the ability to specify precedence 

relations between physical nets so that when a higher priority net is removed and the lower priority power 

plane is expanded, there is design intent information that is updated to show the relationship no longer 

exists. A key characteristic of the layout model is that the physical network model is closely coupled with 

the geometric model. Current pre-processors assume that the source CAD system generates valid 

geometry (i.e., that stratum features do not overlap since they are always supposed to be disjoint), so the 

characteristic may be only of theoretical interest. 

5.4.5.1 49BFootprint definition 

AP 210 provides capability to exchange and share footprint definition that are either generic or that are 

based on specific interconnect substrate technology. Breakout patterns are also supported. Experimental 

results may be captured. This capability extends the ability of organizations to relate their land patterns to 

substrate and assembly technology. 

NOTE 1: The set of Layer_connection_point associated with a Stratum_feature form a 

sample of the point domain of that Stratum_feature. In some cases centreline curves 

define the point domain. In some cases boundary curves define the point domain.

In all cases it is expected that the set of Layer_connection_point be a subset of 

the (geometrically) defined point domain.

NOTE 2: The Layer_connection_point location in an area based stratum feature should 

be sufficiently within the perimeter of the stratum feature to ensure unambiguous 

interpretation of the extent of the point domain.

EXAMPLE: A Layer_connection_point may be referenced by a lower level stratum 

feature with a truncated end condition in which case the Layer_connection_point is 

congruent with the edge of the component of the Stratum_feature. In that case the 

Layer_connection_point is located on the edge of that Stratum_feature.

NOTE 3: A Layer_connection_point may be placed in an area where the conductive 

material is removed since there is no information contained in that Application 

object regarding vertical material processes. It is the abstraction in this 

standard to separate lateral material description from the vertical material 

modification processes.

NOTE 4: A Layer_connection_point is normally not specific to one side of a stratum 

or another but in the case of embedded discrete component it is necessary to 

specify the side of the stratum included in the relationship.

NOTE 5: Both two-dimensional and three-dimensional locations are provided to 

support the case where both a two dimensional and a three dimensional 

representation of the interconnect design exist.
24

5.4.5.2 Land and Trace templates 

AP 210 provides capability to exchange and share definition of templates that will be used in the layout of 

the interconnect substrate. The templates may be simple or complex, and may be controlled by tolerances. 

The templates include explicit geometric models as an integral part of the data. 

AP 210 provides capability to exchange and share definition of trace parameters, including: 

width; 

corner style; 

end extension; 

end style, that are the usual CAD abstractions. 

AP 210 trace parameters are compatible with electronic industry formats including: 

IPC; 

GDSII; 

EDIF. 

AP 210 provides capability to exchange and share definition of land template parameters including the 

explicit geometry of the template, as well as what electrical and thermal requirements the land template 

satisfies. 

5.4.5.3 50BPrinted components 

AP 210 provides capability to exchange and share definition of complex features realized in an 

interconnect that have a specified function. AP 210 represents those features as a printed component 

whose definition is a printed part. 

Typical printed components include: 

printed connectors; 

spiral inductors; 

inter-digital capacitors; 

bypass capacitors created using high-dielectric constant layer between power and ground layers; 

film resistors created using resistive film layers. 

The functional parameters of the printed part (e.g., number of turns, spacing between turns) are captured 

in the template definition that is referenced by the printed part. The printed part may include one or more 

layers (e.g., in the case of a multi-layer transformer). The material stackup in the printed part mirrors a 

subset of the stackup in the interconnect substrate containing the printed component. Explicit mapping is 

provided to relate each layer in the printed part to the corresponding layer in the application to ensure 

traceability and consistency.

NOTE: Compatibility with industry standards (e.g., IPC-7351) is supported.

NOTE: AP 210 trace parameter options are the union of the most prevalent trace 

parameter options used in industrial practice.

NOTE: Software implementations of AP 210 that create trace data that will be 

represented using a specific industry format in a downstream process should take 

care to prevent the user from creating a configuration that is incompatible with 

that specific format.
25

5.4.5.4 51BMicrowave templates 

Microwave templates are a specialization of printed parts. Transmission line templates are explicitly 

supported. Templates that are functional in nature (e.g., a filter template) can be classified by user defined 

classifications with the explicit template geometry supported as well as exchange of all related properties 

in a consistent system of units. The dielectric constant and loss tangent may be exchanged for the 

dielectric material, as well as specific surface treatment. 

To be compatible with microwave layout systems terminals may be: 

point on surface; 

point on edge; 

curve on edge/surface intersection; 

cross-sectional area on edge. 

An interconnect design can be partially or completely implemented with microwave components. This is 

obviously useful where full three-dimensional simulation is required and accurate mechanical shapes are 

mandatory. The current predefined model of surface conditions is not sufficient to meet the requirements 

of e.g., extremely high frequency design, although the structure for applying the surface conditions is 

valid and extensible. Designs that require those surface condition specifications will be supported with 

recommended practices with results fed back into the ISO committee process to result in future updates. 

Currently the cross-sectional terminal template model uses an ad-hoc boundary element representation 

that is cumbersome. The use of this is deprecated as it will be replaced in the future with a manifold sub 

surface model which has recently become available. 

5.4.5.5 52BGD&T 

Since the interconnect substrate is a manufactured product, AP 210 provides full support for application 

of GD&T information model in accordance with the relevant ISO and ASME standards to interconnect 

manufacture. Because AP 210 inherits GD&T data model from AP 203, extensions to AP 203 in future 

editions of that AP that track the relevant standards will be automatically included in future editions of 

AP 210 as well. Complex features including, cutouts, cavities, edge effects are fully supported. 

5.4.6 Material models 

Materials data in AP 210 is grounded in fundamental models of chemical elements, compounds, mixtures 

(alloys), and related information needed to form a substantive basis for exchange of material properties in 

support of physics based analysis or regulatory requirements (e.g., RoHS). 

5.4.7 41BMaterial conductivity models 

Materials data support in AP 210 allows the exchange of several types of conductivity classification for a 

material: 

electrical conductivity, 

thermal conductivity, 

magnetic permeability, 

optical_insertion_loss, 

dielectric_permittivity. 

NOTE: The cross-sectional terminal template model is not mandatory for transmission 

line templates.
26

Figure 5.4.8-1 Complex stackup data supported by AP 210

The following enumerations of electrical and thermal conductivity are provided in the standard: 

'conductive', 'semi-conductive', 'resistive', 'non-conductive'. The following enumerations of relative 

permeability are provided in the standard: 'free space permeabilty', 'low permeability', 'medium 

permeability', 'highly permeable'. The following enumerations of relative optical_insertion_loss are 

provided in the standard: 'vacuum', 'very low loss', 'low loss', 'medium loss', 'high loss'. The following 

enumerations of relative dielectric_permitivity are provided in the standard: 'vacuum permittivity', 'low 

permittivity', 'medium permittivity', 'high permittivity'. 

The numeric values associated with, for instance, electrically conductive are found in industry standard 

handbooks and may be the subject of exchange agreements. This standard assumes that the “layout metal” 

is explicitly causal. For the case of electrical networks, the "layout metal" shall be conductive, semiconductive, or resistive in the applicable material for support of layout traceability to the connectivity 

requirement that layout is implementing. For other cases, it is suggested to create exchange agreements 

and recommended practices as implementations occur. The standard requires that the "conductivity" of 

the “layout metal” be consistent across all the connectivity requirements implemented by that “layout 

metal”. The default condition for conductivity classification is “conductive”. The default domain for 

conductivity is electrical. Non-conductive material may be described by a printed part with specific 

functionality, and one or two other cases (see the standard itself for “dielectric”) are included, but AP 210 

does not directly support the traceability of non-conductive material layout to any connectivity 

requirement.

It is entirely possible to have a layout that includes photonic, thermal, and electrical “layout metal” in one 

design. The standard includes feature subtypes that support this paradigm by allowing the design data to 

specify whether a terminal is electrical (default), thermal or a guided wave terminal. If the material of the 
27

terminal is a form of glass fiber, and if the terminal is a guided wave terminal, it is clear that it is a fiber 

optic terminal and not a microwave terminal. The material of a horn antenna would be the metal forming 

the antenna. Note that “microwave” is considered to be a subset of electrical in this standard. 

The material specification in AP 210 provides the capability to identify the data dictionary document that 

contains the material designator so that e.g., the semantics of “T6061-T6” may be understood by a 

receiving application. 

5.4.8 Stackup Models for layered products

Two dimensional cross-section models for layered interconnect substrate are included to support 

communication between a PCB fabricator and PCB design department. The stackup models support rigid, 

flex, rigid/flex for both low and high density designs. 

Figure 5.4.8-1 illustrates some of the product data types available in AP 210 to support stackup models 

U[4]U. When taken together with the base material models, there is significant capability to predict material 

percentages to support regulated substance calculations. 

5.5 13BDesign Rules 

5.5.1 42BUser defined design rules 

AP 210 provides capability to exchange and share definition of rules created during implementation or by 

user interaction with rule authoring systems. The rule representation capability is compatible with rule 

languages such as RuleMLU[5]U. Both forward chaining and backward chaining capabilities are supported. 

AP 210 provides support for administration and maintenance of rules, including rule life cycles of 

proposal; 

test; 

adoption; 

retirement. 

Rules may be grouped in various ways depending on user requirements. Any data or set of data defined in 

an AP 210 model may be included in the rule query, providing tremendous flexibility. The results of 

executing a rule may be a request for change in some aspect of product data in AP 210. A change request 

could identify the rule or characteristic and associated facts that triggered the change request. NISTIR 

822641 is a report documenting the rule language, available at:U[6]U

5.5.2 43BPredefined design rules 

The following requirements are representations of commonly used electronic domain design rules 

wherein support is provided for identifying product data that violates the design rule: 

Electrical spacing requirements; 

Thermal spacing requirements. 

5.6 14BSimulation models 

AP 210 provides capability to exchange and share simulation models, and to tightly couple the interfaces 

of those simulation models to aspects of product data. Simulation models provide the behavioral 

semantics of the functional elements in the hierarchical functional model. Simulation model interfaces are 

explicitly mapped to certain aspects of product data in AP 210 to support computer based 

experimentation. For example, a simulation model interface could be mapped to a functional terminal or 

to some feature of a physical model. Simulation model interfaces provide the domain types for functional 

terminals in network definitions. 
28

Simulation models may be configuration managed and controlled similarly to other product data. 

5.7 Fabrication technology process capabilities 

AP 210 provides capability to exchange and share the definition of some fabrication process technology 

capabilities. The following capabilities are pre-defined in the standard: 

Minimum annular ring; 

Fabrication allowance; 

Minimum feature sizes on interconnect layer technologies; 

Line width class tolerances on interconnect layer technologies; 

Through-hole technology maximum lead size; 

Lands that are dependent on several combinations of mating lead size, associated via size. 

AP 210 provides capability to assign critical shape characteristics of lands and traces to terminals for 

analysis purposes to evaluate immature fabrication technologies. As the technology progresses from 

immature to mature, the size and shape of the terminal connection area may be changed to reflect the 

maturity of the technology (start with a relatively large connection area and migrate to a smaller area over 

time). Using terminals for this purpose allows direct mapping to design rule checkers for verification 

purposes. These capabilities may be referenced to a process specification to provide traceability. 

5.8 15BAssembly technology process capabilities 

AP 210 provides capability to exchange and share definition of some assembly process technology 

capabilities. The following capabilities are pre-defined in the standard: 

assembly joint identifying the mating features joined in the assembly process; 

bonded joints (e.g., by solder or conductive paste) for use in durability simulations ‚Äì shape and 

material data are included; 

seating plane, nominal and maximum shape properties for components; 

maximum and minimums of gaps required between components, or between components and the 

interconnect; 

package orientation information related to both two and three dimensional component models. 

These capabilities may be referenced to a process specification to provide traceability. 

5.9 16BComponent Specifications 

AP 210 provides a robust, sophisticated model that directly addresses issues of multi-domain 

representation of components and current issues of managing disparate component models across the 

supplier, analyst, OEM PCB designer, MCAD designer, and production engineer roles in supply chains. 

Catalog properties of products are supported by AP 210, either in an exchange or in a shared database 

implementation. AP 210 does not require a single rooted classification structure for product classification. 

It is expected that as industry moves to on-line access to catalog information, AP 210 may be used to 

capture the catalog information used at design time to ensure that data used for design decisions is 

EXAMPLE: A network could connect a resistor to a heatsink. The simulation model for 

the resistor would have a thermal interface for the resistor and for the heatsink 

in order for the user to effectively evaluate the thermal performance of the 

resistor/heatsink combination.

EXAMPLE: A capacitor is attached to a signal between two logic gates. The simulator 

resolves the signal types and automatically does analog to digital and digital to 

analog conversion as necessary based on the capability of the simulator.
29

permanently available to support future decision making processes. The explicit support for mapping 

between the "as designed" and "as published" data sets is a powerful tool. 

5.9.1 4BComponent Functional Specifications 

Figure 5.9.1-1 AP 210 component functional specification. A Functional Specification Defines the 

Information needed to Characterize a Device Under Test via Measured Data. May be Many Inputs 

and Outputs [ISO 10303-210:2001, ©ISO, used with permission]

AP 210 provides capability to exchange and share definition of component functional specifications, 

including discrete and tabular data, and the ability to support a functional test setup (i.e., netlist). The 

capability supports using external standards for signal classification. Since this is a functional 

specification, it is not usually necessary to specify physical (geometric) arrangement of the device under 

test in the test setup. If it is necessary to characterize the physical arrangement of the device under test in 

the test setup, a recommended practice would be developed to show how to apply the assembly model in 

AP 210 to the test setup. 

5.9.2 Component Physical Specifications 

Figure 5.9.2-1 AP 210 component physical specification. 
30

The component physical specifications include a comprehensive model of the container of e.g., the 

semiconductor device, including terminal and body properties. 

5.9.3 45BComponent Functional and Physical Integration 

Synchronization of a 2D layout symbol feature, shape, orientation, and functionality in a library for a 

package definition with the corresponding 3D layout model is exact in AP 210, and facilitates effective 

communication between electrical and mechanical design processes. Refer to the AP 210 Recommended 

Practices for a more detailed description of the implementation procedures to accomplish this capability. 

5.9.4 Connectors 

Figure 5.9.4-1 A subset of the data in the AP 210 connector model. Join Terminals mate with some 

interconnecting material in a layout. Interface terminals mate with other interface terminals in an 

assembly.

Connectors are included as a separate product type of component specification in order to identify their 

critical role in product interfacing and in order to assign related properties in support of that role. A 

mechanical assembly that contains multiple mated pair connectors can be trivially queried to extract 

continuity information. A connector assembly with inserts may be modeled by an enterprise as an 

assembly internally while providing a component specification for customers. 

6. 2BBusiness Cases for Implementation of AP 210 

AP 210 provides a very detailed data model that theoretically could be used as a basis to create a 

CAD/CAM/PDM system. But this data model is not optimized for memory, speed, and specific CAD 

operations. Instead the AP 210 data model is designed to be system neutral and precise, with all needed 

semantic details. Data according to the AP 210 data model can be exported form one CAx-System and 

imported into another one. Different CAx-Systems are able to fill different "slots" in the AP 210 data 

model. So only information that is understood by both system can be transferred. Within AP 210, the 

emphasis is on the product model. Implementations of AP 210 can be integrated with implementations of 

other STEP APs, greatly extending the scope of the integrated data that can be exchanged. This integrated 

architecture provides the means for shareability and reusability of data models, and consequently, STEP 

implementation software modules. AP 210 implementations could be crucial to fulfilling organizations' 

data exchange requirements. 

6.1 17BEnterprise designs and builds its own products 

NOTE: The ability to specify variant designs inherited from AP 214 should be of 

benefit for specifying connectors with multiple conflicting options of cavity 

inserts.

Join Terminals

Interface Terminals
31

This enterprise is an OEM, a tier one, or a tier two supplier in a supply chain. 

Business Environment:

Numerous different ECAD/MCAD/CAM systems in-house 

Manufacturing and Design sites are dispersed 

Netlists and mechanical data are in disparate systems, including spreadsheets 

Digital drawings are main methods of communication 

AP 203 is used for 3D product models 

Cost Drivers:

Management of duplicate designs 

Lost information from translations 

Data re-creation errors 

Maintenance of disparate 2D and 3D component model libraries 

AP 210 Benefits:

Shared data is based on unambiguous information model 

Data loss is minimized

6.2 18BEnterprise subcontracts to manufacture products 

This enterprise is a tier two or tier three or lower tier in the supply chain. 

Business Environment:

Vendor maintains multiple CAD/CAMsystems in support of each contract 

Increased availability of new CAD/CAM systems 

Cost Drivers:

Number of CAD/CAM systems (purchase and maintenance) 

Experienced personnel to operate CAD/CAM systems 

AP 210 Benefits:

Shared data representation allows best system to be employed 

Subcontractor’s potential business base is enlarged 

6.3 19BEnterprise archives its designs for future reference 

Business Environment:

Contracts require archival of data for long periods of time 

Compatibility of future versions of software is not assured 

Cost Drivers:

Support for legacy systems 

Data migration definition 

AP 210 Benefits:

Upward compatibility assured 

Archived data retrieval issues minimized 

Leverage industry leading research and development of the LOTAR project U[7]U,U[8]U. 

6.4 20BEnterprise develops its own EDA/ECAD/MCAD libraries
32

As technology evolution occurs, maintaining legacy libraries consumes resources as software and 

hardware maintenance must be provided. 

6.5 21BEnterprise uses externally defined libraries 

Externally defined libraries may be available for limited number of software platforms, and for limited 

lifetime. 

6.6 2BUse Cases 

A list of realized and potential AP210 use cases along with links to commercial and academic 

implementations is maintained at: Uhttp://www.wikistep.org/index.php/AP210_Use_CasesU.

6.7 23BUsing Systems 

AP 210 defines the product data and the product data framework used for the exchange and sharing of 

computer-interpretable product design and technology library definition data, which may be generated in 

or received by the following types of applications: 

Requirements Capture 

Design Automation 

o automatic component placement system, 

o automatic layout routing system (autorouter), 

o electrical and mechanical component modeling systems (librarian tools), 

o electrical and mechanical computer-aided design system (ECAD/MCAD), 

Design Analysis 

o rule definition system, 

o rule execution system. 

o electrical and mechanical computer-aided engineering analysis system (ECAE/MCAE), 

Manufacturing Automation 

o bare-board test system, 

o computer-aided manufacturing system (CAM), 

o coordinate measurement system (CMM), 

o functional test system, 

o in-circuit test system, 

Enterprise product data management systems 

o component information system (CIS), 

o issue resolution system, 

o manufacturing process planning system (MPP), 

o manufacturing resource planning system (MRP), 

o product data management system (PDM), 

o product lifecycle management system (PLM). 

6.8 24BAP Investigation sequence 

Logically, the sequence for an implementer to follow in investigating AP 210 is: 

1. Create the use case 

2. Review the scope of the AP to determine that the use case falls within the scope. Review of the 

application activity model in Annex F may be useful to clarify the scope. 

3. Review clause 4 of the AP to become familiar with the coverage of the AP. 

4. Review the available recommended practices for coverage of the use case 

5. If recommended practices are available for the use case 

1. Follow their guidance 
33

2. Determine what to do with data unavailable in the transmitting system or that cannot be 

understood by the receiving system; 

6. If a recommended practice is not available for the use case 

1. Determine the conformance options that cover the use case 

2. Review the application objects referenced in the conformance options 

3. Select the conformance option that meets the business needs of the implementation (i.e., 

cost/schedule/data availability) 

4. Define a list of Application Objects to implement 

5. Review the reference paths of the mapping tables for each Application Object to 

determine the aim elements to be implemented and the associated domain constraints; 

6. Review the rules applied to the those aim elements 

7. Review the rules applied to the Application Objects 

8. Determine what to do with data unavailable in the transmitting system or that cannot be 

understood by the receiving system 

7. Consider contributing the work products for this use case to ISO committee to reduce 

implementation cost of AP 210 in the future 

Practically speaking, that approach is time consuming and if possible, the implementers should contact 

the ISO committee or PDES Inc., for training specific to their needs. PDES is well versed in industry 

partnerships arranged to take advantage of the STEP standards, and maintains a core competency in AP 

210. 

7. 3BThe Different Roles in AP 210 Implementations 

7.1 25BSystems Integrator's Role 

The systems integrator determines how the target application system will integrate or interface with 

existing application systems. The following major system considerations, beyond the application itself, 

may be of concern to the systems integrator: 

Multiple APs which may or may not overlap; 

Mixture of STEP data and non-STEP data; 

A suitable implementation form for the target environment; 

Interoperability of systems, internal and external to the enterprise. 

Recent work by the ISO committee reduces the concerns about overlap of APs since much harmonization 

has been accomplished but where inter-disciplinary implementations are being developed, system 

interfaces will need to be carefully examined during development to avoid surprises at integration. 

The systems integrator should recognize that there will be future releases of AP 210. The layered 

interconnect product model has been sufficiently tested and incorporated into stepmod development to 

ensure that AP 210 is suitable for long term applications. The hierarchical continuity model, requirements 

models and mechanical models are all mature. There is some interest in further harmonization with AP 

214 and AP 209 and that may drive some schema extensions. The LOTAR project will drive extensions 

in the GD&T area that are required to maintain compatibility with the ISO and ASME Product 

Manufacturing Information standards. 

If multiple APs are in use, or planned in the near future, any overlap between them must be anticipated. 

APs having different domains may share the same STEP integrated resource constructs. If these 

constructs can be logically grouped to support a specific function, this grouping of constructs is called an 

Application Interpreted Construct (AIC). The use of shared constructs may influence database designs in 

a shared database implementation form. 
34

Non-STEP systems and data may already exist and may have to be interfaced with, or integrated into, the 

new AP 210 application. The overlap between the non-STEP models and the AP 210 AIM should be 

carefully examined to avoid conflicts, inconsistencies, or loss of information. This is certainly true when 

integrating a STEP application with an existing commercial CAD/CAM/CAE system. Frequently, the 

only way to handle this is to communicate product data through an exchange file. 

The systems integrator should decide which of the implementation forms described in Section 5 of this 

document is most suitable for the target environment. AP 210 may be implemented in a shared database 

form, an exchange file form, or a combination of the two. The form selected should meet the specific 

requirements of the application. 

Finally, the systems integrator should determine how the new AP 210 application will interoperate with 

existing internal or external systems (i.e., those of customers, partners, suppliers, and the Government). If 

sharing is accomplished through exchange files, the sending and receiving systems must "understand" the 

exchange file format and the AP 210 schema so the transferred data can be translated to the internal 

format of the receiving system. 

If sharing is accomplished through a database, the applications accessing the product data should have a 

common interface to the database. The Standard Data Access Interface (SDAI) describes such an 

interface. Commercial implementations of SDAI are available. If the system does not use SDAI, a 

common interface must be developed by the implementers using SQL, C++, or other interface 

mechanisms. There are commercial implementations of core PDM data which are compliant with AP 210. 

The OMG PLM Services model v 2.0 which is compliant with AP 214 edition 3 is a useful reference. A 

simple mapping from an AP 210 compliant implementation is needed to be compliant with the OMG 

PLM Services v 2.0. 

Extensions to the STEP data models can be created to satisfy specific application needs. Such changes 

should be reported to the ISO TC 184/SC 4 for possible inclusion in future releases of the standard. 

7.2 26BApplication Developer's Role 

The application developer's role is more focused than the systems integrator's role. After the global 

aspects are considered, the developer sets out to implement the AP 210 application. Person(s) involved 

should have a working knowledge of EXPRESS and understand the AP 210 ARM and AIM. The 

developer determines the relationship of the ARM and the AIM with the proposed application context. 

The data in related existing systems must be mapped to the data described in AP 210 and then to the 

chosen implementation form‚ either a shared database format, a STEP exchange file format, or a 

combination of the two. The AIM EXPRESS schema is used to generate the appropriate implementation 

form. Then methods are developed to get instances of product data into and out of the implementation 

form. Finally, the processing of the product data specific to the application context is added. 

The completed implementation can be tested against the conformance requirements described in the 

standard using the validation software noted elsewhere. This tests the conformance of the implementation 

by itself. Its interoperability with the other systems used to share or communicate product data should 

also be tested. There are examples and test cases available to provide "hands on" experience. 

7.3 27BEnd-User's Role 

Requirements for the target applications must be determined. Working with the application developers 

and the systems integrators, the end-user provides the application expertise needed in the design and 

development process and supplies the real-world test data used during integration and stress testing. An 

implementation that conforms to AP 210 in every respect but does not satisfy the target application's 

requirements is useless. The end-user must guide the development ensuring that the needed functionality 

is achieved. 
35

8. 4BComponents of AP 210 and Their Use in Exchange Implementations 

This section is a summary of each of the components of AP 210 and what they mean to the implementor. 

These components include: 

the scope;

the ARM; 

the AIM; 

the mapping between the ARM and the AIM; 

conformance requirements. 

8.1 28BScope 

As implementation experience grows, recommended practices will be included as well as the 

conformance options that relate to the scope.

8.2 29BARM 

The ARM is defined in clause 4 of the ISO 10303-410 document. This is a change from edition 1 due to 

the adoption of the stepmod methodology. Typically, application experts within a given company know 

the information requirements of applications that fall within the scope of AP 210. They designate the data 

by names that differ to some degree from the names used in STEP for the same Application object. For 

example, the company expert or system developer may refer to a piece of an assembly as a "component". 

The AP 210 project created an “Assembly_component” Application Object in order to capture the 

relevant domain knowledge about that piece of an assembly. Since AP 210 is a computer interpretable 

data dictionary, the developers chose to use slightly modified names for Application Objects in order to 

prevent assumptions about the meanings of the Application Objects. It has been found useful to maintain 

electronic copies of the correspondence between these three dictionaries. In some cases, domain terms 

were sufficiently specific to use without modification (i.e., Land). 

AP 210 contains two separate data models whose components are related by a mapping. The ARM refers 

to data by names and structures preferred by application experts. The AIM describes data using the STEP 

neutral reference data model. 

Since application experts from representative companies assisted in the formulation and review of the 

ARM for AP 210, the ARM will be more easily understood by an application expert considering 

implementing AP 210 than the AIM. The Application objects, attributes, and business rules describing the 

relationships contained in the ARM are documented in clause 4.2 of modules. The ARM is documented 

in EXPRESS and EXPRESS-G, and is in annex h. 

The potential implementer can gain a further understanding of the scope of possible applications 

supportable by AP 210 by reviewing the definitions and business rules of the ARM Application objects 

NOTE: The term “Application object” in this document is meant to represent a 

concept in the application domain of AP 210. The EXPRESS language construct which 

represents an Application object is the ENTITY construct. The use of the term 

“entity” to describe a concept in STEP is reserved for the terms defined in the 

integrated resources, AICs, and AIM models.

This use of a different term and punctuation helps to separate the ARM and AIM 

models. Application objects have an initial Capitalization in the textual 

descriptions whereas entities do not.

EXPRESS does not support declaring Application object as a synonym for the ENTITY

construct, so Application objects are represented by ENTITY objects in the ARM 

EXPRESS.
36

and attributes. Comparisons can be made, at least conceptually, between the Application objects and 

attributes of the ARM and the entities and attributes currently used by the target organization. This 

provides a starting point for mapping or cross referencing the target environment's data to an AP 210 

implementation. 

The ARM EXPRESS does include many constraints but it is not exhaustive. The EXPRESS definitions 

found in AP 210 come in two forms: the EXPRESS short listing, and the EXPRESS expanded listing. The 

ARM for AP 210 uses entities from the stepmod module models of STEP. 

In the short listing, EXPRESS definitions from the stepmod module models are incorporated with the 

EXPRESS "USE FROM" construct. The short listing also includes informal propositions which are 

mandatory, but are not yet coded formally in EXPRESS. 

The EXPRESS expanded listing is the complete, self-contained definition of the ARM. All entities, 

attributes, relationships, and constraints are explicitly defined which permits the EXPRESS expanded 

listing to be compilable. Eventually, most of the informal propositions will be available as formal rules in 

the expanded listing. The complexity of AP 210 and its application context demand as much automation 

of the implementation process as possible. This will be particularly true when existing implementations 

are revised to accommodate changes in the ARM. An AP 210-based application should be developed in a 

way that assumes, and easily accommodates, evolutionary changes to AP 210 and other STEP APs. The 

migration to the stepmod architecture has considerably eased the issue of future maintenance as 

maintenance is now a shared responsibility with the "single source" metaphor in place. 

8.3 30BAIM 

The other dada model of AP210 is the AIM (Application Interpreted Model). The AIM is defined in 

clause 5.2 of the ISO 10303-410 document. Annex E contains the AIM EXPRESS source which is also 

publicly available at the EXPRESS repository U[9]U. The AIM contains the STEP names and structures for 

the data within the scope of AP 210. AIM entities and attributes correspond to ARM entities and 

attributes, but not necessarily on a one to one basis. The AIM is a collection of entities, attributes and 

rules selected from the total collection of STEP integrated resource models that are needed to address the 

scope of the AP. STEP integrated resource models are the raw materials from which APs are built. See 

ISO 10303-1 for a description of the STEP integrated resource models and their relationship to APs. In 

addition, AP 210 domain specific entities (subtypes of generic resource entities) and rules are added to 

meet the domain requirements. In AP 210 complex instances are provided in some cases in order to meet 

the requirements of exchange scenario. 

From the standpoint of the implementer, the AIM represents the product data being shared in terms 

defined by the standard itself. Both parties in a data exchange environment must understand their specific 

data in identical terms. This does not necessarily mean data must be physically formatted the same way. 

The AIM is the APs conceptual data model that is implemented. 

Caution: The descriptive text in clause 4.2 is normative. There are more 

constraints included in the clause 4.2 text than are included in the informative 

ARM EXPRESS.

The validation software developed for AP 210 combines the ARM EXPRESS constraints, 

the AIM EXPRESS constraints and the mapping table constraints into a cohesive model 

checking environment.
37

The EXPRESS definitions found in AP 210 come in two forms: the EXPRESS short listing, and the 

EXPRESS expanded listing. In the short listing, EXPRESS definitions from the integrated resource 

models are incorporated with the EXPRESS "USE FROM" construct. Only the EXPRESS constructs 

which are AP 210 domain specializations are fully defined in the short listing. The short listing also 

includes informal propositions which are mandatory, but are not yet coded formally in EXPRESS. 

The EXPRESS expanded listing is the complete, self-contained definition of the AIM. All entities, 

attributes, relationships, and constraints are explicitly defined which permits the EXPRESS expanded 

listing to be compilable. Eventually, most of the informal propositions will be available as formal rules in 

the expanded listing. 

8.4 31BThe mapping from ARM to AIM

As stated before, the ARM defines data in application terms, and the AIM defines the same data in the 

STEP conceptual model. The STEP conceptual model is the collection of integrated resource parts and 

AICs. Although they are documented in separate publications, the collection is managed by the ISO 

committee as one model. The process of creating the AIM from the ARM is called interpretation. The 

interpretation of a construct defined in a STEP integrated resource that supports a certain requirement 

may result in the creation of a new construct in the AIM that may restrict, narrow, or constrain the 

semantic scope of the integrated resource construct, thereby specializing the construct. 

Interpretation is one of the most critical aspects of the development of STEP standard, and its essence is 

the complete human understanding of application requirements. Interpretation draws not only on the 

meaning of the constructs themselves, but the context within which the constructs are generated, used, or 

received. The context specified in the ARM is defined by such things as the life cycle stage and the 

application domain that bounds the scope of a module that the Application construct is defined or 

referenced in. This is a critical concept to understand in the implementation of AP 210. Due to the 

structure of the ARM model, an Application object may be implemented by different AIM structures 

depending on the subtypes used, the product definition being composed and the product category 

associated with that product definition. 

The context of the STEP integrated resources is not limited to a specific life cycle or type of product. 

Because ARMs and STEP integrated resources are developed as representations of information in 

different contexts, they are exposed to the influence of different contextual factors. In order to account for 

these contextual factors, interpretation of STEP integrated resources relies on the complete human 

comprehension of the requirements represented in an ARM and the in-depth knowledge of the semantics 

and contextual factors under which the STEP integrated resources were developed. 

The ARM to AIM mapping table, contained within the modules, documents the interpretation of 

requirements performed for a specific module. An implementer needs to understand the cross reference 

between the two data models. The mapping table lists its ARM entities and attributes and their 

corresponding AIM entities and attributes and any domain population constraints. 

NOTE: The mapping from ARM to AIM exists in each of the modules that comprise AP 

210. The difficulty readers have in traversing the module HTML documentation is a 

known issue and is being addressed by the ISO committee. The HTML document at the 

AP level has indexes on the top and left that are useful. A PDES inc., team member, 

LKSoft provides a more usable HTML that is available from PDES, Inc. at no cost.

NOTE: The second edition of AP 210 has considerably simplified the relationship 

between the ARM and the AIM in most cases.
38

Having already determined what conformance options to support, the implementer must ascertain what 

AIM entities and attributes encompass the target applications. The conformance option lists the modules 

that are required to support that conformance option and if there are any exclusions, what Application 

objects are excluded. Each module includes one or more ARM Application objects that implicitly define 

it's scope. The mapping table for each module specifies the mappng under that context and thereby 

defines the required AIM constructs and attribute values. 

The same ARM Application object may be interpreted differently in the context of different modules, 

depending on it being used in different roles by other Application objects, or there may be interpretation 

options. 

Once defined, the EXPRESS definitions of the AIM entities will be used in the implementation. The 

source code of the mapping tables is available to help in implementation, as is software licensed under the 

AGPL v3 based on SDAI extensions to extract data from the mapping tables. Due to the extended domain 

coverage of AP 210 parsing the mapping tables is an essential requirement for effective implementations. 

Also highly recommended and available under the AGPL v3 is acquisition of software U[10]U capable of 

parsing the EXPRESS ARM schema, and EXPRESS to EXPRESS-G generators for browsing the 

schemata. For AP 210 validation, the same software creates a special modified form of the ARM that 

contains AIM elements so that a complete data population more closely related to the ARM EXPRESS 

may be available for debug purposes. 

8.4.1 Conformance requirements 

The conformance requirements are defined in clause 6 of the standard. The number of conformance 

classes has been reduced to one, by request of implementors. The conformance option concept has been 

introduced in order to align implementation more closely with the modular architecture. A list of the 

AP210e2 conformance classes and options is maintained at: 

Uhttp://www.wikistep.org/index.php/AP210ed2_conformance_classes_and_conformance_optionsU. That 

section also specifies an initial reference from the conformance option to elements of scope that it 

supports. The ISO committee continues research in ways to add mapping table constraints and rules to 

conformance options so as to reduce implementation confusion. Many of the implementation choices are 

driven by the capabilities of interfaced systems to support specific product data and by the need for 

enterprises to augment ECAD/MCAD data through the design and development process in a supply 

chain.

9. 5BImplementation Forms 

AP 210 can be implemented in several different forms. One form uses the STEP exchange file format to 

transfer product data between application systems or enterprises. A second form uses a database 

implementation, based on the AP 210 AIM, to share product data between multiple application systems or 

enterprises. A third form uses a combination of the first two to create a hybrid implementation with file 

exchange and shared database components working together to meet the needs of the target environment. 

The systems integrators and developers must determine which form is best suited to their specific 

situation. 

NOTE: A very effective effort has been made to avoid defining the same Application 

object in different modules, so the main reference here is to a few legacy cases of 

mapping options.

NOTE: The vast majority of Application object interpretations (99.9%) are not 

dependent on the role or the context.
39

A database implementation may involve architectural considerations not relevant to a file exchange 

scenario. If the architectural context of a particular AP 210 implementation is important, then 

PTI017.03.00 is a useful reference. PTI017.03.00 talks about STEP in general, rather than any specific 

AP, and proposes architecture for implementing STEP in a shared database environment. It discusses the 

key components of such architecture, including an Information Resource Dictionary System (IRDS) 

useful for mapping between multiple data models. It also covers integrating STEP applications and data 

with legacy or non STEP systems and data. Finally, it presents a phased approach to implementing a full 

STEP shared data environment over time. 

9.1 32BFile Exchange 

This involves the exchange of product data between two or more application systems using the STEP 

exchange file standard, ISO 10303-21 (Part 21). For each exchange operation, one application system 

plays the role of sender, and the others play the role of receiver of the exchange Part 21 file. The systems 

may exist in the same or different disciplines or even enterprises. 

Figure 9.1-1 File exchange scenario.

The receiver requests the appropriate product data from the sender by some mutually agreed-upon means 

and the exchange is initiated by the sender. The sender must be able to transform the product data into the 

exchange file format based on the AP 210 schema (i.e., its AIM), and the receiver must be able to 

transform the exchange file into a format acceptable to the receiving system. 

File exchange enables an AP 210-based transfer of product data without modifying the source or 

destination application systems, as long as there is an appropriate translation to and from the exchange 

file format. Translation software is especially useful if one or both of the application systems cannot be 

modified to read or write exchange files. Sometimes other standardized input/output formats, such as 

IGES, are available with application systems. Translators from an IGES file format to a STEP exchange 

file format are available. Translators from several ECAD systems to AP 210 are available. Translators 

from e.g. Gerber, IPC-350 are available. However, incompatibilities between the two exchange formats 

may cause loss of data in the translation. For example, Gerber has no concept of land so an AP 210 file 

generated from a Gerber source would have limited built-in support for land validation. 

9.2 3BShared Database 
40

If there are numerous applications and concurrent application functions to be performed with the product 

data, a shared database may be more efficient. Each application must be able to access the database 

directly through a common or supported interface. 

Figure 9.2-1 Data sharing scenario.

9.2.1 46BNative EXPRESS database 

The AP 210 AIM is used to create a database that can be accessed directly by one or more application 

systems. There are several suppliers able to provide software technology to create a database directly 

from an EXPRESS schema. The Standard Data Access Interface (SDAI) is the standard access layer to 

EXPRESS-based data, and is supported by the software suppliers. 

9.2.2 47BWorking with other database technologies

An implementer may have to consider how heterogeneous applications will determine the mapping 

between the AP 210 conceptual data model and the physical implementation model for the database 

storage technology being used (e.g., SQL data definitions, or object-oriented class definitions). When 

existing database systems must be used, there are additional considerations because the applications will 

need to support mapping from the internal database schema to the AP 210 schema. The functionality to 

manage the product data instances must be present in the application systems' logic. Each interface 

application must understand the internal structure of the database and its relationship to the AP 210 

conceptual data model. Developers must consider 

the mappings between the data structure in the database; 

how the application system wants to see it; 

user presentation; 

the conceptual model of the data (i.e., the AP 210 AIM). 

9.2.3 48BWorking with STEP based data hubs

The OMG PLM Services model is based on AP 214 and provides a straightforward methodology for 

implementing data sharing for PDM related data. The OASIS PLCS model is based on AP 239 and 

provides support for implementing data sharing for logistics. 
41

9.3 34BHybrid (File Exchange and Shared Database) 

This is a combination of file exchange and shared database forms. One or more shared databases may 

exist with product data, but the product data instances may have to be imported or exported through STEP 

exchange files. This is required when legacy or commercial application systems that must work with the 

data cannot be modified to access the shared database(s) directly, while other applications can access the 

database directly. 

As legacy systems are retired and replaced and as commercial products adopt the STEP standards, the 

number of systems requiring file exchange operations should decrease, and the number of systems able to 

directly access STEP databases should increase. The hybrid implementation form provides a migration 

capability between today's systems and the fully-integrated STEP environment of tomorrow. 

Figure 9.3-1 Hybrid sharing scenario.

10. 6BAP 210 Implementation Assistance & Support 

ISO 10303, and its supporting technology, are being developed on a number of fronts. There are 

numerous avenues for assistance and support available to the implementer of AP 210 or other STEP APs. 

The following organizations are sources of assistance. 

10.1 35BISO 

The International Organization for Standardization (ISO) was established in 1946 to facilitate the 

international interchange of goods and services and to encourage cooperation in economic and 

technological endeavors. Sub-Committee 4 (SC4) of Technical Committee 184 (TC184) is responsible for 

the development of STEP. SC4 is responsible for manufacturing languages and data and is part of TC184, 

which is responsible for Industrial Automation Systems and Integration. For more information contact the 

ISO TC184/SC4 Secretariat via SC4ONLINE U[11]U.

10.2 36BPDES, Inc. 
42

PDES, Inc. is a consortium of industrial companies and government agencies. PDES, Inc. was the sponsor 

of AP 210. The member companies apply full time resources to accelerate the development and 

implementation of the STEP standard. They work closely with the ISO committee in driving toward one 

international standard for product model data. There are several pilot projects that have proven the 

usefulness of AP 210 in industrial implementations. PDES member companies also are useful contacts for 

translator availability and integration support. PDES maintains an active list of commercial products that 

are available with AP 210 interfaces or that provide AP 210 interfaces for commercial software 

applications. For more information refer to the PDES, Inc. web site U[12]U or call Jack Harris, General 

Manager at (843) 760-3342. 

11. 7BElectrical and Electronic Standards Comparison 

Table 11-1 is a high level comparison of ECAD industry data formats for educational purposes. 

Committees developing data exchange formats occasionally publish new versions so detailed analysis of 

actual requirements should be accomplished using the documents available at the time of review. 

Table 11-1 Comparison of ECAD Industry Formats.

Standard

Item AP 210 EDIF 2 0 0 EDIF 4 0 0 GDS II IPC 2581

2D component layout yes no yes no yes

2D/3D component layout sync yes no no no no

3D component layout yes no no no no

3D geometry yes no no no no

3D PCB fabrication data yes no no no no

approval yes no no no no

Approved vendor lists yes no no no yes

assembly joint yes no no no no

bare die yes no yes no no

Bill of Material yes no yes no yes

Change request yes no no no no

Changed item yes no no no no

co-planar layers yes no yes no yes

coatings yes no no no yes

complex, dependent, geometric 

figure construction (see note) yes no yes no yes

component attributes yes yes yes no yes

component functional 

specification yes no no no no

component packages extensive no

limited to 2d 

shape and pinout no

limited to 2d 

shape and pinout

component physical specification 

(see note) yes no

component 

outline, pinout, 

pin-mapping no

component 

outline, pinout

connection zone yes no no no no

cross-hatching yes no ? no no

cuts/jumpers yes no no no no

derived plating layers yes no no no no

die bond pad limited no yes no no

dimensioning yes no yes no no
43

drawings yes no yes no yes

effectivity yes no no no no

embedded dies yes no yes no no

embedded discrete components yes no no no no

footprint breakout yes no no no no

full traceability from layout to 

netlist yes no no no no

functional netlist yes yes yes no no

GDT yes no no no no

hierarchical footrpint yes no yes no

footprint for 

surface mount 

only

high speed design yes no yes no no

instantiation using product 

occurrence concept yes yes yes no no

intellectual property rights yes no no no no

intelligent notes yes no no no no

layer surface conditions yes no no no no

layer surface identification yes no no no no

libraries yes yes yes no partial

lyout macros yes no yes no no

manifold surface geometry yes no no no no

manufacturing feature 

identification yes no no no yes

material c onductivity 

classification yes no no no yes

material identification yes no yes no yes

material properties yes no limited no yes

mechanical geometry yes no no no no

microwave design yes no no no no

multi-layer printed components 

(e.g., printed transformers) yes no? no no

multiple conductivity domains 

(see note) yes no partial no no

netlist traceabiliey full no no no no

packaged netlist yes yes yes no no

padstack definitions yes no yes no

only for 

reference

panelization yes no no no yes

part attributes yes yes yes no on component

path delay yes no no no no

PCB geometric fabrication data yes no yes yes yes

PCB material stackup yes no no no partial

PCB/PWB stackup model yes no no no no

PDM data harmonized with AP 

203 yes no no no no

physical netlist yes no yes no yes

pin numbers yes yes yes no yes

printed components (e.g., 

resistors capacitors) using special 

layer material yes no? no no

product classification yes no no no no

product concept yes no no no no

product configuration yes no no no no
44

product identification yes yes yes yes yes

production rule language yes no no no no

programmed devices yes no no no yes

reference designators yes yes yes no yes

requirements yes no no no no

Schematic planned yes yes no no

security classification yes no no no no

simulation interface yes no no no no

simulation model port properties yes no no no no

simulation models yes no yes no no

solder paste stencil yes no no no

as geometry on a 

layer

system netlist yes yes no no no

technology rules (see note) yes no yes no no

terminal preparation yes no yes no no

thermal modeling (lumped 

element) yes no no no no

thermal network yes no no no no

units

ISO 31 & 

English limited limited limited very limited

wire bond yes no yes no no

Note 1. AP 210 geometry is vector based. Gerber is raster based. IPC 2581 is vector based.

Note 2. AP 210 does not support GDS II arrays.

Note 3. AP 210 does not support GDS II type 4 paths.

Note 4. EDIF 4 0 0 has density and specific heat capacity as predefined properties (optional). 

In AP 210 these are user defined units derived from si_units.

Note 5. Complex geometric figures are area_component related in ap 210 (old design intent modification) 

and figure collectors in EDIF 4 0 0.

Note 6. AP 210 and EDIF 4 0 0 Technology rules are not harmonized.

Note 7. AP 210 component physical description and EDIF 4 0 0 description are not harmonized, 

but basic functionality in 2D is compatible.

Note 8. The comparison to EDIF 4 0 0 was not exhaustive. There may be errors.
45

12. 8BReferences 

[1] Uhttp://www.rtca.org/downloads/ListofAvailableDocs_September_2009.htm#_Toc241310811U

[2] Uhttp://eislab.gatech.edu/pubs/reports/E-15-642-D05/GIT-E-15-642-D05_ProAM_Final_Report.pdfU

[3] Uhttp://www.lasermicronics.com/_mediafiles/15-laser-direct-structuring-technology.pdfU

[4] Uhttp://www.ida-step.net/sites/ida-step.net/files/images/6L-Build-up.pngU

[5] http://ruleml.org/

[6] http://www.mel.nist.gov/publications/publications.cgi 

[7] Uhttp://www.prostep.org/en/project-groups/long-term-archiving-lotar.htmlU

[8] Uhttp://aecma-stan.org/Lotar.htmlU

[9] Uhttp://www.steptools.com/sc4/archive/APs/U

[10] Uhttp://sourceforge.net/projects/jsdai/U

[11] Uhttp://www.tc184-sc4.org/U

[12] Uhttp://pdesinc.aticorp.orgU

[13] Uhttp://www.wikistep.org/index.php/AP210_ScopeU

PDES/STEP Data Sharing Architecture (PTI017.03.00) available from PDES Inc.: 

Uhttp://pdesinc.aticorp.orgU

ANSI/X3/SPARC Study Group on Data Base Management Systems: (1975), Interim Report. FDT, 

ACM SIGMOD bulletin. Volume 7, No. 2. 

See also: http://www.wikistep.org/index.php/Main_Page