Guide for Editors
This document provides guidance to the editors of ISO/TC 204 standards by capturing relevant rules and guidelines in a single location. This document may also be of interest to others within the intelligent transport systems (ITS) industry, such as other standards developers and those interested in learning more about ITS standards.
Specifically, this document intends to improve ISO/TC 204 documents by promoting the use of common:
- terminology and relationships among terms;
- documentation that describes the context of standards (e.g., what problem does it solve);
- documentation of details (e.g., rules for presentation of ASN.1); and
- design elements (e.g., encouraging adoption of a common logical data model)
This document attempts to balance competing demands to allow experts to satisfy pressing business needs while also defining processes that will assist in preventing conflicting specifications.
Because this document is primarily intended for ISO/TC 204 editors and other select ITS experts, it is published as an informal wiki page rather than as a full ISO standard. Nonetheless, the wording in the document and the layout is similar to an international standard.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC Directives Part 1 Procedures for the technical work and Consolidated ISO supplement
ISO/IEC Directives Part 2 Principles and rules for the structure and drafting of ISO and IEC documents
ISO House Style ISO House Style
ISO/IEC 5087-3 Information technology — City data model — Part 3: Service level concepts -Transportation planning
ISO 5345 Registry Registry of Intelligent Transport System Items (RITSI)
ISO 14812 Intelligent transport systems — Vocabulary
ISO 14813-1 Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 1: ITS service domains, service groups and services
ISO 14813-5 Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 5: Requirements for architecture description in ITS standards
ISO 14813-6 Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 6: Use of ASN.1
ISO 14817-1 Intelligent transport systems — ITS central data dictionaries — Part 1: Requirements for ITS data definitions
ISO 21217 Intelligent transport systems — Station and communication architecture
ARC-IT Architecture Reference for Cooperative and Intelligent Transportation, located at https://arc-it.net
FRAME European Intelligent Transport Systems (ITS) Framework Architecture, located at https://frame-online.eu
For the purposes of this document, the terms and definitions given in ISO/IEC 24765 and ISO 14812 apply.
This document assumes that the editor is familiar with:
- ITS
- The general rules for writing a requirement statement
- The need to follow a systems engineering process when developing requirements for systems
- The normative references to this document.
Editor's should be aware that there are several standards development organizations (SDOs) involved in standardizing ITS. In some cases, the ISO standards are developed jointly with one or more other SDOs, while in other cases multiple SDOs might work on complementary standards. Complementary standards might be defined in a modular fashion (e.g., an ISO standard defining upper communication layers with lower layers defined by other SDOs) or in a sequential level of detail (e.g., ISO defines globally applicable requirements while regional and national SDOs define more detailed requirements for a particular geographic area. It is important that editors are aware of related activities and coordinate with any appropriate bodies. Some (but certainly not all) of the other SDOs with which ISO TC 204 needs to coordinate include:
- CEN TC 278
- SAE (especially the V2X Communications Steering Committee)
- IEEE (especially their Registration Authority)
Every ISO document should address a real-world need and clearly explains its goal. The scope statement should explain how the reader will be able to derive value from the document. This information is posted online and is the main information that a reader sees when deciding whether to purchase the document. As such, this text should concisely explain the purpose of the document to the extent that it will allow a prospective reader to determine if the document is worth purchasing.
The ISO Directives Part 2 define the ISO requirements for each ISO document. Within ISO/TC 204, it is recommended that the content of international standards and technical specifications also follow a systems engineering process (i.e., provide clearly defined user needs with traceability to the requirements and design elements that satisfy those user needs).
Every ITS standards that addresses an ITS service should clearly identify the service and from where it is derived. In most cases, the ITS service(s) covered by an ISO document should reference one or more of the following resources:
- ISO 14813-1
- ARC-IT
- FRAME
In order to minimize confusion, all ISO documents should be based on a common set of defined terms, as provided in ISO/IEC 24765 and ISO 14812.
Consistently using these definitions reinforce their meaning to users while also minimizing confusion among readers. It also enables the production of consistent ontologies and data models to minimize interoperability among computer applications. Any concerns about the terms contained in ISO 14812 should be brought to the attention of ISO/TC 204 WG 1. Standards may define their own terms to extend this base vocabulary, but if the terms are intended for general usage throughout ITS, they should be submitted for inclusion into ISO 14812.
Any new terms should be defined using a concept model as explained in ISO 704.
It is important to define the user needs addressed by a document and the importance of explaining the purpose of this material to the reader. User needs can be derived from an appropriate combination of the following tools:
- Use Case Template
- Use case diagrams
- User need analysis
Documenting the use case provides important context to the document in a format that can easily be parsed and understood by readers.
Interface standards should provide a reference architecture diagram explaining how the subject standard relates to other standards. For example, if you are defining an application entity standard, the diagram and text should indicate how it might relate to potential facility layer standards, security standards, etc. per the ITS station reference architecture as defined in ISO 21217.
The reference architecture should include the following, as defined in ISO 14813-5, as appropriate:
- Enterprise view
- Functional view
- Physical view
- Communications view
- Trustworthiness view
Using these standard presentation formats promotes better understanding among readers. Most are defined in ARC-IT and have been adopted by TC 204 within ISO 14813-5. While the conventions are derived from ARC-IT, the figures in a standard might vary a bit to show the supset of objects that a particular standard is intended for and to better accommodate international needs.
When possible, ISO documents can provide links to other major reference architectures (e.g., ARC-IT, FRAME)
To promote interoperability across ITS, it is important that data definitions be consistent across applications, to the extent possible. ISO/TC 204 WG 1 is developing the ITS ontology to help promote the reuse of data.
An ontology is intended to be an application-agnostic representation of data. In other words, it focuses on the meaning (i.e., semantics) of data rather than considering how the data might be used in any one application or implemented in software. An ontology provides a theoretical definition, which can become quite complex, whereas an application interface often only needs to convey certain aspects of data with a desire to keeo the interface as simple as possible. This results in three mportant distinctions between ontologies and data models:
- An complete ontology attempts to capture all relationships for a concept while a data model focuses on only information of interest for an application. For example, while an ontology might identify the fact that a field device is owned by an organization and that organization has lots of details (e.g., a name, a date of incorporation, a legal form, etc.). A particular application might not need to know about the owner organization at all, or if it does, it might only be interested in the organization name. The data model is therefore simplified to eliminate unnecessary details (for its particular context).
- An ontology tries to accommodate maximum flexibility across models recognizing that implementations can use different units of measure and different code lists; data models often constrain values to simplify interoperability. For example, an ontology might indicate that vehicle can have a speed, which is represented by a value and a units field. However, a particular application can require that the speed always be represented as kilometers per hour, which can greatly simplify implementation of interoperability.
- Ontologies are conceptual in nature and encourage the use of multiple inheritance to fully capture semantics; by contrast, multiple inheritance can cause problems in software implementations (e.g., due to memory management issues) and are therefore discouraged. Thus, while an ontology might use multiple inheritance, application-specific data models will often simplify the model to remove this type of artifact.
While there are important differences between these models, they each have their purpose and it is important that application-specific models are traced to an over-arching ontology so that the data can more easily be shared across applications without creating hidden complications.
Per Resolution 75 (May 1996):
wherever there is a requirement to elaborate syntax notation in an ISO/TC204 Standard or Technical Report, ASN.1 (ISO 8824…) shall be used
ISO 14813-6 and ISO 14817-1 provide the formal rules for the use of ASN.1 within ITS standards. A copy of thee documents can be obtained by any ISO editor or convenor by contacting the ISO/TC 204 Committee Manager.
Every data element must be described by:
- A Contextual name that identifies:
- Object class characterized by the data element
- Property that the data element represents for the object class
- Representational form
- Definition
- Multiplicity
- Details about the representational form, including:
- Type (in ASN.1)
- Format
- Unit of measure
- Valid value rule
- Constraints
For Example:
| Field | Value |
|---|---|
| Name | Vehicle.length:measure-cm |
| Definition | length of the vehicle as measured from the leading edge of the vehicle to the trailing edge |
| Multiplicity | 1 |
| Type | MeasureType -- i.e., INTEGER |
| Format | N/A |
| Units of Measure | centimeters |
| Valid Value Rule | N/A |
| Constraints | (0..65535) |
MyVehicle ::= SEQUENCE { length VehicleLength-measure-cm, -- INTEGER (0..65535) width VehicleWidth-measure-cm, height VehicleHeight-measure-cm, color VehicleColor-code-vehicle-color, ... }
The ASN.1 structures only need to be defined if the data is uses ASN.1 for transmission. The Structure is encoded as a single element
Data can also be represented in other formats but should always be provided with an ASN.1 definition. When using other formats, attempts should be made to be as consistent as possible with naming formats.
ISO has prepared a variety of documents related to drafting standards.
Our colleagues in TC211 have developed a Good Practices for Standards Development to give accessible and relevant guidance on how to take part in developing standards in ISO/TC 211. But it seems like a great start for TC204 editors!