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 environments, etc.

The ISO 26048 series defines data that can be used to manage field devices, including device configuration, control, and monitoring. Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 26048 series is divided into several individual parts. This document (Part 1) introduces the ISO 26048 series, provides normative content that applies to all subsequent parts, and defines data that is applicable to the management of a wide range of field devices.

The scope of the ISO 26048 series does not define the logic used by the management system, the underlying protocols used to exchange the defined data elements, or internal design of the field device. However, the ISO 26048 series does define place functional requirements on the interface and assumes an interface based on an SNMPv3 environment as specified by ISO 15784-2.

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.

IETF RFC 2578, Structure of Management Information Version 2 (SMIv2), April 1999.

IETF RFC 2579, Textual Conventions for SMIv2, April 1999

IETF RFC 2580

For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 24765, ISO 14812, IETF RFC 3411 and the following apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

ISO Online browsing platform: available at https://www.iso.org/obp

IEC Electropedia: available at http://www.electropedia.org/

SNMP application that monitors and manipulates management information

SNMP application that provides access to management information

fixed or portable roadside module that includes an SNMP agent

to start a process when a trigger (3.13) value transitions from false to true

notification sent with an expectation of an acknowledgement

registry of snapshots within an SNMP agent that can be retrieved by an SNMP manager

SNMP message from an SNMP agent that is generated independently from any explicit request

While a notification is not generated in response to any explicit request, it can be generated based on configured parameters stored within the SNMP agent.

SNMP application that initiates asynchronous messages

SNMP application that processes asynchronous messages

SNMP application that forwards messages between entities

Proxy forwarder applications typically change the protocol or message model as a part of its functionality.

time from the receipt of a Confirmed Class pduType by the command responder to the sending of the response PDU by the command responder

For the purpose of this document, the response time is measured at the application programming interface of the command responder. Any delays imposed within the lower layers are considered to be network delays and not included in the response time.

information captured when a trigger fires within an SNMP agent

A snapshot can be used in the generation of an SNMP notification or the creation of a new entry within a log.

SNMP entity containing one or more command responder and/or notification originator applications

application that provides specific functional processing of SNMP management data

implementation of one or more SNMP message processing models with one or more associated SNMP applications

An SNMP entity may also support one or more security models

fixed or portable roadside module that includes an SNMP agent and an SNMP manager

SNMP field managers are field devices that can control other field devices.

SNMP entity containing one or more command generator and/or notification receiver applications

SNMP entity to which another SNMP entity can send requests or notifications

SNMP agents use the concept of a target to identify the SNMP manager to which a notification is to be sent. 

Field devices can be configured to request data from other field devices to use in their expression or trigger logic.

Field devices can be configured to control other field devices in response to a trigger firing.

get or set request that conforms to the specification of a request message included in a dialogue defined within a document approved by a standards development organization

notification sent without any expectation of an acknowledgement

condition that evaluates to a Boolean value

architecture reference for cooperative and intelligent transportation

American standard code for information interchange

abstract syntax notation one

conformance code table

consolidated protocols implementation conformance statement

datagram transport layer security or transport layer security

feature-to-requirement

Internet Engineering Task Force

internet protocol

internet protocol security

International Organization for Standardization

intelligent transport systems

ITS station

management information base

national transportation communications for ITS protocol

need-to-feature

object identifier

protocol data unit

request for comments

requirements traceability matrix

structure and management of information

simple network management protocol

transport control protocol

transport layer security

user datagram protocol

user-based security model

This document is accompanied by electronic attachments that form an integral part of this document and are available for download through the ISO maintenance portal at:  https://standards.iso.org/iso/ts/26048/-1/ed-1/en.

This document normatively incorporates one or more management information bases (MIBs), which conform to RFC 2578, RFC 2579, and RFC 2580. These files are defined in ASCII text files, which can be accessed electronically from the ISO maintenance portal as indicated in !~Section 80~!.

The filename for each component MIB is the name of the MIB with a ".mib" extension.

This document contains references to and explanations of ASN.1 data concepts within its text. In all cases, the ASN.1 terms are presented in a fixed width font (e.g. !<pre>!such as this!</pre>!) to distinguish these terms from normal English.

Conformance to this document is defined by the traceability tables available through the ISO maintenance portal, including the NTF traceability table, the FTR traceability table, and the RTM. 

Each item of conformance in this document is worded in a manner as if has been selected in these tables. For example requirements are stated as simple "shall" statements even if they are listed as optional in the FTR traceability table. The applicability of each item of conformance is defined in the traceability tables.

Terminology between the different versions of SNMP is slightly different. For the purposes of the ISO 26048 series, the terminology of SNMPv3 is adopted.

The ISO 26048 series defines mechanisms by which field devices can be monitored, configured and controlled. Field devices may be used to support almost any ITS service, defined in ISO 14813-1, with a roadside component.

The ISO 26048 series is concerned with defining the data concepts used to manage a field device. The data concepts defined in this document have been defined based on needs derived from an analysis of various services contained within the architecture reference for cooperative and intelligent transportation (ARC-IT)[19].

Figure 1 depicts the physical view of this interface using the graphical conventions defined by ARC-IT [19] and also documented in ISO 14813-5:2020, Annex B.

The management system of the field device is shown in grey indicating that it can be any type of physical object, such as a central system, another field device, a maintenance laptop or any other device that supports the defined interface.

The field device is shown in orange, indicating that it is located in the field (e.g. along the roadside). It shall have a connection to the management system and may have any number of connections to other ITS stations or external systems.

The figure indicates two information transfers between these physical objects. The first is the "configuration and commands" information flow from the management system to the field device. The second is the "status and notifications" information flow from the field device to the management system. Both flows are shown in green indicating that authentication is required, and both are shown with a single arrowhead indicating a unicast transfer.

This document is based on the use of SNMP, which implements a GET/SET paradigm where there is a command generator and a command responder. However, a single SNMP entity can act as both a command generator (e.g. sending requests to other field devices) and as a command responder (e.g. responding to requests from a centre or other field device) simultaneously. The term "SNMP field manager" is used to specify this type of dual-function device.

Figure 2 depicts how the ISO 26048 series is intended to relate to other standards using the ITS Station architecture, as defined in ISO 21217.

Part 1 of the ISO 26048 series (this document) defines features that are a part of the management entity of the ITS station (ITS-S) architecture. This includes management information that indirectly supports device-specific functionality. The management layer typically also supports other data to manage the communications stack as defined by a variety of SNMPv3 MIBs (e.g., the management information referenced by ISO 15784-2).

!~Section 819~! defines the UTC clock feature, which can be used to support end-device functionality, such as selecting a time-of-day action plan.

Other parts of the ISO 26048 series will address device-specific functionality and are considered part of the definition of ITS-S application entity.

ISO 26048-3 is expected to define management information related to controlling and monitoring a variable message sign.

The information defined for the management entity and ITS-S application entity can theoretically be exchanged over any communications stack, but is designed to be exchanged using SNMPv3, as described in ISO 15784-2, which requires support for the Transport Layer Security (TLS) Transport Model, as defined in RFC 6353. These standards are typically exchanged using well-known internet protocols, such as UDP/IP or TCP/IP over any number of access layers.

This document presents a separate section for each step in the systems engineering process, as described as follows:

User needs — Each user need describes a capability that a management system might need to perform. User needs are written from the perspective of a management system and include a justification for the need. 

High-level design — Each user need is analyzed and decomposed into a set of features. Features are can be separately managed and can potentially support multiple user needs. The applicability of each feature within a user need is defined by the need-to-feature (NTF) traceability table, which is available on the ISO maintenance portal as discussed in !~Section 80~!. 

Requirements — Each feature is decomposed into a set of formal requirements, including data exchange requirements and other requirements (e.g., performance, constraints). The applicability of each requirement within a feature is defined by the feature-to-requirement (FTR) traceability table, which is available on the ISO maintenance portal as discussed in !~Section 80~!. 

Dialogues — Each data exchange requirement is implemented using exactly one standardized dialogue coupled with a defined set of objects. The standardized dialogue is defined as a sequence of SNMP operations. The traceability between data exchange requirements and their associated dialogues are defined in the requirements traceability matrix (RTM), which is available on the ISO maintenance portal as discussed in !~Section 80~!.

Management Information Base — Each data exchange requirement is satisfied using one or more managed objects to be included in the associated dialogue. Objects are instances of object-types, which are defined in electronic MIB(s). The traceability between each data exchange requirement and the associated object-types are defined in the RTM. The RTM and MIBs defined by this document are available on the ISO maintenance portal as discussed in !~Section 80~!. Other MIBs (e.g., those in RFCs) are available in the referenced normative reference.

A management system needs to ensure that users are only allowed to access data according to the authority that they have been granted.

A management system needs to be able to identify and monitor the overall capabilities and health of each field device controller and its cabinet to discover anomalous conditions that can affect its operation or security. This will assist the management system in confirming which controller(s) are in a cabinet, as well as the type and specific instance of each controller and the high-level capabilities offered by the device as well as performing proper maintenance actions.

EXAMPLE               A management system that is receiving unexpected errors can verify which device it is communicating with as a part of a debugging process and can determine if the device configuration has been changed since its last known state so that the appropriate action can be taken if access has not been authorized.

A management system needs to be able to monitor the open/close status of each cabinet door to determine when equipment is being physically accessed.

A management system needs to be able to monitor and control the on/off status of each cabinet fan to manage the cabinet temperature.

A management system needs to be able to monitor and control the on/off status of each cabinet heater to manage the cabinet temperature.

A management system needs to be able to monitor the relative humidity within the cabinet to disable the controller or subsystems in extreme conditions.

A management system needs to be able to monitor the air temperature inside the cabinet to determine when climate control equipment should be activated and/or to disable equipment to prevent overheating.

A management system needs to be able to monitor the status of the incoming mains power line, which is typically provided by the power grid to detect when this power is lost or becomes unstable.

A management system needs to be able to monitor the status of the battery power system to determine the quality of power and amount of charge available.

A management system needs to be able to monitor the status of the cabinet generator power to determine the quality of power being produced and the fuel reserve.

A management system needs to be able to monitor the status of the solar power system to determine the amount of power being generated.

A management system needs to be able to monitor the status of the wind power system to determine the amount of power being generated.

When user-defined triggers fire, one or more independent management systems need to receive real-time notifications containing user-defined information. This will allow a management system to immediately become aware of information that can affect its operation or security without burdening the communications channel with frequent polling for data that seldom changes. Multiple triggers can be monitored with different systems being notified based on the type of condition.

EXAMPLE 1     A management system wants to be immediately notified when the cabinet door opens so that an appropriate response can be initiated if the access is unauthorized.

EXAMPLE 2     A management system wants to have the maintenance system notified when the cabinet door opens and have the traffic management system notified when a new message is displayed on a sign.

One or more independent management systems need to be able to configure a field device to log snapshots for later retrieval. This user need allows a management system to configure conditions that will automatically trigger the logging of snapshot data along with a timestamp. A management system can configure multiple triggers and multiple management systems can configure the same or different conditions.

EXAMPLE 1      A management system wants the device to record the number of vehicles counted every 15 min so that the management system can retrieve the information at the end of each day.

EXAMPLE 2     A management system wants to retrieve diagnostic-related snapshots (e.g., cabinet door open) separately from operation-related snapshots (e.g., a new message on a sign). This can be due to internal logic, or it can be because two separate management systems communicate with the device.

One or more independent management systems need to be able to configure a field device to record a series of snapshots for later retrieval so that conditions can be recreated. This user need allows a management system to configure conditions that will automatically trigger the recording of a series of snapshots, each with a timestamp. 

A management system wants the device to record the count of the number of vehicles approaching an intersection each second after the signal changes to yellow to produce a better estimate of the delays at the signal.

One or more independent management systems need to be able to configure an SNMP field manager to send a command to an SNMP agent when user-defined conditions are detected by the SNMP field manager. This will allow the field manager to alter the state of other field devices as triggers fire without burdening the communications channel between the centre and field location.

The SNMP field manager and SNMP agent can be in the same field device.

EXAMPLE         A management system wants to configure a field manager to automatically display a message (on one device) whenever ice is detected on the roadway (by another device).

For devices that have extensive inter-relationships among configuration parameters, a management system needs to provide all necessary configuration updates prior to the new configuration being validated and implemented. 

A phased-based traffic signal controller has many objects that are safety critical. When reconfiguring a traffic signal controller, it is important to ensure that the values are internally consistent to prevent any potential for unsafe operation. The number of inter-related parameters typically exceed what can be delivered in a single SNMP message. As a result, a distinct mechanism is required to buffer the initial set of changes and to perform validation once all parameters have been set.

One or more management systems need to repeatedly perform requests related to the same group of managed object values. Normal SNMP operations require the complete object identifier (OID) of every object value to be specified in each request. These OIDs are often 10-20 octets in length, which can significantly increase communications overhead when the values being retrieved are small (e.g., one-octet INTEGERs). This document defines a mechanism to allow a manager to configure dynamic objects, which can then be used to interact with multiple managed objects via a single OID.

A management system polls a specific group of integer-based objects periodically to monitor the operation of a field device. The communication network used to connect to the field device includes a link that charges for data usage. Rather than requesting each status object individually, the management system wishes to configure a structure that can be repeatedly requested using less overhead.

Data access is controlled using the view-based access control model (VACM), as defined in RFC 3415, coupled with a design of the OID tree to ensure that administrators can easily restrict access to branches of the tree based on intended access rights.

Configuring the VACM consists of the following major steps:

discovering available contexts within the field device;

configuring MIB views;

assigning each user to VACM group; and

configuring access permissions for each group.

A context represents a complete instantiation of management information. A field device can contain a one or more contexts. For example, a single field device can be used to control the display for two signs (e.g., one facing north and one facing south). Such a device can define two contexts, one for each sign. Each context would contain a complete instance of the MIB with unique object instances for each. When appropriate, object instance values can be linked. For example, each context would likely have a different value for the currently displayed message while both contexts should have a common interpretation of the time of day. Contexts are defined by the device and cannot be configured by a management system.

Many field devices contain a single context and use an empty string to identify the context.

A MIB view represents a subset of objects available within a device to which a user should have access. A MIB view is configured by identifying portions of the OID tree to which access should be granted or prohibited. 

A branch of the OID tree that should only be accessible to administrators can be excluded from a MIB view intended to be used by technicians.

A VACM group represents zero or more authenticated users, where each user is identified by a security name and security model pair. When requests are received, the SNMP engine determines the security name and security model and uses the information to determine which group's access rights to use. The process used to authenticate this information is defined separately by the security model. 

All field technicians can be assigned to the same group.

Once the necessary contexts, VACM groups, and MIB views are defined, access can be configured for each VACM group. The configuration includes a separate assignments based on the type of request (e.g., get, set) as well as the security model and level (e.g., whether encryption is used). 

The same user can be granted different access rights for a context related to a north facing sign than for a context related to a south facing sign.

The same user can be assigned different MIB views for get requests than for set requests.

The same user can be granted different access using encryption than when not using encryption.

Monitoring the field device involves both the field device feature and the cabinet feature. The object-types included within these features primarily consists of information that is either read-only or writable with no or minimal interactions with other management information from a semantic perspective. 

Monitoring cabinet doors is achieved through the use of the cabinet door feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring and controlling cabinet fans is achieved through the use of the cabinet fans feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring and controlling cabinet heaters is achieved through the use of the cabinet heaters feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet humidity is achieved through the use of the cabinet humidity feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet temperature is achieved through the use of the cabinet temperature feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet mains power is achieved through the use of the cabinet mains power feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet battery power is achieved through the use of the cabinet battery power feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet generator power is achieved through the use of the cabinet cabinet generator feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet solar power is achieved through the use of the cabinet solar power feature coupled with the supplemental roadside sensors and actuators feature.

Monitoring cabinet wind power is achieved through the use of the cabinet wind power feature coupled with the supplemental roadside sensors and actuators feature.

Receiving notifications is achieved using a variety of features as depicted in !~Figure 613~!.

When a trigger (!~Section 981~!) fires, it calls an action manager (!~Section 540~!), which may direct the call to the notification factory. When called, the notification factory captures the current value of a specified object and stores this value in a notification snapshot along with an identifier of the condition that initiated the snapshot and timestamp. The object value recorded may be an !@fdCompositeObjectValue@! (ISO26048-1-DynObj.mib), which can consolidate the values of multiple subordinate objects into a single SNMP object. The notification factory then passes the notification snapshot to the notification channel along with information about how the notification snapshot is to be handled (e.g., aggregated or not). Multiple notification factories may use the same notification channel.

If the notification snapshot is flagged for aggregation, it is passed to the notification aggregator; otherwise the notification channel assigns the notification snapshot to an appropriate one-off notification packet.

The notification aggregator combines notification snapshots into a single notification packet, which serves to reduce overall communications overhead. The notification aggregator conceptually manages two aggregate notification packets: one that requires acknowledgements (i.e., an SNMP inform) and another that does not (i.e., a SNMP trap). Notification snapshots from different notification factories can be combined into a single notification packet. Once a notification packet is completed, it is sent back to the notification channel for transmission to the SNMP target.

Once a notification packet is ready to send, the notification channel sends the notification packet to the SNMP target while ensuring that the anti-streaming rate is not exceeded, which allows temporary queueing of notifications so that they do not overwhelm the communications channel.

Finally, as per the rules of SNMPv3, trap messages are unacknowledged and inform messages are acknowledged. The acknowledgement process is handled according to standard SNMPv3 rules (complete with timeout and retry logic).

Logging snapshots is achieved using a variety of features as depicted in !~Figure 743~!.

When a trigger (!~Section 981~!) fires, it calls an action, which may direct the call to a log snapshot factory. When called, the log snapshot factory captures a defined object value from the device and records this in a new entry in the identified log class based on configured parameters. 

While the snapshot only records a single object instance value, the object instance can be an instance of !@fdDynObjCurrentValue@!, which can contain multiple object instance values packaged in an efficient manner.

The log can be managed (e.g., fully or partially cleared) using the log manager. The log manager also reports statistics for the log.

Logging snapshots is achieved using a variety of features as depicted in !~Figure 1053~!.

When a trigger (!~Section 981~!) fires, it calls an action, which may direct the call to a recording factory. When called, if the recording is configured to include pre-event snapshots, the recording factory moves the configured number of previously recorded snapshots, to the extent that they are available, into the recording log. The recording factory continues capturing snapshots per the configuration and stores each into the recording log. 

While each snapshot only records a single object instance value, the object instance can be an instance of !@fdDynObjCurrentValue@!, which can contain multiple object instance values packaged in an efficient manner.

The recording can be managed (e.g., fully or partially cleared) using the recording manager. The recording manager also reports statistics for the recording log.

Logging snapshots is achieved using a variety of features as depicted in !~Figure 798~!.

When a trigger (!~Section 981~!) fires, it calls an action, which may direct the call to a command factory. When called, the SNMP field manager sends the configured SNMP set request to the identified SNMP target using the configured SNMP target parameters. 

Configuring a complex device starts by placing the field device into the transaction mode, which logically creates a copy of the current configuration in a buffer and all set operations on parameter objects from the same management system that started transaction mode are stored in the buffer. Any request from another management system to change any parameter is rejected.

Once the initiating management system has completed its proposed changes, it should direct the field device to verify the buffered parameters to ensure that the settings pass all internal consistency checks. The checks can take time and the field device will transition to a done state at the end of the process. The management station can then retrieve the error code and if there were no errors, it can implement the buffered configuration.

Normal SNMP operations consist of get and set operations on atomic elements, which are identified by a 10-20 octet identifier. Within ITS, a large percentage of the atomic elements that are exchanged are integer values that are encoded in one to four octets. As a result, identifiers consume a significant percentage of the size of each normal SNMP message exchanged within ITS unless a more efficient design is used. 

The solution is provided with the dynamic object feature, which allows a management system to configure a dynamic object to be a reference to a list of object instances supported by the device. Once configured, the management system can reference the single identifier for the dynamic object as a shorthand reference to the list of object instances associated with that dynamic object configuration.

As an added efficiency, the management system can configure the dynamic object to encode its value using the octet encoding rules (OER) rather than the basic encoding rules (BER), which is typically used by SNMP. The results in eliminating additional overhead from the encoding.

A device can establish triggers based on a number of factors. This document defines three trigger mechanisms but does not restrict the development of other trigger mechanisms.

The design of the schedule triggers user need is depicted in !~Figure 484~!.

Each trigger schedule defines time(s) at which a trigger will fire. The trigger schedule uses the local clock to determine when to fire the trigger and thereby implement the action(s). The local clock is based on the UTC clock modified by the time zone and optionally by the daylight saving (i.e., summer) time (DST). When a trigger fires, it causes the action manager to perform one or more defined actions.

The design of the schedule triggers user need is depicted in !~Figure 472~!.

The day plan schedule selects a specific day plan based on the month, day of month, and day of week. Each day plan consists of a description and series times at which a trigger will fire during the day. The day plan schedule and day plan trigger both use the local clock to determine the current local time. The local clock is based on the UTC clock modified by the time zone and optionally by the daylight saving time (DST). When a day plan trigger fires, it causes the action manager to perform one or more defined actions.

The design of the schedule triggers user need is depicted in !~Figure 497~!.

Each conditional trigger is is configured to monitor a value of an object instance and to fire when a configured condition occurs. The value of the object instance can be configured to reference:

local SNMP data (i.e., any data from the local field device); or

data from an SNMP target (i.e., an external field device).

When the conditions defined by the trigger occur (e.g., the value exceeding a defined threshold), the trigger fires causing the action manager to perform one or more defined actions. 

The action feature associates the firing of a trigger with the actions that are to be performed, such as notifying a management system of a trigger firing (!~Section 598~!), logging user-defined snapshots (!~Section 730~!), recording a series of snapshots (!~Section 1047~!), and/or issuing commands (!~Section 787~!).

NOTE                 In theory, the action manager could be activated by a mechanism other than the schedule triggers, schedule day plans, or condition-based triggers mechanisms defined in this document.

The field device shall allow a management system to configure an action owner by defining the number of action groups and actions that an owner is allowed to configure.

The action owner extends the definition of the owner feature and is dependent upon the owner feature to identify an owner.

The field device shall allow a management system to configure an action group, including providing a description and storage type for the action group.

The field device shall allow a management system to configure an action within an action group by referencing the action to be performed.

The field device shall allow a management system to confirm the action-related configuration settings for a specified owner.

The field device shall allow a management system to confirm the configuration of an action group.

The field device shall allow a management system to confirm the configuration of an action.

The field device shall allow a management system to delete an action group and all associated actions.

The field device shall allow a management system to delete a specific action within an action group.

The field device shall allow a management system to toggle the enabled status of each action group. When "notInService", the action group shall not implement any actions. When "active", the action group shall implement all active actions associated with the group when the group is called by a trigger firing.

The field device shall allow a management system to toggle the enabled status of each action associated with an action group. When "notInService", the action will not be implemented. When "active", the action will be implemented if and when the action group calls it.

The field device shall allow a management system to retrieve statistics that summarize the operation of all action owners.

The field device shall allow a management system to retrieve action-related statistics for a specified owner.

The field device shall allow a management system to retrieve the number of times the action group has been called (e.g., by a firing trigger) and the number of times that the number of times that a call has resulted in at least one action failure.

The field device shall allow a management system to retrieve the number of times a call to the action failed due to an error or due to the action being disabled.

The field device shall verify that the access credentials used to place an action in the active state have at least read access to the variable referenced by the action pointer. 

The field device shall record the security credentials used to place an action into the active state and shall ensure that these credentials have at least read access to the variable referenced by the action pointer before implementing the action in response to a trigger firing.

Ensuring that access is allowed can be achieved in real-time (i.e., when the action is called) or algorithmically by re-verifying the credentials upon any event that might change access rights (e.g., edits to the MIB view associated with a management system).

The cabinet represents the enclosure of the field device controller that hosts the SNMP agent that responds to the requests defined by this document.

The field device shall allow a management system to configure the cabinet's location.

This can be performed by a central system or can be performed by a connected device (e.g., a global navigation satellite system receiver), especially in the case of portable devices. 

The field device shall allow a management system to determine the cabinet's location.

The field device shall allow a management system to configure information about the cabinet and each of its major components. The information for each item shall include an alias and asset identifier.

The field device shall allow a management system to identify information about the cabinet and each of its components. The information for each item shall include an alias, an asset identifier, make, model, version, and related information. The information shall also indicate the arrangement of equipment, such as the field device controller being contained within the cabinet.

The field device shall allow a management system to determine the current power source for the cabinet.

The cabinet shall be supported by at least one of the following power sources:

mainline (alternating current) power,

battery power,

generator power,

solar power, or

wind power.

The field device shall support an uninterrupted power supply for the cabinet.

The cabinet battery feature indicates the status of the main cabinet battery, which is generally charged by an external source such as a solar array.

There are no cabinet battery data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one voltage sensor for the cabinet battery. The project specification may specify support for additional voltage sensors for the cabinet battery.

The field device shall support at least one electrical current sensor for the cabinet battery. The project specification may specify support for additional electrical current sensors for the cabinet battery.

The field device shall support at least one charge sensor for the cabinet battery. The project specification may specify support for additional charge sensors for the cabinet battery.

For each cabinet battery voltage sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RBV".

For each cabinet battery electrical current sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RBA".

For each cabinet battery charge sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RBC".

The cabinet door feature indicates the open/close status of each cabinet door monitored by a sensor.

There are no cabinet door data exchange requirements beyond those defined for the RSA feature.

The field device shall monitor the main cabinet door. The project specification may specify additional cabinet doors that shall be monitored.

For each cabinet door monitored, the field device shall provide an entry in the RSA table where fdRSAType equals "RDO" in accordance with the Registry of ITS Identifiers (RITSI).

The cabinet fan feature indicates the on/off status of each cabinet fan.

There are no cabinet fan data exchange requirements beyond those defined for the RSA feature.

The field device shall monitor each cabinet fan to determine if the fan blades are turning at a significant rate. If this requirement is selected, the fdRSAPortDirection for each cabinet fan shall be either input or bidirectional.

The field device shall allow remote on/off control of each cabinet fan. If this requirement is selected, the fdRSAPortDirection for each cabinet fan shall be either output or bidirectional.

For each cabinet fan, the field device shall provide an entry in the RSA table where fdRSAType equals "RFO".

The cabinet generator feature indicates the status of the main cabinet generator.

There are no cabinet generator data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one voltage sensor for the cabinet generator. The project specification may specify support for additional voltage sensors for the cabinet generator.

The field device shall support at least one electrical current sensor for the cabinet generator. The project specification may specify support for additional electrical current sensors for the cabinet generator.

The field device shall support at least one engine speed sensor for the cabinet generator. The project specification may specify support for additional engine speed sensors for the cabinet generator.

The field device shall support at least one fuel level sensor for the cabinet generator. The project specification may specify support for additional fuel level sensors for the cabinet generator.

For each cabinet generator voltage sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RGV".

For each cabinet generator electrical current sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RGA".

For each cabinet generator engine speed sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RGS".

For each cabinet generator fuel level sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RGF".

The cabinet heater feature indicates the on/off status of each cabinet heater.

There are no cabinet heater data exchange requirements beyond those defined for the RSA feature.

The field device shall monitor each cabinet heater to determine if the heater is generating significant heat. If this requirement is selected, the fdRSAPortDirection for each cabinet heater shall be either input or bidirectional.

The field device shall allow remote on/off control of each cabinet heater. If this requirement is selected, the fdRSAPortDirection for each cabinet heater shall be either output or bidirectional.

For each cabinet heater, the field device shall provide an entry in the RSA table where fdRSAType equals "RHO".

The cabinet humidity feature indicates the current relative humidity of the air within the cabinet.

There are no cabinet humidity data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one cabinet humidity sensor. The project specification may specify support for additional cabinet humidity sensors.

For each cabinet humidity sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RCH".

The cabinet mains power feature indicates the status of the mains power line into the cabinet, which is generally provided from the power grid.

There are no cabinet mains power data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one voltage sensor for the cabinet mains power. The project specification may specify support for additional voltage sensors for the cabinet mains power.

The field device shall support at least one electrical current sensor for the cabinet mains power. The project specification may specify support for additional electrical current sensors for the cabinet mains power.

For each cabinet mains power voltage sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RLV".

For each cabinet mains power electrical current sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RLA".

The cabinet solar power feature indicates the status of the solar power system.

There are no cabinet solar power data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one voltage sensor for the cabinet solar power system. The project specification may specify support for additional voltage sensors for the cabinet solar power system.

The field device shall support at least one electrical current sensor for the cabinet solar power system. The project specification may specify support for additional electrical current sensors for the cabinet solar power system.

For each cabinet solar power voltage sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RSV".

For each cabinet solar power electrical current sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RSA".

The cabinet temperature feature indicates the current temperature of the air within the cabinet.

There are no cabinet temperature data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one cabinet temperature sensor. The project specification may specify support for additional cabinet temperature sensors.

For each cabinet temperature sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RCT".

The cabinet wind power feature indicates the status of the wind power system.

There are no cabinet wind power data exchange requirements beyond those defined for the RSA feature.

The field device shall support at least one voltage sensor for the cabinet wind power system. The project specification may specify support for additional voltage sensors for the cabinet wind power system.

The field device shall support at least one electrical current sensor for the cabinet wind power system. The project specification may specify support for additional electrical current sensors for the cabinet wind power system.

For each cabinet wind power voltage sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RWV".

For each cabinet wind power electrical current sensor, the field device shall provide an entry in the RSA table where fdRSAType equals "RWA".

The UTC clock feature allows a field device to maintain awareness of passing time; it represents the UTC time within the field device. However, there is no formal requirement as to the exact time source or accuracy. Ideally, it should be synchronized with a reliable and accurate time source in a secure manner.

The field device shall allow a management system to determine the capabilities of the UTC clock, including which time source and time-keeping options are available.

The field device shall allow a management system to configure which available time source and time-keeping option to use as well as the frequency for synchronizing the clock and when to report discontinuities in time synchronization.

The field device shall allow a management system to determine the configuration of the UTC Clock.

The field device shall allow a management system to determine the time source and time keeping option being used and the last time the clock was synchronized with the configured time source.

The field device shall allow a management system to determine the status of each supported time source.

If a field device supports the configured time capability of the UTC clock feature, the field device shall allow a management system to set the current UTC time using SNMP.

NOTE       This is perhaps the easiest time synchronization to implement, but also the least accurate. Variable multi-second communication network delays can occur between the time the manager initiates the set operation and the time the field device receives the command, especially when the command traverses a complex communications network.

The field device shall allow a management system to retrieve the current time in UTC.

NOTE       Variable multi-second communication network delays can occur between the field device transmitting the time and the manager receiving it – especially when the command has to traverse a complex communications network.

The field device shall allow a management system to determine information about discontinuities in its UTC time to enable to the detection of unusual behaviour in the clock.

NOTE     The UTC time is expected to consistently increment its value; however, resynchronizing with an outside time source can result in an adjustment, known as a discontinuity.

The field device shall allow a management system to configure the time by SNMP.

The field device allows the time to be set using the Network Time Protocol version 4 (NTPv4).

NOTE: NTPv4 does not have any security. Devices that support NTPv4 are encouraged to provide mechanisms to physically disable access to this protocol and thereby close a potential security threat for systems that choose not to use this feature.

The field device is able to set its time using a time signal broadcast over land-based radio waves.

The field device shall allow setting the time in the device based on satellite time signals.

The field device shall allow time-keeping by monitoring the local electrical line frequency.

The field device shall allow time keeping with the use of an on-board time crystal.

The local clock feature allows a field device to be aware of the local time as adjusted from the UTC clock by the local time zone and any daylight saving algorithms in effect, if the daylight saving feature is supported.

The field device shall allow a management system to configure the local time zone for the clock.

The field device shall allow a management system to confirm the configuration of the local clock.

The field device shall allow a management system to determine the local date and time.

The daylight saving time (DST) feature allows a manager to define when the local clock should spring forward and fall backwards to conform to local time customs. In addition to defining when the events occur, the design also allows the manager to specify how large of a shift is required. Finally, the design allows for multi-stage daylight savings adjustments (e.g., spring a half hour forward and then spring another half hour forward before falling back half an hour twice), but only requires support for a single stage. A procurement specification can require support for multi-stage changes, if deemed necessary.

The field device shall allow a management system to determine the number of daylight saving time event pairs that the device supports.

NOTE  A daylight saving time event pair consists of the spring forward and fall back events.

The field device shall allow a management system to configure the start and end times for daylight saving time as well as the amount of time that the local time should shift.

The field device shall allow a management system to confirm the configuration of the daylight savings schedule.

The field device shall allow a management system to determine the status of each daylight savings time rule.

The field device shall allow a management system to determine the total of the current daylight savings time adjustments.

If a field device supports the local clock feature, the field device shall support at least one annual daylight saving adjustment.

The command factory generates a SET request for an SNMP target when activated. The target may be the host field device or a remote field device.

The field device shall allow a management system to toggle the enabled status of a command factory.

The field device shall allow a management system to configure the command and the SNMP target(s) to which the command should be sent along with a description for the entry.

The field device shall allow a management system to configure an owner for commands.

The field device shall allow a management system to verify the configuration of a command factory.

The field device shall allow a management system to verify the command configuration settings for a specified owner.

The field device shall allow a management system to delete a command factory configuration.

The field device shall allow a management system to determine the maximum size (number of octets) allowed for the variable binding list associated with any fdCommandFactoryEntry.

The field device shall allow a management system to retrieve statistics that summarize the operation of all command factories.

The field device shall allow a management system to retrieve command-related statistics for an owner.

The field device shall allow a management system to retrieve statistics about the issuance of commands by the command factory.

The field device shall allow a management system to retrieve information about the last time the command was issued.

The field device shall allow a management system to retrieve the status of the command factory.

The field device shall support a variable binding list of at least 64 octets for each supported command.

The field device shall transmit a Set Request to the associated SNMP target, using the associated SNMP target parameters, each time the command factory is called.

A conditional trigger is a feature that monitors a pre-defined condition and "fires" when the condition transitions to a true state. The parameters that define the trigger also define when the trigger resets and whether the monitored condition changes upon reset. For example, a trigger may be defined to fire when a parameter exceeds a defined value. Depending on the configuration, the trigger may not reset until the parameter drops below the value (and then it monitors the same condition) or the trigger may immediately reset and begin monitoring when the value drops below a defined value.

A trigger can be based on:

any visible data from the local field device;

optionally, any visible data from an external SNMP target; or

optionally, an expression that may use data from the local field device and/or one or more external SNMP targets.

The field device shall allow a management system to configure an owner for conditional triggers.

The field device shall allow a management system to configure a trigger.

The field device shall allow a management system to verify the conditional trigger configuration settings for a specified owner.

The field device shall allow a management system to confirm the current configuration of a trigger.

The field device shall allow a management system to delete a trigger.

The field device shall allow a management system to toggle whether or not the trigger is currently enabled.

The field device shall allow a management system to discover the capabilities of the conditional trigger feature.

The field device shall allow a management system to retrieve statistics regarding all defined triggers.

The field device shall allow a management system to retrieve conditional trigger related statistics for a specified owner.

The field device shall allow a management system to retrieve statistics regarding the firing of a trigger.

The field device shall support triggers that fire when the specified object [or instance of the specified object type(s), if a wildcard is used] is created.

The field device shall support triggers that fire when the specified object [or instance of the specified object type(s), if a wildcard is used] is deleted.

The field device shall support triggers that fire when the monitored value (or values, if a wildcard is used) changes.

The field device shall support triggers that fire when the monitored value equals a specified value.

The field device shall support triggers that fire when the monitored value does not equal a specified value.

The field device shall support triggers that fire when the monitored value first exceeds a specified value.

The field device shall support triggers that fire when the monitored value first falls below a specified value.

The field device shall support triggers that fire based on a hysteresis condition. In other words, a rising trigger will fire when the monitored value first exceeds an upper threshold and this firing will also reset the falling trigger; likewise, a falling trigger will fire when the monitored value falls below a lower threshold and this firing will also reset the rising trigger.

The field device shall support triggers that fire periodically.

The field device shall support triggers that fire when the result of performing a bitwise 'AND' operation with the monitored value and a specified value produces a value that contains at least one set bit.

The field device shall support triggers based on the current value of a specified object.

The field device shall support triggers based on comparisons performed on the relative change in the value of a specified object since its last reading. In other words, the field device will determine the difference between two readings and compare this delta value in the operation (i.e., greater than, less than; equal, not equal, etc.) specified in the trigger.

The field device shall support the use of wildcards when specifying creation triggers. In other words, a single conditional trigger can be defined to monitor the creation of any object that starts with a particular OID string.

The field device shall support the use of wildcards when specifying creation triggers. In other words, a single conditional trigger can be defined to monitor the deletion of any object that starts with a particular OID string.

The field device shall support the use of wildcards when specifying on change triggers. In other words, a single conditional trigger can be defined to monitor changes to any object that starts with a particular OID string.

The field device shall support configuring triggers based on data from the local field device using the default context. In other words, this is the data that represents the current status and configuration of the local field device.

The field device shall support configuring triggers based on data from the local field device using a special context. For example, the local field device can potentially serve as a proxy engine for multiple other devices. While the data can be stored within the local device, the data represents the configuration and status of another device or subcomponent of this device.

The field device shall support configuring triggers based on data from a remote device. In other words, the field device shall be able to be configured to monitor values that it obtains by sending SNMP requests to other field devices (i.e., presumably field devices that do not offer their own support for triggers).

In the absence of any other specification, the field device shall support at least one trigger.

The field device represents the whole deployed unit including the controller and any attached equipment (e.g. sensors or displays that can be alongside or embedded in the roadway).

The field device shall allow a management system to discover the basic capabilities of the field device, including:

the maximum SNMP message size supported by the field device;

the amount of memory supported and available within the field device; and

the communication services provided by the field device.

The field device shall allow a management system to discover the MIB module capabilities to which the field device conforms.

The field device shall allow a management system to configure the field device's identity, including its:

contact,

name, and

location.

The field device shall allow a management system to identify the field device by retrieving the identity information that was configured for the device along with:

a description of the field device implementation, and

the unique identifier of the field device implementation.

The field device shall allow a management system to identify the identifier of the SNMP engine.

The field device shall allow a management system to quickly identify any change to the field device's configuration by monitoring a single parameter.

The field device shall allow a management system to determine if any of the following errors are detected:

PROM integrity error;

RAM integrity error;

program/process error;

display interface error;

roadside sensor input or actuator output error; or

other detected error (specific to make, model, and version of device).

The field device shall allow a management system to monitor the amount of time the controller has been operating since the last reboot and the number of reboots.

The field device shall allow a management system to determine the number of watchdog failures that have occurred.

The field device shall allow a management system to remotely reset the controller.

The field device shall allow a management system to configure the language to be used by controller when the controller writes textual values into objects.

Procurement specifications should identify which languages are to be supported by the field device.

The field device shall allow a management system to determine the current default language used by controller when it writes textual values into objects.

In the absence of any other specification, the maximum allowed response time for any standardized request shall be 100 ms.

The maximum response time for any non-standard request shall be calculated as follows:

Identify the minimum number of standardized request messages that contain all of the objects included in the request for which the calculation is being made.

The maximum response time for a non-standard request shall be the sum of the maximum response times for all of the standardized requests identified in Step a.

The field device shall support a maximum SNMP message size of at least 484 bytes. A specification may require support for larger SNMP message sizes.

The field device shall support an amount of changeable memory as specified by the specification.

The field device shall support an amount of volatile memory as specified by the specification.

Under all circumstances, the field device shall only allow each manager to access data to which it is explicitly authorized.

NOTE             This includes data that is recorded in logs, sent in notifications, and other indirect access mechanisms.

Tables that are likely to contain different definitions for different managers shall be designed to easily restrict access to authorized managers and avoid inadvertent conflicts.

EXAMPLE               A log can be designed to support a scheme where an administrative manager that has universal rights does not inadvertently change the definition of a log for another manager.

The day plan scheduler allows a field device to run a specified day plan, which consists of a series of triggers (e.g., commands) performed at pre-defined times of day. These actions can be enabled even if communications to the manager are not available when the actions are supposed to occur. Only one day plan can be active at any one time; if multiple managers are authorized to write to the day plan schedule, extra care should be taken to coordinate the actions taken.

The field device shall allow a management system to enable/disable the operation of a day plan scheduler. When disabled, the day plan scheduler shall continue to select the applicable day plan, but the day plan shall not issue any of the resultant day plan commands.

The field device shall allow a management system to disable the operation of a configured day plan schedule rule. When disabled, the rule will not affect the selection of a day plan.

The field device shall allow a management system to enable/disable an entire day plan. When disabled, any day plan schedule entry that is associated with the day plan shall be considered not ready and shall not be selected by the scheduling logic.

The field device shall allow a management system to enable/disable a specific trigger within a day plan. Disabling a day plan trigger shall not affect the status of the corresponding day plan.

The field device shall allow a management system to configure the rules for selecting a specific day plan and recording a description for each rule written.

The field device shall allow a management system to configure information that applies to all actions performed within a day plan (e.g., by defining a description and specifying the type of memory to use).

The field device shall allow a management system to configure a trigger to call an action to be performed as a part of a day plan.

The field device shall allow a management system to verify the configuration of the day plan schedule.

The field device shall allow a management system to determine the configuration of a day plan.

The field device shall allow a management system to determine the configuration of a day plan trigger.

The field device shall allow a management system to delete a day plan schedule rule.

The field device shall allow a management system to delete an entire day plan along with all of its scheduled triggers.

The field device shall allow a management system to delete a scheduled trigger within a day plan.