CEN/TC 331
| Projekta Nr. | LVS CEN/TS 16919:2016 |
|---|---|
| Nosaukums | This Technical Specification will be in the series of the Open Standard Interfaces defining manufacturer independent interface definitions where needed. All Sorting equipment of the different manufacturers in a sorting centre produce data which are relevant for service planning, machine and staff planning, optimization of machine utilization and other sorting centre management relevant data. On the other hand the major suppliers for postal IT systems have developed för an example MIS systems for these or more purposes. In sorting centres with mixed machinery and one or more MIS systems, data have to be converted for integration. This standard will allow to define a common interface to avoid these multiple conversions and by this save costs in the postal business. The scope is to develop: An IDT-PAE interface specification should enable interoperability among several systems and processes by providing specifications to the following requirements: a) Data Collection and Transfer: Specification of data transported from the devices to higher level systems There may be more than one permissible protocol referring to different OSI layers. The standard should define where the communication requires polling and where asynchronous messages are used. The basis is messages triggered by events. b) Data Storage and Format: Specification how data is formatted and structured. This concerns the choice between XML, CSV, JSON and other formats including possible binary representations. c) Data Processing Model: Specification of the semantics (meanings) behind the data. This is the most important part and the one of the most important objectives for the specification. This means that conceptual data model and its mapping to the Data Format shall be developed It is important that the specification is not too general or too specific Focus of for the development is: 1) The specificaton should allow interfacing postal processes in order to gather information which shall be prepared for presentation/aggregation to higher-level systems 2) The specification should not favor one vendor over another 3) The specification should not be specific to a programming language, operating system or hardware. 4) The specification should be specific enough, to allow any standards-compliant equipment to be connected to a standards-compliant higher.level systems and get at least basic functionality without any customization. 5) The Data Model should use well-established terms, e.g. taken from the UPU data model, which are suitable to describe postal processes accurately. 6) The Data Model should categorize the information sent and received (e.g. into status, event, control-message) and define standards for each of these categories. 7) The specification should allow for vendor-specific or equipment-specific variations. The scope of these variations should be limited (otherwise we wouldn’t have a standard at all) 8) The specification should provide for future extensions and modifications, such that future versions do not break existing installations. 9) It should be easy to implement an interface which is compliant with this standard. 10) The specification should define how to prevent unauthorized access, preferably be referring to an existing security standard. 11) The specification should use well-established technologies for Data Transport 12) The specification should use established standard for Data Format 13) The sspecification needs to state minimal requirement for data volume and frequency as well as the permissible latency which an implementation need to comply to. |
| Reģistrācijas numurs (WIID) | 41309 |
| Darbības sfēra | This Technical Specification will be in the series of the Open Standard Interfaces defining manufacturer independent interface definitions where needed. All Sorting equipment of the different manufacturers in a sorting centre produce data which are relevant for service planning, machine and staff planning, optimization of machine utilization and other sorting centre management relevant data. On the other hand the major suppliers for postal IT systems have developed för an example MIS systems for these or more purposes. In sorting centres with mixed machinery and one or more MIS systems, data have to be converted for integration. This standard will allow to define a common interface to avoid these multiple conversions and by this save costs in the postal business. The scope is to develop: An IDT-PAE interface specification should enable interoperability among several systems and processes by providing specifications to the following requirements: a) Data Collection and Transfer: Specification of data transported from the devices to higher level systems There may be more than one permissible protocol referring to different OSI layers. The standard should define where the communication requires polling and where asynchronous messages are used. The basis is messages triggered by events. b) Data Storage and Format: Specification how data is formatted and structured. This concerns the choice between XML, CSV, JSON and other formats including possible binary representations. c) Data Processing Model: Specification of the semantics (meanings) behind the data. This is the most important part and the one of the most important objectives for the specification. This means that conceptual data model and its mapping to the Data Format shall be developed It is important that the specification is not too general or too specific Focus of for the development is: 1) The specificaton should allow interfacing postal processes in order to gather information which shall be prepared for presentation/aggregation to higher-level systems 2) The specification should not favor one vendor over another 3) The specification should not be specific to a programming language, operating system or hardware. 4) The specification should be specific enough, to allow any standards-compliant equipment to be connected to a standards-compliant higher.level systems and get at least basic functionality without any customization. 5) The Data Model should use well-established terms, e.g. taken from the UPU data model, which are suitable to describe postal processes accurately. 6) The Data Model should categorize the information sent and received (e.g. into status, event, control-message) and define standards for each of these categories. 7) The specification should allow for vendor-specific or equipment-specific variations. The scope of these variations should be limited (otherwise we wouldn’t have a standard at all) 8) The specification should provide for future extensions and modifications, such that future versions do not break existing installations. 9) It should be easy to implement an interface which is compliant with this standard. 10) The specification should define how to prevent unauthorized access, preferably be referring to an existing security standard. 11) The specification should use well-established technologies for Data Transport 12) The specification should use established standard for Data Format 13) The sspecification needs to state minimal requirement for data volume and frequency as well as the permissible latency which an implementation need to comply to. |
| Statuss | Standarts spēkā |
| ICS grupa | 35.240.99 03.240 35.240.69 |