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

Status
Published
Publication Date
18-Sep-2022
Current Stage
6060 - International Standard published
Start Date
19-Sep-2022
Due Date
28-Feb-2023
Completion Date
19-Sep-2022
Ref Project

Buy Standard

Technical specification
ISO/TS 20684-3:2022 - Intelligent transport systems — Roadside modules SNMP data interface — Part 3: Triggers Released:19. 09. 2022
English language
58 pages
sale 15% off
Preview
sale 15% off
Preview

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 layout
This 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:

Overview

ISO/TS 20684-7, Intelligent transport systems – Roadside modules SNMP data interface – Part 7: Support

features

IETF 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; or

b) 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 Conformance

This 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 features

An 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 relationships
The 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 features

An 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 relationships
The 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.