IEC TR 62699-1-2014: Mapping Rules and Exchange Methods for Heterogeneous Electronic Parts Libraries

📌 Key Insight: IEC TR 62699-1 tackles the critical engineering challenge of searching across dissimilar electronic component libraries by defining a standardized mapping framework and integrated search architecture that bridges disparate data formats, classification systems, and property definitions.

1. The Heterogeneous Parts Library Problem

In modern electronics design, engineers routinely need to search for components across multiple supplier databases, internal corporate libraries, and industry-standard part repositories. Each of these sources typically uses different classification schemes, property naming conventions, data structures, and units of measurement. IEC TR 62699-1, published in December 2014 by IEC Technical Committee 91 (Electronics assembly technology), addresses this fragmentation by providing a comprehensive framework for building an integrated search system across heterogeneous electronic parts libraries.

⚠️ The Scale of the Problem: A typical electronics manufacturer may maintain 10+ internal parts databases alongside subscriptions to 5-8 supplier catalogs, each using different taxonomies. Engineers can spend up to 30% of their design time searching for and qualifying components — time that this standard’s approach aims to dramatically reduce.

The technical report is the first part of a multi-part series under the general title “Mapping rules and exchange methods for heterogeneous electronic parts libraries.” It focuses specifically on establishing the foundational architecture, data formats, mapping rules, and communication protocols needed to enable cross-library search and information retrieval.

2. Architecture and Mapping Framework

2.1 System Architecture and Data Flow

The core architecture defined in IEC TR 62699-1 is an interoperability system consisting of a Utilized Dictionary (UD) that provides a common, unified view across multiple heterogeneous Standard Dictionaries (SDs). Each SD represents an individual parts library with its own schema, classification, and property definitions. The UD acts as a semantic bridge, defining standardized class and property mappings that enable cross-library queries.

The data flow follows a well-defined sequence: a user submits a query through the search interface using the UD terminology, the system translates the query into the native schemas of each target SD, executes parallel searches across the individual libraries, collects and harmonizes the results, and presents them in a unified format. Error and warning messages are defined for handling failures in individual library access.

💡 Architecture Insight: The separation between Utilized Dictionary and Standard Dictionaries is critical. The UD should be maintained as a living document that evolves as new component types emerge. A governance process for UD updates — including version control, change notification, and backward compatibility — is essential for long-term system viability.

Component	Description	Key Features
Utilized Dictionary (UD)	Common unified vocabulary	Standardized classes, properties, units
Standard Dictionary (SD)	Individual library schema	Native classification, native properties
Mapping Rules	Transformation between UD ↔ SD	1:1, 1:N, N:1, 1:0 mapping types
Query Manager	Query distribution and result aggregation	Parallel search, deduplication, ranking
Message Handler	Communication protocol	Request/response, error handling

2.2 Dictionary Format and Structure

The standard defines detailed format specifications for both the Utilized Dictionary and Standard Dictionaries. Each dictionary entry includes a class definition (with unique identifier, name, description, and classification code), root properties (attributes applicable to all members of a class), and specific properties (attributes relevant to particular sub-classes or component types). The format supports hierarchical relationships between classes and inheritance of properties, mirroring the natural taxonomy of electronic components.

Property definitions include data type specifications (string, integer, real, Boolean, enumerated), units of measurement, and value ranges. This rigorous formatting is essential for automated mapping and query translation.

Mapping Type	Description	Example
1:1	One class/property maps directly	“Resistance” in UD → “Resistance” in SD
1:N	One element maps to multiple	“Operating Temp” → {“Tmin”, “Tmax”}
N:1	Multiple elements map to one	{“Width”, “Length”} → “Dimensions”
1:0	Element has no equivalent	UD “RoHS status” → not in legacy SD
0:1	SD element not in UD	SD-specific “Vendor internal code”

3. Mapping Rules and Message Exchange

3.1 Mapping Rule Types

IEC TR 62699-1 defines five fundamental mapping types that cover essentially all relationships between heterogeneous library schemas. The 1:1 direct mapping is the simplest case, where a class or property in the UD has a direct equivalent in the SD. The 1:N and N:1 mappings handle the common situation where one system has a composite property that another splits into multiple atomic properties. The 1:0 mapping addresses the inevitable incompleteness of cross-library harmonization — some concepts in the UD simply have no equivalent in a given legacy library.

⚠️ Mapping Complexity: The 1:N and N:1 mapping types present the greatest implementation challenge. For example, if the UD defines “Operating Temperature Range” as a single composite property while an SD splits it into “Min Operating Temp” and “Max Operating Temp,” the mapping function must correctly handle range queries, partial matches, and boundary conditions. This requires careful mathematical treatment of intervals and set operations.

3.2 Message Exchange Protocol

The standard specifies a comprehensive message exchange protocol supporting four main message types: query requests (search criteria submitted by the user), detail requests (request for full specifications of a selected component), query responses (search results from a library), and detail responses (complete component data). Error and warning messages are defined for handling situations where a library is unavailable, a query times out, or data validation fails.

Each message follows a block structure: a control block with routing and identification information, and a content block carrying the actual payload. The message format is designed to be transport-independent — it can be implemented over HTTP, SOAP, message queues, or proprietary protocols.

Message Type	Direction	Content
Query Request	Client → Server	Search criteria, filter parameters, preferred SDs
Query Response	Server → Client	Matching components, summary data, match scores
Detail Request	Client → Server	Component ID, requested property list
Detail Response	Server → Client	Full component specification, datasheet references
Error / Warning	Server → Client	Error code, description, affected SD

❓ FAQ 1: How does IEC TR 62699-1 relate to IEC 61360 (component data dictionary)?

IEC 61360 provides a standard data dictionary for electronic components with defined classes and properties. IEC TR 62699-1 builds on this by providing the mapping and exchange mechanisms that allow multiple IEC 61360-compliant dictionaries (and non-compliant ones) to be searched as a unified system.

❓ FAQ 2: Is the integrated search system intended to replace individual library search functions?

No. The integrated system is a meta-search layer that adds cross-library search capability on top of existing library search functions. Individual libraries continue to operate independently with their own native interfaces.

❓ FAQ 3: How are units of measurement handled during mapping?

The standard requires that all property definitions include explicit units. During mapping, automatic unit conversion is applied where compatible conversions exist (e.g., mm ↔ inches). Incompatible unit mappings are flagged as errors requiring manual resolution.

❓ FAQ 4: What performance considerations apply to the integrated search system?

Since searches are distributed across potentially many libraries, query response time is dominated by the slowest library. The standard recommends implementing timeout limits, parallel execution, and partial result handling so that a slow or unavailable library does not block the entire search.