Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 14662-10:2015 — Information Technology — Open-edi Reference Model Technical Overview
A Comprehensive Guide to the Framework for Electronic Data Interchange and Business Collaboration
Scope and Purpose
IEC 14662-10:2015 (technically identical to ISO/IEC 14662:2010, confirmed in 2015) defines the Open-edi Reference Model for information technology — a foundational framework for electronic data interchange (EDI) and business collaboration. It provides a common language and architectural structure that enables autonomous organizations to conduct electronic transactions using standardized business procedures, regardless of their internal systems or communication protocols.
The model specifies two interrelated views: the Business Operational View (BOV) and the Functional Service View (FSV). Together they form a comprehensive basis for designing, implementing, and testing Open-edi systems. The standard addresses interoperability, semantic consistency, and conformance requirements, making it essential for developers, integrators, and compliance assessors in global trade, logistics, finance, and government services.
Note: IEC 14662-10:2015 is a joint standard published by IEC and ISO. It supersedes earlier editions and incorporates clarifications on scenario definitions and conformance clauses. The 2015 confirmation ensures alignment with current business process modeling practices.
Technical Architecture and Requirements
Business Operational View (BOV)
The BOV describes the business aspects of an Open-edi transaction. It includes the business entities, roles, relationships, and sequences of actions required to complete a business transaction. Key elements defined in the BOV are:
- Business Scenario — An external specification of a class of business transactions (e.g., purchase order cycle).
- Business Transaction — The actual instance of information exchange between two or more parties.
- Role — The function assumed by a party (e.g., buyer, seller, customs broker).
- Commitment — An obligation agreed upon during a business transaction.
Functional Service View (FSV)
The FSV provides the information technology perspective. It defines the supporting infrastructure necessary to execute the business scenarios. The FSV includes:
- Open-edi Support Functions — Services such as message transport, security, and repository access.
- Operational Phases — Planning, identification, negotiation, execution, and post-processing.
- Data Models — Formal representations of the exchanged information (e.g., using XML, ASN.1, or EDIFACT).
The standard requires that a conformant Open-edi system must support both BOV and FSV specifications in an integrated manner. Table 1 summarizes key differences between the two views.
| Aspect | Business Operational View (BOV) | Functional Service View (FSV) |
|---|---|---|
| Focus | Business semantics, roles, and legal commitments | Technology infrastructure and service interfaces |
| Representation | Natural language, activity diagrams, scenario templates | Formal to specifications, protocol definitions, API contracts |
| Interoperability aim | Semantic understanding between domains | Technical communication between heterogeneous systems |
| Example element | Buyer commitment to pay | Secure message delivery service |
Implementation Tip: When developing an Open-edi solution, start with a clear Business Scenario (BOV) before defining the FSV services. This ensures that the technology supports the actual business requirements, not just abstract data exchange.
Implementation Guidelines
IEC 14662-10:2015 is a reference model, not a protocol specification. Therefore, implementation requires mapping the abstract concepts to concrete technologies. The standard recommends the following steps:
- Scenario Definition — Document the business process using the formal scenario template. Identify all roles, commitments, and information flows.
- Service Identification — Derive the required FSV functions from the BOV (e.g., if commitment is needed, include a notary service).
- Selection of Standards — Choose concrete messaging, security, and syntax standards (e.g., UN/EDIFACT, AS4, X.509) that conform to the FSV service definitions.
- Testing and Validation — Verify that the implementation correctly executes the defined business scenarios, including exception handling.
Caution: The model is abstract and can be misinterpreted. Avoid the common pitfall of treating the FSV as a simple messaging layer; the BOV obligations must be monitored and enforced. A system that only exchanges messages but does not track commitments is not Open-edi conformant.
Compliance and Conformance
Conformance to IEC 14662-10:2015 is declared in two categories:
- BOV Conformance — The system can express and execute a valid business scenario from a given dictionary.
- FSV Conformance — The system supports all required functional services for at least one scenario.
To achieve full conformance, both views must be implemented and verified. The standard does not prescribe a specific conformance testing regime but provides a framework for creating one. Annexes (informative) offer guidance on scenario templates and service definitions.
Important: Many EDI systems are only partially conformant. Full compliance requires that the system can interpret business rules and commitments, not just route data. Verification should include scenario simulation and audit of commitment enforcement.
Organizations seeking certification should prepare a conformance statement detailing which business scenarios and functional services are implemented. A third-party assessment is recommended for high-value transactions (e.g., cross-border trade, healthcare).
Frequently Asked Questions
Q: Is IEC 14662-10:2015 identical to ISO/IEC 14662?
A: Yes. IEC 14662-10:2015 adopts ISO/IEC 14662:2010 without modifications and was confirmed in 2015. The dual numbering reflects joint publication by IEC and ISO.
A: Yes. IEC 14662-10:2015 adopts ISO/IEC 14662:2010 without modifications and was confirmed in 2015. The dual numbering reflects joint publication by IEC and ISO.
Q: What is the difference between Open-edi and traditional EDI?
A: Traditional EDI focuses on message standards (e.g., ANSI X12, EDIFACT). Open-edi goes further by defining business scenarios and commitments, making it possible to automate entire business processes, including legal obligations.
A: Traditional EDI focuses on message standards (e.g., ANSI X12, EDIFACT). Open-edi goes further by defining business scenarios and commitments, making it possible to automate entire business processes, including legal obligations.
Q: Can the model be used with modern REST-based APIs and JSON?
A: Yes. The FSV is technology-agnostic. You can map its services to RESTful endpoints, and the BOV scenarios can be encoded using JSON-LD. Many current implementations use AS4 or REST profiles with the Open-edi reference model.
A: Yes. The FSV is technology-agnostic. You can map its services to RESTful endpoints, and the BOV scenarios can be encoded using JSON-LD. Many current implementations use AS4 or REST profiles with the Open-edi reference model.
Technical article published 2026. Based on IEC 14662-10:2015 (ISO/IEC 14662:2010).