Informationsteknik, kontorsutrustning

ISO/IEC 18013 establishes guidelines for the design format and data content of an ISO-compliant driving licence (IDL) with regard to human-readable features (ISO/IEC 18013-1), ISO machine-readable technologies (ISO/IEC 18013-2), and access control, authentication and integrity validation (ISO/IEC 18013-3). It creates a common basis for international use and mutual recognition of the IDL without impeding individual countries/states in applying their privacy rules and national/community/regional motor vehicle authorities in taking care of their specific needs.

The purpose of storing IDL data on machine-readable media on the IDL is to:

• increase productivity (of data and IDL use),

• facilitate electronic data exchange, and

• assist in authenticity and integrity validation.

This part of ISO/IEC 18013 thus specifies the following:

• mandatory and optional machine-readable data;

• the logical data structure;

• encoding rules for the machine-readable technologies currently supported.

To prevent unauthorised access to the data contained on a contactless IC (e.g. by eavesdropping), provision is made to protect the privacy of the licence holder via basic access protection [requiring a human-readable and/or machine-readable key/password on the IDL to access the data on the PIC (via protected-channel communication)]. The implementation details of this function however are defined in ISO/IEC 18013-3.

Provision is made for issuing authorities to validate the authenticity and integrity of the mandatory and optional data. In addition, the option of protecting access to optional data (beyond basic access protection) is provided for. The exact mechanism used to achieve such protection (e.g. encryption and/or additional access control) is specified in ISO/IEC 18013-3.

This International Standard specifies a transfer structure, syntax, and coding of messages and data formats when using high-capacity ADC media between trading partners (specifically between suppliers and recipients) and, where applicable, in support of carrier applications, such as bills of lading, and carrier sortation and tracking.

The data encoded according to this International Standard include

— data which may be used in the shipping, receiving and inventory of transport units;

— data which may be contained within supporting documentation, in paper or electronic form, related to unit loads or transport packages;

— data which may be used in the sortation and tracking of transport units.

This International Standard describes the ISO 646 syntax for automatic data capture.

This International Standard is not the controlling specification for data structures (e.g. CII) referenced in this International Standard.

This International Standard does not supersede or replace any applicable safety or regulatory marking or labelling requirements. This International Standard is to be applied in addition to any other mandated labelling requirements.

This multi‐part International Standard defines a set of metadata keys and their meanings for use in PDF files to identify printed products and their component pages, to describe their appearance and characteristics and to guide their production.

The structure of the metadata is intended to encapsulate sufficient information in a PDF file to guide the production of printed products without the creator needing to know the details of the production processes that will be used.

The document part metadata conforming to this International Standard may be used to communicate the intended appearance of print products and their components. Example of intended use are: direct interpretation within a production process, creation of job tickets such as XJDF, or populating records in an MIS. This standard builds on the DPart syntax as specified in ISO 16612-1 (PDF/VT) and ISO 32000-2 (PDF 2.0) which is designed for encoding metadata related to pages or groups of pages in PDF files.

NOTE The document part metadata provided in this International Standard applies to individual document parts, whereas XMP metadata typically applies to the scope of the entire document. XMP can apply to the scope of an individual page or part of a page but this usage is very uncommon. Thus, XMP is not applicable for the case where metadata is required for sets of pages such as multiple recipients or binding information. For example, XMP is used within PDF/X for file conformance identification and is also used for additional file level information such as author.

This part of this International Standard defines a base conformance level that includes the syntax of the metadata framework and the semantics of a core set of metadata.

This part of ISO/IEC 18013 describes the test methods used for conformity testing, that is methods for

determining whether a driving licence can be considered to comply with the requirements of ISO/IEC

18013 for:

• machine readable technologies (ISO/IEC 18013-2), and

• access control, authentication and integrity validation (ISO/IEC 18013-3).

The test methods described in this part of ISO/IEC 18013 are based on specifications defined in ISO/IEC

18013-2 and ISO/IEC 18013-3 and underlying normative specifications.

This part of ISO/IEC 18013 deals with test methods specific to IDL requirements. Test methods

applicable to (smart) cards in general (e.g. those specified in the ISO/IEC 10373 series) are outside the

scope of this part of ISO/IEC 18013.

Hence the purpose of this part of ISO/IEC 18013 is to:

• provide IDL implementers with requirements for conformity evaluation,

• provide IDL issuing authorities with requirements for quality assurance, and

• provide test laboratories and test tool providers with test suite requirements.

The Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled in accordance with the conceptual modelling framework used in the ISO 19100 series of International Standards and including both the spatial and non-spatial properties of geographic features.

This International Standard defines the XML Schema syntax, mechanisms and conventions that:

* provide an open, vendor-neutral framework for the description of geospatial application schemas for the transport and storage of geographic information in XML;

* allow profiles that support proper subsets of GML framework descriptive capabilities;

* support the description of geospatial application schemas for specialized domains and information communities;

* enable the creation and maintenance of linked geographic application schemas and datasets;

* support the storage and transport of application schemas and datasets;

* increase the ability of organizations to share geographic application schemas and the information they describe.

Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport.

NOTE If an ISO 19109 conformant application schema described in UML is used as the basis for the storage andtransportation of geographic information, this International Standard provides normative rules for the mapping of such an application schema to a GML application schema in XML Schema and, as such, to an XML encoding for data with a logical structure in accordance with the ISO 19109 conformant application schema.

This document provides a set of CANopen application profile specifications that describes the CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks.

It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices).

It does not specify CANopen devices.

The CleANopen application profile specifications consist of several parts dealing with the following:

— general definitions;

— functionality of the virtual devices;

— pre-defined PDOs and SDOs;

— application objects.

This document specifies broadcast authentication protocols, which are protocols that provide data integrity and entity authentication in a broadcast setting, i.e. a setting with one sender transmitting messages to many receivers. To provide entity authentication, there should be a pre-existing infrastructure which links the sender to a cryptographic secret. The establishment of such an infrastructure is beyond the scope of this document.

This document specifies MAC algorithms suitable for applications requiring lightweight cryptographic

mechanisms. These mechanisms can be used as data integrity mechanisms to verify that data has not

been altered in an unauthorised manner. They can also be used as message authentication mechanisms

to provide assurance that a message has been originated by an entity in possession of the secret key.

The following MAC algorithms are specified in this document:

a) LightMAC;

b) Tsudik's keymode;

c) Chaskey-12.

Annex A defines the Object Identifiers for the MAC algorithms specified in this document.

This standard defines a generic container format to store a delivered set of documents, including

a means to link otherwise disconnected data. In this context, the term document refers to any

digital resource that provides information about the built or natural environment, including, but

not limited to, any 2D or 3D representation or model, spreadsheet, image or text-based digital

resource.

This standard is suitable for all parties dealing with information concerning the built

environment, where there is a need to exchange multiple documents and their

interrelationships, either as part of the process or as contracted deliverables. The format is

intended to use resources either included in the container (such as documents) or referenced

remotely (such as web resources). A key feature is that the container can include information

about the relationships between the documents. Relevant use-cases reflect the need for

information exchange during the entire life cycle of any built asset and may include, but is not

limited to, the handover of

1. a published bidding package,

2. required project deliverables at a specific project stage,

3. shared information as background or for further development, or

4. published approval packages.

The container format includes a header file and optional link files that define relationships by

including references to the documents, or to elements within them. The header file uniquely

identifies the container and its contractual or collaborative intention. This information is defined

using the RDF and OWL semantic web standards.

The header file, along with any additional RDF/OWL files or resources, forms a suite that may be

directly queried by software. Where it includes link references into the content of documents

that don’t support standardized querying mechanisms, their resolution may depend on third

party interpreters. Alternatively, the link references may be interpreted by the recipient

applications, or reviewed interactively by the recipient.

The format can also be used to deliver multiple versions of the same document with the ability

to convey the known differences or priority between them.

This Part 2 of the ICDD standard adds functionality to the container format specified in Part 1.

Part 1 defines a generic container format to store documents using various formats and

structure and the ability to provide links between documents or between referable subsets of

these documents (documents and datasets are the payload of the container). Building on that

foundation, Part 2 of this standard adds the possibility of adding more semantic (meaningful)

information to the contents of the container, as well as to the links between pieces of

information in the container using Linked Open Data technology.

This standard does not prescribe the structure or format of the documents in the payload.

This standard is suitable for industry sectors such as the built environment, where many

different standards are used, where there is a mixture of digital representations of proposed or

existing built and natural assets (in open or proprietary formats), requiring the use of legacy

systems and the application of different classification systems. This part adds the ability to link,

in a semantic and meaningful way, those islands of data represented using different formats and

structure. This standard is not meant to replace other standards such as ISO 16739 which is

recognized as the standard for describing building objects.

This standard provides two conformance classes. Both conformance classes open the ability to

specialize the container for use cases not otherwise handled.

In Conformance Class A, the container format of Part 1 is expanded with an ontology dynamic

semantics, providing basic support for creating an information model that captures the required

semantics of project, organization or sector standards and agreements. By doing so, it provides

building blocks that make it easier to link different sources of information. This is achieved by

introducing support for typed entities, typed entity properties and typed relationships between

those entities (such as the relationship between an assembly and its parts or between a physical

entity and its associated requirements). There is also support for defining provenance,

versioning and creating libraries.

In Conformance Class B, the user is offered complete freedom to add user defined ontologies to

the container, with the sole condition that it is expressed in RDF/OWL.

The use cases are in line with those of Part 1, but may include numerous extensions. The

following list gives some examples:

1. Make use of asset type libraries describing the required properties per asset type

2. Link to a specific classification system, e.g. CoClass, Uniclass or OmniClass™

3. Add the ability for exchanging systems engineering information

4. Link to product requirement libraries

5. Add semantic links (i.e. meaningful links) to and between information provided using

existing standards like PLCS, IFC and GML

6. Link to an ontology for Units and Measures, like QUDT

7. Link to one or more Product Catalogues

Since this standard capitalizes on Linked Open Data technology, the header file, along with any

additional RDF/OWL files, forms a suite that may be directly queried by software using standard

techniques such as SPARQL.

This document specifies a communication protocol for networked control systems. The protocol provides peer-to-peer communication for networked control using web-services. The document describes services in layer 2 and layer 3.

The layer 2 (data link layer) specification also describes the MAC sub-layer interface to the physical layer. The physical layer provides a choice of transmission media. The layer 3 (network layer), as described in EN 14908-1, is integrated in UDP/IP communication using IPv4 and IPv6 protocols.

ISO 11783 as a whole specifies a serial data network for control and communications on forestry or agricultural

tractors and mounted, semi-mounted, towed or self-propelled implements. Its purpose is to standardize the method

and format of transfer of data between sensor, actuators, control elements, and information-storage and -display

units, whether mounted on, or part of, the tractor or implement. This part of ISO 11783 describes the management

of source addresses (SAs) for control functions (CFs) of electronic control units (ECUs), the association of

addresses with the functional identification of a device and the detection and reporting of network-related errors. It

also specifies procedures for initialization and response to brief power outages, and minimum requirements, for

network-connected ECUs.

This document defines requirements for short-range communication for the purposes of compliance

checking in autonomous electronic fee-collecting systems. Compliance checking communication (CCC)

takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side

mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are

delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules

of the pertinent toll regime.

The operator of the compliance checking interrogator is assumed to be part of the toll charging role as

defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification

of whether the driver has fulfilled his obligations and the checking status and performance of the OBE.

The CCC reads, but does not write, OBE data.

This document is applicable to OBE in an autonomous mode of operation; it is not applicable to

compliance checking in dedicated short-range communication (DSRC)-based charging systems.

It defines data syntax and semantics, but does not define a communication sequence. All the attributes

defined herein are required in any OBE claimed to be compliant with this document, even if some values

are set to “not defined” in cases where certain functionality is not present in an OBE. The interrogator is

free to choose which attributes are read, as well as the sequence in which they are read. In order to

achieve compatibility with existing systems, the communication makes use of the attributes defined in

ISO 14906 wherever useful.

The CCC is suitable for a range of short-range communication media. Specific definitions are given for

the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as

specified in ETSI ES 200 674-1 and ARIB DSRC as alternatives to the CEN-DSRC. The attributes and

functions defined are for compliance checking by means of the DSRC communication services provided

by DSRC layer 7, with the CCC attributes and functions made available to the CCC applications at the

road-side equipment (RSE) and OBE. The attributes and functions are defined on the level of application

data units (ADU).

This document defines requirements for short-range communication for the purposes of compliance

checking in autonomous electronic fee-collecting systems. Compliance checking communication (CCC)

takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side

mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are

delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules

of the pertinent toll regime.

The operator of the compliance checking interrogator is assumed to be part of the toll charging role as

defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification

of whether the driver has fulfilled his obligations and the checking status and performance of the OBE.

The CCC reads, but does not write, OBE data.

This document is applicable to OBE in an autonomous mode of operation; it is not applicable to

compliance checking in dedicated short-range communication (DSRC)-based charging systems.

It defines data syntax and semantics, but does not define a communication sequence. All the attributes

defined herein are required in any OBE claimed to be compliant with this document, even if some values

are set to “not defined” in cases where certain functionality is not present in an OBE. The interrogator is

free to choose which attributes are read, as well as the sequence in which they are read. In order to

achieve compatibility with existing systems, the communication makes use of the attributes defined in

ISO 14906 wherever useful.

The CCC is suitable for a range of short-range communication media. Specific definitions are given for

the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as

specified in ETSI ES 200 674-1 and ARIB DSRC as alternatives to the CEN-DSRC. The attributes and

functions defined are for compliance checking by means of the DSRC communication services provided

by DSRC layer 7, with the CCC attributes and functions made available to the CCC applications at the

road-side equipment (RSE) and OBE. The attributes and functions are defined on the level of application

data units (ADU).

This part of ISO/IEC 19785 specifies the procedures to be followed by the Biometric Registration Authority (RA) in preparing, maintaining, and publishing registers of identifiers for biometric organizations and biometric objects. ISO/IEC JTC 1 shall not interfere with the operations of the RA, which shall be a separately managed entity.

This part of ISO/IEC 19785 specifies and publishes registered CBEFF patron formats defined by the CBEFF

patron ISO/IEC JTC 1/SC 37, and specifies their registered CBEFF patron format types (see ISO/IEC 19785-

1:2015) and resulting full ASN.1 Object Identifiers.

The proposed standard will specify an interface of a BioAPI C++ framework and BioAPI C++ BSP which will

mirror the corresponding components specified in ISO/IEC 30106-1.The semantic equivalence of this

standard will be maintained with ISO/IEC 30106-2 (Java implementation) and ISO/IEC 30106-3 (C#

implementation). In spite of the differences in actual parameters passed between functions, the names and

interface structure are the same.

Purpose

This document defines a Petri net modeling language or technique, called High-level Petri Nets, including its syntax and semantics. It provides a reference definition that can be used both within and between organizations, to ensure a common understanding of the technique and of the specifications written using the technique. This document will also facilitate the development and interoperability of Petri net computer support tools.

This document is Part 1 of a multi-part standard, ISO/IEC 15909. Part 1 describes definitions, semantics, execution, and graphical notations for High-level Petri Nets. A transfer format for the High-level Petri Nets is the subject of Part 2, while Part 3 addresses techniques for enrichments, extensions, and structuring mechanisms.

Business Drivers

Reliable software development requires powerful mathematical models and tools. The usability of Petri nets has been proven for non-trivial industrial applications.

This document is written as a reference for systems analysts, designers, developers, maintainers and procurers, and for Petri net tool designers and developers.

Fields of Application

The standard defined in this document is applicable to a wide variety of concurrent discrete event systems and in particular distributed systems. Generic fields of application include:

— requirements analysis;

— development of specifications, designs and test suites;

— descriptions of existing systems prior to re-engineering;

— modeling business and software processes;

— providing the semantics for concurrent languages;

— simulation of systems to increase confidence;

— formal analysis of the behavior of systems;

— and development of Petri net support tools.

This standard may be applied to the design of a broad range of systems and processes, including aerospace, air traffic control, avionics, banking, biological and chemical processes, business processes, communication protocols, computer hardware architectures, control systems, databases, defense command and control systems, distributed computing, electronic commerce, fault-tolerant systems, games, hospital procedures, information systems, Internet protocols and applications, legal processes, logistics, manufacturing systems, metabolic processes, music, nuclear power systems, operating systems, transport systems (including railway control), security systems, telecommunications, and workflow.

Structure of this document

This document defines High Level Petri Nets showing common concepts for Petri Nets first, and then describing several typical types of Petri Nets, such as Place/Transition Nets, Symmetric Nets, and Petri Nets with Time. Each of the Petri Net types is described with its definition, semantics, and execution.

Their graphical notations are provided in informative Annex B.

More precisely, this document is structured as follows.

Clause 1 describes the scope, the areas of application and the intended audience of this document.

Clause 4 defines conformance levels.

Clause 2 gives references to International Standards that are essential for the correct interpretation of this document.

Clause 3 defines all terms relevant to this document and includes a list of abbreviations and notations.

Clause 5 defines the common formal concepts that are shared by all Petri net types defined in this

document. The common concepts are described with their definition, formal semantics and execution.

Clauses 6, 7, 8, 9 and 10 respectively define the types of Petri nets included in this document: Place/Transition Nets, Symmetric Nets, High-level Petri Nets, Petri Nets with Priorities, and Petri Nets with Time. Each of these types of Petri nets is described with their definition, formal semantics, and execution.

Additionally, Clauses 9 and 10 also describe the models of Petri Nets with Priorities and Petri Nets with Time, respectively.

Normative Annex A develops the main mathematical apparatus required for defining the Petri net types included in this document.

Informative Annex B provides guidelines for the graphical notations of the Petri net types included in this document.

A bibliography concludes this document.

This part of ISO 19150 sets a framework for geographic information service ontology and the description of geographic information Web services in OWL.

The Web Ontology Language (OWL) is the language adopted for ontologies.

This part of ISO 19150 will make use of service metadata (ISO 19115-1) and service definition (ISO 19119) whenever appropriate

This part of ISO 19150 does not define semantics operators, rules for ontologies, and does not develop any application ontology.

In reference to ISO 19101-1:2014, Clause 6.2, this part of ISO 19150 defines and formalizes the following purpose of the ISO geographic information reference model:

* geographic information service components and their behaviour for data processing purposes over the Web, and

* OWL ontologies to cast ISO/TC 211 standards to benefit from and support the Semantic Web.

In reference to ISO 19101-1:2014, Clause 8.3, this part of ISO 19150 addresses the Meta:Service foundation of the ISO geographic information reference model.

This part of ISO/IEC 19823 describes methods for determining conformance to the security crypto suite defined in ISO/IEC 29167-21.

This part of ISO/IEC 19823 contains conformance tests for all mandatory functions.

The conformance parameters are the following:

— parameters that apply directly affecting system functionality and inter-operability

— protocol including commands and replies

— nominal values and tolerances

Unless otherwise specified, the tests in this part of ISO/IEC 19823 are to be applied exclusively to RFID tags and interrogators defined in the ISO/IEC 18000- series using ISO/IEC 29167-21.