Information service
35 Information technology
New standards
CEN/TS 18212-5:2026
Personal identification - Requirements for biometric products - Part 5: Face biometrics
Scope: The CEN/TS 18212 series [4] specifies a generic framework for the establishment of requirements and their evaluation methodology for biometric products. The requirements depend on the biometric mode considered, and are adapted to each scenario, through the definition of a variety of application profiles.
The CEN/TS 18212 series [4] specifies the evaluation methodology, the individual TESTs, and the application profiles (with their particular requirements).
This document is focussed on face biometrics, and provides the specifics of this biometric mode for the application of all the specifications provided in parts 1 till 3 from CEN/TS 18212 series [4]. It also defines a set of application profiles, that detail the applicable TESTs, the evaluation parameters and the assessment criteria.
In detail, this document defines, for face biometric products:
- general aspects of a face biometric product;
- common resources needed for the evaluation;
- each of the possible TESTs to be applied;
- application profiles for different kinds of face biometrics products.
NOTE 1 National regulations and requirements can apply.
NOTE 2 Regarding biometrics for public sector applications, see also BSI TR 03121 [10] which can apply.
NOTE 3 For an overview of sectors addressed in the Cybersecurity Act, see Regulation (EU) 2019/881[11].
NOTE 4 This part defines all potential TESTs that could be applicable when evaluating the functionality of a biometric product using this biometric mode. It will be the relevant application profile (3.1.1), the one that will specify which of these TESTs are applicable.
The following topics are left out of the scope of this document:
- Vulnerability assessment of the storage system used for the biometric reference/s.
- Vulnerability assessment of communication protocols and interfaces dealing with the operation of the biometric product.
- Evaluation of the performance of human operators in terms of identity proofing.
- Validation of documents providing the biometric reference.
The CEN/TS 18212 series [4] specifies the evaluation methodology, the individual TESTs, and the application profiles (with their particular requirements).
This document is focussed on face biometrics, and provides the specifics of this biometric mode for the application of all the specifications provided in parts 1 till 3 from CEN/TS 18212 series [4]. It also defines a set of application profiles, that detail the applicable TESTs, the evaluation parameters and the assessment criteria.
In detail, this document defines, for face biometric products:
- general aspects of a face biometric product;
- common resources needed for the evaluation;
- each of the possible TESTs to be applied;
- application profiles for different kinds of face biometrics products.
NOTE 1 National regulations and requirements can apply.
NOTE 2 Regarding biometrics for public sector applications, see also BSI TR 03121 [10] which can apply.
NOTE 3 For an overview of sectors addressed in the Cybersecurity Act, see Regulation (EU) 2019/881[11].
NOTE 4 This part defines all potential TESTs that could be applicable when evaluating the functionality of a biometric product using this biometric mode. It will be the relevant application profile (3.1.1), the one that will specify which of these TESTs are applicable.
The following topics are left out of the scope of this document:
- Vulnerability assessment of the storage system used for the biometric reference/s.
- Vulnerability assessment of communication protocols and interfaces dealing with the operation of the biometric product.
- Evaluation of the performance of human operators in terms of identity proofing.
- Validation of documents providing the biometric reference.
Base documents: CEN/TS 18212-5:2026
ISO/IEC 23008-12:2025/Amd 2:2026
Information technology — High efficiency coding and media delivery in heterogeneous environments — Part 12: Image File Format — Amendment 2: Low-overhead image file format
Scope: Amendment to ISO/IEC 23008-12:2025
Base documents:
ISO 23247-5:2026
Automation systems and integration — Digital twin framework for manufacturing — Part 5: Digital thread for digital twin
Scope: This document specifies how a digital thread enables the creation, connectivity, management, and maintenance of manufacturing digital twins across the product life cycle, including design, planning, production, and testing by defining principles, presenting methodologies, and providing use case examples.
Base documents:
ISO 39004:2026
Road traffic safety — Good practice for service providers using digital platform
Scope: This document provides good practice that can be adopted by any service provider, not limited to e-hailing and p-hailing operators, for the implementation of work-related road traffic safety (RTS) management.
This document is applicable to any service provider to offer further protection to the drivers for digital platform providers as well as other road users through the adoption of a proactive approach to manage work-related road risks.
This document is applicable to any service provider to offer further protection to the drivers for digital platform providers as well as other road users through the adoption of a proactive approach to manage work-related road risks.
Base documents:
ISO/IEC TR 23888-3:2026
Information technology — Artificial intelligence for multimedia — Part 3: Optimization of encoders and receiving systems for machine analysis of coded video content
Scope: This document provides information about optimizations for encoders and receiving systems for conducting machine analysis tasks on coded video content. It provides a concept-level overview of recent practices and provides comments on technical aspects and cautions to be taken when interpreting the results. This document describes technologies that have recently been studied and have demonstrated benefits to coding efficiency for some machine analysis tasks.
Base documents:
ISO 42503:2026
Sharing economy — Framework for implementation
Scope: This document establishes a framework for the implementation of a sharing economy. It specifies requirements for and gives guidance on the operational economic, social, environmental, legal and other considerations and factors associated with implementation of sharing economy applications and approaches in sharing economy contexts.
This document is applicable to all actors participating in the sharing economy ecosystem, including platform operators, providers, users and other stakeholders.
This document is applicable to all types and sizes of organization (e.g. commercial enterprises, government agencies, not-for-profit organizations).
This document is applicable to all actors participating in the sharing economy ecosystem, including platform operators, providers, users and other stakeholders.
This document is applicable to all types and sizes of organization (e.g. commercial enterprises, government agencies, not-for-profit organizations).
Base documents:
ISO/TR 19312:2026
Graphic technology — Analysis of a method for predicting print image quality for prints from high-speed inkjet printing system from combinations of paper properties
Scope: This document presents an analysis of a test method and procedures for predicting print image quality for prints from high-speed inkjet printing systems. Results from an initial set of tests are reported.
Based on this method, a set of paper properties and their ISO related standards is given, in addition to those presented in ISO 15397.
Based on this method, a set of paper properties and their ISO related standards is given, in addition to those presented in ISO 15397.
Base documents:
ISO/TS 24971-2:2026
Medical devices — Guidance on the application of ISO 14971 — Part 2: Machine learning in artificial intelligence
Scope: This document provides guidance on risks specific to artificial intelligence (AI) and machine learning (ML) and how to apply the risk management process of ISO 14971 to ML-enabled medical devices (MLMD). This document is intended to be used in conjunction with ISO 14971 and ISO/TR 24971[2].
This document does not apply to MLMD employing large language models (LLM) or generative AI.
This document does not apply to MLMD employing large language models (LLM) or generative AI.
Base documents:
ISO/IEC 9837:2026
Systems and software engineering — Systems resilience concepts
Scope: This document establishes concepts for understanding and improving systems resilience. Systems resilience addresses the capabilities of systems under adversity.
This document is applicable to human-created systems that can be either physical or conceptual, or a combination of both. It applies to systems as defined in ISO/IEC/IEEE 15288, including services and products. It is not intended to apply to naturally occurring systems.
This document is applicable to human-created systems that can be either physical or conceptual, or a combination of both. It applies to systems as defined in ISO/IEC/IEEE 15288, including services and products. It is not intended to apply to naturally occurring systems.
Base documents:
ISO TS 24971-2:2026
Medical devices - Guidance on the application of ISO 14971 - Part 2: Machine learning in artificial intelligence
Scope:
ISO TS 24971-2:2026 This document provides guidance on risks specific to artificial intelligence (AI) and machine learning (ML) and how to apply the risk management process of ISO 14971 to ML-enabled medical devices (MLMD). This document is intended to be used in conjunction with ISO 14971 and ISO/TR 24971[2].
This document does not apply to MLMD employing large language models (LLM) or generative AI.
Base documents:
IEC 62911:2025/COR1:2026
Corrigendum 1 - Audio, video and information technology equipment - Routine electrical safety testing in production
Scope: Corrigendum for IEC 62911:2025
Base documents:
Replaced standards
CWA 15748-1:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 1: Application Programming Interface (API) - Service Provider - Interface (SPI) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-1:2008
CWA 15748-10:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 10: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-10:2008
CWA 15748-11:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 11: Vendor Dependent Mode Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-11:2008
CWA 15748-12:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 12: Camera Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-12:2008
CWA 15748-13:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 13: Alarm Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-13:2008
CWA 15748-14:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 14: Card Embossing Unit Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-14:2008
CWA 15748-15:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 15: Cash-In Module Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-15:2008
CWA 15748-16:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 16: Card Dispenser Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-16:2008
CWA 15748-17:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 17: Barcode Reader Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-17:2008
CWA 15748-18:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 18: Item Processing Module Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-18:2008
CWA 15748-2:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 2: Service Class Definition - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-2:2008
CWA 15748-29:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 29: XFS MIB Architecture and SNMP Extensions MIB Version 3.10
Scope: This specification describes the general MIB definition (Management Information Base) for the XFS environment and some new APIs that allow network management of Service Providers from the application layer. This specification is mainly focused on the following areas: * SNMP management architecture * MIB structure definition * Trap format definition * Management extension of the Service Providers Interface Full implementation of the above features depends on the individual vendor-supplied Service Providers. This specification outlines the functionality and requirements for applications using the XFS network management services, and for the development of those services. The XFS device specific MIB and the application MIB definitions will be defined in separate documents. An agent is compliant with the XFS MIB, if it supports the XFS MIB as defined in this specification and the referenced device/application specific XFS MIB specifications. No restrictions are placed on how an agent is implemented. The MIB feature is an optional addendum to the XFS CWA. In addition, the main focus of this standard is on the standardisation of the MIB specification, not any specific implementation. From a management perspective, the key to multi-vendor management is that the MIB and values are consistent.
Base documents: CWA 15748-29:2011
CWA 15748-3:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 3: Printer and Scanning Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-3:2008
CWA 15748-30:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 30: XFS MIB Device Specific Definitions - Printer Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsPTR sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsPTR version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsPTR (1) - xfsPTRV1 (1) The xfsPTRV1 sub-tree contains the following variables: * xfsPTRInstances(1) is the number of managed services for the PTR class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsPTRStatusTable(2) identifies the table for the PTR variables. * xfsPTRSubDeviceTable(3) identifies the table for the PTR device. * xfsPTRErrorTable(4) identifies the table for the PTR error counters. * xfsPTRResetTable(5) identifies the table for the PTR reset variable. * xfsPTRResetDeviceTable(6) identifies the table for the PTR reset device variables. * xfsPTRCapabilitiesTable(7) identifies the table for the PTR capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-30:2011
CWA 15748-31:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 31: XFS MIB Device Specific Definitions - Identification Card Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsIDC sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsIDC version one sub-tree is identified by: xfsMIBRoot - xfsManagedService(2) - xfsIDC (2) - xfsIDCV1 (1) The xfsIDCV1 sub-tree contains the following variables: - xfsIDCInstances(1) is the number of managed services for the IDC class installed on the XFS subsystem. It is a 32 bit numerical field. - xfsIDCStatusTable(2) identifies the table for the IDC variables. - xfsIDCSubDeviceTable(3) not applicable to the IDC device. - xfsIDCErrorTable(4) identifies the table for the IDC error counters. - xfsIDCResetTable(5) identifies the table for the IDC reset variable. - xfsIDCResetDeviceTable(6) identifies the table for the IDC reset device variables. - xfsIDCCapabilitiesTable(7) identifies the table for the DEP device capabilities variables The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-31:2011
CWA 15748-32:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 32: XFS MIB Device Specific Definitions - Cash Dispenser Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCDM sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCDM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCDM (3) - xfsCDMV1 (1) The xfsCDMV1 sub-tree contains the following variables: * xfsCDMInstances(1) is the number of managed services for the CDM class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsCDMStatusTable(2) identifies the table for the CDM variables. * xfsCDMSubDeviceTable(3) identifies the sub-device table for the CDM device. * xfsCDMErrorTable(4) identifies the table for the CDM error counters. * xfsCDMResetTable(5) identifies the table for the CDM reset variable. * xfsCDMResetDeviceTable(6) identifies the table for the CDM reset device variables. * xfsCDMCapabilitiesTable(7) identifies the table for the CDM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-32:2011
CWA 15748-33:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 33: XFS MIB Device Specific Definitions - PIN Keypad Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsPIN sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsPIN version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsPIN (4) - xfsPINV1 (1) The xfsPINV1 sub-tree contains the following variables: * xfsPINInstances(1) is the number of managed services for the PIN class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsPINStatusTable(2) identifies the table for the PIN variables. * xfsPINSubDeviceTable(3) not applicable to the PIN device. * xfsPINErrorTable(4) identifies the table for the PIN error counters. * xfsPINResetTable(5) identifies the table for the PIN reset variable. * xfsPINResetDeviceTable(6) identifies the table for the PIN reset device variables. * xfsPINCapabilitiesTable(7) identifies the table for the PIN capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-33:2011
CWA 15748-34:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 34: XFS MIB Device Specific Definitions - Check Reader/Scanner Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCHK sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCHK version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCHK (5) - xfsCHKV1 (1) The xfsCHKV1 sub-tree contains the following variables: * xfsCHKInstances(1) is the number of managed services for the CHK class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsCHKStatusTable(2) identifies the table for the CHK variables. * xfsCHKSubDeviceTable(3) not applicable to the CHK device. * xfsCHKErrorTable(4) identifies the table for the CHK error counters. * xfsCHKResetTable(5) identifies the table for the CHK reset variable. * xfsCHKResetDeviceTable(6) identifies the table for the CHK reset device variables. * xfsCHKCapabilitiesTable(7) identifies the table for the CHK capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-34:2011
CWA 15748-35:2011
Extensions for Financial Services (XFS) interface specification Release 3.10 - Part 35: XFS MIB Device Specific Definitions - Depository Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsDEP sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsDEP version one sub-tree identified by: xfsMIBRoot - xfsManagedService (2) - xfsDEP (6) - xfsDEPV1 (1) The xfsDEPV1 sub-tree contains the following variables: * xfsDEPInstances(1) is the number of managed services for the DEP class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsDEPStatusTable(2) identifies the table for the DEP variables. * xfsDEPSubDeviceTable(3) not applicable to the DEP device. * xfsDEPErrorTable(4) identifies the table for the DEP error counters. * xfsDEPResetTable(5) identifies the table for the DEP reset variable. * xfsDEPResetDeviceTable(6) identifies the table for the DEP reset device variables. * xfsDEPCapabilitiesTable(7) identifies the table for the DEP device capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-35:2011
CWA 15748-36:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 36: XFS MIB Device Specific Definitions - Text Terminal Unit Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsTTU sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsTTU version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsTTU (7) - xfsTTUV1 (1) The xfsTTUV1 sub-tree contains the following variables: * xfsTTUInstances(1) is the number of physical devices for the TTU class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsTTUStatusTable(2) identifies the table for the TTU variables. * xfsTTUSubDeviceTable(3) not applicable to the TTU device. * xfsTTUErrorTable(4) identifies the table for the TTU error counters. * xfsTTUResetTable(5) identifies the table for the TTU reset variable. * xfsTTUResetDeviceTable(6) identifies the table for the TTU reset device variables. * xfsTTUCapabilitiesTable(7) identifies the table for the TTU capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-36:2011
CWA 15748-37:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 37: XFS MIB Device Specific Definitions - Sensors and Indicators Unit Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsSIU sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsSIU version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsSIU (8) - xfsSIUV1 (1) The xfsSIUV1 sub-tree contains the following variables: * xfsSIUInstances(1) is the number of managed services for the SIU class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsSIUStatusTable(2) identifies the table for the SIU variables. * xfsSIUSubDeviceTable(3) not applicable to the SIU device. * xfsSIUErrorTable(4) identifies the table for the SIU error counters. * xfsSIUResetTable(5) identifies the table for the SIU reset variable. * xfsSIUResetDeviceTable(6) identifies the table for the SIU reset device variables. * xfsSIUCapabilitiesTable(7) identifies the table for the SIU capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-37:2011
CWA 15748-38:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 38: XFS MIB Device Specific Definitions - Camera Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCAM sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCAM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCAM (10) - xfsCAMV1 (1) The xfsCAMV1 sub-tree contains the following variables: * xfsCAMInstances(1) is the number of managed services for the CAM class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsCAMStatusTable(2) identifies the table for the CAM variables. * xfsCAMSubDeviceTable(3) not applicable to the CAM device. * xfsCAMErrorTable(4) identifies the table for the CAM error counters. * xfsCAMResetTable(5) identifies the table for the CAM reset variable. * xfsCAMResetDeviceTable(6) identifies the table for the CAM reset device variables. * xfsCAMCapabilitiesTable(7) identifies the table for the CAM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-38:2011
CWA 15748-39:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 39: XFS MIB Device Specific Definitions - Alarm Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsALM sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsALM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsALM (11) - xfsALMV1 (1) The xfsALMV1 sub-tree contains the following variables: - xfsALMInstances(1) is the number of managed services for the ALM class installed on the XFS subsystem. It is a 32 bit numerical field. - xfsALMStatusTable(2) identifies the table for the ALM variables. - xfsALMSubDevicesTable(3) not applicable to the ALM device. - xfsALMErrorTable(4) identifies the table for ALM error counters. - xfsALMResetTable(5) identifies the table for the ALM reset variable. - xfsALMResetDeviceTable(6) identifies the table for the ALM reset device variables. - xfsALMCapabilitiesTable(7) identifies the table for the ALM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-39:2011
CWA 15748-4:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 4: Identification Card Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-4:2008
CWA 15748-40:2011
Extensions for Financial Services (XFS) interface specification Release 3.10 - Part 40: XFS MIB Device Specific Definitions - Card Embossing Unit Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCEU sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCEU version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCEU (12) - xfsCEUV1 (1) The xfsCEUV1 sub-tree contains the following variables: - xfsCEUInstances(1) is the number of physical devices for the CEU class installed on the XFS subsystem. - xfsCEUStatusTable(2) identifies the table for the CEU variables. - xfsCEUSubDevicesTable(3) not applicable to the CEU device. - xfsCEUErrorTable(4) identifies the table for the CEU error counters. - xfsCEUResetTable(5) identifies the table for the CEU reset variable. - xfsCEUResetDeviceTable(6) identifies the table for the CEU reset device variables. - xfsCEUCapabilitiesTable(7) identifies the table for the CEU capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-40:2011
CWA 15748-41:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 41: XFS MIB Device Specific Definitions - Cash In Module Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCIM sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCIM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCIM (13) - xfsCIMV1 (1) The xfsCIMV1 sub-tree contains the following variables: - xfsCIMInstances(1) is the number of managed services for the CIM class installed on the XFS subsystem. It is a 32 bit numerical field. - xfsCIMStatusTable(2) identifies the table for the CIM variables. - xfsCIMSubDeviceTable(3) this table contains the sub-device table for the CIM device. - xfsCIMErrorTable(4) identifies the table for the CIM error counter variables. - xfsCIMResetTable(5) identifies the table for the CIM reset variable. - xfsCIMResetDeviceTable(6) identifies the table for the CIM reset device variables. - xfsCIMCapabilitiesTable(7) identifies the table for the CIM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-41:2011
CWA 15748-43:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 43: XFS MIB Device Specific Definitions - Vendor Dependent Mode Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsVDM sub-tree version 1.1, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsVDM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsVDM (9) - xfsVDMV1 (1) The xfsVDMV1 sub-tree contains the following variables: * xfsVDMInstances(1) is the number of managed services for the VDM class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsVDMStatusTable(2) identifies the table for the VDM variables. * xfsVDMSubDeviceTable(3) not applicable to the VDM device. * xfsVDMErrorTable(4) identifies the table for the VDM error counters. * xfsVDMResetTable(5) identifies the table for the VDM reset variable. * xfsVDMCapabilitiesTable(7) identifies the table for VDM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-43:2011
CWA 15748-44:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 44: XFS MIB Application Management MIB 3.10
Scope: This document provides the specific MIB definition (Management Information Base) variables for the Application Management sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. The xfsAppMIB version one sub-tree is identified by: xfsMIBRoot - xfsManagedApp (1000) - xfsAppMIBV1 (1) The xfsAppMIBV1 sub-tree contains the following variables: * xfsConsumerApplication is the state of the consumer application functionality. * xfsSupervisorApplication is the state of the supervisor functionality. * xfsConsumerAppCommStatus is the status of the communication between the consumer application and the host. * xfsExtension is a list of vendor dependent additional application state information. The xfsConsumerApplication and xfsSupervisorApplication variables allow the applications view of the overall state of the terminal to be determined and reported. These variables identify system issues, e.g. the consumer application may be offline while all devices are available - the terminal is then not able to offer transaction services (even if the individual states of all the terminal’s devices are online and functioning properly). The xfsConsumerAppCommStatus reports the communication status of the customer application with the host, whether it is online, offline or the communication status is unknown. This document describes the OID structure for reporting the application state. This MIB reflects the status of the consumer application, the status of the supervisor application and the status of the consumer application communications. The status of XFS devices is separately defined and reported by the XFS device class MIBs. It is important to be clear that this document provides a standard interface for management clients to obtain state information. It does not define an interface for how this information is obtained locally. How this information is populated by local self-service SNMP agents is the responsibility of the agent implementation. In addition, the application management agent implementation must be compatible with the device agent so that the agents can coexist on the same platform. This approach: - Allows the SNMP agent supplier to define how best that this information be populated. - Avoids the CEN XFS device standard from encroaching in non-device functionality. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-44:2011
CWA 15748-45:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 45: XFS MIB Device Specific Definitions - Card Dispenser Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsCRD sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsCRD version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsCRD (14) - xfsCRDV1 (1) The xfsCRDV1 sub-tree contains the following variables: - xfsCRDInstances(1) is the number of managed services for the CRD class installed on the XFS subsystem. It is a 32 bit numerical field. - xfsCRDStatusTable(2) identifies the table for the CRD variables. - xfsCRDSubDeviceTable(3) this table contains the sub-device table for the CRD device. - xfsCRDErrorTable(4) identifies the table for the CRD error counter variables. - xfsCRDResetTable(5) identifies the table for the CRD reset variable. - xfsCRDResetDeviceTable(6) identifies the table for the CRD reset device variables. - xfsCRDCapabilitiesTable(7) identifies the table for the CRD capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-45:2011
CWA 15748-46:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 46: XFS MIB Device Specific Definitions - Barcode Reader Device Class MIB 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsBCR sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsBCR version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsBCR (15) - xfsBCRV1 (1) The xfsBCRV1 sub-tree contains the following variables: - xfsBCRInstances(1) is the number of managed services for the BCR class installed on the XFS subsystem. It is a 32 bit numerical field. - xfsBCRStatusTable(2) identifies the table for the BCR variables. - xfsBCRSubDevicesTable(3) not applicable to the BCR device. - xfsBCRErrorTable(4) identifies the table for BCR error counters. - xfsBCRResetTable(5) identifies the table for the BCR reset variable. - xfsBCRResetDeviceTable(6) identifies the table for the BCR reset device variables. - xfsBCRCapabilitiesTable(7) identifies the table for the BCR capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-46:2011
CWA 15748-47:2011
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 47: XFS MIB Device Specific Definitions - Item Processing Module Device Class MIB Version 3.10
Scope: This document provides the device specific MIB definition (Management Information Base) variables for the xfsIPM sub-tree version one, as foreseen by the XFS MIB Architecture and SNMP Extensions Programmer’s Reference document. All the attributes in all the MIBs are Mandatory. In the case where a vendor’s device does not support an attribute then a request for this unsupported attribute should return NULL. The xfsIPM version one sub-tree is identified by: xfsMIBRoot - xfsManagedService (2) - xfsIPM (16) - xfsIPMV1 (1) The xfsIPMV1 sub-tree contains the following variables: * xfsIPMInstances(1) is the number of managed services for the IPM class installed on the XFS subsystem. It is a 32 bit numerical field. * xfsIPMStatusTable(2) identifies the table for the IPM variables. * xfsIPMSubDeviceTable(3) this table contains the sub-device table for the IPM device. * xfsIPMErrorTable(4) identifies the table for the IPM error counter variables. * xfsIPMResetTable(5) identifies the table for the IPM reset variable. * xfsIPMResetDeviceTable(6) identifies the table for the IPM reset device variables. * xfsIPMCapabilitiesTable(7) identifies the table for IPM capabilities variables. The XFS MIB Architecture and SNMP Extensions Programmer’s Reference document provides an overview of the MIB structure.
Base documents: CWA 15748-47:2011
CWA 15748-5:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 5: Cash Dispenser Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-5:2008
CWA 15748-6:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 6: PIN Keypad Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-6:2008
CWA 15748-61:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 61: Application Programming Interface (API) - Service Provider - Interface (SPI) - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-61:2008
CWA 15748-62:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 62: Printer and Scanning Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-62:2008
CWA 15748-63:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 63: Identification Card Device Class Interface - Migration from Version 3.02 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-63:2008
CWA 15748-64:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 64: Cash Dispenser Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-64:2008
CWA 15748-65:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 65: PIN Keypad Device Class Interface - Migration from Version 3.03 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-65:2008
CWA 15748-66:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 66: Check Reader/Scanner Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-66:2008
CWA 15748-67:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 67: Depository Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-67:2008
CWA 15748-68:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 68: Text Terminal Unit Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-68:2008
CWA 15748-69:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 69: Sensors and Indicators Unit Device Class Interface - Migration from Version 3.01 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-69:2008
CWA 15748-7:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 7: Check Reader/Scanner Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-7:2008
CWA 15748-70:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 70: Vendor Dependent Mode Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-70:2008
CWA 15748-71:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 71: Camera Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-71:2008
CWA 15748-72:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 72: Alarm Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-72:2008
CWA 15748-73:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 73: Card Embossing Unit Device Class Interface - Migration from Version 3.0 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-73:2008
CWA 15748-74:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 74: Cash-In Module Device Class Interface - Migration from Version 3.02 (CWA 14050) to Version 3.10 (this CWA) - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-74:2008
CWA 15748-8:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 8: Depository Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-8:2008
CWA 15748-9:2008
Extensions for Financial Services (XFS) interface specification - Release 3.10 - Part 9: Text Terminal Unit Device Class Interface - Programmer's Reference
Scope: No scope available.
Base documents: CWA 15748-9:2008
CWA 13937-1:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 1: Base Architecture - Programmer's Reference
Scope: J/XFS defines a standardized interface to all common financial devices which can be used by applications and applets 1 written in the Java programming language. One of the reasons why these new banking applications are written in the Java language is that these programs are supposed to run on many different hardware platforms. One of the main obstacles in doing platform independent programming is accessing devices. One of the main goals of this standard is to allow access to banking devices in a 100% pure Java way on both thin and thick clients, e.g. on a network computer as well as in a Linux, WinNT, OS/2 or Unix workstation. Another goal is to allow the remote access to devices on different machines. Additional efforts have to be done to find and access these devices. This is the main reason why central administration processes and an additional communication layer are also defined by this architecture. If only local access to devices is needed, an implementation may omit this communication layer. No change is required to the Device Controls or Device Services. So, neither the application programmer nor the hardware manufacturer who programs a Device Service need be aware of whether or not a communication layer exists in the middle. Due to the nature of network computers which are supported as clients, it is not possible to guarantee that local persistent storage possibilities exist on each client. Therefore, any configuration information must be kept on a central server. If local storage exists and no central configuration possibilities are required, all configuration information can also be kept on the local workstation. The basic architecture of J/XFS is similar to the JavaPOS 2 architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS...(Truncated)
Base documents: CWA 13937-1:2000
CWA 13937-3:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 3: Magnetic Stripe & Chip Card Device Class Interface - Programmer's Reference
Scope: This document describes the Magnetic Stripe Device (MSD) as well as Chip Card Device (CCD) classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Device Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository.
To support Magnetic Stripe devices and Chip Card devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
To support Magnetic Stripe devices and Chip Card devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-3:2000
CWA 13937-4:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 4: Text Input/Output Device Interface - Programmer's Reference
Scope: This document describes the Text Input / Output Device Class ( TIO ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Text I/O Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-4:2000
CWA 13937-5:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 5: Cash Dispenser, Recycler and ATM Device Class Interface - Programmer's Reference
Scope: This document describes the printer device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Cash Dispenser, Recycler and ATM¿s the basic Device Control structure is extended with various properties and methods specific to this device which are described
on the following pages.
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Cash Dispenser, Recycler and ATM¿s the basic Device Control structure is extended with various properties and methods specific to this device which are described
on the following pages.
Base documents: CWA 13937-5:2000
CWA 13937-6:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 6: Printer Device Class Interface - Programmer's Reference
Scope: This document describes the printer device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support printers the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-6:2000
CWA 13937-7:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 7: Alarm Device Interface - Programmer's Reference
Scope: This document describes the printer device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support alarm devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-7:2000
CWA 16008-1:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 1: Base Architecture - Programmer's Reference
Scope: J/XFS defines a standardized interface to all common financial devices which can be used by applications and applets1 written in the Java programming language. One of the reasons why these new banking applications are written in the Java language is that these programs are supposed to run on many different hardware platforms. One of the main obstacles in doing platform independent programming is accessing devices. One of the main goals of this standard is to allow access to banking devices in a 100% pure Java way on both thin and thick clients, e.g. on a network computer as well as in a Linux, Windows, OS/2 or Unix workstation.
Base documents: CWA 16008-1:2009
CWA 13937-8:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 8: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Scope: This document describes the Sensors and Indicators Device Class ( SIU ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Sensors and Indicators Units, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-8:2000
CWA 16008-10:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 10: Check Reader/Scanner Device Class Interface - Programmer's Reference
Scope: This document describes the Check Reader/Scanner class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. This specification has been superseded by the new part 13: Scanner Class Interface and it is now deprecated. It is strongly suggested to use the new device class interface for new implementations. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Device Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository. To support Check Reader/Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-10:2009
CWA 13937-9:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 9: Depository Device Class Interface - Programmer's Reference
Scope: This document describes the depository device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support depository devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Manager - Device Communication - Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support depository devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-9:2000
CWA 16008-11:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 11: Camera Device Class Interface - Programmer's Reference
Scope: This document describes the Camera Device Class ( CAM ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Camera Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-11:2009
CWA 13937-10:2000
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 10: Check Reader/Scanner Device Class Interface - Programmer's Reference
Scope: This document describes the Check Reader/Scanner class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Device Manager - Device Communication - Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository. To support Check Reader/Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : - Application - Device Control and Device Manager - Device Communication - Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository. To support Check Reader/Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 13937-10:2000
CWA 16008-12:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 12: Vendor Dependant Mode Specification - Programmer's Reference
Scope: This document describes the Vendor Dependant Mode class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support VDM devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-12:2009
CWA 16008-13:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 13: Scanner Device Class Interface - Programmer's Reference
Scope: This document describes the Scanner device classes. These classes are basic on the J/XFS architecture which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which allows applications and devices to be distributed within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager resides in a central repository. To support Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device type. The extensions are described on the following pages.
Base documents: CWA 16008-13:2009
CWA 14923-8:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 8: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Scope: This document describes the Sensors and Indicators Device Class ( SIU ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven
and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device
(i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support Sensors and Indicators Units, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device
(i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support Sensors and Indicators Units, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-8:2004
CWA 13449-1:1998
Extensions for Financial Services (XFS) interface specification - Part 1: Application Programming Interface (API) - Service Provider Interface (SPI) - Programmer's Reference
Scope: This is part 1 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-1:1998
CWA 16008-2:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 2: Pin Keypad Device Class Interface - Programmer's Reference
Scope: This document describes the Pin Keypad Device (PIN) classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : • Application • Device Control and Device Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository. To support Pin Keypad devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-2:2009
CWA 13449-2:1998
Extensions for Financial Services (XFS) interface specification - Part 2: Service Classes Definition
Scope: This is part 2 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-2:1998
CWA 16008-3:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 3: Magnetic Stripe & Chip Card Device Class Interface - Programmer's Reference
Scope: This document describes the Magnetic Stripe Device (MSD) as well as Chip Card Device (CCD) classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : • Application • Device Control and Device Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control layer. This is the usual interface between applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository. To support Magnetic Stripe devices and Chip Card devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-3:2009
CWA 13449-3:1998
Extensions for Financial Services (XFS) interface specification - Part 3: Printer Device Class Interface Programmer's Reference
Scope: This is part 3 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-3:1998
CWA 16008-4:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 4: Text Input/Output Device Class Interface - Programmer's Reference
Scope: This document describes the Text Input / Output Device Class ( TIO ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Text I/O Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-4:2009
CWA 13449-4:1998
Extensions for Financial Services (XFS) interface specification - Part 4: Identification Card Device Class Interface - Programmer's Reference
Scope: This is part 4 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-4:1998
CWA 16008-5:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 5: Cash Dispenser, Recycler and ATM Device Class Interface - Programmer's Reference
Scope: This document describes the Cash Dispenser, Recycler and ATM device classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS : • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Cash Dispenser, Recycler and ATM’s the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages..
Base documents: CWA 16008-5:2009
CWA 16008-6:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 6: Printer Device Class Interface - Programmer's Reference
Scope: This document describes the printer device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support printers the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-6:2009
CWA 13449-5:1998
Extensions for Financial Services (XFS) interface specification - Part 5: Cash Dispenser Device Class Interface - Programmer's Reference
Scope: This is part 5 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-5:1998
CWA 13449-6:1998
Extensions for Financial Services (XFS) interface specification - Part 6: PIN Keypad Device Class Interface - Programmer's Reference
Scope: This is part 6 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-6:1998
CWA 16008-7:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 7: Alarm Device Class Interface -Programmer's Reference
Scope: This document describes the Alarm device classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. For Alarm Devices the basic Device Control class is extended with a method specific to this device which is described on the following pages.
Base documents: CWA 16008-7:2009
CWA 13449-7:1998
Extensions for Financial Services (XFS) interface specification - Part 7: Check Reader/Scanner Device Class Interface - Programmer's Reference
Scope: This is part 7 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-7:1998
CWA 16008-8:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 8: Sensors and Indicators Unit Device Class Interface - Programmer's Reference
Scope: This document describes the Sensors and Indicators Unit Device Class ( SIU ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support Sensors and Indicators Units, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-8:2009
CWA 13449-8:1998
Extensions for Financial Services (XFS) interface specification - Part 8: Depository Device Class Interface - Programmer's Reference
Scope: This is part 8 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-8:1998
CWA 16008-9:2009
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Release 2009 - Part 9: Depository Device Class Interface - Programmer's Reference
Scope: This document describes the depository device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous. Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS: • Application • Device Control and Manager • Device Communication • Device Service Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver). During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository. To support depository devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 16008-9:2009
CWA 13449-9:1998
Extensions for Financial Services (XFS) interface specification - Part 9: Text Terminal Unit Device Class Interface - Programmer's Reference
Scope: This is part 9 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-9:1998
CWA 13449-10:1998
Extensions for Financial Services (XFS) interface specification - Part 10: Sensors and indicators Unit Device Class Interface - Programmer's Reference
Scope: This is part 10 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-10:1998
CWA 13449-11:1998
Extensions for Financial Services (XFS) interface specification - Part 11: Vendor Dependent Mode Device Class Interface - Programmer's Reference
Scope: This is part 11 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-11:1998
CWA 13449-12:1998
Extensions for Financial Services (XFS) interface specification - Part 12: Camera Device Class Interface - Programmer's Reference
Scope: This is part 12 of the multi-part CWA 13449, describing Release 2.0 of the XFS interface specification.
Base documents: CWA 13449-12:1998
CWA 14923-1:2004
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 1: Base Architecture - Programmer's Reference
Scope: J/XFS defines a standardized interface to all common financial devices which can be used by applications and applets1 written in the Java programming language. One of the reasons why these new banking applications are written in the Java language is that these programs
are supposed to run on many different hardware platforms. One of the main obstacles in doing platform independent programming is accessing devices.
One of the main goals of this standard is to allow access to banking devices in a 100% pure Java way on both thin and thick clients, e.g. on a network computer as well as in a Linux, WinNT, OS/2 or Unix workstation.
Another goal is to allow the remote access to devices on different machines. Additional efforts have to be done to find and access these devices. This is the main reason why central administration processes and an additional communication layer are also defined by
this architecture.
If only local access to devices is needed, an implementation may omit this communication layer. No change is required to the Device Controls or Device Services. So, neither the application programmer nor the hardware manufacturer who programs a Device Service need be aware of whether or not a communication layer exists in the middle.
Due to the nature of network computers which are supported as clients, it is not possible to guarantee that local persistent storage possibilities exist on each client. Therefore, any configuration information must be kept on a central server. If local storage exists and no
central configuration possibilities are required, all configuration information can also be kept on the local workstation.
The basic architecture of J/XFS is similar to the JavaPOS2 architecture. It is event driven and asynchronous.
are supposed to run on many different hardware platforms. One of the main obstacles in doing platform independent programming is accessing devices.
One of the main goals of this standard is to allow access to banking devices in a 100% pure Java way on both thin and thick clients, e.g. on a network computer as well as in a Linux, WinNT, OS/2 or Unix workstation.
Another goal is to allow the remote access to devices on different machines. Additional efforts have to be done to find and access these devices. This is the main reason why central administration processes and an additional communication layer are also defined by
this architecture.
If only local access to devices is needed, an implementation may omit this communication layer. No change is required to the Device Controls or Device Services. So, neither the application programmer nor the hardware manufacturer who programs a Device Service need be aware of whether or not a communication layer exists in the middle.
Due to the nature of network computers which are supported as clients, it is not possible to guarantee that local persistent storage possibilities exist on each client. Therefore, any configuration information must be kept on a central server. If local storage exists and no
central configuration possibilities are required, all configuration information can also be kept on the local workstation.
The basic architecture of J/XFS is similar to the JavaPOS2 architecture. It is event driven and asynchronous.
Base documents: CWA 14923-1:2004
CWA 14923-2:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 2: Pin Keypad Device Class Interface - Programmer's Reference
Scope: This document describes the Pin Keypad Device (PIN) classes based on the basic
architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object.
Location and/or routing information for the Device Manager reside in a central
repository.
To support Pin Keypad devices the basic Device Control structure is extended with
various properties and methods specific to this device which are described on the
following pages
architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service object and attaching this to the requesting Device Control object.
Location and/or routing information for the Device Manager reside in a central
repository.
To support Pin Keypad devices the basic Device Control structure is extended with
various properties and methods specific to this device which are described on the
following pages
Base documents: CWA 14923-2:2004
CWA 14923-3:2004
J/eXtensions for Financial Services (J/XFS) for the Java Platform - Part 3: Magnetic Stripe & Chip Card Device Class Interface - Programmer's Reference
Scope: This document describes the Magnetic Stripe Device (MSD) as well as Chip Card
Device (CCD) classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in
J/XFS :
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the
desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository.
To support Magnetic Stripe devices and Chip Card devices the basic Device
Control structure is extended with various properties and methods specific to this
device which are described on the following pages.
Device (CCD) classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in
J/XFS :
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the
desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository.
To support Magnetic Stripe devices and Chip Card devices the basic Device
Control structure is extended with various properties and methods specific to this
device which are described on the following pages.
Base documents: CWA 14923-3:2004
CWA 14923-4:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 4: Text Input/Output Device Interface - Programmer's Reference
Scope: This document describes the Text Input / Output Device Class ( TIO ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device
Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or
routing information for the Device Manager reside in a central repository.
To support Text I/O Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device
Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or
routing information for the Device Manager reside in a central repository.
To support Text I/O Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-4:2004
CWA 14923-5:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 5: Cash Dispenser, Recycler and ATM Device Class Interface - Programmer's Reference
Scope: This document describes the Cash Dispenser, Recycler and ATM device classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and
asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device
Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or
routing information for the Device Manager reside in a central repository.
To support Cash Dispenser, Recycler and ATM’s the basic Device Control structure is extended with various properties and methods specific to this device which are described on
the following pages.
asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device
Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or
routing information for the Device Manager reside in a central repository.
To support Cash Dispenser, Recycler and ATM’s the basic Device Control structure is extended with various properties and methods specific to this device which are described on
the following pages.
Base documents: CWA 14923-5:2004
CWA 14923-6:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 6: Printer Device Class Interface - Programmer's Reference
Scope: This document describes the printer device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device
(i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support printers the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device
(i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support printers the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-6:2004
CWA 14923-7:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 7: Alarm Device Interface - Programmer's Reference
Scope: This document describes the Alarm device classes based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside
in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a
device driver).
During application startup the Device Manager is responsible for locating the desired Device
Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
For Alarm Devices the basic Device Control class is extended with a method specific to this device which is described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside
in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a
device driver).
During application startup the Device Manager is responsible for locating the desired Device
Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
For Alarm Devices the basic Device Control class is extended with a method specific to this device which is described on the following pages.
Base documents: CWA 14923-7:2004
CWA 14923-9:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 9: Depository Device Class Interface - Programmer's Reference
Scope: This document describes the depository device class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support depository devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support depository devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-9:2004
CWA 14923-10:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 10: Check Reader/Scanner Device Class Interface - Programmer's Reference
Scope: This document describes the Check Reader/Scanner class based on the basic
architecture of J/XFS which is similar to the JavaPOS architecture. It is event
driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the
desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository.
To support Check Reader/Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
architecture of J/XFS which is similar to the JavaPOS architecture. It is event
driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Device Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager
which reside in the Device Control layer. This is the usual interface between
applications and J/XFS devices. Device Control objects access the Device Manager to find an associated Device Service. Device Service objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the
desired Device Service object and attaching this to the requesting Device Control object. Location and/or routing information for the Device Manager reside in a central repository.
To support Check Reader/Scanner devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-10:2004
CWA 14923-11:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 11: Camera Specification - Programmer's Reference
Scope: This document describes the Camera Device Class ( CAM ) based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated
Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired
Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support Camera Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS:
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated
Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired
Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support Camera Devices, the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-11:2004
CWA 14923-12:2004
J/eXtensions for Financial Sevices (J/XFS) for the Java Platform - Part 12: Vendor Dependant Mode Specification - Programmer's Reference
Scope: This document describes the Vendor Dependant Mode class based on the basic architecture of J/XFS which is similar to the JavaPOS architecture. It is event driven and asynchronous.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated
Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support VDM devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Three basic levels are defined in JavaPOS. For J/XFS this model is extended by a communication layer, which provides device communication that allows distribution of applications and devices within a network. So we have the following layers in J/XFS :
• Application
• Device Control and Manager
• Device Communication
• Device Service
Application developers program against control objects and the Device Manager which reside in the Device Control Layer. This is the usual interface between applications and J/XFS Devices. Device Control Objects access the Device Manager to find an associated
Device Service. Device Service Objects provide the functionality to access the real device (i.e. like a device driver).
During application startup the Device Manager is responsible for locating the desired Device Service Object and attaching this to the requesting Device Control Object. Location and/or routing information for the Device Manager reside in a central repository.
To support VDM devices the basic Device Control structure is extended with various properties and methods specific to this device which are described on the following pages.
Base documents: CWA 14923-12:2004
ISO/TS 20684-2:2021
Intelligent transport systems — Roadside modules SNMP data interface — Part 2: Generalized field device basic management
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided into several individual parts.
This part of the ISO 20684 series identifies basic user needs for the management of virtually any field device and traces these needs to interoperable designs. This includes the ability to identify the device, its capabilities, and its status.
NOTE This document is similar to portions of NTCIP 1103 v03 and NTCIP 1201 v03.
ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided into several individual parts.
This part of the ISO 20684 series identifies basic user needs for the management of virtually any field device and traces these needs to interoperable designs. This includes the ability to identify the device, its capabilities, and its status.
NOTE This document is similar to portions of NTCIP 1103 v03 and NTCIP 1201 v03.
ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
ISO/TS 20684-6:2022
Intelligent transport systems — Roadside modules SNMP data interface — Part 6: Commands
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the user needs, requirements and design elements that are used to issue an SNMP set-request in response to a trigger firing. This allows a manager to configure the field device to implement simple responses to conditions in the field.
NOTE 1 There are similarities between certain portions of the Event MIB defined in IETF RFC 2981 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the user needs, requirements and design elements that are used to issue an SNMP set-request in response to a trigger firing. This allows a manager to configure the field device to implement simple responses to conditions in the field.
NOTE 1 There are similarities between certain portions of the Event MIB defined in IETF RFC 2981 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
ISO/TS 20684-3:2022
Intelligent transport systems — Roadside modules SNMP data interface — Part 3: Triggers
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the needs, requirements and design for multiple mechanisms to fire triggers, which result in the device attempting to perform an action. Specific types of actions are defined in other documents and can include sending notifications (ISO/TS 20684-4), entering data into a log for later retrieval (ISO/TS 20684-5), and/or initiating SNMP-based requests (ISO/TS 20684-6).
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the needs, requirements and design for multiple mechanisms to fire triggers, which result in the device attempting to perform an action. Specific types of actions are defined in other documents and can include sending notifications (ISO/TS 20684-4), entering data into a log for later retrieval (ISO/TS 20684-5), and/or initiating SNMP-based requests (ISO/TS 20684-6).
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
ISO/TS 20684-7:2022
Intelligent transport systems — Roadside modules SNMP data interface — Part 7: Support features
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies user needs, requirements and design elements that are normatively used by other parts of the ISO 20684 series. Specifically, it defines an internal field device clock, a mechanism for grouping object values together to provide for more efficient transfer of data, and it provides formal requirements for the SNMP target and target parameters as defined in IETF RFC 3413.
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies user needs, requirements and design elements that are normatively used by other parts of the ISO 20684 series. Specifically, it defines an internal field device clock, a mechanism for grouping object values together to provide for more efficient transfer of data, and it provides formal requirements for the SNMP target and target parameters as defined in IETF RFC 3413.
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
ISO/TS 20684-5:2022
Intelligent transport systems — Roadside modules SNMP data interface — Part 5: Logs
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the user needs, requirements and design elements that are used to record timestamped information in a log for later retrieval. This allows a manager to determine the state of a particular object instance nearly simultaneously when the trigger action occurs without frequent polling.
NOTE 1 There are similarities between certain portions of NTCIP 1103.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the user needs, requirements and design elements that are used to record timestamped information in a log for later retrieval. This allows a manager to determine the state of a particular object instance nearly simultaneously when the trigger action occurs without frequent polling.
NOTE 1 There are similarities between certain portions of NTCIP 1103.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
ISO/TS 20684-4:2022
Intelligent transport systems — Roadside modules SNMP data interface — Part 4: Notifications
Scope: Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the needs, requirements and design for the field device to send notifications to one or more managers. It relies upon the definition of triggers as defined in ISO/TS 20684-3.
NOTE 1 There are similarities between certain portions of NTCIP 1103 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts.
This document specifies the needs, requirements and design for the field device to send notifications to one or more managers. It relies upon the definition of triggers as defined in ISO/TS 20684-3.
NOTE 1 There are similarities between certain portions of NTCIP 1103 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Base documents:
Drafts
prEN ISO/IEC 25029
Artificial intelligence - AI-enhanced nudging (ISO/IEC DIS 25029:2026)
Scope: This standard applies to nudging mechanisms enhanced by AI systems.
This document provides definitions, concepts, and guidelines to address AI-enhanced nudging mechanisms by organisations.
This standard aims to support organisations to deal with AI-enhanced nudging mechanisms in alignment with existing AI standards.
“AI-enhanced nudging mechanisms” are a sub category of digital nudges and which are enhanced by AI systems.
It provides use-cases to illustrate AI-enhanced nudging mechanisms. It provides guidelines and requirements for designing responsible AI-enhanced nudging mechanisms. This includes horizontal processes and key indicators using specific vertical examples.
This document provides definitions, concepts, and guidelines to address AI-enhanced nudging mechanisms by organisations.
This standard aims to support organisations to deal with AI-enhanced nudging mechanisms in alignment with existing AI standards.
“AI-enhanced nudging mechanisms” are a sub category of digital nudges and which are enhanced by AI systems.
It provides use-cases to illustrate AI-enhanced nudging mechanisms. It provides guidelines and requirements for designing responsible AI-enhanced nudging mechanisms. This includes horizontal processes and key indicators using specific vertical examples.
Base documents: ISO/IEC DIS 25029; prEN ISO/IEC 25029
prEN ISO/IEC 42102
Information technology - Artificial intelligence - Framework for characterizing AI system methods and capabilities (ISO/IEC DIS 42102:2026)
Scope: This document provides a framework of descriptors to support the consistent characterization of AI system methods and capabilities. The framework helps AI stakeholders describe AI systems and have a common understanding of them. This document applies to all types of organizations involved in any of the lifecycle stages of AI systems as well as to any AI stakeholder roles
Base documents: ISO/IEC DIS 42102; prEN ISO/IEC 42102
prEN IEC 63203-801-2:2026
Wearable electronic devices and technologies - Part 801-2: Smart body area network (SmartBAN) - Low complexity medium access control (MAC) for SmartBAN
Scope: This document specifies low complexity medium access control (MAC) for SmartBAN.
As the use of wearables and connected body sensor devices grows rapidly in the Internet of Things (IoT), wireless body area networks (BAN) facilitate the sharing of data in smart environments such as smart homes, smart life etc. In specific areas of digital healthcare, wireless connectivity between the edge computing device or hub coordinator and the sensing nodes requires a standardized communication interface and protocols.
The present document describes the following MAC specifications:
– channel structure;
– MAC frame formats;
– MAC functions.
As the use of wearables and connected body sensor devices grows rapidly in the Internet of Things (IoT), wireless body area networks (BAN) facilitate the sharing of data in smart environments such as smart homes, smart life etc. In specific areas of digital healthcare, wireless connectivity between the edge computing device or hub coordinator and the sensing nodes requires a standardized communication interface and protocols.
The present document describes the following MAC specifications:
– channel structure;
– MAC frame formats;
– MAC functions.
Base documents: 124/388/CDV; prEN IEC 63203-801-2:2026
prEN 304 623 V0.1.3
Cyber Security (CYBER);
CRA;
Cybersecurity requirements for boot managers
Scope: The present document specifies technical cybersecurity product requirements and corresponding assessment criteria for boot managers. The products with digital elements in scope, there after "the products":
• are specified within the technical description of the category of product number 8 by the Commission Implementing Regulation (EU) 2025/2392 as:
- "Software products with digital elements that manage the process of initial system startup after power on/restart by initialising hardware, loading or transferring control to the operating system environment or system resources, and selecting boot options. This category includes but is not limited to UEFI firmware, single stage and multi-stage boot loaders."
• are only covered within the product context described in clause 4.
The scope covers software and firmware components that manage the boot process from power-on through establishment of the chain of trust to handoff to the boot target. Products in scope include boot management software and firmware regardless of distribution model or integration level. These are:
• System firmware that performs hardware initialisation and boot management.
• Bootloaders that manage boot target selection, verification, and loading.
• Embedded boot firmware in IoT and embedded devices.
• Network boot implementations enabling remote boot capabilities.
• Boot managers that integrate with hardware security components for chain of trust establishment.
NOTE 1: Boot managers may be single-stage (direct loading) or multi-stage (staged verification).
NOTE 2: For microcontrollers (MCUs) and microprocessors (MPUs):
• Silicon-integrated immutable firmware: Mask ROM, fused code, or boot firmware integrated during chip manufacturing is assessed as part of MCU/MPU hardware under semiconductor standards.
• Updateable boot managers: Boot software in flash storage (including OTP programmed post-manufacture) is assessed using the present document when distinctly identifiable or independently updatable.
NOTE 3: Runtime services executing after boot target handoff (such as secure monitor mode handlers or attestation services) are in scope only if they provide verification or attestation services to the boot process itself, not to the boot target.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I Part I under the conditions identified in Annex A.
• are specified within the technical description of the category of product number 8 by the Commission Implementing Regulation (EU) 2025/2392 as:
- "Software products with digital elements that manage the process of initial system startup after power on/restart by initialising hardware, loading or transferring control to the operating system environment or system resources, and selecting boot options. This category includes but is not limited to UEFI firmware, single stage and multi-stage boot loaders."
• are only covered within the product context described in clause 4.
The scope covers software and firmware components that manage the boot process from power-on through establishment of the chain of trust to handoff to the boot target. Products in scope include boot management software and firmware regardless of distribution model or integration level. These are:
• System firmware that performs hardware initialisation and boot management.
• Bootloaders that manage boot target selection, verification, and loading.
• Embedded boot firmware in IoT and embedded devices.
• Network boot implementations enabling remote boot capabilities.
• Boot managers that integrate with hardware security components for chain of trust establishment.
NOTE 1: Boot managers may be single-stage (direct loading) or multi-stage (staged verification).
NOTE 2: For microcontrollers (MCUs) and microprocessors (MPUs):
• Silicon-integrated immutable firmware: Mask ROM, fused code, or boot firmware integrated during chip manufacturing is assessed as part of MCU/MPU hardware under semiconductor standards.
• Updateable boot managers: Boot software in flash storage (including OTP programmed post-manufacture) is assessed using the present document when distinctly identifiable or independently updatable.
NOTE 3: Runtime services executing after boot target handoff (such as secure monitor mode handlers or attestation services) are in scope only if they provide verification or attestation services to the boot process itself, not to the boot target.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I Part I under the conditions identified in Annex A.
Base documents: Draft ETSI EN 304 623 V0.1.3
prEVS-ISO/IEC/IEEE 12207
Systems and software engineering - Software life cycle processes (ISO/IEC/IEEE 12207:2026, identical)
Scope: This document establishes a common framework for software life cycle processes. Its terminology can be referenced and applied across the software industry. It contains processes, activities and tasks that can be applied during the acquisition of a software system, product, or service and during the supply, development, operation, maintenance, and disposal of software products and services. This is accomplished through the involvement of stakeholders, with the goal of achieving customer satisfaction. This document includes those aspects of system definition needed to provide the context for software systems and services. This document also provides processes that can be employed for defining, controlling, and improving software life cycle processes within an organization or a project.
This document is applicable to one-of-a-kind software systems, software systems for wide commercial or public distribution, and customised, adaptable software systems. Software includes the software portion of firmware. It applies to a complete stand-alone software system and to software systems that are embedded and integrated into larger more complex and complete systems of systems (SoS). The processes, activities, and tasks of this document can also be applied during the acquisition of a system that contains software.
This document applies to the full life cycle of software systems, products, and services, including conception, development, operations, support, and retirement, and to their acquisition and supply, whether performed internally or externally to an organization. The life cycle processes of this document can be applied concurrently, iteratively, and recursively to a software system and incrementally to its elements.
This document can be applied in organizations and software projects using a variety of formal engineering approaches. It is applicable for agile approaches and methods, which are most widely used for software development, sustainment, and maintenance, and which are believed to be more affordable and to deliver usable products more quickly.
This document does not identify or require any specific software life cycle model, development methodology, method, modelling approach, or techniques for selecting a life cycle model for the organization or project and mapping the processes, activities, and tasks in this document into that model. Using engineering judgment to help achieve the desired level of quality is also outside the scope of this document.
This document does not detail information items in terms of name, format, explicit content, and recording media. ISO/IEC/IEEE 15289 identifies the content for life cycle process information items (documentation).
This document is applicable to one-of-a-kind software systems, software systems for wide commercial or public distribution, and customised, adaptable software systems. Software includes the software portion of firmware. It applies to a complete stand-alone software system and to software systems that are embedded and integrated into larger more complex and complete systems of systems (SoS). The processes, activities, and tasks of this document can also be applied during the acquisition of a system that contains software.
This document applies to the full life cycle of software systems, products, and services, including conception, development, operations, support, and retirement, and to their acquisition and supply, whether performed internally or externally to an organization. The life cycle processes of this document can be applied concurrently, iteratively, and recursively to a software system and incrementally to its elements.
This document can be applied in organizations and software projects using a variety of formal engineering approaches. It is applicable for agile approaches and methods, which are most widely used for software development, sustainment, and maintenance, and which are believed to be more affordable and to deliver usable products more quickly.
This document does not identify or require any specific software life cycle model, development methodology, method, modelling approach, or techniques for selecting a life cycle model for the organization or project and mapping the processes, activities, and tasks in this document into that model. Using engineering judgment to help achieve the desired level of quality is also outside the scope of this document.
This document does not detail information items in terms of name, format, explicit content, and recording media. ISO/IEC/IEEE 15289 identifies the content for life cycle process information items (documentation).
Base documents: ISO/IEC/IEEE 12207:2026
prEN 304 618 V0.2.2
Cyber Security (CYBER);
CRA;
Cybersecurity requirements for password managers
Scope: The present document specifies technical requirements and corresponding assessment criteria for password managers related to cybersecurity. The products with digital elements in scope, thereafter "the product":
• are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 as:
"Products with digital elements that store passwords, locally on a device or on a remote server, including activities such as generation of passwords as well as password sharing and integration with local or third-party applications for usage of passwords.
This category includes but is not limited to local password managers, password managers provided as browser extensions, enterprise password managers as well as hardware-based password managers".
• are only covered within the product context described in clause 4.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I Part I under the conditions identified in annex A.
Password Managers: a subset of identity and access management systems. For other types of authentication mechanisms, see the IAM standard prEN 40000-10 currently drafted by CEN TC 224. Consult clause 3.1 for the product definition.
• are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 as:
"Products with digital elements that store passwords, locally on a device or on a remote server, including activities such as generation of passwords as well as password sharing and integration with local or third-party applications for usage of passwords.
This category includes but is not limited to local password managers, password managers provided as browser extensions, enterprise password managers as well as hardware-based password managers".
• are only covered within the product context described in clause 4.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I Part I under the conditions identified in annex A.
Password Managers: a subset of identity and access management systems. For other types of authentication mechanisms, see the IAM standard prEN 40000-10 currently drafted by CEN TC 224. Consult clause 3.1 for the product definition.
Base documents: Draft ETSI EN 304 618 V0.2.2
prEN 304 635 V1.0.1
Cyber Security (CYBER);
CRA;
Cybersecurity requirements for Virtualisation Execution Stack (VES) and Container Execution Stack (CES), including hypervisors and container runtime systems
Scope: The present document specifies technical requirements and corresponding assessment criteria for Virtualisation Execution Stack (VES) and Container Execution Stack (CES) products, including hypervisors and container runtime systems, related to cybersecurity. The products with digital elements in scope, thereafter referred to as the "product":
• are specified within the "technical description" of the "category of product" in Class II, point 1 by the Commission Implementing Regulation (EU) 2025/2392 as:
"Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments";
• are only covered within the product context described in clause 4.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I, Part I under the conditions identified in Annex A.
Commission Implementing Regulation (EU) 2025/2392 identifies hypervisors and container runtime systems as core components. However, actual market products typically include additional elements beyond the hypervisor kernel or container runtime binary. These additional components provide essential management, orchestration, and operational capabilities that are necessary for real-world deployment and are therefore included within the scope of the present document.
The present document addresses the CRA Class II, point 1 product category within the following product contexts:
• Virtualisation Execution Stack (VES) for hypervisor-based environments; and
• Container Execution Stack (CES) for container-based environments.
The corresponding terms and definitions are provided in clause 3. The architectural decomposition, in-scope components, and security-relevant environmental dependencies are specified in clause 4.
Accordingly, the present document defines security requirements not only for the core execution systems identified in the CRA but also for the broader product context in which these systems are deployed, ensuring alignment with market reality and comprehensive coverage of security risks. The Management and Orchestration (M&O) System, Container Engine (CE), and Container Orchestrator (CO) are covered by the present document and are in scope only where they are developed or provided by the manufacturer, or under the responsibility of the manufacturer, as part of the declared product.
Any usage of AI agents is out of scope of the present document.
Where the product includes or depends on components that are outside the scope of the present document, the applicable requirements are to be addressed through the relevant operational-environment provisions or other relevant harmonised standards, as identified in clause 4.3.
• are specified within the "technical description" of the "category of product" in Class II, point 1 by the Commission Implementing Regulation (EU) 2025/2392 as:
"Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments";
• are only covered within the product context described in clause 4.
The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847, Annex I, Part I under the conditions identified in Annex A.
Commission Implementing Regulation (EU) 2025/2392 identifies hypervisors and container runtime systems as core components. However, actual market products typically include additional elements beyond the hypervisor kernel or container runtime binary. These additional components provide essential management, orchestration, and operational capabilities that are necessary for real-world deployment and are therefore included within the scope of the present document.
The present document addresses the CRA Class II, point 1 product category within the following product contexts:
• Virtualisation Execution Stack (VES) for hypervisor-based environments; and
• Container Execution Stack (CES) for container-based environments.
The corresponding terms and definitions are provided in clause 3. The architectural decomposition, in-scope components, and security-relevant environmental dependencies are specified in clause 4.
Accordingly, the present document defines security requirements not only for the core execution systems identified in the CRA but also for the broader product context in which these systems are deployed, ensuring alignment with market reality and comprehensive coverage of security risks. The Management and Orchestration (M&O) System, Container Engine (CE), and Container Orchestrator (CO) are covered by the present document and are in scope only where they are developed or provided by the manufacturer, or under the responsibility of the manufacturer, as part of the declared product.
Any usage of AI agents is out of scope of the present document.
Where the product includes or depends on components that are outside the scope of the present document, the applicable requirements are to be addressed through the relevant operational-environment provisions or other relevant harmonised standards, as identified in clause 4.3.
Base documents: Draft ETSI EN 304 635 V1.0.1