ISO 14813-5:2010

Intelligent transport systems - Reference model architecture(s) for the ITS sector - Part 5: Requirements for architecture description in ITS standards

ISO 14813-5:2010 gives requirements for the description and documentation of the architecture of intelligent transport systems (ITS) in standards dealing with ITS. It also gives the definitions of terms to be used when documenting or referencing aspects of architecture description in those standards.

Systèmes intelligents de transport (ITS) — Architecture(s) de modèle de référence pour le secteur ITS — Partie 5: Exigences pour la description d'architecture dans les normes ITS

General Information

• Status: Withdrawn
• Publication Date: 28-Jun-2010
• Withdrawal Date: 28-Jun-2010
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 1 - Architecture
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 27-Jan-2020
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 14813-5:2020 - Intelligent transport systems - Reference model architecture(s) for the ITS sector - Part 5: Requirements for architecture description in ITS standards
• Effective Date: 13-May-2017
• Revises: ISO/TR 14813-5:1999 - Transport information and control systems - Reference model architecture(s) for the TICS sector - Part 5: Requirements for architecture description in TICS standards
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14813-5
First edition
2010-07-01
Intelligent transport systems —
Reference model architecture(s) for the
ITS sector —
Part 5:
Requirements for architecture description
in ITS standards
Systèmes intelligents de transport (ITS) — Architecture(s) de modèle de
référence pour le secteur ITS —
Partie 5: Exigences pour la description d'architecture dans les normes
ITS
Reference number
©
ISO 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Conformance .1
3 Normative references.1
4 Terms and definitions .2
5 Requirements.2
5.1 General requirements .2
5.1.1 Architecture description.2
5.1.2 Service description .2
5.1.3 Architecture description elements .2
5.2 Further guidance .3
5.3 ITS architecture elements.3
5.3.1 General requirements .3
5.3.2 Conceptual architecture .4
5.3.3 Logical architecture .5
5.3.4 Physical architecture (optional).5
5.3.5 Communications architecture (optional) .5
5.3.6 Organisational architecture (optional) .5
5.4 Object-oriented architecture .5
5.4.1 General .5
5.4.2 Specific requirements for object-oriented description .6
5.4.3 Relationship to ITS service domains, service groups and services.6
5.4.4 Control behaviour.6
5.4.5 Multiple viewpoints .6
5.5 Process-oriented architecture .6
5.5.1 General .6
5.5.2 Specific requirements for process-oriented methodology description .6
5.6 Application architecture/deployment (implementation) design .8
5.7 Layout of architecture description in ITS standards and other deliverables.8
5.7.1 Description method.8
5.7.2 Usage of terms.8
5.7.3 Plain language .9
5.7.4 Deployment design .9
5.7.5 Use of annexes .9
5.7.6 Relationships with other standards .9
Annex A (informative) Standards for specific architecture methodologies .10
Annex B (normative) Glossary of ITS architecture terms, abbreviated terms and numeric notation.11
Bibliography.30

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 14813-5 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition of ISO 14813-5 cancels and replaces ISO/TR 14813-5:1999, of which it constitutes a
technical revision.
ISO 14813 consists of the following parts, under the general title Intelligent transport systems — Reference
model architecture(s) for the ITS sector :
⎯ Part 1: ITS service domains, service groups and services
⎯ Part 2: Core TICS reference architecture [Technical Report]
⎯ Part 3: Example elaboration [Technical Report]
⎯ Part 4: Reference model tutorial [Technical Report]
⎯ Part 5: Requirements for architecture description in ITS standards
⎯ Part 6: Data presentation in ASN.1

iv © ISO 2010 – All rights reserved

Introduction
1)
“Architecture” can be defined as “Design; the way components fit together ” . Architecture is implicit in any
construction, be it of a physical entity (such as a building), an operational entity (such as a company or
organisation), a system entity (such as a software system) or a business entity (such as a commercial
business operation).
While it may be stated that every entity has an architecture, the particular architecture may be an explicit
construction as a result of a deliberate design process or the implicit result of an unplanned series of events,
or sometimes the combination of both.
In physical construction, it is generally recognised that a deliberate design process will produce a better and
more efficient building that one where a group of individuals have collected whatever materials happened to
be nearby in order to create a shelter.
Intelligent transport systems (ITS) are systems deployed in transportation environments to improve both the
driving experience and the safety and security of drivers, passengers and pedestrians. ITS can also assist in
the labour, energy, environmental and cost efficiency of transportation systems. It is a feature of most ITS that
their architecture involves the collection, use and exchange of information/data within and between software
systems which affect or control the behaviour of physical equipment, providing a service to the actors involved
in, or interacting with, the transport sector.
In order to maximise the efficiency of co-existing ITS, to obtain compatibility and/or interoperability and to
eliminate contention, the systems need to co-exist and operate within a known and supportive architectural
framework.
The ITS sector is still emerging and developing and is still close to the start of its evolution and application.
The technology is developing and changing rapidly and ITS services have generally to make provision not
only for its interaction with other services, but with migration from one technology generation to later iterations.
This part of ISO 14813 is designed to ensure that, in order to obtain maximum interoperability, efficiency and
migration capability, architecture is an explicit process in the development of, and specifications defined within,
ITS standards.
“Architecture” is used in an informal manner to mean a variety of different concepts and, in formal architecture
design, there are differing methodologies and opinions as to their suitability for use in ITS system and
standards design. This has limited effective communication in the ITS sector by causing uncertainty as to the
meaning of the word when it is used in one context or another. A second function of this part of ISO 14813 is
to provide consistent terminology to be used in describing architectural aspects of ITS standards and provide
a consistent form for ITS architecture description in standards in the ITS sector.
An ITS architecture is a framework for ITS deployments. It is a high-level description of the major elements
and the interconnections among them. It provides the framework around which the interfaces, specifications
and detailed ITS designs can be defined. An ITS architecture is not a product design or a detailed
specification for physical deployment and is not specific to any one location. “Systems architecture” is perhaps
the closest general term, but this is sometimes too specific to include the conceptual aspects included in the
term “ITS Architecture” and often also implies a location-specific solution. The purpose of an ITS architecture
is to maximise efficiency, interoperability and multimodality of multiple interacting ITS in a complex and
developing sector.
1) Interoperability Clearinghouse Glossary of Terms, http://www.ichnet.org/glossary.htm)
This part of ISO 14813 does not give preference to any one methodology for architecture development and
description. It requires only that the consideration of architecture be an explicit process that takes into account
the interrelationships and interoperability of ITS, and that an architecture description be provided within ITS
standards.
This part of ISO 14813 requires that the architecture aspects of ITS standards be described explicitly in each
and every ITS standard, and that all such standards be related to the (one or more) ITS service domains,
service groups and services set out in ISO 14813-1 that they are designed to enable or support.

vi © ISO 2010 – All rights reserved

INTERNATIONAL STANDARD ISO 14813-5:2010(E)

Intelligent transport systems — Reference model architecture(s)
for the ITS sector —
Part 5:
Requirements for architecture description in ITS standards
1 Scope
This part of ISO 14813 gives requirements for the description and documentation of the architecture of
intelligent transport systems (ITS) in standards dealing with ITS. It also defines the terms to be used when
documenting or referencing aspects of architecture description in those standards (see Annex B).
Although the use of contemporary systems engineering practices is assumed by this part of ISO 14813, it
does not define such practices.
NOTE Guidance on the use of the unified modelling language (UML) in ITS architectures can be found in
ISO/TR 17452 and ISO/TR 24529. Guidance on the use of the process-orientated methodology in ITS architectures can
be found in ISO/TR 26999.
2 Conformance
There are no specific conformance tests specified within or associated with this part of ISO 14183.
Developers of standards claiming conformance with this part of ISO 14183 are, however, required to describe
the architecture of their system in their deliverables, or to make reference to other standards or publicly
available documents that provide such description. The level of detail or the methodology used for such
description is not specified and is left to the discretion of the standards developers.
Implementers of ITS cannot, of course, be required to make such provision, but are advised to do so in their
plans and tender documents. This part of ISO 14813 is therefore also designed as a consistent reference for
ITS system designers.
3 Normative references
The following referenced documents are indispensable for the application 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.
2)
ISO/IEC 8824 (all parts), Information technology — Abstract Syntax Notation One (ASN.1)
2)
ISO/IEC 8825 (all parts), Information technology — ASN.1 encoding rules

2) ASN.1 standards are divided into the abstract syntax notation one (ASN.1) specifications and the ASN.1 encoding
rules. ISO/IEC 8824-1 to ISO/IEC 8824-4 and ISO/IEC 8825-1 to ISO/IEC 8825-4 correspond to ITU-T Recommendations
X.680, X.681, X.682 and X.683, and X.690, X.691, X.692 and X.693, respectively. See http://www.itu.int/ITU-
T/studygroups/com17/languages/.
ISO/IEC 9834-1, Information technology — Open Systems Interconnection — Procedures for the operation of
OSI Registration Authorities: General procedures and top arcs of the International Object Identifier tree —
Part 1
ISO 14813-1, Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 1:
ITS service domains, service groups and services
ISO/TR 14813-6, Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 6:
Data presentation in ASN.1
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
4 Terms and definitions
For the purposes of this document, the terms and definitions given in Annex B and the following apply.
4.1
ITS architecture
non-specific system design for a family of functionally different intelligent transport systems (ITS),
interconnected to operate in consort and harmony
NOTE 1 An ITS architecture can be described from different viewpoints, and from multiple viewpoints by conceptual,
logical and/or physical representations.
NOTE 2 An ITS architecture is not specific to any single location.
5 Requirements
5.1 General requirements
5.1.1 Architecture description
All ITS standards shall provide an architecture description, by inclusion in the standard or by reference to
other relevant standards. The architecture description shall include information detailing the vision and
mission to be achieved by applying the standard, together with a description of the architectural aspects of the
standard, detailed in one of the forms specified in this part of ISO 14813. Such information may appear in
either the scope or requirements clauses, as considered appropriate by the authors.
5.1.2 Service description
All architecture descriptions shall either start with, or be clearly related to, one or more of the ITS service
domains, service groups and services in accordance with ISO 14813-1.
5.1.3 Architecture description elements
It is important that all ITS standards be able to be compared for inter-relationships and, consequently, this part
of ISO 14813 needs to be applied to the architecture description elements of all ITS standards.
2 © ISO 2010 – All rights reserved

The requirements for architecture description elements are as follows.
a) Architecture scope
The scope of the architecture shall be described by reference to the ITS service domains, service groups
and services defined in ISO 14813-1.
In implementing an application based on an ITS standard, implementers will normally also need to ensure
that they are designing consistently with their organisation's enterprise architecture. Enterprise
architectures do not normally form part of ITS standards.
b) ITS system descriptions/definition
Where schematics are included, they shall either be simply understood high-level use-case diagrams or
shall be expressed in the form of process or object models.
c) Protocol descriptions/definition
In most cases, protocol descriptions will not be required in an architecture standard. If protocol
descriptions are required, they shall be written in a widely accepted and standardised formal description
language (e.g. SDL, XML, ASN.1).
d) Data description/definition
Data concepts, where defined, and as required by ISO 14813-6, shall be described using ASN.1 in
accordance with ISO 14813-6, ISO\IEC 8824 and, where appropriate, ISO\IEC 8825.
This requirement is aimed at maximising interoperability and reuse of data. Actual data may be defined
and applied using other formats, such as SDL or XML, but shall be described as an SDL, XML module
within a formal ASN.1 data definition. ISO 14813-6 provides examples of how to achieve this.
There is no requirement that architecture description be elaborated in levels of detail that require data
definition, and indeed this will not normally be done. However, where data definition is made, it shall be
done in a way that it is consistent with the requirements of ISO 14813-6.
Where a sector already uses an existing standard notation (e.g. EDIFACT, X12), such use is permissible so
long as the message content, structure and transaction elements are clearly and separably defined. Usually,
this will be by reference to another standard (e.g. EDIFACT Board standard). Where attribute limitations
(e.g. range of numerical values) are appropriate within the ITS standard — such as where a time/size limited
air interface transaction is involved — such attribute limitations shall be specified.
5.2 Further guidance
Further guidance and assistance in the description and elaboration of systems architecture is to be found in
the other parts of ISO 14813, as well as in ISO/TR 17452, ISO 19501, ISO/TR 24529, ISO 24531 and
ISO/TR 26999 (see the Bibliography).
5.3 ITS architecture elements
5.3.1 General requirements
Systems architecture identifies the major actors, use cases, interfaces and components and provides a basis
for understanding all their inter-relationships and interactions.
All ITS standards shall provide a description of the aspects of their architecture, either by process-oriented or
object-oriented analysis, with the depth of such description varying according to the relevance to the
deliverable. Where a limited standard (e.g. one determining protocols alone) is prepared, a simple statement
determining its relevance in the overall architecture shall suffice.
As the name implies, an object-oriented architecture starts with the objects or entities that are involved in the
system, characterises them and defines their relationships with other objects, entities, actors or exit interfaces,
etc. A process-oriented methodology, conversely, starts with the processes and works towards the
object/entities/actors/exit interfaces. Both approaches have their advantages and disadvantages and it is not
within the remit of this part of ISO 14813 to require or prefer either.
There are some aspects and viewpoints that should, however, be considered regardless of the methodology,
and at least a summary explanation of these aspects should be given in the architecture portion of any ITS
standard. The documentation for each of these architecture aspects is specified below.
Architectures can, and should, be viewed from different perspectives according to the views of those parties
(both human and machine) likely to be involved. An ITS architecture shall consider the following architecture
aspects:
a) conceptual (or reference) architecture, starting from, and related to, one or more specific ITS service
domains, service groups and services (see ISO 14813-1);
b) logical (sometimes called “functional”) architecture;
c) physical architecture;
d) communications architecture;
e) organisational architecture.
This part of ISO 14813 recognises that in general practice there could be several other viewpoints needed to
fully comprehend an architectural model, and this option is available to those providing architecture
description in ITS standards. What matters most is that the composite description satisfies all user and
interface requirements, all non-functional requirements and that it provides a rigorous basis not only for the
initial design, but also for the ongoing development of the system as it evolves and interacts in new ways with
its environment.
Architectures may be described and defined in many different ways. Differing descriptive formats and
notations may be used in these descriptions, but the notation that is being adopted most rapidly and widely is
the unified modelling language (UML) (see ISO/IEC 19501). However, many forms of process-oriented
methodology have been in use for a long period of time and are well-known and understood by many users.
This part of ISO 14813 strongly recommends, but does not require, that architecture descriptions use
overview use-case diagrams/descriptions, with pictorial elaboration, rather than system-modelling software, to
explain the context of the standard at an early stage of the architecture description in order to enable
non-architecture experts to understand the scope and context of the architecture description.
The depth at which architecture considerations need to be defined in a standard, or indeed in a specification
or terms of reference (TOR), will vary from a simple statement of one or two paragraphs or a figure or table, to
a fully detailed specification that can be used as the basis for detailed software development. This part of
ISO 14813 leaves the depth of coverage to the judgement of the standard, system or TOR developer;
however, the following subclauses detail the perspectives where some description is required in an ITS
standard.
5.3.2 Conceptual architecture
5.3.2.1 The clause or section of the ITS standard on conceptual architecture shall provide an overall
operational description of an ITS system, incorporating operational concepts and user requirements, together
with its known inter-relationships with other systems. The description of the conceptual architecture shall
always use one or more of the ITS service domains, service groups and services as its starting point; or its
scope shall be related clearly to assisting the fulfilment of one or more specified ITS service domains, service
groups and services.
4 © ISO 2010 – All rights reserved

5.3.2.2 The overview shall be described by means of a vision/mission statement describing the objective
result of applying the standard. The method by which they are to be achieved shall be explained.
5.3.2.3 This shall be accompanied by a simple use-case diagram/description, hierarchy chart or network
diagram (e.g. reference model) and/or an overview description dealing with the overall system concepts and
relationships and reference points only and, where appropriate, summarising the business case.
5.3.3 Logical architecture
A clause or section shall describe the nature of the system based on the information, control or functions and
shall describe the interrelations of these aspects; the logical architecture is independent of any hardware
focus or software.
A logical architecture can be described either from an object- or process-oriented perspective. Either
methodology may be used at the discretion of the working group preparing the standard.
5.3.4 Physical architecture (optional)
Following the explanation of the logical architecture, this description, where provided, shall allocate, in generic
terms, the logical architecture to physical entities (but not in relation to the deployment of equipment).
NOTE A physical architecture, while it describes physical configurations in system terms, is not specific to any
particular location.
5.3.5 Communications architecture (optional)
Communications architecture, where provided, shall offer a high-level description of the media and medium
standards and protocols used to support and communicate through the system.
5.3.6 Organisational architecture (optional)
Organisational architecture, where provided, shall identify how the organisation's(s') specific requirements are
to be met. The development process shall include recognition of dependencies and boundaries for functions.
5.4 Object-oriented architecture
5.4.1 General
This clause or section in an ITS standard is relevant where object-oriented architecture description/system
design is employed.
UML is being used increasingly worldwide to describe the static and dynamic logical design and behaviour of
complex systems because of its de facto universality in describing software intensive systems in a manner
that is understandable across cultures, companies and customs.
UML provides for user requirements, when encapsulated in use cases, to be related to other requirements in
other use cases and also to other UML artefacts [when suitable computer-aided software engineering (CASE)
tools are employed]. However, it is not necessary that use cases be expressed in UML in order for them to be
meaningful and unambiguous (this is discussed in greater detail in ISO/TR 24529 and ISO/TR 17452).
UML is also useful in documenting data models as described in ISO 14817.
All architecture description is heavily dependent on the concept of abstraction. In object-oriented architecture
definition, the use of abstraction is particularly important as an approach to design at every level, but
especially at the architectural design level.
5.4.2 Specific requirements for object-oriented description
If an object-oriented approach is used to describe the logical architecture, it shall provide an integrated
description working from the identified classes, their attributes, methods and messages and associations. In
order to achieve consistency of approach and enable cross-referencing between deliverables, the object
analysis symbols used shall be from the UML, as specified in ISO/IEC 19501, and shall, as far as practicable,
use the UML “views” of the model that are deemed appropriate. There is, however, no requirement that UML
views always be used.
5.4.3 Relationship to ITS service domains, service groups and services
In an object-oriented analysis of the architectural aspects of an ITS standard, the highest-level (abstract)
“classes” described shall always be related to the provision of one or more specified ITS service domains,
service groups and services, as defined in ISO 14813-1.
5.4.4 Control behaviour
Control behaviour describes changes of ITS architecture elements from one state to another.
5.4.5 Multiple viewpoints
The need for multiple viewpoints in architecture models has been widely recognised and an object-oriented
architecture shall describe multiple views. The appropriateness of particular viewpoints is left to the discretion
of the developer of the deliverable.
5.5 Process-oriented architecture
5.5.1 General
A process-oriented (functional) decomposition of the logical architecture is represented by functional, control
and information architectures. If a process-oriented approach is used, the requirements defined in 5.5.2 shall
be provided.
There are three basic types of process-oriented methodology for ITS architecture:
a) framework;
b) defined;
c) specific.
The principal differences between these approaches depends on
⎯ the viewpoints created,
⎯ the “outputs” produced, and
⎯ how these viewpoints and outputs are used.
5.5.2 Specific requirements for process-oriented methodology description
5.5.2.1 Context
The following clauses or sections are relevant where process-oriented architecture is employed.
6 © ISO 2010 – All rights reserved

5.5.2.2 Framework ITS architecture
A framework ITS architecture provides the most general and flexible approach and shows the functionality
needed for a set of stakeholder aspirations.
A framework ITS architecture shall comprise identification of stakeholder needs and a functional viewpoint.
It may, at the discretion of the developers of the deliverable, also include guidance documents for creation of
other outputs.
A framework architecture shall provide a high-level defined ITS architecture which provides a description of
the way in which ITS is to be deployed and shall describe at least the following:
⎯ stakeholder needs;
⎯ functional viewpoint;
⎯ physical viewpoint;
⎯ communications viewpoint.
A framework architecture should strive to enable close control of outputs, particularly physical and
communications viewpoint contents. Several defined architectures can usually be created from one framework
architecture.
The use of architecture tools is not required in order to develop a framework architecture; however, the
complexity and interdependencies of most ITS mean that it is usually highly desirable and often a necessity.
A framework architecture shall be unambiguous: clear and with only one possible reasonable interpretation.
A framework architecture shall be technology-independent and shall identify the data that flows between the
functions and the “things” that interact with the identified functions.
5.5.2.3 Context diagram
A context diagram shall be provided to show the relationship between a system and those parts (called
“terminators”) of its environment with which it interacts. The context diagram shall identify the system
boundary using terminators. A terminator can be a person, an organisation or another system and shall have
a description and identify what is expected of it as a terminator.
5.5.2.4 Data flow diagrams
Data flow diagrams shall be provided and shall comprise
⎯ functions, which “do” things within the system to fulfil user needs,
⎯ data stores, which contain data that is used by one or more functions,
⎯ data flows, which identify the transfer of data between functions, between data stores and functions, and
which transfer data between functions and terminators, and
⎯ trigger data flows, which are sent by one function to activate another function.
5.5.2.5 Functional decomposition
Functional decomposition shall be provided. The functional areas for decomposition shall be related and
referenced to the ITS service domains, service groups and services (see ISO 14813-1). Functions can only
exist in one location and will show the resulting data flows.
Each function that comprises lower-level functions has its own data flow diagram (DFD). This shall also
provide a description of the functions which gives a summary of what the function does and links to diagrams
containing that function, and shall identify data flows, which shall be named, entering and leaving the function
and a list of user needs that the function is designed to satisfy. Terminators shall be named and the top-level
terminator data flows identified.
NOTE Physical data flows typically comprise the functional data flows that pass data from
⎯ subsystem to subsystem,
⎯ module to module,
⎯ module to subsystem,
⎯ subsystem to terminator,
⎯ module to terminator.
Where appropriate, diagrams shall be used to support descriptions.
5.5.2.6 Communications viewpoint
An analysis of the physical data flows shall be provided to identify the characteristics of the physical links that
will carry the data.
EXAMPLE Types of data to be transferred, physical mode of data transfer, security requirements, data transfer
capacity required.
5.6 Application architecture/deployment (implementation) design
The specific design for a deployment describes the actual equipment deployment, in one or more specific
locations, designed to achieve the application architectures. The deployment architecture is not considered
appropriate for standardisation and shall not be included in an ITS standard. Where considered useful to
assist understanding of the deliverable, an informative annex may show an example of a deployment design
that uses the architecture defined in the deliverable.
5.7 Layout of architecture description in ITS standards and other deliverables
5.7.1 Description method
So long as the definition and description requirements are met in explicit clauses of ITS deliverables, their
authors shall have the freedom to describe the aspects of their system's architecture in the manner that best
describes their architecture to the lay person.
5.7.2 Usage of terms
The usage in ITS deliverables of the terms given in Annex B is not a requirement of this part of ISO 14813.
However, when those terms are used, the definition of the terms shall be in accordance with Annex B. In order
to avoid confusion, an architecture description given in an ITS deliverable shall not use standardised
terminology in any way other than as defined in this part of ISO 14813.
Other terms and their definitions may also be used in an architecture definition; however, where used, they
shall be defined in the standard and shall be explicit; alternatively, reference to a public source of the term and
definition shall be provided.
8 © ISO 2010 – All rights reserved

5.7.3 Plain language
The deliverable describing architecture shall otherwise use plain language for architecture description and
shall, as far as possible, avoid the use of jargon.
5.7.4 Deployment design
Deployment (implementation) design shall not form a part of the architecture description, nor indeed any part
of the normative clause of a standard for the ITS sector. Where the inclusion of an example of an
implementation design is considered to assist understanding of the architecture description in an ITS standard,
it shall be given in an informative annex and it shall be clearly stated that the annex provides only an
informative example. There shall be no inference, either directly or indirectly, that the example is normative or
offers a preferred deployment.
5.7.5 Use of annexes
Where it is considered appropriate by the authors of an ITS standard, and where it is considered essential in
order to provide interoperability, technical solutions (but not location-specific deployment designs) may be
provided as informative annexes to the standard. In such cases, the main body of the standard shall clearly
determine and define all normative requirements to be met and any informative annex shall simply provide
example solutions on how to meet these requirements.
NOTE There is always an opportunity for additional informative annexes to be added at revision of a standard.
5.7.6 Relationships with other standards
Where known and appropriate, other relationships and inter-relationships with other known existing or planned
ITS standards shall be described at the appropriate place in the architecture description of an ITS standard;
nevertheless, such references shall not place or imply any limitations whatsoever on the scope or use of other
standards.
Annex A
(informative)
Standards for specific architecture methodologies
This part of ISO 14813 provides requirements and guidance at a non-technique-specific level. For guidance
on specific architecture methodology in an ITS context the reader is referred to
⎯ ISO/TR 24529,
⎯ ISO/TR 17452, and
⎯ ISO/TR 26999.
See References [13], [11] and [16].
10 © ISO 2010 – All rights reserved

Annex B
(normative)
Glossary of ITS architecture terms,
abbreviated terms and numeric notation
The usage in an ITS standard of the actual terms, abbreviated terms and numeric notation that are defined in
this annex is not a requirement of this part of ISO 14813; nor are all of the terms defined herein. However,
where used, their definitions shall be those given in this annex.
Other terms may also be used, but their definitions shall be provided in the standard in which they are used
and shall be explicit; alternatively, reference to a public source of the term and definition shall be provided.
B.1 Terms and definitions
B.1.1
abstraction
essential characteristics of an entity that distinguish it from all other kinds of entities
NOTE 1 Adapted from ISO/IEC 19501.
NOTE 2 An abstraction defines a boundary relative to the perspective of the viewer.
NOTE 3 Abstraction is perhaps the most powerful tool available to a software engineer. Abstraction aims at reducing
detail, making the thing that has been subjected to abstraction simpler to handle. Abstractions usually build on lower-level
abstractions, leading to a layered, hierarchical design. (Szyperski, 1998)
B.1.2
action
specification of an executable statement that implements a procedure
[ISO/IEC 19501:2005]
B.1.3
action sequence
series of actions in a predetermined sequence
B.1.4
activation
execution of an action
[ISO/IEC 19501:2005]
B.1.5
actor
coherent set of roles that users play when interacting within use cases
B.1.6
aggregate class
class that can be divided into subclasses
B.1.7
aggregation
special form of association that specifies a whole-part relationship between the aggregate (whole) and a
component part
[ISO/IEC 19501:2005]
B.1.8
analysis
part of the software development process whose primary purpose is to formulate a model of a domain
[ISO/IEC 19501:2005]
NOTE Analysis focuses on what to do, design focuses on how to do it. Contrast: design (B.1.47).
B.1.9
application architecture
set of functions combined to form a high-level system design
B.1.10
architecture
organisational structure and associated behaviour of a system
[ISO/IEC 19501:2005]
NOTE An architecture can be recursively decomposed into parts that interact through interfaces, relationships that
connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components
and subsystems.
B.1.11
architecture element
definable element of a system, which forms part of a component or system but which does not necessarily
have independent operational functionality
B.1.12
artefact
physical piece of information that is used in or produced by a software development process
NOTE An artefact may constitute the implementation of a deployable component.
[ISO/IEC 19501:2005]
B.1.13
ASN.1
abstract syntax notation one
[ISO/IEC 8824-1:2002]
B.1.14
ASN.1 type
data type (or type for short) that represents in a formalised way a class of information (e.g. numerical, textual,
still image or video information)
[ISO/IEC 8824-1:2002]
B.1.15
associated ASN.1 type
ASN.1 type which is used to represent a non-ASN.1 type in an ASN.1 module
[ISO/IEC 8824-1:2002]
12 © ISO 2010 – All rights reserved

B.1.16
association
semantic relationship between two or more classifiers that specifies connections among their instances
[ISO/IEC 19501:2005]
B.1.17
attribute
abstraction of properties and values belonging to, or characteristic of, an entity
B.1.18
basic encoding rules
BER
standardised determination of data encoding conforming to ASN.1, as defined ISO/IEC 8825, in accordance
with ISO/IEC 8824
NOTE Alternative forms of encoding include the packed encoding rules (PER).
B.1.19
behaviour
observable effects of an operation or event, including its results
B.1.20
binary association
association between two classes
[ISO/IEC 19501:2005]
B.1.21
boolean
enumeration whose values are true and false
[ISO/IEC 19501:2005]
NOTE A field of mathematical logic developed in the mid-19th century by the English mathematician George Boole
which allows a database searcher to combine concepts in a keyword sear
...