AP210ed2 concept of operations
This document provides information to support organizations wishing to develop data exchange and sharing implementations using AP 210.
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-processable 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 engineering (during the design to manufacturing transition) that the design is mature enough for production may be validated by examining the engineering artifacts.
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.
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"[]. 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.
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 can support software managed at the serialized item level and will be considered as part of a future edition upon request to the committee.
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.
Current implementations focus primarily on printed circuit cards, although only the layered layout model is domain specific to layered products. Application of cables, wire harness, 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, solder paste stencils, test coupons, in-circuit test fixtures). Mechanical products are included (e.g., chassis, brackets, fasteners..)
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.
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.
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.
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 the assembly or for the 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.
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:
- 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.
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.
Product 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.
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.
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 it's 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 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 manufacturing rule that any 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; 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 good 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.
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.
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.
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 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.
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.
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 where a component supplier publishes library or "usage view" data on the web while maintaining design data in an internal repository.
Information 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.
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.
- "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, for instance, of a Monte-Carlo prediction of production variability.
AP 210 provides capability to exchange these functional models:
- A 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.).
- The interface to a function is represented in AP 210 by a usage view.
- The definition of a network is represented in AP 210 by a design view.
Note: This is a representation using STEP technology of the industry standard hierarchical decomposition.
- 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).
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.
- 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.
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 the authoritative source.
- 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 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.
Product 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;
- 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:
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.
For 2D shapes, the ability to provide intersections with planes parallel to the seating plane but at different locations is provided.
Design 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.
Assembly 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, augmented 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 archival.
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.[]
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.
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.
Some examples of component grouping that are supported by AP 210:
EXAMPLE 2 An example is the collection of components necessary to satisfy the functional requirement for a power supply.
EXAMPLE 3 An example is the collection of components necessary to satisfy the functional requirement for a digital signal processor.
EXAMPLE 4 An example is 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.
A critical item to note in the AP 210 assembly models 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.
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.
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.
Experimental results may be captured. This capability extends the ability of organizations to reuse experimental results from one design to another.
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 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).
Assembly models for mechanical products
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.
Layered interconnect models
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 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 physics-based 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[]. 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.
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).
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.
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.
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.
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: Compatibility with industry standards (e.g., IPC-7351) is supported.
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:
- corner style;
- end extension;
- end style, that are the usual CAD abstractions.
AP 210 trace parameters are compatible with electronic industry formats including:
NOTE: AP 210 trace parameter options are the union of the industry format trace parameter options. NOTE: Software implementations of AP 210 that create trace data that will be represented using an industry format in a downstream process should take care to prevent the user from creating a configuration that is incompatible with that specific format.
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.
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.
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.
NOTE: The cross-sectional terminal template model is not mandatory for transmission line templates
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. Complex features including, cutouts, cavities, edge effects are fully supported. 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.
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).
Material conductivity models
Materials data support in AP 210 allow the exchange of several types of conductivity classification for a material:
- electrical conductivity,
- thermal conductivity,
- magnetic permeability,
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_permittivity 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, semi-conductive, 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 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.
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[]. When taken together with the base material models, there is significant capability to predict material percentages to support regulated substance calculations.
User 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 RuleML. Both forward chaining and backward chaining capabilities are supported. AP 210 provides support for administration and maintenance of rules, including rule life cycles of
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:[]
Predefined 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.
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.
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.
Simulation models may be configuration managed and controlled similarly to other product data.
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.
Assembly 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.
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 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.
Component Functional Specifications
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.
Component Physical Specifications
The component physical specifications includes a comprehensive model of the container of e.g., the semiconductor device, including terminal and body properties.
Component 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.
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.
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.
Business 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 AP‚Äôs, 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. Uses of AP 210 implementations could be crucial to fulfilling organizations' data exchange requirements.
Enterprise designs and builds its own products
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
- 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
Enterprise 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
- 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
Enterprise archives its designs for future reference
- Contracts require archival of data for long periods of time
- Compatibility of future versions of software is not assured
- 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 ,.
Enterprise develops its own EDA/ECAD/MCAD libraries
As technology evolution occurs, maintaining legacy libraries consumes resources as software and hardware maintenance must be provided.
Enterprise uses externally defined libraries
Externally defined libraries may be available for limited number of software platforms, and for limited lifetimes.
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
- automatic component placement system,
- automatic layout routing system (autorouter),
- electrical and mechanical component modeling systems (librarian tools),
- electrical and mechanical computer-aided design system (ECAD/MCAD),
- Design Analysis
- rule definition system,
- rule execution system.
- electrical and mechanical computer-aided engineering analysis system (ECAE/MCAE),
- Manufacturing Automation
- bare-board test system,
- computer-aided manufacturing system (CAM),
- coordinate measurement system (CMM),
- functional test system,
- in-circuit test system,
- Enterprise product data management systems
- component information system (CIS),
- issue resolution system,
- manufacturing process planning system (MPP),
- manufacturing resource planning system (MRP),
- product data management system (PDM),
- product lifecycle management system (PLM).
AP Investigation sequence
Logically, the sequence for an implementor to follow in investigating AP 210 is:
- Create the use case
- 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.
- Review clause 4 of the AP to become familiar with the coverage of the AP.
- Review the available recommended practices for coverage of the use case
- If recommended practices are available for the use case
- Follow their guidance
- Determine what to do with data unavailable in the transmitting system or that cannot be understood by the receiving system;
- If a recommended practice is not available for the use case
- Determine the conformance options that cover the use case
- Review the application objects referenced in the conformance options
- Select the conformance option that meets the business needs of the implementation (i.e., cost/schedule/data availability)
- Define a list of Application Objects to implement
- 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;
- Review the rules applied to the those aim elements
- Review the rules applied to the Application Objects
- Determine what to do with data unavailable in the transmitting system or that cannot be understood by the receiving system
- 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 implementors 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.
The Different Roles in AP 210 Implementations
Systems 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.
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.
Application 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.
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.
Components 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.
As implementation experience grows, recommended practices will be included as well as the conformance options that relate to the scope. AP210_Scope
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.
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 ‚ÄúENTITY‚Äù construct, so Application objects are represented by ‚ÄúENTITY‚Äù objects in the ARM EXPRESS.
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 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.
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 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. AP developers are no longer required to "copy and paste" models.
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.
The other data model of AP 210 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 . 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.
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 EXPRESS 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.
The mapping from ARM to AIM
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. for free.
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.
NOTE: The second edition of AP 210 has considerably simplified the relationship between the ARM and the AIM in most cases.
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.
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.
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.
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[] 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.
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. AP210ed2 conformance classes and conformance options provides a list of the conformance options. 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.
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.
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.
This involves the exchange of product data between two or more application systems using the STEP exchange file standard, ISO 10303-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.
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 data validation.
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.
Native 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.
Working 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 system must 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).
Working 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.
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.
AP 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 implementor of AP 210 or other STEP APs. The following organizations are sources of assistance.
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 
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: or call Jack Harris, General Manager at (843) 760-3342.
Electrical 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. This page will be updated upon notification of errata.
- Figure 1-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 2-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 4-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5-2: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5-3: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5-4: First published in this document.
- Figure 5-5: First published in this document.
- Figure 5-6: 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
- Figure 5-7: First published in this document.
- Figure 5-8: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5.4.3-1: 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
- Figure 5.4.3-2: ISO 10303-210:2001, ©ISO, used with permission
- Figure 5.4.4-1: 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
- Figure 5.4.5-1: First published in this document.
- Figure 5.4.5-2: ISO 10303-210:2001, ©ISO, used with permission
- Figure 5.4.5-3: ISO 10303-210:2001, ©ISO, used with permission
- Figure 5.4.8-1: LKSoft; www.ida-step.net
- Figure 5.9.1-1: ISO 10303-210:2001, ©ISO, used with permission
- Figure 5.9.2-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 5.9.4-1: AP 210 training, Asheville, North Carolina, 2003, PDES Inc.
- Figure 9.1-1: PDES/STEP Data Sharing Architecture, PDES Inc.
- Figure 9.2-1: PDES/STEP Data Sharing Architecture, PDES Inc.
- Figure 9.3-1: PDES/STEP Data Sharing Architecture, PDES Inc.
- PDES/STEP Data Sharing Architecture (PTI017.03.00): available from PDES Inc.: 
- ANSI/X3/SPARC Study Group on Data Base Management Systems: (1975), Interim Report. FDT, ACM SIGMOD bulletin. Volume 7, No. 2.
- See also: