IRIS

Intelligent Roadway Information System

Action Plans

Select View ➔ Plans and Schedules menu item

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

Notes: administrator notes, possibly including hashtags
Sync Actions: if selected, the phase can only be changed if all associated devices are online.
Sticky: if selected, messages sent with device actions will be configured to persist even if communication or power is lost. Also, pixel service checks will be enabled.
Ignore Auto-Fail: if selected, device action messages will ignore detector auto-fail ([exit … ] or [slow … ] only)

API Resources 🕵️

iris/api/action_plan (primary)
iris/api/action_plan/{name}

Access	Primary	Secondary
👁️ View	name
👉 Operate		phase
💡 Manage	notes, active	sync_actions, sticky, ignore_auto_fail, default_phase

Plan Phases

A plan phase is used to associate device actions with a plan. The current phase can be changed by an operator, or at specified times with time actions.

A phase can be associated with any number of device actions. Advanced plans can have many phases, each with separate actions.

The basic phases are deployed and undeployed. Additional phases can be added on the Plan Phases tab. Each phase must have a unique name. By specifying Hold Time, a transient phase will advance automatically to the Next Phase. Hold Time must be a multiple of 30 seconds.

API Resources 🕵️

iris/api/plan_phase (primary)
iris/api/plan_phase/{name}

Access	Primary
👁️ View	name
🔧 Configure	hold_time, next_phase

Device Actions

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

DMS, displays the message pattern on the sign
ramp meter, enables metering operation
beacon, activates flashing lights
camera, recalls the specified camera preset
lane marking, activates in-pavement LEDs

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

0 activate wiper
1-12 a preset number to recall

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.

Tag	Description	Tag Mode
`[cg` … `]`	ClearGuide data	Replace
`[exit` … `]`	Exit ramp backup	Condition
`[feed` … `]`	Msg-Feed message	Replace
`[pa` … `]`	Parking area availability	Replace
`[rwis_` … `]`	RWIS weather conditions	Condition
`[slow` … `]`	Slow traffic warning	Condition + Replace
`[standby]`	Standby messages	Standby
`[ta` … `]`	Scheduled time actions	Replace
`[tt` … `]`	Travel time estimation	Replace
`[tz` … `]`	Toll zone pricing	Replace
`[vsa]`	Variable speed advisory	Condition + Replace

Time Actions

A time action automatically changes the phase at specified dates and times. These events are scheduled using either a day plan or a specific date (but not both). A time of day must also be specified (HH:MM in 24-hour format). Whenever the scheduled time occurs, the action plan will be changed to the specified phase.

API Resources 🕵️

iris/api/time_action (primary)
iris/api/time_action/{name}

Access	Primary	Secondary
👁️ View	name, action_plan	day_plan, sched_date, time_of_day
💡 Manage		phase

Time Action Tag

The time of a scheduled time action 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

dir: Chronological direction
- n: Next scheduled time action after the current time
- p: Previous scheduled time action before the current time
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 time 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 time 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":

Month (1-12)
Day (1-31)
Weekday (1-7)
Week (1-4, or -1 for last)
Shift - only needed for days like Black Friday (Fourth Thursday of November +1)

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. If the user is in the list specified by the action_plan_alert_list system attribute, an email event will be logged to the email_event table.

Events

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