IRIS

Intelligent Roadway Information System

Action Plans

Select View βž” Plans and Schedules menu item

Action plans provide a way to automate and coördinate control of devices, such as DMSs and ramp meters.

API Resources πŸ•΅οΈ
  • iris/api/action_plan (primary)
  • iris/api/action_plan/{name}
Access Primary Secondary
πŸ‘οΈ View name
πŸ‘‰ Operate phase
πŸ’‘ Manage default_phase, notes, active sync_actions, sticky, ignore_auto_fail

Plan Phases

The phase of an action plan represents its current state. It can be changed manually by an operator or on specific conditions using phase actions. Advanced plans can have many phases, each with separate actions.

There are 8 built-in phases required for proper action plan operation:

Phase Name Description
deployed Generic "in use" actions
undeployed Generic "not in use" actions
alert_before Before alert actions
alert_during During alert actions
alert_aftger After alert actions
ga_open Gate arm open actions
ga_change Gate arm change actions
ga_closed Gate arm closed actions

Additional phases can be added on the Plan Phases tab. Each phase must have a unique name, and names are case-sensitive.

Only selectable phases can be chosen by an operator; otherwise they must be automatic, with phase actions.

API Resources πŸ•΅οΈ
  • iris/api/plan_phase (primary)
  • iris/api/plan_phase/{name}
Access Primary
πŸ‘οΈ View name
πŸ”§ Configure selectable

Phase Actions

A phase action can automatically change the phase of an action plan. When the specified condition occurs, it will become to_phase. This can be limited to specific days using a day plan. Also, if from_phase is set, it will only take effect if the current phase matches.

API Resources πŸ•΅οΈ
  • iris/api/phase_action (primary)
  • iris/api/phase_action/{name}
Access Primary
πŸ‘οΈ View name, action_plan
πŸ’‘ Manage day_plan, condition, params, from_phase, to_phase

Conditions

There are several conditions which can trigger a phase change. Each condition has parameters which may include keywords for Field, Mode or Period. These may be abbreviated, as long as they match a unique prefix (e.g. occupancy could be shortened to occ).

Hold Time

Condition triggers when the plan has been in from_phase for longer than the hold time.

  • Params: s, mm:ss or HH:mm:ss

  • Example: 15:00 (for 15 minutes)

Clock Time

Condition triggers at a specific time of day, optionally on a specific date.

  • Params: HH:mm or yyyy-MM-dd'T'HH:mm

  • Example: 2026-05-01T14:00 (at 2 PM on May 1, 2026)

Traffic Threshold

Condition triggers when a detector or station field goes above or below a threshold value.

  • Params: Detector or station ID, field < or > value

  • Field keywords: speed, flow, density, occupancy

  • Example: 1234,den>30 (when detector 1234 has density greater than 30)

RWIS Threshold

Condition triggers when an RWIS field goes above or below a threshold value.

  • Params: Sensor ID, field < or > value

  • Field keywords: friction, surface_temp, wind_gust, visibility, precipitation

  • Examples:

    Params Station Meaning Suggested Message
    WS0123,fric<70 WS0123 friction below 70 SLIPPERY
    WS0123,surf<0 WS0123 surface temp below 0 VERY SLIPPERY
    WS0123,fric<60 WS0123 friction below 60 ICY
    WS0001,wind>64 WS0001 gusts above 64 WIND GUSTS
    WS0001,wind>96 WS0001 gusts above 96 HIGH WINDS
    WS0666,vis<1609 WS0666 vis. below 1 mi REDUCED VISIBILITY
    WS0666,vis<402 WS0666 vis. below 1/4 mi LOW VISIBILITY
    WS0012,precip>6 WS0012 hour rain above 6 mm FLOODING POSSIBLE
    WS0012,precip>8 WS0012 hour rain above 8 mm FLASH FLOODING
Alarm

Condition triggers when an alarm is triggered or cleared.

  • Params: Alarm ID, state

  • State keywords: triggered, cleared

  • Example: A100,trigger

Device Actions

Device actions use hashtags to associate devices with one phase of an action plan. These devices can be:

Any number of device actions can be associated with each phase of an action plan.

Priority determines the priority of messages created by the action. For camera actions, instead this indicates:

API Resources πŸ•΅οΈ
  • iris/api/device_action (primary)
  • iris/api/device_action/{name}
Access Primary Secondary
πŸ‘οΈ View name, action_plan
πŸ’‘ Manage hashtag, phase msg_priority, msg_pattern

Action Tags

A device action message pattern is a message to display on a device. These patterns support additional action tags which are not valid MULTI. They are only usable in device actions - not operator-composed messages.

Replace tags are substituted with computed text before being sent to a sign. For example, a [tt … ] tag will be replaced with the current estimated travel time. These tags can be used only on DMS devices.

Condition tags add a stipulation which activates the device only when the condition is met. These tags can be used with any device type, such as a flashing beacon.

Tag Description Tag Mode Source
[cg … ] ClearGuide data Condition + Replace clearguide
[exit … ] Exit ramp backup Condition exit_warning
[feed … ] Msg-Feed protocol message Replace N/A
[pa … ] Parking area availability Replace parking
[slow … ] Slow traffic warning Condition + Replace slow_warning
[standby] Standby messages Standby standby
[ta … ] Time action Replace N/A
[tt … ] Travel time estimation Replace travel_time
[tz … ] Toll zone pricing Replace tolling
[vsa] Variable speed advisory Condition + Replace speed_advisory

Time Action Tag

The time of a phase action with a Clock Time condition can be displayed in DMS messages using device actions within the same action plan. A [ta … ] action tag in the message pattern will be replaced with the appropriate value. It has the following format:

[ta dir,format ]

Parameters

  1. dir: Chronological direction
    • n: Next phase action with Clock Time after the current time
    • p: Previous phase action with Clock Time before the current time
  2. format: Time format pattern (h a if omitted)

The format parameter is specified using a Java DateTimeFormatter pattern, summarized in this table:

Symbol Meaning
h hour (1-12)
H hour of day (0-23)
mm minute (00-59)
a AM or PM
E weekday (e.g. Mon)
EEEE full weekday (e.g. Monday)
d day of month (1-31)
M month number (1-12)
L month (e.g. Jan)
LLLL full month (e.g. January)

The default pattern, h a, would format a time at 2 in the afternoon as 2 PM. To include minutes, h:mm a could be used instead.

Example 1

ROAD WORK[nl]STARTING AT [tan,h:mm a]

If next scheduled action is at 2:30 AM, the resulting message will be:

ROAD WORK
STARTING AT 2:30 AM

Example 2

BLIZZARD WARNING[nl]FROM [tap][nl]UNTIL [tan]

If the time is between two scheduled actions, 4 AM to 10 PM, the message will be:

BLIZZARD WARNING
FROM 4 AM
UNTIL 10 PM

Day Plans

A day plan is a set of days which can be used for scheduling. They contain a table of day matchers, which specify either active days or holidays, depending on the holidays flag. A matcher contains 5 fields, which can be NULL for "any":

API Resources πŸ•΅οΈ
  • iris/api/day_plan (primary)
  • iris/api/day_plan/{name}
Access Primary
πŸ‘οΈ View name, holidays
  • iris/api/day_matcher (primary)
  • iris/api/day_matcher/{name}
Access Primary
πŸ‘οΈ View name, day_plan, month, day, weekday, week, shift

Manual Control

On the Plan tab of the client interface, users can manually change the phase of an action plan. In addition to having "Operate" access permission for action plans, the user must have it for all associated device actions (every device using the matching hashtag).

Events

Whenever an action plan phase changes, a time-stamped event record can be stored in the action_plan_event table.

When a user changes the phase, if they are in the list specified by the action_plan_alert_list system attribute, an email event will be logged to the email_event table.

Repository: IRIS