ISO/TS 20684-3:2022
(Main)Intelligent transport systems — Roadside modules SNMP data interface — Part 3: Triggers
Intelligent transport systems — Roadside modules SNMP data interface — Part 3: Triggers
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies the needs, requirements and design for multiple mechanisms to fire triggers, which result in the device attempting to perform an action. Specific types of actions are defined in other documents and can include sending notifications (ISO/TS 20684-4), entering data into a log for later retrieval (ISO/TS 20684-5), and/or initiating SNMP-based requests (ISO/TS 20684-6). NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.
Systèmes de transport intelligents — Interface de données SNMP pour les modules en bord de route — Partie 3: Déclencheurs
General Information
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 20684-3
First edition
2022-09
Intelligent transport systems —
Roadside modules SNMP data
interface —
Part 3:
Triggers
Systèmes de transport intelligents — Interface de données SNMP pour
les modules en bord de route —
Partie 3: Déclencheurs
Reference number
ISO/TS 20684-3:2022(E)
© ISO 2022
---------------------- Page: 1 ----------------------
ISO/TS 20684-3:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 20684-3:2022(E)
Contents Page
Foreword ........................................................................................................................................................................................................................................iv
Introduction .................................................................................................................................................................................................................................v
1 Scope ................................................................................................................................................................................................................................. 1
2 Normative references ..................................................................................................................................................................................... 1
3 Terms and definitions .................................................................................................................................................................................... 1
4 Conformance ............................................................................................................................................................................................................ 2
5 User needs ................................................................................................................................................................................................................... 4
5.1 Schedule triggers .................................................................................................................................................................................. 4
5.1.1 Schedule triggers user need ..................................................................................................................................... 4
5.1.2 Schedule triggers design overview .................................................................................................................... 5
5.1.3 Schedule triggers graphical relationships ................................................................................................... 5
5.2 Schedule day plans .............................................................................................................................................................................. 6
5.2.1 Schedule day plans user need ................................................................................................................................. 6
5.2.2 Schedule day plans design overview ................................................................................................................ 6
5.2.3 Schedule day plans graphical relationships ............................................................................................... 6
5.3 Condition-based triggers ............................................................................................................................................................... 7
5.3.1 Condition-based triggers user need .................................................................................................................. 7
5.3.2 Condition-based triggers design overview ................................................................................................. 8
5.3.3 Graphical relationships................................................................................................................................................. 8
6 Requirements .......................................................................................................................................................................................................... 9
6.1 Action manager ...................................................................................................................................................................................... 9
6.1.1 Action manager definition ......................................................................................................................................... 9
6.1.2 Action manager data exchange requirements ......................................................................................... 9
6.1.3 Action manager capability requirements .................................................................................................... 9
6.2 Conditional trigger .............................................................................................................................................................................. 9
6.2.1 Conditional trigger definition ................................................................................................................................. 9
6.2.2 Conditional trigger data exchange requirements .............................................................................. 10
6.2.3 Capability requirements ........................................................................................................................................... 10
6.3 Day plan ..................................................................................................................................................................................................... 13
6.3.1 Day plan definition ........................................................................................................................................................ 13
6.3.2 Day plan data exchange requirements ........................................................................................................13
6.3.3 Day plan capabilities ....................................................................................................................................................13
6.4 Day plan scheduler ........................................................................................................................................................................... 14
6.4.1 Day plan scheduler definition .............................................................................................................................. 14
6.4.2 Day plan scheduler data exchange requirements .............................................................................. 14
6.4.3 Day plan scheduler capabilities .......................................................................................................................... 14
6.5 Trigger schedule .................................................................................................................................................................................15
6.5.1 Trigger schedule definition .................................................................................................................................... 15
6.5.2 Trigger schedule data exchange requirements .................................................................................... 15
6.5.3 Trigger schedule capabilities ................................................................................................................................ 15
7 Security vulnerabilities .............................................................................................................................................................................15
Annex A (normative) Management information base (MIB) ...................................................................................................17
Annex B (normative) Requirements traceability matrix (RTM) ........................................................................................51
Bibliography .............................................................................................................................................................................................................................58
iii© ISO 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/TS 20684-3:2022(E)
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.The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 20684 series can be found on the ISO website.Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.© ISO 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 20684-3:2022(E)
Introduction
0.1 Background
The need for standardized communication with ITS field devices is growing around the world.
Several countries have adopted Simple Network Management Protocol (SNMP) based field device
communication standards.There is a growing view and empirical evidence that standardizing this activity will result in improved
ITS performance, reduced cost, reduced deployment time, and improved maintainability. The ISO 20684
series extends ISO 15784-2 by defining the management information necessary to monitor, configure
and control features of field devices. The data elements defined in all parts of ISO 20684 series may be
used with any protocol but were designed with an expectation that they would be used with one of the
ISO 15784-2 protocols.By using this approach, agencies can specify open procurements and systems can be expanded
geographically in an open and non-proprietary manner, which reduces costs, speeds up deployment,
and simplifies integration.0.2 Overview
SNMP is a collection of well-thought-out and well-proven concepts and principles. SNMP employs the
sound principles of abstraction and standardization. This has led to SNMP being widely accepted as the
prime choice for communication between management systems and devices on the internet and other
communications networks.The original implementation of SNMP was used to manage network devices such as routers and
switches. Since then, the use of SNMP has grown into many areas of application on the internet and has
also been used successfully over various serial communications networks.This document defines management information for ITS field devices following the SNMP conventions.
0.3 Document approach and layoutThis document defines:
a) the conformance requirements for this document (Clause 4);
b) a set of user needs for user-defined trigger conditions that can “fire” to initiate actions (Clause 5);
c) a set of detailed requirements for the identified user needs (Clause 6);d) security considerations for the information defined in this document (Clause 7);
e) the management information bases that define the data for the defined requirements (Annex A);
f) the requirements traceability matrix (RTM) that traces the requirements to the design elements
(Annex B).© ISO 2022 – All rights reserved
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/TS 20684-3:2022(E)
Intelligent transport systems — Roadside modules SNMP
data interface —
Part 3:
Triggers
1 Scope
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic
signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS)
environments, etc.Field devices often need to exchange information with other external entities (managers). Field devices
can be quite complex, necessitating the standardization of many data concepts for exchange. As such,
the ISO 20684 series is divided several individual parts.This document specifies the needs, requirements and design for multiple mechanisms to fire triggers,
which result in the device attempting to perform an action. Specific types of actions are defined in
other documents and can include sending notifications (ISO/TS 20684-4), entering data into a log for
later retrieval (ISO/TS 20684-5), and/or initiating SNMP-based requests (ISO/TS 20684-6).
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS
architecture.2 Normative references
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 20684-1:2021, Intelligent transport systems — Roadside modules SNMP data interface — Part 1:
OverviewISO/TS 20684-7, Intelligent transport systems – Roadside modules SNMP data interface – Part 7: Support
featuresIETF RFC 2578, Structure of Management Information Version 2 (SMIv2), April 1999.
IETF RFC 2579, Textual Conventions for SMIv2, April 1999.IETF RFC 2580, Conformance Statements for SMIv2, April 1999.
IETF RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management
Frameworks, December 2002.3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20684-1 and the following
apply.© ISO 2022 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/TS 20684-3:2022(E)
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp— IEC Electropedia: available at https:// www .electropedia .org/
3.1
hysteresis event
condition defined by alternating upper and lower limits
Note 1 to entry: The condition only evaluates to true when:
a) the value rises above the upper limit and the previous true state was when the value was below the lower
limit; orb) the value falls below the lower limit when the previous true state was above the upper limit.
Note 2 to entry: Hysteretic boundaries can be used to reduce the number of events that can potentially occur
when data fluctuates over a small range near the boundary. Crossing the boundary in one direction generally
reflects the onset of anomalous conditions while crossing in the other direction indicates a return to normal
conditions.EXAMPLE A user wants to be alerted when the speed along a motorway falls below 50 km/h. If the speed
along the motorway was varying between 45 km/h and 55 km/h, the management station would receive an alert
each time the average fell below 50 km/h during this variation. With a hysteretic boundary, the user can set a
lower bound of 50 km/h and an upper bound of 60 km/h; in this case, the manager receives an alert the first time
that the speed falls below 50 km/h, but does not receive another alert until the speed increases to 60 km/h.
4 ConformanceThis clause follows the rules defined in ISO 20684-1. Table 1 traces each user need to a set of software
features. Table 2 traces each feature to a set of requirements. Table 3 defines terms that are used as
predicates in the conformance codes listed in Tables 1 and 2. For a full understanding of these tables
and codes, see ISO 20684-1.Table 1 — User need and feature conformance
Need Requirement Conformance
5.1: Schedule triggers O,1 (1..*)
6.1: Action manager M
6.5: Trigger schedule M
20684-7 6.1: Local clock M
20684-7 6.2: UTC clock M
20684-7 6.3: Daylight saving time O
5.2: Schedule day plans O,1 (1..*)
6.1: Action manager M
6.3: Day plan M
6.4: Day plan scheduler M
20684-7 6.1: Local clock M
20684-7 6.2: UTC clock M
20684-7 6.3: Daylight saving time O
5.3: Condition-based triggers O,1 (1..*)
6.1: Action manager M
6.2: Conditional trigger M
© ISO 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TS 20684-3:2022(E)
Table 2 — Requirement conformance
Feature Requirement Conformance
6.1: Action manager
6.1.2.1: Determine action manager capabilities M
6.1.2.2: Configure an action manager M
6.1.2.3: Verify action manager configuration M
6.1.2.4: Retrieve action manager statistics M
6.1.2.5: Retrieve action manager enabled status M
6.1.2.6: Toggle action manager M
6.1.2.7: Delete action manager M
6.2: Conditional trigger
6.2.2.1: Discover triggering capabilities M
6.2.2.2: Configure trigger M
6.2.2.3: Confirm trigger configuration M
6.2.2.4: Delete trigger definition M
6.2.2.5: Retrieve statistics for trigger M
6.2.2.6: Retrieve summary statistics for triggers M
6.2.2.7: Toggle trigger enabled status M
6.2.2.8: Monitor trigger status M
6.2.3.1.1: Support for creation event O,2(1..*)
6.2.3.1.2: Support for deletion event O,2(1..*)
6.2.3.1.3: Support for change in value event O,2(1..*)
6.2.3.1.4: Support for equal event O,2(1..*)
6.2.3.1.5: Support for not equal event O,2(1..*)
6.2.3.1.6: Support for greater than event O,2(1..*)
6.2.3.1.7: Support for less than event O,2(1..*)
6.2.3.1.8: Support for hysteresis event O,2(1..*)
6.2.3.1.9: Support for periodic event O,2(1..*)
6.2.3.1.10: Support for bitwise 'and' event on an INTEGER O,2(1..*)
6.2.3.1.11: Support for bitwise 'and' event on an OCTET STRING O,2(1..*)
6.2.3.2.1: Support for triggers based on current values M
6.2.3.2.2: Support for triggers based on delta values O
6.2.3.3.1: Support for creation wildcards creation:O
6.2.3.3.2: Support for deletion wildcards deletion:O
6.2.3.3.3: Support for on change wildcards onChange:O
6.2.3.4.1: Support for local data with the default context M
6.2.3.4.2: Support for local data with a specialized context O
6.2.3.4.3: Support for remote data O
6.2.3.5: Number of triggers M
6.3: Day plan
6.3.2.1: Configure a day plan M
6.3.2.2: Verify day plan configuration M
6.3.2.3: Toggle the enabled status of a day plan M
6.3.2.4: Determine the enabled status of a day plan M
6.3.2.5: Delete a day plan M
6.3.2.6: Configure a day plan trigger M
© ISO 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/TS 20684-3:2022(E)
TTabablele 2 2 ((ccoonnttiinnueuedd))
Feature Requirement Conformance
6.3.2.7: Verify day plan trigger configuration M
6.3.2.8: Toggle the enabled status of a day plan trigger M
6.3.2.9: Determine the enabled status of a day plan trigger M
6.3.2.10: Delete a day plan trigger M
6.4: Day plan scheduler
6.4.2.1: Configure the day plan selection rules M
6.4.2.2: Verify the day plan selection rule configuration M
6.4.2.3: Disable a day plan schedule rule M
6.4.2.4: Delete a day plan schedule rule M
6.4.2.5: Determine day plan scheduler status M
6.4.2.6: Determine day plan schedule statistics M
6.4.2.7: Toggle the operation of a day plan scheduler M
6.4.2.8: Monitor day plan scheduler errors M
6.5: Trigger schedule
6.5.2.1: Configure a scheduled trigger M
6.5.2.2: Verify schedule for a trigger M
6.5.2.3: Toggle the enabled status of a trigger M
6.5.2.4: Determine enabled status of scheduled trigger M
6.5.2.5: Determine performance of scheduled trigger M
6.5.2.6: Delete a scheduled trigger M
6.5.3.1: Support calendar triggers O,4(1..*)
6.5.3.2: Support one-shot triggers O,4(1..*)
Table 3 — External standard reference
Predicate Subclause
creation 6.2.3.1.1
deletion 6.2.3.1.2
on-change 6.2.3.1.3
5 User needs
5.1 Schedule triggers
5.1.1 Schedule triggers user need
A manager needs to be able to schedule a field device to perform actions at one or more future
known dates and times. The action to be performed can be to issue any command that the manager is
authorized to issue via SNMP, log information, or send a manager a notification. Multiple independent
managers can potentially wish to schedule these actions for various purposes with a level of confidence
that they will not be inadvertently overwritten by other managers.© ISO 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TS 20684-3:2022(E)
5.1.2 Schedule triggers design overview
5.1.2.1 Required features
In the simplest case, the “schedule actions” user need shall support the following features.
a) Trigger schedule, as specified by this document, which defines rules for when a scheduled trigger
should fire.b) Action manager, as specified by this document, which identifies the actions that are to be performed
by the device when each trigger fires.c) Clock - local, as specified by ISO/TS 20684-7, which is based on the UTC clock with adjustments to
reflect the local time zone. It is used by the trigger schedule to determine when it is time to fire the
trigger.d) Clock - UTC, as specified by ISO/TS 20684-7, which is used to track the current UTC time.
5.1.2.2 Optional featuresAn implementation may support the DST feature, as defined in ISO/TS 20684-7, which defines the
specific details about daylight saving time events that adjust the local clock forwards and backwards.
5.1.3 Schedule triggers graphical relationshipsThe relationships among these features are depicted in Figure 1.
Figure 1 — Schedule triggers
Each trigger schedule defines time(s) at which a trigger will fire. The trigger schedule uses the
ClockLocal to determine when to fire the trigger and thereby implement the action(s). The ClockLocal
is based on the ClockUTC modified by the time zone and optionally by the daylight saving (i.e.. summer)
time (DST). When a trigger fires, it causes the ActionManager to perform one or more defined actions;
the mechanisms used to define these actions are covered by other documents, such as ISO/TS 20684-4
© ISO 2022 – All rights reserved---------------------- Page: 10 ----------------------
ISO/TS 20684-3:2022(E)
(for issuing notifications), ISO/TS 20684-5 (for logging data), and ISO/TS 20684-6 (for issuing SNMP
requests).5.2 Schedule day plans
5.2.1 Schedule day plans user need
A manager needs to be able to activate a daily schedule of actions where the schedule is selected based
on the current day-of-week and date and the actions within the daily schedule are based on local time-
of-day. Being able to activate a daily schedule as a single unit can simplify the definition of the schedule
of actions that tend to follow daily patterns. For example, with this mechanism a manager could define
two day plans (i.e. two plans, each of which covers one 24-hour day): a 'normal' day plan and a 'holiday'
day plan. The scheduling table would only need one entry to select the normal plan for every day of
the year and a separate entry for each specific day when the holiday schedule is desired. According to
the scheduler logic, the holiday day plan would be selected on the specified days because those entries
would be more specific.NOTE 1 Achieving the same level of configuration with the more generic "schedule triggers" user need would
produce a much more convoluted configuration. However, if the scheduling logic does not require a day plan, the
"schedule triggers" user need provides a very simple design.NOTE 2 As only one day plan schedule can be active at any one time, it is recommended that only a single
manager be granted access to the day plan schedule.5.2.2 Schedule day plans design overview
5.2.2.1 Required features
In the simplest case, the “schedule day plans” user need shall support the following features.
a) Day plan schedule, as specified by this document, which defines the rules for selecting a day plan to
run; only one day plan can be active at any time.b) Day plan, as specified by this document, which provides a description of the day plan and a list of
triggers to be fired at defined times during the day.c) Action manager, as specified by this document, which defines the actions that are to be performed
by the device when each trigger fires.d) Clock - local, as specified within ISO/TS 20684-7, which is based on the UTC clock with adjustments
to reflect the local time zone. It is used by the day plan schedule to select a day plan and is used by
the day plan to identify when it is time to fire each trigger.e) Clock - UTC, as specified by ISO/TS 20684-7, which is used track the current UTC time.
5.2.2.2 Optional featuresAn implementation may support the DST feature, as defined in ISO/TS 20684-7, which defines the
specific details about daylight saving time events that adjust the local clock forwards and backwards.
5.2.3 Schedule day plans graphical relationshipsThe relationships among these features are depicted in Figure 2.
© ISO 2022 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TS 20684-3:2022(E)
Figure 2 — Schedule day plans
The DayPlanSchedule selects a specific DayPlan based on the local month, day of month, and day of week.
Each DayPlan consists of a description and series times at which a trigger will fire during the day. The
DayPlanSchedule and DayPlanEvent both use the ClockLocal to determine the current local time. The
ClockLocal is based on the ClockUTC modified by the time zone and optionally by the daylight saving
time (DST). When a trigger fires, it causes the ActionManager to perform one or more defined actions;
the mechanisms used to define these actions are covered by other standards, such as ISO/TS 20684-4
(for issuing notifications), ISO/TS 20684-5 (for logging data), and ISO/TS 20684-6 (for issuing SNMP
requests).5.3 Condition-based triggers
5.3.1 Condition-based triggers user need
One or more managers need to be able to configure a field device to fire a trigger when defined
conditions occur. The trigger can cause the device to issue any command that the manager is authorized
to issue via SNMP, log information, or send the manager a notification. Multiple independent managers
can wish to schedule these triggers for various purposes with a level of confidence that they will not be
inadvertently overwritten by other managers.EXAMPLE 1 A manager wants the device to record the number of vehicles counted during every signal cycle.
EXAMPLE 2 A manager wants the device to issue a notification to a maintenance agency immediately when a
cabinet door opens.EXAMPLE 3 A manager wants to activate external equipment under certain conditions, such as when the
temperature drops below freezing.© ISO 2022 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/TS 20684-3:2022(E)
5.3.2 Condition-based triggers design overview
5.3.2.1 Required features
In the simplest case, the “condition-based triggers” user need shall support the following features:
a) Conditional trigger, as specified by this document, which defines the conditions under which the
trigger fires.b) Action manager, as specified by this document, which identifies the actions that are to be performed
by the device when each trigger fires.5.3.2.2 Optional feature group #1
An implementation may support the following features as a single group for this user need.
a) SNMP target, as specified in ISO/TS 20684-7, which can be used t...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.