Informationsteknik, kontorsutrustning

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 document specifies

* rules and guidelines for defining biometric data interchange formats that are extensible without invalidating previous data structures,

* the meaning of common data elements for use in biometric data interchange formats,

* common data structures for tagged binary data formats based on an extensible specification in ASN.1,

* common data structures for textual data formats based on an XML schema definition, and

* conformance testing concepts and methodologies for testing the syntactic conformance of biometric data blocks.

This Part of the Standard deals with data formats for both Transport and Storage of Genomic Information, with reference conversion process and informative annexes.

This document provides specifications for the normative representation of the following type of genomic data:

 • Genomic sequence reads identifiers which are treated in clause 11.5.15.

 • Genomic sequence reads (both unaligned reads and aligned reads) which are treated in clause 10.

 • Reference sequences which are treated in clause 11.7.3.

 • Quality values which are treated in clause 11.4.2.

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.

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

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-22.

1.1 General

This document provides guidance on the application of an SMS based on ISO/IEC 20000-1. It provides examples and recommendations with examples to enable organizations to interpret and apply ISO/IEC 20000-1, including references to other parts of ISO/IEC 20000 and other relevant standards.

Figure 1 illustrates an SMS with the clause content of ISO/IEC 20000-1. It does not represent a structural hierarchy, sequence, or authority levels. It shows that the guidance for Clause 8, Operation of the SMS, has been split into sub-clauses to reflect the service lifecycle.

The structure of clauses is intended to provide a coherent presentation of requirements, rather than a model for documenting an organization’s policies, objectives, and processes. Each organization can choose how to combine the requirements into processes. The relationship between each organization and its customers, users, and other interested parties influences how the processes are implemented. However, 179 an SMS as designed by an organization cannot exclude any of the requirements specified in ISO/IEC 20000-1.

The term ‘service’ as used in this document refers to the services in the scope of the SMS. The term ‘organization’ as used in this document refers to the organization in the scope of the SMS. The organization manages and delivers services to customers and can also be referred to as a service provider. Any use of the terms ‘service’ or ’organization’ with a different intent is distinguished clearly in this document. It should be noted that the organization in the scope of the SMS can be part of a larger organization, for example an IT department of a large corporation. The term ‘delivered’, as used in this document, can be interpreted as all of the service lifecycle activities that are performed in addition to daily operational activities. Service lifecycle activities include planning, design, transition, and improvement.

1.2 Application

The guidance in this document is generic and is intended to be applicable to any organization applying an SMS, regardless of the organization's type or size, or the nature of the services delivered.

The service provider is accountable for the SMS and therefore cannot ask another party to fulfill the requirements of Clauses 4 and 5 of ISO/IEC 20000-1. For example, the organization cannot ask another party to provide the top management and demonstrate top management commitment or to demonstrate the control of parties involved in the service lifecycle.

Some activities in Clauses 4 and 5 may be performed by another party under the management of the organization. For example, organizations can engage other parties to conduct internal audits on their behalf. Another example is when an organization asks another party to create the initial service management plan. The plan, once created and agreed, is the direct responsibility of and is maintained by the organization. In these examples, the organization is using other parties for specific short-term activities. The organization has accountability, authorities, and responsibilities for the SMS. The organization can therefore demonstrate evidence of fulfilling all of the requirements of Clauses 4 and 5 of ISO/IEC 20000-1.

For clauses 6 – 10 of ISO/IEC 20000-1, an organization can show evidence of meeting all of the requirements itself. Alternatively, an organization can show evidence of retaining accountability for the requirements when other parties are involved in meeting the requirements in Clauses 6 to 10 of ISO/IEC 20000-1. Control of other parties involved in the service lifecycle should be demonstrated by the organization (see 8.2.3). For example, the organization can demonstrate evidence of controls for another party who is providing infrastructure service components or operating the service desk including the incident management process.

The organization cannot demonstrate conformity to the requirements in ISO/IEC 20000-1 if other parties are used to provide or operate all services, service components or processes within the scope of the SMS. However, if other parties provide or operate only some of the services, service components, or processes, the organization can normally demonstrate evidence of meeting the requirements specified in ISO/IEC 20000-1.

The scope of this document excludes the specification of products or tools. However, ISO/IEC 20000-1 and this document can be used to help with the development or acquisition of products or tools that support the operation of an SMS.

1.3 Structure

This document follows the clauses in ISO/IEC 20000-1 and, from clause 4 onwards, provides three sections per clause or sub-clause:

a) Required activities: a summary of the activities required by this clause in ISO/IEC 20000-1—note that this does not replicate the requirement statements in ISO/IEC 20000-1 or add new requirements, but simply describes the activities;

b) Explanation: an explanation of the purpose of the clause and practical guidance on clause contents, including examples and recommendations with examples on how to implement the requirements of ISO/IEC 20000-1;

c) Other information: guidance on roles and responsibilities and on documented information supporting the implementation of an SMS. Further relevant information may also be included.

This document includes guidance on the scope definition and applicability to the requirements specified in ISO/IEC 20000-1.

This document can assist in establishing whether ISO/IEC 20000-1 is applicable to an organization’s circumstances. It illustrates how the scope of an SMS can be defined, irrespective of whether the organization has experience of defining the scope of other management systems.

The guidance in this document can assist an organization in planning and preparing for a conformity assessment against ISO/IEC 20000-1.

Annex A contains examples of possible scope statements for an SMS. The examples given use a series of scenarios for organizations ranging from very simple to very complex supply chains.

This document can be used by personnel responsible for planning the implementation of an SMS, as well as assessors and consultants. It supplements the guidance on the application of an SMS given in ISO/IEC 20000-2.

Requirements for bodies providing audit and certification of an SMS can be found in ISO/IEC 20000-6:2017 which recommends the use of this document.

This document provides specifications for non-invasive attack test tools and provides information about how to operate such tools. The purpose of the test tools are the collection of signals (i.e. side-channel leakage) and their analysis as a non-invasive attack on a cryptographic module Implementation Under Test (IUT).

1.1.1 Scope of 24751

ISO/IEC 24751 is a multi-part standard that defines an AccessForAll framework to enable: 

•Individuals to discover, explore, refine, prioritize and request their personally unique preferences, for a given context, and

•AccessForAll services to satisfy the individual preferences by delivering a match (e.g, finding, assembling, developing, recruiting or using other strategies to deliver products,services, configurations or environments that match the preferences [herein referred to as AfA resources])

AccessForAll is in large part motivated by the goal of addressing currently unmet or poorly met preferences (where the term ‘preferences’ encompasses the range from critical needs to preferences). This goal is in part satisfied by registries, which are open to any individual or organization, to register possible preference concepts (as AccessForAll Preference Concepts), including concepts associated with unanticipated, emerging or new preferences. These registered AccessForAll Preference Concepts might then be used to express individual preferences within a broad diversity of AccessForAll implementing services. An AccessForAll Concept Registry is intended to register possible preference concepts; it is not used for individuals to declare or store personal preferences or personal preference sets (AfA Preference Statement), this is achieved through AccessForAll services that support discovery, exploration, refinement, prioritization and matching of Individual Preference Statements. (An AccessForAll Preference Concept might itself be able to represent a preference or it may require qualification and/or combination with other  preference concepts to form a preference through an AfA Preference Statement).

1.1.2 Future Parts

This International Standard is designed to accommodate developments in technology and implementations and supports the addition of more parts in the future.

1.2 Scope of Part 1 of 24751

Part 1 specifies the basic principles of an AccessForAll approach and the specifications for AccessForAll (AfA) registries.

This part defines:

•a framework and basic principles to support matching of individually unique preferences (that may vary according to the context, including the user goal) to resources that satisfy the preferences.

•specifications for AccessForAll (AfA) registries to register AfA Preference Concepts

In order to make it easier for users and developers to understand and use AfA Preference Concepts, this part supports registration of multiple names and descriptions for a given AfA Preference Concept. It aims to enable users, developers, and others to use their chosen names and descriptions, in their chosen natural language, and yet have them interoperate within many systems.

AccessForAll Preference Concepts will be used by AccessForAll services to:

•enable individuals to create AfA Preference Statements (3.5) or requests, (this includes discovering, exploring, evaluating and refining an understanding of the preferences that work best for them in a given context to achieve a given goal),

•identify resources that match AfA preference concepts (including, but not limited to, through the application of resource metadata)

•match resources to personally declared AfA Preference Statements

This document defines a normalized taxonomy for systems of systems (SoS) to facilitate communications among stakeholders. It also briefly explains what a taxonomy is and how it applies to the SoS to aid in understanding and communication.

This part of ISO/IEC 19757 specifies Schematron, a schema language for XML. This part of ISO/IEC 19757 establishes requirements for Schematron schemas and specifies when an XML document matches the patterns specified by a Schematron schema.

This document gives guidelines for how to process and resolve potential vulnerability information in a product or service.

This document is applicable to vendors involved in handling vulnerabilities.

This document defines multi-point gestures for common system actions used in information and communication technology (ICT) systems. It specifies movements for clear and classified gestures recognized by the systems and applications. The multi-point gestures are performed using an input device (e.g. multi-touch pad, multi-touch screen, etc.) or body parts (e.g. fingertips, hands, etc.). These multi-point gestures are intended to operate in a consistent manner regardless of systems, platforms or applications.

The gestures for common system actions denote system level functions and common functions across applications of ICT systems. The system level functions are executed at a system or a platform level. They include initiation, resume, restart and termination of an application, etc. The common functions across applications are commonly executed among applications of a system or a platform. The functions include navigation of menus, opening an object, closing an object, etc.

NOTE ICT systems include, but are not limited to, digital televisions, set-top boxes, video game consoles, communication devices, internet devices, entertainment devices, and personal computers (PCs).

This document specifies interindustry commands that may be used for security operations. This

document also provides informative directives on how to construct security mechanisms with

ISO/IEC 7816-4 defined commands.

The choice and conditions of use of cryptographic mechanism in security operations may affect card

exportability. The evaluation of the suitability of algorithms and protocols is outside the scope of this

document. It does not cover the internal implementation within the card and/or the outside world.

1.1 General Scope of the Standard

The main objective of the present document is to present the Reference Data Model for Public Transport, based on:

— the Reference Data Model, EN 12896, known as Transmodel V5.1;

— EN 28701:2012, Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this standard (EN 12896— 1:2016 and EN 12896— 2:2016) following their successful publication.

incorporating the requirements of

— EN 15531— 1 to — 3 and TS 15531— 4 and — 5: Service interface for real— time information relating to public transport operations (SIRI);

— TS 16614— 1 and 2: Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.

Particular attention is drawn to the data model structure and methodology:

— the data model is described in a modular form in order to facilitate the understanding and the use of the model;

— the data model is entirely described in UML.

The following functional domains are considered:

— Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places.

— Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type— related vehicle schedules)

— Passenger Information (planned and real— time)

— Fare Management (fare structure, sales, validation, control)

— Operations Monitoring and Control: operating day— related data, vehicle follow— up, control actions

— Driver Management:

— Driver Scheduling (day— type related driver schedules),

— Rostering (ordering of driver duties into sequences according to some chosen methods),

— Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance).

— Management Information and Statistics (including data dedicated to service performance indicators).

The data modules dedicated to cover most functions of the above domains will be specified.

Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".

1.2 Functional Domain Description

The different functional domains (enumerated above) taken into account in the present document, and of which the data have been represented as the reference model, are described in EN 12896-1:2016 "Public Transport Reference Data Model – Part 1: Common Concepts".

1.3 Particular Scope of this Document

The present European Standard entitled "Reference Data Model for Public Transport – Part 4: Operations Monitoring and Control" incorporates the following data packages:

— Dated Production Components MODEL;

— Call MODEL;

— Production Plan MODEL;

— Detecting and Monitoring MODEL;

— Control Action MODEL;

— Event and Incident MODEL;

— Messaging MODEL;

— Situation MODEL; and

— Facility Monitoring and Availability MODEL.

The data structures represented in this part form descriptions of data that are specific to operations for an operational day (as opposed to those planned for day types). They reference to structures as described in EN 12896-1:2016, such as version frames or generic grouping mechanisms, but also to EN 12896-2:2016 and EN 12896-3:2016.

This document itself is composed of the following parts:

— Main document (normative) presenting the data model for the domain Operations Monitoring and Control;

— Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions;

— Annex B (normative), providing a complement to EN 12896-1:2016, particularly useful for parts 4 to 8 of the Public Transport Reference Data Model;

— Annex C (informative), indicating the data model evolutions; and

— Annex D (informative), providing a mapping between the Situation Publication model of DATEX II (CEN/TS 16157, Situation Publication Data Model 2.2, 2013), SIRI Situation Exchange (CEN/TS 15531-5:2016) and SIRI Facility Monitoring (CEN/TS 15531-4:2011).