Progress Report by UUzgpZav

VIEWS: 17 PAGES: 82

									                                   Progress Report

Reporting Period: January 2005 – March 2005

Reference: Research Project Work Order #6 -- Federal Aid Project CFDA-20.205 /
Contract No. BC543, "Standards Research, Testing & Training Development for the
Traffic Engineering Research Lab."

Investigators: Faculty -- Leonard J. Tung (P.I.), Jim Simpson, and Jim Zheng

              Technical Consultant -- James Langston (on call only)

              Research Associate -- Olivier Marietta-Tondin
                                    Khue Ngo, Lead Associate
                                    Francisco Ortiz
                                    Sivam Ramalingam

              Technical Staff --    Christine Chen
                                    Doug Murphy (started in January)
                                    Angela Ruffin
                                    Chris Taylor


              Department of Electrical and Computer Engineering
              FAMU-FSU College of Engineering, Florida State University
              2525 Pottsdamer Street, Tallahassee, FL 32310
              Phone: (850)410-6469 / Fax: (850)410-6479 / Email: tung@eng.fsu.edu


Project Manager:     Jeffrey M. Morgan

                     State Traffic Engineering and Operations Office
                     Traffic Engineering Research Lab
                     Florida Department of Transportation
                     605 Suwannee Street, MS 36
                     Tallahassee, FL 32399-0450

______________________________________________________________________
This report was prepared by Leonard J. Tung, April 2005.
                                                  Progress Report No.5: January 2005 – March 2005



1. PROGRESS
1.1 Milestones accomplished during this reporting period:

   January 13, 2005: Transportation Control Systems (Suncoast Metal Fabrication)
      became qualified as a FDOT Manufacturer of wired cabinet.

   January 19, 2005: Newbasis became qualified as a FDOT Manufacturer of pull boxes.
      Tomar Electronics, Inc. became qualified as a FDOT Manufacturer of pre-
      emption device.

   February 3, 2005: Electrotechnics Corporation became qualified as a FDOT
      Manufacturer of time switche and wired cabinet.

   February 14, 2005: Cost Cast Inc.became qualified as a FDOT Manufacturer of traffic
      signal mount.

   February 28, 2005: Traficon USA became qualified as a FDOT Manufacturer of video
       vehicle detector.

   March 1, 2005: Synertech became qualified as a FDOT Manufacturer of pull box.

   March 3, 2005: Electronic Integrated Systems Inc.became qualified as a FDOT
       Manufacturer of microwave vehicle detectors.

   March 15, 2005: Southern Manufacturing became qualified as a FDOT Manufacturer
       of traffic control cabinet and intersection illumination street sign.

   March 15, 2005: ADDCO     passed the NTCIP Qualification Test for Permanent Mount
       Dynamic Message Signs.

   March 29, 2005: McCain qualified as a FDOT Manufacturer of traffic controller.
      Chemque Inc. qualified as a FDOT Manufacturer of loop sealant.

   March 30, 2005: Bondo Corporation qualified as a FDOT Manufacturer of loop
      sealant.


1.2 Schedule
    Faculty Researchers:
       Leonard Tung is in charge of the administration part of the project and also works
       in the following areas of research: NTCIP and Dynamic Message Signs (DMS).
       In the spring of 2005, he works out of his office in A341 in COE.

       Jim Zheng coordinates the research activities of the Monitoring of LED Traffic
       Signals area that includes the testing of LED signal heads, conventional signal


                                              1
                                                Progress Report No.5: January 2005 – March 2005


       heads and dynamic message signs.

       Jim Simpson coordinates the research activities of the quality research team. He
       works in the areas of statistical process control and experimental design
       techniques concerning the FDOT Equipment Approval Process including the
       FDOT Approved Product List.

   Research Associates and Technical Staff:
      At the moment, the research team consisted of one consultant, four research
      associates, and four technical staff members. The team has been given various
      tasks involving the surveying, collecting and compiling of specifications and
      standards in the research areas of Light Emitting Diodes, Less-Intrusive Vehicle
      Detection, Dynamic Message Signs, NTCIP, Advanced Transportation
      Controllers, Quality Control Certification, and Testing Infrastructure
      Improvements. The team's tasks also include the testing of various devices for
      compliance to specifications.

    In the spring of 2005, the team's weekly meeting has been scheduled on Thursday
from 9:15 to 10:15 AM. During these meetings, each team member is required to report
the work done during the past week, problems encountered if any and projection of future
activity. Each team member is to maintain a personal log detailing his/her research work.
Also during each meeting, one team member is required to give a detailed formal report
on his/her work. The minutes of the meetings are recorded. The spring schedule of the
research team is attached. (Attachment 1)

1.3 Mode of Operation
    FDOT Project/Lab Manager, Jeff Morgan, works each weekday with the research
    team to guide and direct the progress of the research being done.

   Carl Morse and Bob Griner of FDOT and Steve Bentz of PBS&J support Mr. Morgan
   in various areas of work at the TERL.

   The members of the research team continue to maintain the practices and procedures
   of the TERL, which have been developed and regularly revised since their forming.

   Each student is assigned a personal record book to record all research and testing
   activities performed at the Lab. A reading file notebook, containing all practices and
   procedures adopted by the TERL has been implemented as required reading for all
   staff.

1.4 Summary of the Research Tasks
    Our research efforts are concentrated in the following areas:
       a) Monitoring of LED Traffic Signals – Signal Illumination:
          This area consists of the research and monitoring of light emitting diode (LED)
          vehicular traffic / pedestrian signals and other luminary technologies that may
          be applicable for this use (including DMS testing.) Doug Murphy, an



                                            2
                                        Progress Report No.5: January 2005 – March 2005


  undergraduate and a technical staff, has been working closely with and under
  the supervision of Dr. Zheng since January. A progress report by Doug is
  attached. (Attachment 5)

b) Vehicle Detection and GPS:
   This area consists of the research and identification of application and
   performance standards for the various less-intrusive vehicle detection
   technologies and pedestrian detection technologies. Khue Ngo, a graduate
   student and TERL Research Associate, works closely with Mr. Morgan, Mr.
   Morse and Dr. Tung in this area. A progress report by Khue is attached.
   (Attachment 2) Chris Taylor, an undergraduate and a technical staff, has been
   working with Khue in the area of GPS. A progress report by Chris is attached.
   (Attachment 4)

c) National Transportation Communications for ITS Protocol (NTCIP):
   This area consists of the research and identification of NTCIP testing and
   performance standards of various devices, such as traffic signal and DMS
   controllers, for ITS applications. Angela Ruffin, an undergraduate and
   technical staff, work closely with Dr. Tung and Mr. Morgan in this area.
   Angela together with James Langston, a technical consultant (on-call only), has
   trained Khue Ngo and Chris Taylor in the area of DMS NTCIP-Compliance
   testing. A report by Khue and Angela is attached. (Attachment 6)

d) Technology Transfer:
   This area consists of developing ways to disseminate the product developed at
   the TERL to interested parties. The TERL website was updated and moved to
   the following address: http:/potentia.eng.fsu.edu/. Technical staff/
   administrative assistant Christine Chen is working on a 10-minute introduction
   video presentation of the TERL under the supervision of Mr. Morgan and Dr.
   Tung. Further development and daily maintenance of the Departments web-
   based interactive Approved Product List (APL) is also a responsibility of this
   area.

e) Advanced Transportation Traffic Signal Controller & Intersection Operation:
   Effort in this area is limited to NTCIP Compliance of ASC by the NTCIP team.

f) Quality Engineering:
   This area consist of the following two areas: 1) the continued refinement and
   implementation of the FDOT APL Vendor Quality Assurance Program
   developed at the TERL and 2) the analyzing of all testing procedures
   performed at the TERL to enhance their efficiency and accuracy. Francisco
   Ortiz, Olivier Marietta-Tondin, and Sivam Ramalingam, all graduate students
   and TERL Research Associates, assists Dr. Simpson & Mr. Morgan in the
   refinement and implementation of this program. Steve Bentz of PBS&J has
   joined this group in February to help implementing the program. A progress
   report by the Quality Research Team is attached. (Attachment 3)



                                    3
                                           Progress Report No.5: January 2005 – March 2005




1.4.1 The following research tasks are currently in progress:
    1) NTCIP Standards Development, Testing and Training
         testing in progress for devices submitted by DMS manufacturer ADDCO
         completed the NTCIP Qualification Test for Adaptive Micro Systems
           Permanent Mount Dynamic Message Sign
         literature search in progress for existing ASC functional requirements and
           specifications involving NTCIP
         review of NTCIP 1202 Version 1 and 2 standards (in progress)
         review of NEMA TS 2 standard (in progress)
         review of ASC MIB developed by Dade County in 1999 (in progress)
         review of Naztec documentation of ASCs implementing NTCIP (in
           progress)
         review of NTCIP 8007 NTCIP Testing and Conformity Assessment
           Documentation Within NTCIP Standards Publications Comment Draft
         review of IEEE 829 IEEE Standard for Software Test Documentation
         initial development with Intelligent Devices, Inc. NTCIP ActiveX Control
           and Device Tester software
         work with JScript .NET (possible language for development of test
           scripts)

   2) Quality Research Engineering
        modification of the quality control minimum standards checklist (ongoing)
        development began on the 2nd phase of this program: a monitoring
          program to verify compliance to quality standards once a device is sold
          and installed in the state. (ongoing)

   3) Display Properties Testing for LED Traffic Signals and DMS
        design and build a 60-foot light tunnel (design complete, construction is
          ON HOLD)
        purchase equipment for the PC based testing system (on hold)
        chromaticity study of LED signal heads (on going, with several brands by
          various manufacturers being tested)
        intensity study of signal heads (on going, with several brands by various
          manufacturers being tested)
        viewing angle study of LEDs on DMSs (ongoing)
        intensity test of flasher LED warning signals (ongoing)
        test procedures documentation (under revision)

   4) Vehicle Detection
        evaluation of various installed detector technologies (ON HOLD)
        re-evaluation of various detectors that were previously evaluated by the
          TERL (ON HOLD)
        update the current TERL developed vehicle detection standards
          (microwave, infrared, video, radar, etc.) which contain the minimum


                                       4
                                          Progress Report No.5: January 2005 – March 2005


       standards required to become approved and placed on the Approved
       Product List (APL). (Complete)
      develop analytical software tools to perform statistical analysis on the
       travel-time data collected with GPS technology. (90%)

5) Traffic Engineering Applications
     identify a Traffic Engineering Consultant that will be working on an as-
        needed basis on Traffic Engineering issues. (ON HOLD)

6) Technology Transfer
     updated and moved the TERL project internet web site now located at
       http://potentia.eng.fsu.edu, (includes the Approved Product List (APL)).
     publish TERL quarterly newsletter, Technology Lab Notes, which
       highlights a specific activity each quarter. (ON HOLD)

7) Continue the solicitation, compiling, and sorting of specs / standards in all
major research areas (on going).




                                      5
                                                 Progress Report No.5: January 2005 – March 2005




2. Next Quarter Goals and Objectives:
2.1 NTCIP Testing Procedures:
1) Continue the support of the TERL Dynamic Message Sign Pre-qualification Program.
2) Continue the development of the Actuated Signal Controller NTCIP standards for
    Florida.
3) Begin development of an NTCIP/SunGuide device testing program for all ITS
    devices supported by the FDOT SunGuide software.

2.2 Monitoring of LED Traffic Signals:
1) Investigate the discrepancy of intensity measurements collected with two devices
    (with Photo Research colorimeter and with a power meter) and those measured by an
    independent national lab.
2) Finalize the development of the TERL Statewide LED Signal Monitoring Program.

2.3 Dynamic Message Sign (DMS) Technology:
1) Continue other work being done, concerning the DMS, in the NTCIP and Monitoring
    of LED Traffic Signals (display testing) areas.

2.4 Vehicle Detection: (ON HOLD)

2.5 Vehicle Traffic Controller Technology:
1) Develop the knowledge required to produce training material and provide training
    and assistance concerning signalized intersection & traffic controller operation
    (isolated and coordinated intersection operation).
2) Start the development of testing procedures to be used to evaluate a traffic controller
    to FDOT standards that will be used late to automate the testing procedures
    (including the development of a Florida Specific ASC MIB).

2.6 Quality Engineering:
1) Continue the review and enhancement of the TERL Quality Assurance Program and
    implement the program to determine the existence and level of quality control and
    assurance programs in-place by approved FDOT manufacturers in their manufacture
    of traffic equipment.
2) Complete the QA/QC review of the FDOT Approved Product List and recommend
    changes.
3) Aid in the statistical analysis of experiments in LED testing and NTCIP compliance
    testing.

2.7 Portable GPS Unit for Moving Vehicle Studies:
1) To evaluate the potential of a portable GPS device as an effective research tool for
    conducting moving vehicle studies.
2) To evaluate or develop applications programs for reading and subsequently compiling
    the raw data acquired by the GPS unit. A database program is required to present the
    results in a convenient format.


                                             6
                                                Progress Report No.5: January 2005 – March 2005



3) To evaluate or develop application software for computing the distance, travel time,
   delay, stops, and fuel consumption based on the data collected by the GPS unit.


2.8 Technology Transfer:
1) To maintain the web site located at http://rite.eng.fsu.edu
2) To maintain the quarterly publication of the Technology Lab Notes newsletter.
3) Produce an introductory video describing the activities at the TERL.
4) Present lab material at various meetings, workshops, etc.
5) Maintain the computer network at the TERL.

2.9 Training:
1) Continue the development of training facilities in each area of research.




                                            7
            Progress Report No.5: January 2005 – March 2005




Attachment 1
Schedule for TERL
   Spring 2005




        8
                                                                 Progress Report No.5: January 2005 – March 2005




                              TERL Schedule for Spring 2005 Semester

                             Monday            Tuesday            Wednesday          Thursday            Friday        Hrs

Christine Chen              8:30 – 2:00       8:30 – 2:00          8:30 – 2:00      8:30 – 12:00                       20

Chris Taylor               11:50 - 12:50      1:05 - 3:05         11:50 - 12:50      1:05 - 3:05       10:50 - 12:50   10
                            2:00 - 3:00                            2:00 - 3:00

Doug Murphy                11:00 – 2:00                           11:00 - 2:00      8:00 - 10:15       11:00 - 2:00    20
                                                                   3:00 - 6:00       2:30 - 5:15        3:00 - 6:00

Khue Ngo                    1:00 - 5:00       1:00 - 4:00          1:00 - 5:00      9:00 – 11:00                       16
                                                                                     1:00 - 4:00

Angela Ruffin               1:00 – 3:30       2:30 – 4:30          1:00 – 3:00      9:00 – 10:00        1.00 – 3.30     8

Francisco Ortiz                               11:00 – 3:00        9:00 - 12:00      9:00 - 12:00                       13
                                                                                     1:00 – 4.00

Sivam Ramalingam            11:00 -2:00       9:00 - 2:00         11:00 - 2:00       9:00 – 2:00        9:00 – 1:00    20

Steven Bentz                7:30 -5:00         7:30 -5:00          7:30 -5:00        7:30 -5:00         7:30 -5:00     40

Olivier Tondin              8:00 - 11:00      8:00 - 11:00        8:00 - 11:00      8:00 - 11:00       8:00 - 11:00    15


        The meetings are scheduled for Thursdays at 9.15 am

        CONTACT INFORMATION:
        IPTEL                              410-6415                    EE Fax                     410-6479
        TERL (FSU Line)                    410-6492                    TERL Fax                   410-6402
        Jeff Morgan                        414-5254                    jeffrey.morgan@dot.state.fl.us
        Carl Morse                         414-4863                    carl.morse@dot.state.fl.us
        Bob Griner                         414-4865                    bob.griner@dot.state.fl.us
        Dr. Leonard Tung                   410-6469                    tung@eng.fsu.edu
        Dr. Jim Zheng                      410-6464                    zheng@eng.fsu.edu
        Dr. Jim Simpson                    410-6354                    simpson@eng.fsu.edu
        Christine Chen                     668-3102                    yfs@devils.eng.fsu.edu
        James Langston                     421-8453                    langston@eng.fsu.edu
        Doug Murphy                        350-0373                    murphdo@eng.fsu.edu
        Khue Ngo                           339-2482                    khuengo@eng.fsu.edu
        Francisco Ortiz                    410-6332/284-5824 (cell)    fortiz@eng.fsu.edu
        Sivam Ramalingam                   561-0699                    ramalsi@eng.fsu.edu
        Angela Ruffin                      915-5765                    ruffian@eng.fsu.edu
        Olivier Marietta-Tondin            321-6542                    marietta@eng.fsu.edu
        Chris Taylor                       818-497-1784                cat02e@fsu.edu
        Steve Bentz                        342-3330/508-0007(cell)     steven.bentz@dot.state.fl.us (not avail)



                                                             9
                Progress Report No.5: January 2005 – March 2005




  Attachment 2
Research Progress Report

          By

       Khue Ngo




           10
                                                    Progress Report No.5: January 2005 – March 2005


                         Traffic Engineering Research Laboratory
       Florida Department of Transportation and FAMU - FSU College of Engineering

            Research Progress Report – 1st Quarter 2005
Vehicle and Pedestrian Detection System + GPS Travel Time + NTCIP


 Area Manager: Dr. Leonard J. Tung
 Research Associate: Khue Q Ngo
 Date: April 2005

     1. TERL network maintenance

 Most of the time, I set up, maintained the computer system. The job description running from set
 up new workstation, install software, backup the system, troubleshot network printers to
 reconfigure the system, adding new devices.

     2. NTCIP

 Meeting with NTCIP group (James Langston, Angela Rufftin and Chris Taylor) every other
 week, discussing the NTCIP testing and specification issues.

 Reviewed NTCIP 120x standards.


     3. TMC and ITC Test Plan

 Being an active member in TMC and ITC Test Plan project, we have weekly meeting discussing
 the indispensable work to prepare for the test lab in July 2005. Reviewed plans and made
 suggestions. Working on putting a mock-up TMC system to testing purpose.

     4. GPS project

 Guided Chris Taylor on programming the interface for GPS based travel time analytical software.

     5. Other tasks

 Maintaining and updating the working schedule for all research associates. Producing the TERL
 meeting minutes every week.

 Reviewed and wrote summary report on Video vehicle Detection system.

 Reviewed ITS office’s Magnetic Non-intrusive Vehicle Detector Specs.

 Reviewed the Redlight Traffic Camera Guide.




                                               11
                Progress Report No.5: January 2005 – March 2005




  Attachment 3
Research Progress Report

          By

 Quality Research Team




           12
                                       Progress Report No.5: January 2005 – March 2005



   Traffic Engineering Research Laboratory (TERL)


          Florida Department of Transportation (FDOT)



                  Quality Assurance Department

Progress Report




                             For Period:

                  January 1st 2005 – March 31th 2005



                       Quality Research Team:

                         Dr. James Simpson
                           Francisco Ortiz
                       Olivier Marietta-Tondin
                            Steven Bentz
                         Sivam Ramalingam




                                  13
                                                   Progress Report No.5: January 2005 – March 2005



1.0    Introduction
       In the first quarter of 2005 the number of submittals by manufacturers gradually
       increased with significant build up in the pre-evaluation loop. It was mainly
       because the deadline for the qualification was just around the corner (February 28,
       2005). This challenge however, was handled quite smoothly, because the pre-
       evaluation system was updated and improved (details in section 3.0). The new
       version QA survey is now under full implementation. Any new submittal that
       does not adhere to the new format fails pre-evaluation immediately.
       Work on LED fixtures test procedures from design of experiment approach,
       resumed. Francisco and Olivier undertook a significant part of this work
       previously. Sivam assisted by Doug Murphy, the research assistant working in the
       LED area, is now continuing this work.


2.0    Personnel
       FDOT appointed Mr. Steven Bentz on February 1, 2005. Steve serves as full time
 personnel and currently stationed in the COE building to look after quality matters. Steve also
 assists Jeff Morgan in handling inquiries by manufacturers. Steve is currently is being trained
 by other QRT members and has gained satisfactory proficiency that he is able to perform his
 own evaluation.


3.0    QA Evaluation Tools
       Internal quality documents are subject to continuous upgrade and improvement. A
       standardized pre-valuation format was established and incorporated in the
       database. This allowed automated report generation for pre-evaluation process.
       This feature has tremendously reduced the time it takes to perform one pre-
       evaluation. Currently an attempt to create the same feature for the evaluation
       process is undergoing.
       Francisco at this moment is working on developing a draft of re-evaluation
       protocol, which, is the next phase of this program.




                                              14
                                                     Progress Report No.5: January 2005 – March 2005



4.0     QRT Presentations at TERL
        QRT Personnel made two Presentations at the TERL:


        1. Upgrades in the QA Survey and evaluation – Francisco Ortiz
        2. Upgrades in the Database system – Olivier Marietta-Tondin



5.0     QA Evaluation Update
        To date 89 Vendors/Manufacturers have submitted documents for qualification
                29 have qualified (5 of 29 are DMS makers)
                7 are due for re-qualification (1 of 7 is a DMS maker)
                50 remain in the system in various queues and re-routings
                3 Remain inactive


Status of Companies as of end of 1st Quarter 2005

                          Company Name                                          Status
  Optisoft                                                             Due for Re-evaluation
  3M / ITS                                                             Due for Re-evaluation
  Eagle Traffic Control Systems                                        Due for Re-evaluation
  Skyline                                                              Due for Re-evaluation
  Vultron, Inc. (DMS)                                                  Due for Re-evaluation
  Reno A&E                                                             Due for Re-evaluation
  Armorcast                                                            Due for Re-evaluation
  Polara Engineering, Inc.                                             Qualified
  Dambach, Inc. (DMS)                                                  Qualified
  Adaptive Micro Systems, Inc. (DMS)                                   Qualified
  US Traffic Corporation (IDC)                                         Qualified
  Mark IV (DMS)                                                        Qualified
  Gelcore                                                              Qualified
  Swarco (DMS)                                                         Qualified
  Daktronics (DMS)                                                     Qualified
  Newbasis                                                             Qualified
  Temple                                                               Qualified
  Southern Manufacturing                                               Qualified
  McCain                                                               Qualified



                                                15
                                                    Progress Report No.5: January 2005 – March 2005


  Pencell Plastics                                                      Qualified
  Atlantic Scientific                                                   Qualified
  Leotek                                                                Qualified
  Eberle Design (aka EDI)                                               Qualified
  Synertech                                                             Qualified
  Dialight                                                              Qualified
  Naztec                                                                Qualified
  Transportation Control Systems (Suncoast Metal Fabrication)           Qualified
  Econolite Control Product                                             Qualified
  Control Technologies                                                  Qualified
  Bondo Corporation                                                     Qualified
  Electrotechnics Corporation                                           Qualified
  Traficon USA                                                          Qualified
  Cost Cast Inc.                                                        Qualified
  Tomar Electronics, Inc.                                               Qualified
  Chemque Inc.                                                          Qualified
  Electronic Integrated Systems Inc.                                    Qualified


6.0     Future Plans
        Development of re-evaluation protocol for the qualified manufacturers shall be one of the
main agenda of future-plan and it has already begun. Visits to the manufacturers’ facilities are
currently under planning. This activity would serve well in the development of re-evaluation
protocol and help to improve the current pre-evaluation and evaluation system that are in place.
These site visits are anticipated to take place sometime in May 2005.




                                               16
                Progress Report No.5: January 2005 – March 2005




  Attachment 4
Research Progress Report

          by

      Chris Taylor




           17
                                    Progress Report No.5: January 2005 – March 2005



                        Progress Report
                       As of Apr 12, 2005
                          Chris Taylor

Projects Summary
     + GPS software with Khue Ngo
          + Polished UI

          + Finished basic graphing features
          + Finished “all run” graphing feature
          + Planned for HTML report format

          + Working on GPS database importing
     + NTCIP
     + iAPL

     + Miscellaneous


              Project: GPS software with Khue Ngo
     This project’s design tree has two major branches, the
front-end and the back-end. In the last months I have been
continuing to write the front-end, and I have been re-writing the
back-end. Each task requires a different development strategy.
     To review, the overall project is intended to offer
graphical analysis of data collected in the field. Cars are
tagged with GPS sensors provided by Time Management Inc.
(http://vehiclewatch.com), which they call TMGPS. The data is
pre-processed into an Access database, which is then interpreted
by Muffin to be presented through Bagel.

I had already completed a tool to select databases:




                               18
                                  Progress Report No.5: January 2005 – March 2005




This is the first screen shown to the user.




                             19
                                  Progress Report No.5: January 2005 – March 2005


Immediately afterwards, the user may adjust graph
properties. This is an improvement over my original
design, which involved multiple forms.




The wizard design pattern was removed in an effort to make
the feel of the application more professional.

It’s also intended to be more powerful. All of the options
are in one place, and many more are available now to adjust
the format of the resulting graph.

The “Bagel” back-end component has been completed for the
features required so far, those visible in the UI.




                             20
                                  Progress Report No.5: January 2005 – March 2005




On the next page are some examples of the present output.




                             21
     Progress Report No.5: January 2005 – March 2005




22
     Progress Report No.5: January 2005 – March 2005




23
                                  Progress Report No.5: January 2005 – March 2005


I wrote a NSIS script (Nullsoft Scriptable Install System)
for the GPS project that detects when required components
are already installed and allows you to install them in a
graphical interface.

This means that the installation procedure involves a
single executable with an intuitive UI.




Project: NTCIP
I have been meeting with James about this project. It’s
mainly in the hands of James and Angela right now, but Khue
and I are receiving training.



                             24
                                  Progress Report No.5: January 2005 – March 2005




Project: iAPL
I have been unable to meet with Brandon on this project.
This is a problem because he is the only one with keys to
the server. I am also waiting for a reply to an E-mail
from the FDOT inquiring about the standards for an APL that
runs on DOT servers.


Project: Miscellaneous
+ automated testing for Doug
+ tech support for the workgroup
+ brought in a phone




                             25
                Progress Report No.5: January 2005 – March 2005




  Attachment 5
Research Progress Report

          by

    Doug Murphy




           26
                                                    Progress Report No.5: January 2005 – March 2005


                           Traffic Engineering Research Laboratory
         Florida Department of Transportation and FAMU - FSU College of Engineering

                         Research Progress Report – 1st Quarter 2005

                             LED Signal Research
Area Manager: Dr. Jim Zheng
Research Associate: Doug Murphy
Date: March 31, 2005
Report ID: LED 2.2.5-01


          In the first quarter of 2005, the LED department of the Traffic Engineering
             Research Laboratory has primarily focused on training new personnel and
             critically examining the current testing procedures. Additionally, the lab has
             achieved the long sought-after goal of automating data-acquisition and
             continues to pursue goals set in previous progress reports.
          Due to the overtly technical nature of the LED area, an exhaustive introduction is
             mandatory for any new Research Associate. Over the past quarter, training has
             included: mastering the equipment used in the laboratory, expanding
             knowledge of background optical principles, and thoroughly researching
             achievements and other issues from the LED department’s past.
          One problem that the LED department is intent on fixing is the discrepancies
             between the results achieved by our laboratory and the results of independent
             labs. To achieve success in this area, we have taken a methodical approach to
             pinpointing all sources of variability in the measurement process. Currently,
             the lab is exploring the extent to which each variable affects the chromaticity
             and luminous intensity output of LED modules. Attachment A-2 provides the
             reader with some preliminary results regarding how the length of the “on time”
             of one 12-inch red LED module affects its luminance output. Additional
             variability factors that will be tested soon are: perpendicular distance between
             source and measuring instrument (see attachment B), temperature, ambient
             light, and humidity. Once enough data is collected on how the individual
             factors affect results, we will begin “phase two” of testing, which will consist
             of designing and performing multivariable experiments that will yield results
             that explain how the factors interact. Also, this will allow us to identify any
             spurious correlations that appeared in “phase one.” One example of this could
             be that the apparent affect of time on luminance (see attachment A-2) is
             actually due to changes in temperature that occur inside an LED module as it
             remains lit for an extended period of time. Ultimately, the TERL will author
             strict new LED-testing procedures that will, hopefully, minimize the accuracy
             of results and maximize the reliability and consistency of them.
          Future goals that remain are: develop the capabilities to test LED devices that are
             currently installed “in the field,” and determine if the continuous observation
             of the performance of a new devices should be part of the TERL’s tasks.



                                               27
                                                    Progress Report No.5: January 2005 – March 2005




ATTACHMENT A-1 – LED 1.2.3.1-01

          THE EFFECTS OF TIME ON LED MEASUREMENTS


PURPOSE:

To identify the extent to which the luminous intensity and chromaticity of LED traffic signals
vary with time. Additionally, the time it takes the output of LED modules to stabilize must be
identified. From this information, a “correction equation” can be developed such that the TERL
can confidently relate any result—collected at any time—to the “stabilized” result.

Secondary objectives:
       - Determine if the time vs. intensity and time vs. chromaticity slope is applicable to all
           LEDs.
       - Identify how long the LED ”warm-up period” should be such that the LED properties
           will remain constant for future experiments.
       - Determine how long an LED module must remain off so that it returns to its initial
           state.



                       EQUPIMENT & SETTINGS
This experiment will be performed with a Photo Research PR-650 SpectraColorimeter operated
with the SpectraWin 1.34 software. Set the PR-650 to average 10 results for each reading.



                                METHODOLOGY
For all steps below, make sure that the horizontal and vertical angles between the LED and
measuring equipment are 0. Additionally, make sure that the center of both the LED and the
measuring lens are at the same height and on the same axis.


PART I: time vs. output

    1. Set up the PR-650 at a fixed distance of 20 m.
    2. Turn on the LED and take intensity and chromaticity measurements every minute for 2
       hours or until the same result is achieved for 10 readings.
    3. Repeat step 2 a total of three times, letting the LED modules rest at least 3 hours between
       each trial.
    4. Repeat steps 2 and 3 with green, red and amber LED modules.




                                               28
                                                   Progress Report No.5: January 2005 – March 2005


PART II: resting time

   1. Identify the “initial” intensity and chromaticity values of the LED module you are testing
      by taking measurements every minute for 5 minutes after the module has been off for 1
      hour.
   2. Turn the module on for 1 hour, and then turn it off.
   3. After it has been off for 1 minute, turn it on and take measurements every minute for 5
      minutes.
   4. Repeat step 4, but increase the “off time” by one minute each time. Continue to take a
      measurement every minute for 5 minutes. Do this until the results match the initial
      results found in step one.
   5. Verify this “off time” is correct by leaving the module on for 1 hour, then turning it off
      for the length of the “off time” and taking measurements.




ATTACHMENT A-2 – LED 1.2.3.2-01



                                              29
                                                             Progress Report No.5: January 2005 – March 2005




                                PRELIMINARY RESULTS REGARDING THE EFFECTS OF
                                         TIME ON LED MEASUREMENTS




                                                  Luminance vs. Time
                                               12-inch RED Optisoft LED
                                                        3/17/05

                     1720


                     1670
Luminance (cd/m^2)




                     1620


                     1570


                     1520


                     1470
                            0        20       40       60              80            100            120        140
                                                        Time (minutes)




                       ATTACHMENT B – LED 1.2.3.1-02


                                   THE EFFECTS OF DISTANCE ON LED MEASUREMENTS



                                                        30
                                                       Progress Report No.5: January 2005 – March 2005




PURPOSE:

To determine a standard “optimal” distance from which to measure
LED traffic lights for use in future experiments. This will be accomplished
by first gathering data from range of distances between the LED source
and the measurement equipment, and then analyzing the results.

Secondary objectives:

        -    Find overall range in results.
        -    Find range at each distance.
        -    Identify the distances that yield the most and least consistent results.
        -    Determine if “overall” average has a valid use.



                        EQUPIMENT & SETTINGS
This experiment will be performed with a Photo Research PR-650 SpectraColorimeter operated
with the SpectraWin 1.34 software. Set the PR-650 to average 10 results for each reading.



                                 METHODOLOGY
Let the LED warm up for the amount of time recommended in the conclusion of “The Effects of
Time on LED measurements (LED 1.2.3.1.1).”

For all steps below, make sure that the horizontal and vertical angles between the LED and
measuring equipment are 0. Additionally, make sure that the center of both the LED and the
measuring lens are at the same height and on the same axis.

    1. Begin by setting horizontal distance ‘D’ = 0 m.
    2. Gather 20 measurements of both luminance (cd/m^2) and the chromaticity coordinates (x
       and y).
    3. Add 2 m to ‘D’ and begin at step 1 again. Continue this cycle until D = 20 m.
    4. Perform the above process 3 whole times. Between each trail, let both the PR-650 and
       the LED rest for at least 3 hours.

            National Transportation Communication for ITS Protocol
                                             Khue Ngo
                                            Angela Ruffin


NT 2.1.4.1-4
Completed: 03/31/05


I. Introduction


                                                  31
                                                     Progress Report No.5: January 2005 – March 2005




    The National Transportation Communication for Intelligent Transportation Systems
(ITS) Protocol (NTCIP) is a suite of standards for communication between traffic control
devices. The intent of the protocol is to allow ITS devices of various types and
manufacturers to communicate with each other. This is important because, traditionally,
traffic control devices have used protocols specific to the manufacturer as well as the
project. NTCIP is designed to eliminate many of the problems caused by application
specific protocols by providing a suite of communications protocols suitable for a diverse
range of applications.
    The benefits of implementing a system in accordance to such standards are substantial,
because the incompatibilities of devices from different manufacturers are eliminated.
One of the main benefits of the implementation of NTCIP compliant systems is that
future expansions of the systems can be realized with any other NTCIP compliant
devices. Competitive bids can be considered for expansion with such systems, whereas
the options are limited with devices using proprietary protocols. Consequently, this also
helps ensure that systems won’t become prematurely obsolete. Another benefit is that
systems of different political entities can be linked together cooperatively. With each
municipality using systems with different protocols, this type of cooperation would be
difficult. Perhaps most importantly, NTCIP allows a wide range of traffic control devices
to share the same communications channel. Thus, new devices can be added to systems
by making use of existing channels. These benefits are certainly incentives to strive
toward implementing standard, NTCIP compliant traffic control systems.
    As it is desirable to implement NTCIP compliant systems, it is necessary to ensure
that all devices used in such systems are indeed compliant. The goal of the NTCIP
project is to develop methods for testing and verifying the compliance of such traffic
control devices to the standards set forth. This includes the development of testing
procedures, as well as the actual testing of traffic control devices. It is the overall goal of
the project to develop more efficient and effective means of testing NTCIP compliance of
traffic control devices.

II. Progress Summary

     Initially, the work in the NTCIP area focused on the acquisition of experience with the
NTCIP and NTCIP testing of Dynamic Message Signs (DMS) and Actuated Signal Controllers
(ASC). After the development of the Florida DMS Minimum Specifications, however, the focus
shifted to the development of test procedures and testing tools suitable for NTCIP qualification of
DMS manufacturers. Ultimately, a test procedure was developed and is currently being used to
carry out the testing of demonstration devices submitted by DMS manufacturers seeking entrance
to the Florida market. Using the tools previously developed for use with the Exerciser (DMS
central macro, object check macro, etc.), tests have been successfully carried out on devices
submitted by Skyline, Vultron, Dambach, Mark IV, 3M, Swarco, Adaptive Micro Systems, and
ADDCO. Although the efforts of Phase 3 were primarily directed toward the implementation of a
DMS testing program, a decision was made to focus the efforts of Phase 4 work on the
development and implementation of an ASC NTCIP testing program, to be integrated with
FDOT’s existing ASC certification program. These goals are summarized below.

       Maintain existing DMS NTCIP qualification testing program.
       Develop ASC NTCIP qualification testing program


                                                32
                                                           Progress Report No.5: January 2005 – March 2005


             o  Develop list of functional requirements for ASCs to be accomplished from
                central
             o Develop ASC MIB
             o Develop test procedures
             o Develop testing tools
        Carry out ASC NTCIP qualification testing

                 This work has formed the initial stages of the development process. The
            literature search for ASC functional requirements, along with the reviews of
            NTCIP 1202, NEMA TS 2, the Dade County MIB, and Naztec documentation
            has been completed. This has provided some background for the development
            of ASC functional requirements to be accomplished from central. The reviews
            of NTCIP 8007 and IEEE 829 have provided background for the development
            of the actual test procedures. A working group composed of TERL and FDOT
            staff has been assembled to assist in the development of ASC NTCIP
            requirements.

             III. Test of ADDCO Dynamic Message Sign
         In addition to the work done in the development of the NTCIP testing program, an
            actual test on an ADDCO DMS was carried out. After a hardware upgrade, as
            well as several software upgrades, the final implementation did seem to
            demonstrate the ability of the manufacturer to meet the NTCIP requirements
            set forth by FDOT. The portion of the test report indicating the results of the
            individual tests (omitting documentation files) is provided below.




  NTCIP Qualification Test Procedure for Permanent Mount Dynamic
                            Message Signs

NT 3.1.1.1.1-01
Completed: 17 Mar 05

0. Object Support

This part of the test is meant to serve as a preliminary test of the device’s supported objects. The device
should support all mandatory objects as specified by FDOT requirements (9802-4.2).

Requirements

        0.1 Object Support - Verify that all of the required objects are supported by the device. If large
         groups of required objects are not supported by the device, the manufacturer should be contacted
         to add support of these objects before the test proceeds further. It may not be possible for the


                                                      33
                                                         Progress Report No.5: January 2005 – March 2005


         demonstration device to include all required functions, and, thus, some allowances may be
         required for such functions. However, critical functions (and the objects associated with these
         functions) should be supported.



Requirement          Status/           Related Files            Comments
                     Date
0.1 Object           Passed            objectcheck.txt          All of the required objects are supported by
Support              3/10/2004                                  the device. Allowances were made for
                                                                instances that had not yet been created.


Example Test Procedure

Required Macros
    objectcheck.mac

Required Input Files
    DMSobjectcheckinput01.txt
    DMSobjectcheckinput02.txt
    DMSobjectcheckinput03.txt
    DMSobjectcheckinput04.txt
    DMSobjectcheckinput05.txt
    DMSobjectcheckinput06.txt
    DMSobjectcheckinput07.txt
    DMSobjectcheckinput08.txt
    DMSobjectcheckinput09.txt
    DMSobjectcheckinput10.txt
    DMSobjectcheckinput11.txt
    DMSobjectcheckinput12.txt
    DMSobjectcheckinput13.txt
    DMSobjectcheckinput14.txt
    DMSobjectcheckinput15.txt


    1.   Run the objectcheck.mac macro. Specify DMSobjectcheckinput01.txt as the input file.
    2.   Examine the report file.
              Ensure that no errors are reported and that the information reported by each object is
                  appropriate (Satisfies Requirement 0.1 Object Support).
         Note: Some false errors may be reported by the macro. These errors could be attributed to objects
            with no instance (such as objects within tables). The errors could also be attributed to objects
            dealing with features not supported by the demonstration device (such as fans). Additionally,
            the information retrieved from objects with octet string (hexadecimal string) syntax may not be
            correctly represented, as an attempt is made to convert these strings to ASCII strings in the
            report file. The manufacturer should be contacted to verify any questionable errors.


1. Global Configuration

This conformance group is meant to provide general information about the device. A table is provided to
give information about each module of the device. The information provided for each module includes the
device node, manufacturer, model, version, and type. This information is needed so that the device can be
identified by other devices.



                                                    34
                                                          Progress Report No.5: January 2005 – March 2005



         Objects: globalMaxModules.0, moduleNumber.x, moduleDeviceNode.x, moduleMake.x,
         moduleModel.x, moduleVersion.x, moduleType.x

Requirements

        1.1 Obtain Global Configuration Information – Verify that all of the required Global
         Configuration objects respond properly to SNMP “get” requests, and verify that the information
         provided by these objects is correct for the device.


Requirement            Status/         Related Files               Comments
                       Date
1.1 Obtain Global      Passed          centrallog01ADDCO.txt       All of the required global configuration
Configuration          3/10/2004                                   objects responded properly and the
Information                                                        information provided by these objects is
                                                                   correct for the device.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1.   Run the DMScentral.mac macro.
    2.   At the main command prompt, enter “globalconfig.”
    3.   Examine the report file. Ensure that the information from each table entry is correct for the device
         (Satisfies Requirement 1.1 Global Configuration).
              Note: The response from the moduleDeviceNode.x objects may not be correctly represented
              in the report file, as attempts are made to convert these object identifiers in ASCII strings.
              The actual object identifiers can be examined in the Exerciser log.


2. Global Time Management

This conformance group is used to keep track of time for the device. The objects in this conformance group
keep track of the global time (number of seconds since midnight on January 1, 1970), the time differential
between this time and local time, and whether or not daylight savings time is used.

         Objects: globalTime.0, globalDaylightSaving.0, globalLocalTimeDifferential.0


Requirements

        2.1 Obtain Time Information – Verify that all Global Time Management objects correctly respond
         to SNMP “get” requests. Also verify that the actual time reported by the device is correctly
         constructed from the parameters.
        2.2 Set Time Parameters – Verify that each of the Global Time Management objects can be set,
         and that the actual time reported by the device is correctly constructed from the new parameter
         values.


                                                     35
                                                         Progress Report No.5: January 2005 – March 2005




Requirement               Status/           Related Files              Comments
                          Date
2.1 Obtain Time           Passed            centrallog02ADDCO.tx       The global time management
Information               3/10/2004         t                          objects correctly responded to
                                                                       SNMP “get” requests.
2.2 Set Time              Passed            centrallog02ADDCO.tx       Each of the global time management
Parameters                3/10/2004         t                          objects was set properly.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1.   Run the DMScentral.mac macro.
    2.   Obtain information about time parameters. At the main command prompt, enter “globaltime.” At
         the Global Time command prompt, enter “status.”
    3.   Examine the report file. Verify that the device correctly reports all time information.
    4.   Set the global time. At the main command prompt, enter “globaltime.” At the Global Time
         command prompt, enter “set.” As prompted, enter the following information:
         Global Time (s): 1041426000
         Enable Daylight Savings Time? (y/n) n
         Local Time Differential: 0
    5.   Repeat steps 2 and 3.
    6.   Verify that the time for the device has changed to 1:00 P.M. January 1, 2003.
    7.   Repeat step 4, entering the following time information:
         Global Time (s): 1041426000
         Enable Daylight Savings Time? (y/n) n
         Local Time Differential: 3600
    8.   Verify that the time for the device has changed to 2:00 P.M. January 1, 2003.
    9.   Examine the report file.
               Verify that the device correctly reported all time information (Successful completion of
                  steps 3 and 5 Satisfy Requirement 2.1 Obtain Time Information).
               Verify that no errors are reported in the report file (Successful results for steps 6 and 8
                  Satisfy Requriement 2.2 Set Time Parameters).




3. Global Report

This conformance group is used to log special events that occur within the device. The device can be
configured to log events corresponding to any object supported by the device. The events can be set up to
monitor various objects and log the values of these objects in the event of exceeding some threshold or
simply upon change. This could be used to monitor the temperature of the device, for example, and make
entries in the log when a certain threshold temperature is exceeded. The objects of this conformance group
also provide a means of separating these events into classes, so that associated events can be grouped



                                                    36
                                                         Progress Report No.5: January 2005 – March 2005


together. In addition to the standard objects, FDOT requires support of an object that reflects whether or
not any of the classes are 90% full.

        Objects: maxEventLogConfigs.0, eventConfigID.x, eventConfigClass.x,
        eventConfigMode.x, eventConfigCompareValue.x, eventConfigLogOID.x,
        eventConfigAction.x, maxEventLogSize.0, eventLogClass.x.y,
        eventLogNumber.x.y, eventLogID.x.y, eventLogTime.x.y, eventLogValue.x.y,
        maxEventClasses.0, eventClassNumber.x, eventClassLimit.x,
        eventClassClearTime.x, eventClassDescription.x, eventClassNumRowsInLog.x


Requirements

       3.1 Obtain General Log Information – Verify that the maxEventLogConfigs.0, maxEventLogSize.0,
        and maxEventClasses.0 objects correctly respond to SNMP “get” requests. Also, verify that the
        information provided by these objects is in accordance with FDOT requirements.
       3.2 Set Up Classes – Verify that classes can be configured.
       3.3 Configure Events – Verify that events can be configured.
       3.4 Obtain Log Information – Verify that the information from the log is properly reported. Verify
        that information for logged events is properly recorded in the log. Verify that logged events are
        properly separated into classes. Verify that classes only store the specified number of log entries,
        and that the number of log entries stored in each class is correctly reported by the
        eventClassNumRowsInLog.x object.
       3.5 Clear Classes – Verify that classes can be cleared.


Requirement            Status/           Related Files        Comments
                       Date
3.1 Obtain General     Passed            centrallog03Add      The maximum event log size and maximum
Log Information        6/10/2004         co.txt,retest03Ad    event classes supported by the device, 800
                                         dco.txt              and 16 respectively, are in accordance with
                                                              FDOT requirements of 200 and 7. The value
                                                              of maximum number of event configurations
                                                              supported by the device, 32, is not in
                                                              accordance with the FDOT minimum
                                                              requirement of 50. After a software upgrade,
                                                              the maximum number of event configurations
                                                              supported by the device, ‘50’, is in
                                                              accordance with the FDOT minimum
                                                              requirement of ‘50’.
3.2 Set Up Classes     Passed            centrallog03Add      Classes were properly configured.
                       3/18/2004         co.txt
3.3 Configure          Passed            centrallog03Add      Events were properly configured.
Events                 3/18/2004         co.txt
3.4 Obtain Log         Passed            centrallog03Add      The information for logged events was
Information            3/18/2004         co.txt               appropriately separated into classes and
                                                              recorded in the logs. The classes only stored
                                                              the specified number of log entries, and the
                                                              number of log entries stored in each class
                                                              was correctly reported by the
                                                              eventClassNumRowsInLog.x object.
3.5 Clear Classes      Passed            centrallog03Add      Classes were properly cleared.
                       3/18/2004         co.txt



                                                    37
                                                        Progress Report No.5: January 2005 – March 2005




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None


    1.  Run the DMScentral.mac macro.
    2.  Obtain general log information. At the main command prompt, enter “globalreport.” At the
        Global Report command prompt, enter “status.” At the Global Report Status command prompt,
        enter “general.”
    3. Examine the report file. Verify that no errors are reported. Verify that the maximum number of
        event configurations, class configurations, and log entries supported by the device are correctly
        reported and that these values are in accordance with FDOT requirements (Satisfies Requirement
        3.1 Obtain General Log Information).
    4. Set the test object. At the main command prompt, enter “single.” As prompted, enter the
        following information:
        Request Type: set
        Object Name: dmsTimeCommLoss.0
        Object Syntax: i
        Value: 150
    5. Set up class. At the main command prompt, enter “globalreport.” At the Global Report command
        prompt, enter “classconfig.” As prompted, enter the following information:
        Class Number: 3
        Class Size: 10
        Class Description: Test Class For Changing Values
    6. Obtain class information. At the main command prompt, enter “globalreport.” At the Global
        Report command prompt, enter “status.” At the Global Report Status command prompt, enter
        “classconfig.” When prompted to enter the class number, enter “3.”
    7. Set up class. At the main command prompt, enter “globalreport.” At the Global Report command
        prompt, enter “classconfig.” As prompted, enter the following information:
        Class Number: 4
        Class Size: 10
        Class Description: Test Class For Threshold Values
    8. Obtain class information. At the main command prompt, enter “globalreport.” At the Global
        Report command prompt, enter “status.” At the Global Report Status command prompt, enter
        “classconfig.” When prompted to enter the class number, enter “4.”
    9. Examine the report file. Verify that no errors are reported. Verify that the device correctly
        reported the class configuration information requested in steps 6 and 8 and that this information
        reflects the settings of steps 5 and 7.
    10. Configure event. At the main command prompt, enter “globalreport.” At the Global Report
        command prompt, enter “eventconfig.” As prompted, enter the following information:
        Event Number: 3
        Class Number: 3
        Configuration Mode: change
        Value 1: 10
        Value 2: 10
        Object to be Monitored: dmsTimeCommLoss.0
        Object to be Logged: dmsTimeCommLoss.0



                                                   38
                                                     Progress Report No.5: January 2005 – March 2005


    Enable Logging? y
11. Obtain event configuration information. At the main command prompt, enter “globalreport.” At
    the Global Report command prompt, enter “status.” At the Global Report Status command
    prompt, enter “eventconfig.” When prompted to enter the event configuration number, enter “3.”
12. Configure event. At the main command prompt, enter “globalreport.” At the Global Report
    command prompt, enter “eventconfig.” As prompted, enter the following information:
    Event Number: 4
    Class Number: 4
    Configuration Mode: greater
    Value 1: 200
    Value 2: 1
    Object to be Monitored: dmsTimeCommLoss.0
    Object to be Logged: dmsTimeCommLoss.0
    Enable Logging? y
13. Obtain event configuration information. At the main command prompt, enter “globalreport.” At
    the Global Report command prompt, enter “status.” At the Global Report Status command
    prompt, enter “eventconfig.” When prompted to enter the event configuration number, enter “4.”
14. Configure event. At the main command prompt, enter “globalreport.” At the Global Report
    command prompt, enter “eventconfig.” As prompted, enter the following information:
    Event Number: 5
    Class Number: 4
    Configuration Mode: less
    Value 1: 100
    Value 2: 1
    Object to be Monitored: dmsTimeCommLoss.0
    Object to be Logged: dmsTimeCommLoss.0
    Enable Logging? y
15. Obtain event configuration information. At the main command prompt, enter “globalreport.” At
    the Global Report command prompt, enter “status.” At the Global Report Status command
    prompt, enter “eventconfig.” When prompted to enter the event configuration number, enter “5.”
16. Examine the report file. Verify that no errors are reported. Verify that the device correctly
    reported the event configuration information requested in steps 11, 13, and 15 and that this
    information reflects the settings of steps 10, 12, and 14.
17. Obtain log information. At the main command prompt, enter “globalreport.” At the Global
    Report command prompt, enter “status.” At the Global Report Status prompt, enter “logentry.”
    As prompted, enter the following information:
    Class Number: 3
18. Obtain log information. At the main command prompt, enter “globalreport.” At the Global
    Report command prompt, enter “status.” At the Global Report Status prompt, enter “logentry.”
    As prompted, enter the following information:
    Class Number: 4
19. Examine the report file. Verify that no errors are reported. Verify that the device reported no log
    entries for classes 3 or 4.
20. Obtain time reference. At the main command prompt, enter “single.” As prompted, enter the
    following information:
    Request Type: get
    Object Name: globalTime.0
    Object Syntax: d
21. Set test object value. At the main command prompt, enter “single.” As prompted, enter the
    following information:
    Request Type: set
    Object Name: dmsTimeCommLoss.0
    Object Syntax: i
    Value: 250
22. Set test object value. At the main command prompt, enter “single.” As prompted, enter the
    following information:



                                                39
                                                           Progress Report No.5: January 2005 – March 2005


          Request Type: set
          Object Name: dmsTimeCommLoss.0
          Object Syntax: i
          Value: 50
    23.   Set test object value. At the main command prompt, enter “single.” As prompted, enter the
          following information:
          Request Type: set
          Object Name: dmsTimeCommLoss.0
          Object Syntax: i
          Value: 150
    24.   Obtain log information. At the main command prompt, enter “globalreport.” At the Global
          Report command prompt, enter “status.” At the Global Report Status command prompt, enter
          “logentry.” As prompted, enter the following information:
          Class Number: 3
          Entry Number: all
    25.   Obtain log information. At the main command prompt, enter “globalreport.” At the Global
          Report command prompt, enter “status.” At the Global Report Status command prompt, enter
          “logentry.” As prompted, enter the following information:
          Class Number: 4
          Entry Number: all
    26.   Examine the report file. Verify that no errors are reported. Verify that report class 3 contains
          three entries, all corresponding to event configuration 3. Also, verify that the times and values
          logged are appropriate (corresponding to the events induced in steps 21 through 23). Verify that
          report class 4 contains two entries. Verify that the first entry corresponds to event configuration 4
          and that the second corresponds to event configuration 5. Also, verify that the times and values
          logged are appropriate (corresponding to the events induced in steps 22 and 23).
    27.   Repeat steps 20 through 23.
    28.   Repeat steps 20 through 23.
    29.   Repeat steps 20 through 23.
    30.   Repeat steps 24 and 25.
    31.   Examine the report file. Verify that no errors are reported. Verify that report class 3 contains ten
          entries, all corresponding to event configuration 3. Also, verify that the times and values logged
          are appropriate (corresponding to the most recent events induced in steps 21 through 23 and steps
          27 through 29). Verify that report class 4 contains eight entries, each corresponding to either
          event 4 or event 5. Also, verify that the times and values logged are appropriate (corresponding to
          the events induced in steps 22 through 23 and steps 27 through 29).
    32.   Clear class. At the main command prompt, enter “globalreport.” At the Global Report command
          prompt, enter “clearclass.” When prompted to enter the class number, enter “3.”
    33.   Clear class. At the main command prompt, enter “globalreport.” At the Global Report command
          prompt, enter “clearclass.” When prompted to enter the class number, enter “4.”
    34.   Repeat steps 17 through 19.
    35.
     (Successful Results for Steps 9, 19, 26, and 31 Satisfies Requirement 3.2 Set Up Classes)
     (Successful Results for Steps 16, 26, and 31 Satisfies Requirement 3.3 Configure Events)
     (Successful Results for Steps 19, 26, 31, and 34 Satisfies Requirement 3.4 Obtain Log
        Information)
     (Successful Results for Steps 9, 19, and 34 Satisfies Requirement 3.5 Clear Classes)




4. Global Security

This conformance group is used to handle security for the device. In each SNMP packet, a community
name is used to identify the sender. Different community names imply different access privileges to the
device. Thus, the objects in this conformance group are used to specify which privileges are to be given to


                                                      40
                                                        Progress Report No.5: January 2005 – March 2005


which community names. The administrator community name (which can be any name) is the only
community name given access to the security node. This community name implies total access to the
device. All other community names are considered user community names, and the privileges associated
with each one of these names are defined by the objects in this conformance group.

         Objects: communityNameAdmin.0, communityNamesMax.0,
         communityNameIndex.x, communityNameUser.x,
         communityNameAccessMask.x


Requirements

        4.1 Obtain Security Information – Verify that all Global Security objects correctly respond to
         SNMP “get” requests with the administrator community name. Verify that these objects do not
         respond to SNMP “get” requests that do not contain the administrator community name.
        4.2 Set Administrator Community Name – Verify that the administrator community name can be
         modified, and verify that this new administrator community name, and only this new administrator
         community name, is given access to the security node.
        4.3 Set User Access – Verify that user community names can be added, and that these names are
         recognized by the device with the appropriate privileges.



Requirement            Status/        Related Files            Comments
                       Date
4.1 Obtain             Passed         centrallog04ADDCO.       All global security objects properly
Security               3/11/2004      txt                      responded to “get” requests with the
Information                                                    administrator community name. The
                                                               objects did not respond to get request that
                                                               did not contain the administrator
                                                               community name.
4.2 Set                Passed         centrallog04ADDCO.       The administrator community name was
Administrator          3/11/2004      txt                      modified, and only the new administrator
Community Name                                                 community name was given access to the
                                                               security node.
4.3 Set User           Passed         centrallog04ADDCO.       A user community name, “FDOTuser” was
Access                 3/11/2004      txt                      added and was recognized by the device
                                                               with the appropriate privileges.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None


    1.   Run the DMScentral.mac macro.
    2.   Set the community name used by the macro to the administrator community name. At the main



                                                   41
                                                    Progress Report No.5: January 2005 – March 2005


      command prompt, enter “changecn.” When prompted, enter the administrator community name
      for the device.
3.    Access administrator community name information. At the main command prompt, enter
      “globalsecurity.” At the Global Security command prompt, enter “status.” When prompted to
      enter the number for the user community name for which information is requested, enter “admin.”
4.    Examine the report file and verify that the device appropriately responded to the request,
      providing the administrator community name.
5.    Obtain user community name information. At the main command prompt, enter “globalsecurity.”
      At the Global Security command prompt, enter “status.” When prompted to enter the number for
      the user community name for which information is requested, enter “1.”
6.    Examine the report file and verify that the device appropriately responded to the request,
      providing the specified user community name and access mask (note: the access mask will not be
      shown correctly in the output file, see the Exerciser log).
7.    Set the community name used by the macro to the user community name obtained in step 6. At
      the main command prompt, enter “changecn.” When prompted, enter the user community name
      obtained in step 6.
8.    Verify that the device recognizes the user community name. At the main command prompt, enter
      “single.” As prompted enter the following information:
      Request Type: get
      Object Name: globalMaxModules.0
      Syntax: d
      Verify that the device responded appropriately to the request.
9.    Repeat step 2.
10.   Modify the user community name. At the main command prompt, enter “globalsecurity.” At the
      Global Security command prompt, enter “user.” As prompted, enter the following information:
      User Community Name Number: 1
      New User Community Name: FDOTuser
      Access Mask: 4294967295
11.   Repeat steps 5 and 6.
12.   Set the community name used by the macro to the community name originally obtained in step 6.
      At the main command prompt, enter “changecn.” When prompted, enter the user community
      name originally obtained in step 6.
13.   Verify that the device no longer recognizes the old user community name. At the main command
      prompt, enter “single.” As prompted enter the following information:
      Request Type: get
      Object Name: globalMaxModules.0
      Syntax: d
      Verify that the device did not respond with the requested information.
14.   Set the community name used by the macro to “FDOTuser.”. At the main command prompt, enter
      “changecn.” When prompted to enter the community name, enter “FDOTuser.”
15.   Repeat step 8.
16.   Verify that the device does not allow security node access. At the main command prompt, enter
      “single.” As prompted enter the following information:
      Request Type: get
      Object Name: communityNameAdmin.0
      Syntax: s
      Verify that the device did not respond with the requested information.
17.   Repeat step 2.
18.   Change the administrator community name. At the main command prompt, enter
      “globalsecurity.” At the Global Security command prompt, enter “admin.” When prompted to
      enter the new administrator community name, enter “FDOTadmin.”
19.   Repeat step 16.
20.   Change the community name used by the macro to the new administrator community name. At
      the main command prompt, enter “changecn.” When prompted to enter the new community name,
      enter “FDOTadmin.”
21.   Repeat steps 3 and 4.



                                               42
                                                          Progress Report No.5: January 2005 – March 2005


    22. Examine the report file.
            (Successful results for steps 4, 6, 11, 16, 19, and 21 Satisfy Requirement 4.1 Obtain
               Security Information)
            (Successful results for steps 18 through 21 Satisfy Requirement 4.2 Set
               Administrator Community Name).
            (Successful results for steps 10 through 16 Satisfy Requirement 4.3 Set User Access).




5. Sign Configuration

This conformance group is used to provide general information about the sign type and features.

         Objects: dmsSignType.0, dmsBeaconType.0


Requirements

        5.1 Obtain Sign Configuration Information – Verify that the information provided by the objects in
         this conformance group is correct for the device and in accordance with FDOT specifications.


Requirement              Status/         Related Files               Comments
                         Date
5.1 Obtain Sign          Passed          centrallog05ADDCO.txt       The information provided by the
Configuration            3/10/2004                                   dmsSignType.0 and dmsBeaconType.0
Information                                                          objects, ‘full matrix’ and ‘no beacons’
                                                                     respectively, was correct for the device
                                                                     and in accordance with FDOT
                                                                     specifications.




Example Test Procedure

Required Macros
    DMScentral.mac


Required Input Files
None


    1.   Run the DMScentral.mac macro.
    2.   Perform a status check on sign attributes. At the main command prompt, type “status.” At the
         status command prompt, type “sign.”
    3.   Examine the report file.
               Verify that the sign type reported is correct for the device and that it is in accordance with
                  FDOT specifications.
                  Verify that the beacon type is correct for the device and in accordance


                                                     43
                                                        Progress Report No.5: January 2005 – March 2005


                 with FDOT specifications (Satisfies Requirement 5.1 Obtain Sign
                 Configuration Information).



6. GUI Appearance

Only one object from this conformance group is required. This object provides
information about the sign technology used.

         Objects: dmsSignTechnology.0

Requirements

        6.1 Obtain GUI Appearance Information – Verify that the information provided
         by the dmsSignTechnology.0 object is correct for the device and in accordance
         with FDOT specifications.


Requirement             Status/        Related Files              Comments
                        Date
6.1 Obtain GUI          Passed         centrallog05ADDCO.txt      The information provided by the
Appearance              3/10/2004                                 dmsSignTechnology.0 object, LED,
Information                                                       was correct for the device and in
                                                                  accordance with FDOT specifications.




Example Test Procedure

Required Macros
    DMScentral.mac


Required Input Files
None


    1.   Run the DMScentral.mac macro.
    2.   Perform a status check on sign attributes. At the main command prompt, enter “status.” At the
         status command prompt, enter “sign.”
    3.   Examine the report file.
               Verify that the sign technology reported is correct for the device and that it is in
                  accordance with FDOT specifications (Satisfies Requirement 6.1 Obtain GUI
                  Appearance Information).




                                                   44
                                                   Progress Report No.5: January 2005 – March 2005


7. Font Configuration

This conformance group is used to maintain fonts for the device. Through the objects in
this group, new fonts can be downloaded onto the device.

        Objects: numFonts.0, fontIndex.x, fontNumber.x, fontName.x, fontHeight.x,
        fontCharSpacing.x, fontLineSpacing.x, fontVersionID.x, maxFontCharacters.0,
        fontIndex.x.y, characterNumber.x.y, characterWidtht.x.y, characterBitmap.x.y,

Requirements

                 7.1 Obtain Font Information – Verify that all Font Configuration objects
                  correctly respond to SNMP “get” requests. Verify that the number of
                  fonts supported by the device, given by the numFonts.0 object, is in
                  accordance with FDOT specifications (9802-4.2). Also, verify that the
                  number of characters per font supported by the device, given by the
                  maxFontCharacters.0 object, is in accordance with FDOT specifications
                  (9802-4.2).
                 7.2 Download Fonts – Verify that new fonts and characters can be
                  downloaded to the device. Also, verify that these new fonts and characters
                  are properly displayed by the device.



Requirement             Status/      Related Files          Comments
                        Date
7.1 Obtain Font         Passed       centrallog07ADDCO.     The value of the numFonts.0 object, '4',
Information             6/2/2004     txt                    is in accordance with the FDOT
                                                            minimum requirement of '4'. The value
                                                            of the maxFontCharacters.0 object, '127',
                                                            is not in accordance with the FDOT
                                                            minimum requirement of ‘255’.
                                                            After a software upgrade, the value of
                                                            the maxFontCharacters.0 object, ‘255’,
                                                            is in accordance with the FDOT
                                                            minimum requirement.
7.2 Download Fonts      Passed       centrallog07ADDCO.     The new font characters were
                        3/11/2004    txt                    downloaded to the device and properly
                                                            displayed.



Example Test Procedure

Required Macros
DMScentral.mac

Required Input Files
None



                                              45
                                                 Progress Report No.5: January 2005 – March 2005




   1. Send an SNMP “get” request for the numFonts.0 and maxFontCharacters.0
      objects. Verify that the responses from the device are in accordance with the
      FDOT requirements for the number of fonts and the number of characters per
      font to be supported (Satisfies Requirement 7.1 Obtain Font Information).
   2. Overwrite character bitmaps with bitmaps for Greek letters. Set the fontHeight.4
      object to a value of 7. Set the characterWidth.4.71, characterWidth.4.79, and
      characterWidth.4.80 objects to values of 5. Set the characterBitmap.4.71 object
      to the hexadecimal string “FC 61 08 42 00.” Set the characterBitmap.4.79 object
      to the hexadecimal string “22 A3 18 AB 60.” Set the characterBitmap.4.80 object
      to the hexadecimal string “FA 94 A5 29 40.”
   3. Run the DMScentral.mac macro.
   4. Display a message using the Greek characters downloaded in step 2. At the main
      command prompt, enter “quickset.” When prompted, enter the message
      “[fo4]GOP.”
   5. Verify that the message “” is displayed. Also, examine the report file and
      ensure that no errors are reported (Satisfies Requirement 7.2 Download Fonts).




8. VMS Sign Configuration

This conformance group is used to provide information about the attributes of the sign.
Information is provided about the height and width of the sign, in pixels. Information is
also provided about the height and width of the characters, in pixels. Additionally,
information about the physical spacing of the pixels is provided. This information is
needed for other devices to be able to determine the attributes of the sign.

       Objects: vmsCharacterHeightPixels.0, vmsCharacterWidthPixels.0,
       vmsSignHeightPixels.0, vmsSignWidthPixels.0, vmsHorizontalPitch.0,
       vmsVerticalPitch.0.

Requirements

      8.1 Obtain VMS Sign Configuration Information – Verify that the information
       provided by each of the objects is correct for the device and in accordance with
       FDOT specifications.




                                            46
                                                           Progress Report No.5: January 2005 – March 2005


Requirement               Status/          Related Files            Comments
                          Date
8.1 Obtain VMS Sign       Passed           centrallog08ADDCO        The sign height and width, ‘16’ and ‘36’
Configuration             3/10/2004        .txt                     pixels, respectively, and is correct for the
Information                                                         device. The character height and width is
                                                                    variable, which is correct for the device.




Example Test Procedure

Required Macros
    DMScentral.mac


Required Input Files
None


    1.   Run the DMScentral.mac macro.
    2.   Perform a status check on sign attributes. At the main command prompt, type “status.” At the
         status command prompt, type “sign.”
    3.   Examine the report file.
               Verify that the sign and character height and width are correct for the device and in
                  accordance with FDOT specifications. Also, verify that the vertical and horizontal pitch
                  information is correct for the device and in accordance with FDOT specifications
                  (Satisfies Requirement 8.1 Obtain VMS Sign Configuration Information).




9. MULTI Configuration

This conformance group is used to handle the default MULTI language settings. Default colors, fonts,
flash timings, page timings, line justifications, and page justifications are all defined through these objects.
All of the default settings can be overridden by MULTI tags, but these default settings minimize the use of
tags within MULTI strings.

         Objects: defaultBackgroundColor.0, defaultForegroundColor.0,
         defaultFlashOn.0, defaultFlashOff.0, defaultFont.0, defaultJustificationLine.0,
         defaultJustificationPage.0, defaultPageOnTime.0, defaultPageOffTime.0,
         defaultCharacterSet.0

Requirements

                 9.1 Obtain MULTI Defaults Information – Verify that information about
                  MULTI default parameters is correctly reported by the device.
                 9.1 Set MULTI Defaults – Verify that all of the MULTI defaults can be set
                  to the full range of values specified by FDOT requirements, and verify
                  that these defaults are implemented by the device.


                                                      47
                                                 Progress Report No.5: January 2005 – March 2005




Requirement            Status/     Related Files          Comments
                       Date
9.1 Obtain MULTI       Passed      centrallog09ADDCO.     The information about MULTI default
Defaults Information   3/10/2004   txt                    parameters was correctly reported by the
                                                          device.
9.2 Set MULTI          Passed      centrallog09ADDCO.     All of the MULTI defaults were able to
Defaults               3/10/2004   txt                    be set and implemented by the device.




Example Test Procedure

Required Macros
           DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Set MULTI defaults. At the main command prompt, enter “multidefaults.” At the
       MULTI defaults command prompt, enter “setdefaults.” As prompted, enter the
       following information:
       Background Color: black
       Foreground Color: amber
       Flash On Time: 15
       Flash Off Time: 5
       Font Number: 1
       Line Justification: right
       Page Justification: bottom
       Page On Time: 20
       Page Off Time: 5
    3. Obtain MULTI defaults information. At the main command prompt, enter
       “multidefaults.” At the MULTI defaults command prompt, enter “status.”
    4. Examine the report file. Verify that no errors are reported in the report file, and
       verify that “Not Defined” is not reported for any of the parameters. Also, verify
       that all parameters reflect the settings chosen in step 2 (Satisfies Requirement
       9.1 Obtain MULTI Defaults Information).
    5. At the main command prompt, enter “quickset.” When prompted, enter the
       message “[fl]FL[/fl].”
    6. Verify that the default MULTI settings were implemented. Examine the report
       file. Verify that no errors were reported. Verify that the message “FL” is
       displayed on the sign in the bottom right corner. Verify that the message is
       flashing on for approximately 1.5 seconds and flashing off for approximately .5
       seconds.


                                            48
                                             Progress Report No.5: January 2005 – March 2005


7. Set MULTI defaults. At the main command prompt, enter “multidefaults.” At the
    MULTI defaults command prompt, enter “setdefaults.” As prompted, enter the
    following information:
    Background Color: black
    Foreground Color: amber
    Flash On Time: 15
    Flash Off Time: 5
    Font Number: 2
    Line Justification: center
    Page Justification: middle
    Page On Time: 20
    Page Off Time: 5
8. At the main command prompt, enter “quickset.” When prompted, enter the
    message “DOT[np]DMS.”
9. Verify that the default MULTI settings were implemented. Examine the report
    file. Verify that no errors were reported. Verify that the sign transitions between
    the messages “DOT” and “DMS,” leaving each message on for approximately 2
    seconds, and blanking for approximately .5 seconds between messages. Verify
    that each of the messages is centered vertically and horizontally on the sign.
    Also, verify that the messages are displayed using the second font for the device.
10. Set MULTI defaults. At the main command prompt, enter “multidefaults.” At the
    MULTI defaults command prompt, enter “setdefaults.” As prompted, enter the
    following information:
    Background Color: black
    Foreground Color: amber
    Flash On Time: 15
    Flash Off Time: 5
    Font Number: 1
    Line Justification: left
    Page Justification: top
    Page On Time: 20
    Page Off Time: 5
11. At the main command prompt, enter “quickset.” When prompted, enter the
    message “DOT.”
12. Verify that the default MULTI settings were implemented. Examine the report
    file. Verify that no errors were reported. Verify that the message “DOT” was
    displayed in the top left corner of the sign (Successful Results of Steps 6, 9, and
    12 Satisfies Requirement 9.2 Set MULTI Defaults).




                                        49
                                                 Progress Report No.5: January 2005 – March 2005


10. Message Table

This conformance group is used to handle messages stored in memory. The objects in
this conformance group keep track of the messages and each message’s associated
parameters. These parameters include a message owner (used to keep track of who
stored the message in memory), beacon and pixel service settings (specifying whether or
not these features are to be activated with the message), a run-time priority, and a CRC.
Additionally, these objects are used for validation of the messages (ensuring the
messages have no MULTI syntax errors, etc.) and error detection. Objects in this
conformance group also provide the information about the message capabilities of the
device (the maximum number of changeable messages, the number of permanent
messages, etc.).

       Objects: dmsNumPermanentMsg.0, dmsNumChangeableMsg.0,
       dmsMaxChangeableMsg.0, dmsFreeChangeableMemory.0,
       dmsNumVolatileMsg.0, dmsMaxVolatileMsg.0, dmsFreeVolatileMemory.0,
       dmsMessageMemoryType.x.y, dmsMessageNum.x.y,
       dmsMessageMultiString.x.y, dmsMessageOwner.x.y, dmsMessageCRC.x.y,
       dmsMessageBeacon.x.y, dmsMessagePixelService.x.y,
       dmsMessageRunTimePriority.x.y, dmsMessageStatus.x.y,
       dmsValidateMessageError.0



Requirements

      10.1 Obtain Message Information – Verify that the information provided by the
       dmsNumPermanentMsg.0, dmsNumChangeableMsg.0,
       dmsMaxChangeableMsg.0, dmsFreeChangeableMemory.0,
       dmsNumVolatileMsg.0, dmsMaxVolatileMsg.0, and dmsFreeVolatileMemory.0
       objects is correct for the device and in accordance with FDOT requirements
       (9802-4.2). Also, verify that the dmsNumChangeableMsg.0,
       dmsFreeChangeableMemory.0, dmsNumVolatileMsg.0, and
       dmsFreeVolatileMemory.0 objects update appropriately as parameters and
       messages are modified.
      10.2 Set Message – Verify that valid messages can be set. Verify that all related
       parameters can be set as well.
      10.3 Obtain Information for Message Entry – Verify that the information for
       messages and associated parameters is correctly reported by the device. Verify
       that the CRC reported by the device is correct.
      10.4 Set Invalid Message – Verify that invalid messages are not validated and that
       the errors are properly reflected by the dmsValidateMessageError.0 object.
      10.5 CRC Calculation – Verify that the CRCs calculated by the device are
       correct..
      10.6 Set Message with Beacons Activated – Verify that beacons are activated with
       messages requiring beacon activation.


                                            50
                                                   Progress Report No.5: January 2005 – March 2005


        10.7 Set Message with Pixel Service Enabled – Verify that pixel service
         operations are carried out when requested with activated messages.



Requirement             Status/      Related Files            Comments
                        Date
10.1 Obtain Message     Passed       centrallog10ADDCO.txt    The information provided by the
Information             3/10/2004                             general message information objects is
                                                              correct for the device and in
                                                              accordance with FDOT requirements.
10.2 Set Message        Passed       centrallog10ADDCO.txt    Valid messages were set and all
                        3/10/2004                             related parameters were properly set as
                                                              well.
10.3 Obtain             Passed       centrallog10ADDCO.txt    The information for messages and
Information for         3/10/2004                             associated parameters were properly
Message Entry                                                 reported by the device.
10.4 Set Invalid        Passed       centrallog10ADDCO.txt    An invalid message was not validated
Message                 3/10/2004                             and the error, MULTI syntax, was
                                                              properly reflected by the
                                                              dmsValidateMessageError.0 object.
10.5 CRC Calculation    Passed       centrallog10ADDCO.txt    The CRC calculated by the device was
                        3/10/2004                             correct.
10.6 Set Message with   Not Tested                            Beacons are not required on all-LED
Beacons Activated                                             signs.
10.7 Set Message with   Not Tested                            Pixel service is not required on all-
Pixel Service Enabled   3/10/2004                             LED signs.

Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Obtain general message information. At the main command prompt, enter
       “status.” At the status command prompt, enter “messageinfo.”
    3. Set a message in memory. At the main command prompt, enter “setmessage.”
       Enter the following information as prompted:
       Message Number: 21
       Message: ABC
       Message Owner: owner1
       Run Time Priority: 100
       Beacons Activation: n
       Pixel Service Enabling: n
       When given the option of activating the message, enter “n.”
    4. Obtain information for the message previously set. At the main command prompt,



                                              51
                                             Progress Report No.5: January 2005 – March 2005


    enter “status.” At the status command prompt, enter “message.” When
    prompted for the message number, enter “21.”
5. Again, obtain general message information. At the main command prompt, enter
    “status.” At the status command prompt, enter “messageinfo.”
6. Examine the report file.
         Ensure that no errors have been reported.
         Verify that the general message information reported by the device is in
            accordance with FDOT requirements for the number of changeable
            messages and the amount of changeable memory to be supported. Also,
            verify that the number of changeable messages used by the device and the
            amount of free changeable memory reported by the device are correctly
            updated (Satisfies Requirement 10.1 Obtain Message Information).
         Verify that the message and parameters set in step 2 are correctly
            reported by the device in the status inquiry performed in step 3 (Satisfies
            Requirement 10.2 Set Message and Requirement 10.3 Obtain
            Information for Message Entry).
         Verify that the CRC value reported in the status inquiry performed in step
            3 is 49859 (0x C2 C3) (Satisfies Requirement 10.5 CRC Calculation).
7. Attempt to set an invalid message. At the main command prompt, enter
    “setmessage.” Enter the following information as prompted:
    Message Number: 10
    Message: D[invalidtag]OT
    Message Owner: Owner1
    Run Time Priority: 100
    Beacons Activation: n
    Pixel Service Enabling: n
8. Examine the report file. Verify that the report file indicates that an error
    occurred in setting the message. Verify that the validation error status indicates a
    MULTI syntax error (Satisfies Requirement 10.4 Set Invalid Message).
9. Set a message enabling beacons. Repeat step 2, choosing “y” for the beacon
    option. When given the option to activate the message, enter “y.” Enter the
    following information as prompted:
    Activation Priority: 255
    Message Duration: 20
10. Examine the report file and ensure that no errors were reported. Verify that the
    message was appropriately displayed and that the beacons were activated
    (Satisfies Requirement 10.6 Set Message with Beacons Activated).
11. Configure automatic pixel service. At the main command prompt, enter
    “pixelservice.” At the pixel service command prompt, enter “set.” As prompted,
    enter the following information:
    Pixel Service Duration: 90
    Pixel Service Cycle Period: 5
    Time of First Daily Pixel Service: 240
12. Set a message enabling pixel service. At the main command prompt, enter
    “setmessage.” As prompted, enter the following information:
    Message Number: 11


                                        52
                                                 Progress Report No.5: January 2005 – March 2005


       Message: DMS
       Message Owner: Owner1
       Run Time Priority: 100
       Beacons Activation: n
       Pixel Service Enabling: y
       When given the option of activating the message, enter “y.” As prompted, enter
       the following the information:
       Activation Priority: 255
       Message Duration: 30
   13. Examine the report file and verify that no errors are reported. Verify that the
       message is displayed. Monitor the sign for ten minutes and verify that the pixel
       service operation is carried out by the device (Satisfies Requirement 10.7 Set
       Message with Pixel Service Enabled).


11. Sign Control

This conformance group is used to control the operation of the device. Objects within
this conformance group handle the control mode (central, local, etc.), software resets,
message activation, and the important information concerning activated messages.

       Objects: dmsControlMode.0, dmsSWReset.0, dmsActivateMessage.0,
       dmsMessageTimeRemaining.0, dmsMsgTableSource.0, dmsMsgRequesterID.0,
       dmsMsgSourceMode.0, dmsMemoryMgmt.0, dmsActivateMsgError.0

Requirements

      11.1 Obtain Control Mode Information – Verify that the device responds
       appropriately to “get” requests for the dmsControlMode.0 object, correctly
       indicating the control mode of the device.
      11.2 Set Control Mode - Verify that the control mode can be set, and that the
       device behaves appropriately for the setting.
      11.3 Software Reset – Verify that the software can be reset.
      11.4 Activate Message – Verify that valid messages can be activated and that
       these messages are correctly displayed.
      11.5 Obtain Message Timing Information – Verify that the
       dmsMessageTimeRemaining.0 object correctly reports the remaining activation
       time of the currently activated message. Verify that the message is terminated
       when this value reaches 0. Additionally, verify that this value is correctly
       initialized when messages are activated.
      11.6 Modify Message Timing – Verify that the message timer can be modified to
       change the duration of an activated message. Verify that the new time is
       implemented by the device.
      11.7 Obtain Message Source Information – Verify that the dmsMsgSourceMode.0
       object correctly reflects the reason for a message being displayed.
      11.8 Activate Message with Invalid CRC – Verify that message activations with


                                            53
                                                  Progress Report No.5: January 2005 – March 2005


        incorrect CRC values are not carried out by the device.
       11.9 Activate Message with Low Priority – Verify that message activations with
        activation priorities lower than the run time priorities of the currently activated
        messages are not carried out by the device.


Requirement             Status/     Related Files            Comments
                        Date
11.1 Obtain Control     Passed      centrallog11ADDCO.tx     The device indicates central control at
Mode Information        3/11/2004   t                        all times. This is due to the fact that
                                                             the local control switch does not
                                                             disable central control, only enabling
                                                             local control.
11.2 Set Control Mode   Passed      centrallog11ADDCO.tx     Since the device cannot be changed to
                        3/11/2004   t                        local control, there is never a need to
                                                             switch control to central override
                                                             mode. This was not tested.
11.3 Software Reset     Passed      centrallog11ADDCO.tx     The device was successfully reset
                        3/11/2004   t                        from central, and the default software
                                                             reset message was displayed.
11.4 Activate Message   Passed      centrallog11ADDCO.tx     Valid message was activated and
                        3/11/2004   t                        properly displayed.
11.5 Obtain Message     Passed      centrallog11ADDCO.tx     The dmsMessageTimeRemaining.0
Timing Information      3/11/2004   t                        object correctly reported the remaining
                                                             activation time of an activated
                                                             message. The message was terminated
                                                             when this value reached 0. The value
                                                             was also correctly initialized when the
                                                             message was activated.
11.6 Modify Message     Passed      centrallog11ADDCO.tx     The message timer was modified to
Timing                  3/11/2004   t                        change the duration of an activated
                                                             message and the new time was
                                                             implemented by the device.
11.7 Obtain Message     Passed      centrallog11ADDCO.tx     A message was displayed and the
Source Information      3/11/2004   t                        device correctly reported the source of
                                                             the message to be central. A message
                                                             expired, causing activation of the end
                                                             duration message, and the device
                                                             correctly reported the source of the
                                                             message to be end duration. The
                                                             communications loss message was
                                                             also induced, and the sign correctly
                                                             reported the source of the message to
                                                             be a communications loss. The reset
                                                             message was also induced, and the
                                                             device correctly reported the source of
                                                             the message to be a software reset.
11.8 Activate Message   Passed      centrallog11ADDCO.tx     Message with an invalid CRC was not
with Invalid CRC        3/11/2004   t                        activated
11.9 Activate Message   Passed      centrallog11ADDCO.tx     Message activation with an activation
with Low Priority       3/11/2004   t                        priority lower than the run time
                                                             priority of the existing message was
                                                             not carried out by the device.




                                             54
                                               Progress Report No.5: January 2005 – March 2005




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

   1. Run the DMScentral.mac macro.
   2. Manually set the controller control mode switch to remote control.
   3. Obtain control status information. At the main command prompt, enter
       “control.” At the control command prompt, enter “status.”
   4. Attempt to set and activate a message. At the main command prompt, enter
       “setmessage.” As prompted, enter the following information:
       Message Number: 10
       Message: TM0
       Message Owner: Owner1
       Run Time Priority: 100
       Beacons Activation: n
       Pixel Service Enabling: n
       When given the option of activating the message, enter “y.” As prompted, enter
       the following information:
       Activation Priority: 255
       Message Duration: 20
   5. Verify that the message was properly displayed (Satisfies Requirement 11.4
       Activate Message).
   6. Manually set the controller control mode switch to local control.
   7. Repeat step 3.
   8. Repeat step 4, entering the following information as prompted:
       Message Number: 11
       Message: TM1
       Message Owner: Owner1
       Run Time Priority: 100
       Beacons Activation: n
       Pixel Service Enabling: n
       When given the option of activating the message, enter “y.” As prompted, enter
       the following information:
       Activation Priority: 255
       Message Duration: 20
   9. Verify that the message was not displayed (the previously displayed message
       remained as the activated message).
   10. Remotely override central control. At the main command prompt, enter
       “control.” At the control command prompt, enter “mode.” When prompted to



                                          55
                                             Progress Report No.5: January 2005 – March 2005


    enter the desired control mode, enter “centraloverride.”
11. Repeat step 3.
12. Repeat step 8.
13. Verify that the message was properly displayed (Successful Results of Steps 5, 9,
    and 13 Satisfy Requirement 11.2 Set Control Mode).
14. Examine the report file. Verify that in the control status inquiries of steps 3, 7,
    and 11 indicate control modes of central, local, and central override, respectively
    (Satisfies Requirement 11.1 Obtain Control Mode Information).
15. Reactivate message 10 for 20 minutes. At the main command prompt, enter
    “activatemessage.” Enter the following information as prompted:
    Message Number: 10
    Activation Priority: 255
    Message Duration: 20
    Verify that the message is displayed.
16. Repeat step 3.
17. Pause for five minutes.
18. Repeat step 3.
19. Modify the message duration. At the main command prompt, enter “control.” At
    the control command prompt, enter “time.” When prompted for the new message
    duration, enter “1.”
20. Repeat step 3.
21. Verify that the message expires after 1 minute (Satisfies Requirement 11.6
    Modify Message Timing).
22. Examine the report file. Verify that the message duration reported for the status
    inquiries in steps 16, 18, and 20 are 20, 15, and 1, respectively (Satisfies
    Requirement 11.5 Obtain Message Timing Information). Also, verify that the
    source of the activated message reported in the status inquiries is central
    (Satisfies Requirement 11.7 Obtain Message Source Information).
23. Attempt to activate a message with an invalid CRC. At the main command
    prompt, enter “single.” As prompted, enter the following information:
    Type of Request: set
    Object Name: dmsActivateMessage.0
    Object Syntax: h
    Value: 00 3C FF 03 00 0A C2 C3 9C 4B BF 3B
24. Verify that the message is not displayed (Satisfies Requirement 11.8 Activate
    Message with Invalid CRC).
25. Activate message 10. At the main command prompt, enter “activatemessage.”
    As prompted, enter the following information:
    Message Number: 10
    Activation Priority: 255
    Message Duration: 20
    Verify that the message is displayed.
26. Attempt to activate message 11 with a lower activation priority. At the main
    command prompt, enter “activatemessage.” As prompted, enter the following
    information:
    Message Number: 11



                                        56
                                                  Progress Report No.5: January 2005 – March 2005


        Activation Priority: 50
        Message Duration: 20
    27. Verify that the message was not displayed and that the report file indicates a
        priority error for the activation attempt (Satisfies Requirement 11.9 Activate
        Message with Low Priority).
    28. Reset the controller. At the main command prompt, enter “control.” At the
        Control command prompt, enter “reset.” Verify that the device is reset (Satisfies
        Requirement 11.3 Software Reset).




12. Default Message Control

This conformance group is used to control the default messages that are displayed under
special conditions.

        Objects: dmsShortPowerRecoveryMessage.0,
        dmsLongPowerRecoveryMessage.0, dmsShortPowerLossTime.0,
        dmsResetMessage.0, dmsCommunicationsLossMessage.0,
        dmsTimeCommLoss.0, dmsPowerLossMessage.0, dmsEndDurationMessage.0

Requirements

       12.1 Obtain Default Message Information – Verify that the default messages for
        the device are properly reported, and that these messages are implemented by the
        device.
       12.2 Set Default Messages – Verify that the default messages can be set, and that
        these messages are implemented by the device.


Requirement            Status/     Related Files            Comments
                       Date
12.1 Obtain Default    Passed      centrallog12ADDCO.txt    The device correctly reported the
Messages Information   3/16/2004                            default message settings.
12.2 Set Default       Passed      centrallog12ADDCO.txt    Set messages in changeable memory
Messages               3/16/2004                            (1-6). Set the default messages to point
                                                            to these six messages. Induced each of
                                                            special conditions (power loss, short
                                                            power loss recovery, long power loss
                                                            recovery, software reset,
                                                            communications loss, and message
                                                            expiration). In each case, the correct
                                                            default message was displayed by the
                                                            sign. The only exception to this was
                                                            power loss, for which the sign was
                                                            blanked. Also all the actions were not


                                             57
                                             Progress Report No.5: January 2005 – March 2005


                                                       logged by the macro because it crashed
                                                       when the traps were received.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

   1. Run the DMScentral.mac macro.
   2. Set message to be used as default message in memory. At the main command
      prompt, enter “setmessage.” As prompted, enter the following information:
      Message Number: 1
      Message: DM1
      Message Owner: Owner1
      Run Time Priority: 100
      Beacons Activation: n
      Pixel Service Enabling: n
      When given the option of activating the message, enter “n.”
   3. Repeat step 2 using the following message information:
      Message Number: 2
      Message: DM2
      Message Owner: Owner1
      Run Time Priority: 100
      Beacons Activation: n
      Pixel Service Enabling: n
   4. Repeat step 2 using the following message information:
      Message Number: 3
      Message: DM3
      Message Owner: Owner1
      Run Time Priority: 100
      Beacons Activation: n
      Pixel Service Enabling: n
   5. Repeat step 2 using the following message information:
      Message Number: 4
      Message: DM4
      Message Owner: Owner1
      Run Time Priority: 100
      Beacons Activation: n
      Pixel Service Enabling: n
   6. Repeat step 2 using the following message information:
      Message Number: 5
      Message: DM5


                                        58
                                           Progress Report No.5: January 2005 – March 2005


    Message Owner: Owner1
    Run Time Priority: 100
    Beacons Activation: n
    Pixel Service Enabling: n
7. Repeat step 2 using the following message information:
    Message Number: 6
    Message: DM6
    Message Owner: Owner1
    Run Time Priority: 100
    Beacons Activation: n
    Pixel Service Enabling: n
8. Set the default messages and parameters. At the main command prompt, enter
    “defaultmessages.” At the default messages command prompt, enter “set.” As
    prompted, enter the following information:
    Message Memory Type for Short Power Loss Recovery Message: changeable
    Message Number for Short Power Loss Recovery Message: 1
    Message Memory Type for Long Power Loss Recovery Message: changeable
    Message Number for Long Power Loss Recovery Message: 2
    Short Power Loss Recovery Time: 10
    Message Memory Type for Reset Message: changeable
    Message Number for Reset Message: 3
    Message Memory Type for Communications Loss Message: changeable
    Message Number for Communications Loss Message: 4
    Communications Loss Threshold Time: 5
    Message Memory Type for Power Loss Message: changeable
    Message Number for Power Loss Message: 5
    Message Memory Type for End Duration Message: changeable
    Message Number for End Duration Message: 6
9. Obtain default message information. At the main command prompt, enter
    “defaultmessages.” At the default messages command prompt, enter “status.”
10. Examine the report file. Verify that no errors are reported in the report file.
    Additionally, verify that the information reported by the device for the status
    inquiry is appropriate for the default messages and parameters defined above
    (Satisfies Requirement 12.1 Obtain Default Messages Information).
11. Induce a short power loss. Disconnect power from the device for 5 seconds, and
    reconnect power. Verify that the default short power loss recovery message,
    “DM1,” is displayed by the device.
12. Induce a long power loss. Disconnect power from the device for 15 seconds, and
    reconnect power. Verify that the default long power loss recovery message,
    “DM2,” is displayed by the device.
13. Reset the DMS controller. Verify that the default reset message, “DM3,” is
    displayed by the device.
14. Induce a communications loss. Refrain from sending messages to the device for a
    period of 6 minutes. Verify that the default communications loss message,
    “DM4,” is displayed by the device.
15. Remove power. While power is removed, verify that the default power loss



                                      59
                                                   Progress Report No.5: January 2005 – March 2005


        message, “DM5,” is displayed by the device. Reconnect power.
    16. Activate a message for one minute. At the main command prompt, enter
        “activatemessage.” As prompted, enter the following information:
        Message Number: 1
        Activation Priority: 255
        Message Duration: 1
        Verify that the message “DM1” is displayed. Verify that after one minute, the
        default end duration message, “DM6,” is displayed (Successful Results of Steps
        11 through 15 Satisfy Requirement 12.2 Set Default Messages).



13. Pixel Service Control

This conformance group is used to control the pixel service parameters. The objects in
this group control the duration, timing, and frequency of the tests.

        Objects: vmsPixelServiceDuration.0, vmsPixelServiceFrequency.0,
        vmsPixelServiceTime.0

Requirements

       13.1 Obtain Pixel Service Parameter Information – Verify that the information
        about the pixel service parameters is properly reported by the device. Also, verify
        these parameters are implemented by the device.
       13.2 Set Pixel Service Parameters – Verify that the pixel service parameters can
        be set. Also, verify that these parameters are implemented by the device.


Requirement              Status/      Related Files         Comments
                         Date
13.1 Obtain Pixel        Not Tested                         Pixel service is not required for all-LED
Service Parameter                                           signs.
Information
13.2 Set Pixel Service   Not Tested                         Pixel service is not required for all-LED
Parameters                                                  signs.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None



                                              60
                                                Progress Report No.5: January 2005 – March 2005


   1. Run the DMScentral.mac macro.
   2. Set the automatic pixel service parameters. At the main command prompt, enter
      “pixelservice.” At the pixel service command prompt, enter “set.” As prompted,
      enter the following information:
      Pixel Service Duration: 90
      Pixel Service Cycle Period: 5
      Time of First Daily Pixel Service: 120
   3. Obtain pixel service information. At the main command prompt, enter
      “pixelservice.” At the pixel service command prompt, enter “status.”
   4. Examine the report file. Verify that no errors are reported in the report file, and
      verify that the status response from the device indicates the parameter values set
      in step 2 (Satisfies Requirement 13.1 Obtain Pixel Service Parameter
      Information).
   5. Set a message enabling pixel service. At the main command prompt, enter
      “setmessage.” As prompted, enter the following information:
      Message Number: 10
      Message: DOT
      Message owner: owner1
      Run Time Priority: 100
      Beacons Activation: n
      Pixel Service Enabling: y
      When given the option of activating the message, enter “y.” As prompted, enter
      the following information:
      Activation Priority: 255
      Message Duration: 30
   6. Verify that the message is properly displayed. Examine the report file and verify
      that no errors are reported. Verify that within five minutes, a pixel service is
      carried out (Satisfies Requirement 13.2 Set Pixel Service Parameters).




14. MULTI Error Control

This conformance group is used to provide information about MULTI errors in messages.
If an attempt is made to validate a message with MULTI syntax errors, the errors are
reported by the objects in this conformance group.

       Objects: dmsMultiSyntaxError.0, dmsMultiSyntaxErrorPosition.0,
       dmsMultiOtherErrorDescription.0

Requirements

      14.1 Obtain MULTI Error Information – Verify that MULTI errors in messages
       are correctly reported.




                                           61
                                                Progress Report No.5: January 2005 – March 2005




Requirement            Status/     Related Files         Comments
                       Date
14.1 Obtain MULTI      Passed      centrallog14ADDCO.    The device correctly reported a MULTI
Error Information      3/16/2004   txt                   syntax error corresponding to an invalid
                                                         tag and, appropriately, failed to validate
                                                         the message.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

           1. Run the DMScentral.mac macro.
           2. Set a message with a MULTI error. At the main command prompt, enter
              “quickset.” When prompted, enter the message “D[invalidtag]OT.”
           3. At the main command prompt, enter “status.” At the status command
              prompt, enter “multierror.”
           4. Examine the report file. Verify that the message set entry reports a
              MULTI error. Verify that the MULTI error status response indicates the
              type of MULTI error to be an unsupported tag. Verify that an appropriate
              value is reported for the position of the MULTI error (Satisfies
              Requirement 14.1 Obtain MULTI Error Information).


15. Illumination/Brightness Control

This conformance group is used to control and monitor the brightness of the sign display.
The brightness can be controlled manually, by a timer, or by a photocell algorithm. The
objects in this conformance group handle control of the display by each of the
aforementioned methods. Additionally, the objects in this conformance group report the
brightness level of the device, the maximum brightness level of the device, the maximum
photocell reading, and the photocell reading.

       Objects: dmsIllumControl.0, dmsIllumMaxPhotocellLevel.0,
       dmsIllumPhotocellLevelStatus.0, dmsIllumNumBrightLevels.0,
       dmsIllumBrightStatus.0, dmsIllumManLevel.0, dmsIllumBrightnessValues.0,
       dmsIllumBrightnessValuesStatus.0, dmsIllumLightOutputStatus.0

Requirements



                                           62
                                                 Progress Report No.5: January 2005 – March 2005


       15.1 Obtain Brightness Control Information – Verify that all
        Illumination/Brightness Control objects correctly respond to SNMP “get” requests
        and provide the correct information.
       15.2 Manual Control – Verify that the sign’s brightness can be controlled
        manually. Also, verify that the information reported by the device correctly
        indicates the brightness of the device.
       15.3 Photocell Control – Verify that the sign’s brightness can be controlled using
        the photocell algorithm. Also, verify that the information reported by the device
        correctly indicates the brightness of the device.
       15.4 Photocell Algorithm Configuration – Verify that the photocell algorithm can
        be modified, and that the device correctly implements the algorithm.



Requirement              Status/      Related Files         Comments
                         Date
15.1 Obtain Brightness   Passed       centrallog15ADDCO.    All Illumination/Brightness Control
Control Information      3/16/2004    txt                   objects correctly responded to SNMP
                                                            “get” requests and provided the correct
                                                            information.
15.2 Manual Control      Passed/      centrallog15ADDCO.    An attempt was made to manually
                         21 Apr 04    txt                   modify the brightness of the sign by
                                      retest15ADDCO.txt     setting the dmsIllumControl.0 object
                                                            to 4 (manual), and setting the
                                                            dmsIllumManLevel.0 object to various
                                                            values. The device allowed
                                                            modification of the objects, and
                                                            indicated, through the
                                                            dmsIllumBrightLevelStatus.0 object,
                                                            that the brightness level was being
                                                            adjusted. However, no noticeable
                                                            change in the sign’s brightness could
                                                            be observed.
                                                            After a software upgrade, user was
                                                            able to manually control sign’s
                                                            brightness.
15.3 Photocell Control   Passed/      centrallog15ADDCO.    Following a software upgrade, the
                         21 Apr 04    txt                   brightness of the sign was controlled
                                      retest15ADDCO.txt     using the photocell.
15.4 Photocell           Not Tested
Algorithm
Configuration




Example Test Procedure

Required Macros
    DMS Central.mac




                                            63
                                                Progress Report No.5: January 2005 – March 2005


Required Input Files
None

   1. Obtain brightness control information. At the main command prompt, enter
      “display.” At the display command prompt, enter “status.”
   2. Examine the report file. Verify that no errors are reported in the file. Verify that
      the display control mode, the photocell range, the current photocell level, the
      display brightness range, and the current brightness level are correctly reported
      in the file (Satisfies Requirement 15.1 Obtain Brightness Control Information).
   3. Manually set brightness level. At the main command prompt, enter “display.” At
      the display command prompt, enter “manual.” When prompted to enter to enter
      a brightness level, enter the maximum brightness level allowed (the user is
      provided with a range).
   4. Verify that the brightness of the sign changed to the brightest level. Examine the
      report file and verify that no errors are reported (Satisfies Requirement 15.2
      Manual Control).
   5. Return brightness control to photocell control. At the main command prompt,
      enter “display.” At the display command prompt, enter “photocell.”
   6. Verify that brightness of the sign is being controlled through the photocell. Also,
      examine the report file and verify that no errors are reported (Satisfies
      Requirement 15.3 Photocell Control).
   7. Load a new brightness algorithm. Construct a suitable brightness values string.
      At the main command prompt, enter “single.” When prompted to enter the
      request type, enter “set.” When prompted to enter the object name, enter
      “dmsIllumBrightnessValues.0.” When prompted to enter the object syntax type,
      enter “h.” When prompted to enter the value to which the object is to be set,
      enter the brightness values string constructed.
   8. Examine the report file and verify that no errors are reported. Verify that the new
      algorithm is properly implemented (Satisfies Requirement 15.4 Photocell
      Algorithm Configuration).




16. Sign Status

This conformance group is used to provide information about status fields currently being
displayed on the sign (such as time, temperature, etc.). Additionally, objects in this
conformance group keep track of “Watchdog Failures” and the status of the cabinet
doors.

       Objects: statMultiFieldRows.0, statMultiFieldIndex.x, statMultiFieldCode.x,
       statMultiCurrentFieldValue.x, watchdogFailureCount.0, dmsStatDoorOpen.0

Requirements




                                           64
                                                  Progress Report No.5: January 2005 – March 2005


       16.1 Obtain Status Field Information – Verify that the device correctly reports the
        information associated with each of the status fields.
       16.2 Obtain Watchdog Failure Counts Information – Verify that the
        watchdogFailureCount.0 object correctly reports the number of watchdog failures.
       16.3 Obtain Cabinet Doors Status Information – Verify that the
        dmsStatDoorOpen.0 object correctly reports the status of the cabinet doors.



Requirement            Status/     Related Files             Comments
                       Date
16.1 Obtain Status     Passed      centrallog16ADDCO.tx      The status field information was
Field Information      6/10/2004   t,                        incorrectly reported by the device.
                                   retest16ADDCO.txt         After a software upgrade, the device
                                                             correctly reported the information
                                                             associated with status fields.
16.2 Obtain Watchdog   Passed      centrallog16ADDCO.tx      The watchdogFailureCount.0 object
Failure Counts         3/16/2004   t                         correctly reported the number of
Information                                                  watchdog failures.
16.3 Obtain Cabinet    Passed      centrallog16ADDCO.tx      The dmsStatDoorOpen.0 object
Doors Status           3/16/2004   t                         correctly reported the status of the
Information                                                  cabinet doors.



Example Test Procedure


Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Set a message utilizing field device information. At the main command prompt,
       enter “quickset.” When prompted to enter the message, enter “[f4,3][np][f7,3].”
    3. Verify that the message is correctly displayed, alternating between messages
       indicating the temperature and the day of the week.
    4. Obtain field device status information. At the main command prompt, enter
       “status.” At the status command prompt, enter “fields.”
    5. Examine the report file. Verify that no errors are reported in the file.
            Verify that the information for the field device utilized by the message are
               properly reported (the status response should indicate the first field device
               to be the temperature and the actual temperature should be indicated
               along with the same information for the day of the week) (Satisfies
               Requirement 16.1Obtain Status Field Information).
            Verify that the number of watchdog failures is correctly reported in the
               status report (Satisfies Requirement 16.2 Obtain Watchdog Failure


                                             65
                                                    Progress Report No.5: January 2005 – March 2005


                 Counts).
                Verify that the status of the cabinet doors is correctly reported (Satisfies
                 Requirement 16.3 Obtain Cabinet Doors Status Information).




17. Status Error

This conformance group is used to report various errors associated with the device
(communications, temperature, power, etc.).

        Objects: shortErrorStatus.0, controllerErrorStatus.0

Requirements

       17.1 Obtain Status Error Information – Verify that errors with the device are
        correctly reported by the shortErrorStatus.0 and controllerErrorStatus.0 objects.



Requirement             Status/      Related Files             Comments
                        Date
17.1 Obtain Status      Failed/      Retest17ADDCO.txt         The value of the shorterrorstatus.0
Error Information       17 Mar 05                              object did not accurately reflect the
                                                               status of the device, even when pixel
                                                               failures were detected by the device.



Example Test Procedure


Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Obtain error status information. At the main command prompt, enter “status.”
       At the status command prompt, enter “error.”
    3. Examine the report file. Verify that no errors were reported in communicating
       with the device, and verify that the status report indicates that no errors have
       occurred with the device.
    4. Induce a power failure. Remove power from the device.
    5. Repeat step 2.


                                               66
                                                  Progress Report No.5: January 2005 – March 2005


    6. Examine the report file. Verify that no errors were reported in communicating
        with the device, and verify that the last status report indicates a power error.
    7. Restore power to the device.
    8. Induce a pixel error.
    9. Repeat step 2.
    10. Examine the report file. Verify that the no errors were reported in
        communicating with the device and verify that the last status report indicates a
        pixel error (Successful Results for Steps 3, 6, and 10 Satisfy Requirement 17.1
        Obtain Status Error Information).




18. Pixel Error Status

This conformance group is used to report information about failed pixels. The objects in
this group provide information about the number and location of failed pixels, along with
information about the status of the pixels (stuck on or stuck off) and the method in which
the failure was detected. Additionally, the conformance group can be used to activate a
pixel test.

        Objects: PixelFailureTableNumRows.0, pixelFailureDetectionType.x,
        pixelFailureIndex.x, pixelFailureXLocation.x, pixelFailureYLocation.x,
        pixelFailureStatus.x, pixelTestActivation.0

Requirements

       18.1 Obtain Pixel Error Information – Verify that information about failed pixels
        is correctly reported.
       18.2 Activate Pixel Test – Verify that pixel tests can be activated using the
        pixelTestActivation.0 object.
       18.3 Clear Pixel Failure Table – Verify that the pixel failure table can be cleared
        using the pixelTestActivation.0 object.



Requirement           Status/      Related Files             Comments
                      Date
18.1 Obtain Pixel     Passed/      Centrallog18ADDCO.t       Pixel error information was incorrectly
Error Information     17 Mar 05    xt, retest18ADDCO.txt     reported. After hardware upgrade,
                                                             information about pixels was correctly
                                                             reported with number of failed pixels
                                                             varied.
18.2 Activate Pixel   Passed/      Centrallog18ADDCO.t       Pixel test was activated using
Test                  17 Mar 05    xt, retest18ADDCO.txt     pixelTestActivation.0 object.
18.3 Clear Pixel      Passed/      Centrallog18ADDCO.t       Pixel failure table was cleared using
Failure Table         17 Mar 05    xt, retest18ADDCO.txt     pixelTestActivation.0 object.




                                             67
                                                 Progress Report No.5: January 2005 – March 2005




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

   1. Run the DMScentral.mac macro.
   2. Clear the pixel failure table. At the main command prompt, enter “control.” At
       the control command prompt, enter “pixeltest.” At the pixel test command
       prompt, enter “cleartable.”
   3. Obtain pixel failure information. At the main command prompt, enter “status.”
       At the status command prompt, enter “pixel.” When prompted to enter the pixel
       detection method, enter “test.”
   4. Examine the report file. Verify that no errors relating to communication with the
       device are reported. Verify that no test pixel failures are reported.
   5. Induce pixel failures.
   6. Activate pixel test. At the main command prompt, enter “control.” At the control
       command prompt, enter “pixeltest.” At the pixel test command prompt, enter
       “test.”
   7. Verify that the pixel service is carried out. Examine the report file and verify that
       no errors relating to communication with the device are reported (Satisfied
       Requirement 18.2 Activate Pixel Test).
   8. Obtain pixel failure information. At the main command prompt, enter “status.”
       At the status command prompt, enter “pixel.” When prompted to enter the pixel
       detection method, enter “test.” When prompted to enter the pixel number, enter
       “all.”
   9. Examine the report file. Verify that no errors relating to communication with the
       device are reported. Verify that the information about the pixel failures induced
       in step 5 is correctly reported (Satisfies Requirement 18.1 Obtain Pixel Error
       Information).
   10. Repeat steps 2 and 3.
   11. Repeat step 4 (Successful Results of Steps 4 and 11 Satisfy Requirement 18.3
       Clear Pixel Failure Table).




19. Lamp Error Status

This conformance group is used to provide information about failed lamps. Information
is provided about the status of each failed lamp (stuck on or stuck off). Additionally, one
object in this group is used to activate lamp tests.




                                            68
                                                 Progress Report No.5: January 2005 – March 2005


        Objects: lampFailureStuckOn.0, lampFailureStuckOff.0, lampTestActivation.0

Requirements

       19.1 Activate Lamp Test – Verify that lamp tests can be activated using the
        lampTestActivation.0 object.
       19.2 Obtain Lamp Failure Information – Verify that information about lamp
        failures is correctly reported




Requirement            Status/      Related Files       Comments
                       Date
19.1 Activate Lamp     Not Tested                       The demonstration device did not support
Test                                                    lamps (all-LED).
19.2 Obtain Lamp       Not Tested                       The demonstration device did not support
Failure Information                                     lamps (all-LED).



Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Induce lamp failures.
    3. Activate lamp tests. At the main command prompt, enter “control.” At the
       control command prompt, enter “lamp.”
    4. Verify that the lamp tests were carried out. Examine the report file and verify that
       no errors are reported (Satisfies Requirement 19.1 Activate Lamp Test).
    5. Obtain lamp failure information. At the main command prompt, enter “status.”
       At the status command prompt, enter “error.”
    6. Examine the report file. Verify that no errors related to communication with the
       device are reported. Verify that the information regarding the lamp failures
       induced in step 2 is properly reported (Satisfies Requirement 19.2 Obtain Lamp
       Failure Information).
    7. Restore lamps to operational status.




20. Fan Error Status


                                            69
                                                   Progress Report No.5: January 2005 – March 2005




This conformance group is used to provide information about failed fans. Additionally,
one object within the group is used to activate fan tests.

        Objects: fanFailures.0, fanTestActivation.0

Requirements

       20.1 Activate Fan Test – Verify that fan tests can be activated using the
        fanTestActivation.0 object
       20.2 Obtain Fan Failure Information – Verify that information about fan failures
        is correctly reported




Requirement              Status/      Related Files       Comments
                         Date
20.1 Activate Fan Test   Not Tested                       The demonstration device did not support
                                                          Fan.
20.2 Obtain Fan          Not Tested                       The demonstration device did not support
Failure Information                                       Fan.



Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Induce fan failures.
    3. Activate fan tests. At the main command prompt, enter “control.” At the control
       command prompt, enter “fan.”
    4. Verify that the fan tests were carried out. Examine the report file and verify that
       no errors are reported (Satisfies Requirement 20.1 Activate Fan Test).
    5. Obtain fan failure information. At the main command prompt, enter “status.” At
       the status command prompt, enter “error.”
    6. Examine the report file. Verify that no errors related to communication with the
       device are reported. Verify that the information regarding the fan failures
       induced in step 2 is properly reported (Satisfies Requirement 20.2 Obtain Fan
       Failure Information).
    7. Restore fans to operational status.



                                              70
                                                Progress Report No.5: January 2005 – March 2005




21. Power Status

This conformance group is used to provide information about the sign’s power supply
(voltage, type of power supply, etc.).

        Objects: signVolts.0, lineVolts.0, powerSource.0

Requirements

       21.1 Obtain Power Status Information – Verify that the correct information about
        the power supply is reported



Requirement            Status/     Related Files         Comments
                       Date
21.1 Obtain Power      Failed/     Retest21ADDCO.txt     The line voltage and power source were
Status Information     17 Mar 05                         incorrectly reported.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1. Run the DMScentral.mac macro.
    2. Obtain power status information. At the main command prompt, enter “status.”
       At the status command prompt, enter “error.”
    3. Examine the report file. Verify that no errors related to communication with the
       device are reported. Verify that the sign voltage, line voltage, and power source
       type are properly reported in the status report (Satisfies Requirement 21.1
       Obtain Power Status Information).



22. Temperature Status

This conformance group is used to provide information about readings from the
temperature sensors. Information is provided about the maximum and minimum
temperature readings in the control cabinet and the sign housing, as well as maximum
and minimum ambient temperature readings.


                                           71
                                                  Progress Report No.5: January 2005 – March 2005




       Objects: tempMinCtrlCabinet.0, tempMaxCtrlCabinet.0, tempMinAmbient.0,
       tempMaxAmbient.0, tempMinSignHousing.0, tempMaxSignHousing.0

Requirements

      22.1 Obtain Temperature Information – Verify that the correct temperature
       information is reported



Requirement            Status/     Related Files           Comments
                       Date
22.1 Obtain            Passed      centrallog22ADDCO.      The device reported temperature
Temperature            3/16/2004   txt                     information correctly.
Information




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

   1. Run the DMScentral.mac macro.
   2. Obtain temperature status information. At the main command prompt, enter
      “status.” At the status command prompt, enter “temp.”
   3. Examine the report file. Verify that no errors are reported. Verify that the range
      of temperatures reported by the control cabinet temperature sensors, ambient
      temperature sensors, and sign housing temperature sensors are correct (Satisfies
      Requirement 22.1 Obtain Temperature Information).




23. Florida Department of Transportation DMS

This conformance group is intended to address functional requirements not addressed by
the national standards. Optional objects are used to provide information about multiple
power supplies. Another optional object is used to set a maximum temperature threshold
for the sign housing. If the sign housing temperature exceeds this threshold, the sign is
blanked. Objects are also required that control the generation of errors in the log after
long communications failures. One object is used to specify a maximum failed pixel
threshold. If the number of failed pixels exceeds this threshold, the sign is to be blanked.


                                             72
                                                 Progress Report No.5: January 2005 – March 2005


This feature can be overridden by setting this object to the number of pixels supported by
the sign. Other objects are used to handle messages displayed during long power losses
(for fiber/flip disk hybrid signs). One object is used to indicate when any of the event
classes in the log are filled to 90% capacity. Another optional object is used to specify a
maximum length of time of inactivity. If this time is exceeded, the user is logged off.
One object is also used to indicate the reason for the sign being blanked in the event of a
special condition such as excess LED temperature, long power loss, or excessive numbers
of failed pixels.

       Objects: fdotPowerSupplyFailures.0 (optional), fdotPowerSupplyTableRows.0
       (optional), fdotPowerSupplyNumber.x (optional), fdotPowerSupplyType.x
       (optional), fdotPowerSupplyDescription.x (optional), fdotPowerSupplyVoltage.x
       (optional), fdotPowerSupplyStatus.x (optional), fdotCriticalMaxTemperature.0
       (optional), fdotDmsMaxPollTime.0, fdotDmsErrorGenerationToggle.0,
       fdotMaxNumPixelFailure.0, fdotLongPowerLossTime.0 (optional),
       dmsLongPowerLossMessage.0 (optional), fdotLog90Full.0,
       dmsNoActivityTime.0 (optional), fdotMsgSourceModeExtension.0

Requirements

      23.1 Obtain Maximum Poll Time Parameter Information – Verify that the device
       correctly responds to “get” requests for the fdotDmsMaxPollTime.0 and
       fdotDmsErrorGenerationToggle.0 objects.
      23.2 Set Maximum Poll Time Parameters – Verify that a maximum poll time for
       error generation disabling can be set. Also, verify that error generation is disabled
       if this time limit is exceeded, and this feature is enabled. Also, verify that the
       feature can be disabled.
      23.3 Obtain Pixel Failure Threshold Information – Verify that the device
       responds appropriately to “get” requests for the fdotMaxNumPixelFailure.0
       object.
      23.4 Set Pixel Failure Threshold – Verify that the pixel failure threshold can be
       set. Also, verify that the sign is blanked and the correct information is reported
       by the fdotMsgSourceModeExtension.0 object if this threshold is exceeded.
       Verify that this feature can be overridden by setting the threshold to the total
       number of pixels supported by the sign.
      23.5 FDOT Specific Conditions – Verify that the fdotMsgSourceModeExtension.0
       object provides the correct information for special conditions such as the number
       of failed pixels exceeding the pixel failure threshold defined by
       fdotMaxNumPixelFailure.0 object.




                                            73
                                                   Progress Report No.5: January 2005 – March 2005


Requirement              Status/     Related Files            Comments
                         Date
23.1 Obtain Maximum      Passed      centrallog23_1ADDCO      The device correctly responded to
Poll Time Parameter      3/24/2004   .txt                     “get” requests for the
Information                                                   fdotDmsMaxPollTime.0 and
                                                              fdotDmsErrorGenerationToggle.0
                                                              objects.
23.2 Set Maximum         Passed      centrallog23ADDCO.tx     A maximum poll time for error
Poll Time Parameters     3/24/2004   t                        generation disabling was set. The error
                                                              generation was disabled when the time
                                                              limit was exceeded.
23.3 Obtain Pixel        Passed/     retest23ADDCO.txt        After a hardware upgrade, the device
Failure Threshold        17 Mar 05                            appropriately responded to “get”
Information                                                   requests for the
                                                              fdotMaxNumPixelFailure.0 object.
23.4 Set Pixel Failure   Passed/     retest23ADDCO.txt        After a hardware upgrade, the pixel
Threshold                17 Mar 05                            failure threshold was able to be set.
                                                              The sign was blanked and the correct
                                                              information, pixel failure, was
                                                              reported when this threshold was
                                                              exceeded.
23.5 FDOT Specific       Passed      retest23ADDCO.txt        After a hardware upgrade, the
Conditions               17 Mar 05                            fdotMsgSourceModeExstention.0
                                                              object provided the correct
                                                              information for the special condition
                                                              of the number of failed pixels
                                                              exceeding the pixel failure threshold.
23.6 Log Warning         Passed      centrallog23_1ADDCO      The fdotLog90Full.0 object correctly
                         6/2/2004    .txt                     indicated when a log was 90% full.




Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None


    1. Run the DMScentral.mac macro.
    2. Configure an event class. At the main command prompt, enter “globalreport.”
       At the Global Report command prompt, enter “classconfig.” As prompted, enter
       the following information:
       Class Number: 1
       Class Size: 10
       Class Description: Test Class
    3. Verify that the class contains no entries. At the main command prompt, enter
       “globalreport.” At the Global Report command prompt, enter “status.” At the
       Global Report Status command prompt, enter “logentry.” When prompted to


                                              74
                                             Progress Report No.5: January 2005 – March 2005


    enter the class number, enter “1.” Examine the report file and verify that the
    device indicated that the class contained no log entries.
4. Configure an event. At the main command prompt, enter “globalreport.” At the
    Global Report command prompt, enter “eventconfig.” As prompted, enter the
    following information:
    Event Number: 1
    Class Number: 1
    Configuration Mode: change
    Value 1: 1
    Value 2: 1
    Object to be Monitored: dmsMessageTimeRemaining.0
    Object to be Logged: dmsMessageTimeRemaining.0
    Enable Logging: n
5. Set up FDOT maximum poll time parameters. At the main command prompt,
    enter “fdot.” At the FDOT command prompt, enter “set.” As prompted, enter
    the following information:
    Maximum Poll Time (minutes): 5
    Enable Maximum Poll Time Feature: y
    Pixel Failure Threshold: 50
6. Set and activate message. At the main command prompt, enter “quickset.” When
    prompted to enter the message, enter “ABC.”
7. Modify the activation time for the message. At the main command prompt, enter
    “control.” At the Control command prompt, enter “time.” When prompted to
    enter the new activation time for the message (minutes), enter “120.”
8. Enable event configuration. At the main command prompt, enter “single.” As
    prompted, enter the following information:
    Request Type: set
    Object Name: eventConfigAction.1
    Object Syntax Type: i
    Value: 3
9. Wait for a period of 10 minutes, sending no messages to the device.
10. Disable the event configuration. At the main command prompt, enter “single.”
    As prompted, enter the following information:
    Request Type: set
    Object Name: eventConfigAction.1
    Object Syntax Type: i
    Value: 2
11. Examine the log entries. At the main command prompt, enter “globalreport.” At
    the Global Report command prompt, enter “status.” At the Global Report Status
    command prompt, enter “logentry.” As prompted, enter the following
    information:
    Class Number: 1
    Log Entry Number: all
    Verify that five log entries are reported (four or six entries is also acceptable),
    corresponding to sequentially decremented values of the activation time (Satisfies
    Requirement 23.2 Set Maximum Poll Time Parameters).



                                        75
                                             Progress Report No.5: January 2005 – March 2005


12. Obtain maximum poll time parameters. At the main command prompt, enter
    “fdot.” At the FDOT command prompt, enter “status.” Examine the report file
    and verify that the device indicated that the maximum poll time is set to 5 minutes
    and that the feature is enabled (Satisfies Requirement 23.1 Obtain Maximum
    Poll Time Parameter Information).
13. Verify that the log fill warning is not reported. Examine the report file. In the
    previous request, verify that a warning is not indicated for the log.
14. Turn off maximum poll time feature. At the main command prompt, enter “fdot.”
    At the FDOT command prompt, enter “set.” As prompted, enter the following
    information:
    Maximum Poll Time (minutes): 65535
    Enable Maximum Poll Time Feature: n
    Pixel Failure Threshold: 50
15. Clear the test class. At the main command prompt, enter “globalreport.” At the
    Global Report command prompt, enter “clearclass.” When prompted to enter a
    class number, enter “1.”
16. Configure a test class to log the log fill warning. At the main command prompt,
    enter “globalreport.” At the Global Report command prompt, enter
    “classconfig.” As prompted, enter the following information:
    Class Number: 2
    Class Size: 3
    Class Description: Test Class 2
17. Configure an event for logging the log fill warning. At the main command
    prompt, enter “globalreport.” At the Global Report command prompt, enter
    “eventconfig.” As prompted, enter the following information:
    Event Number: 2
    Class Number: 2
    Configuration Mode: change
    Value 1: 1
    Value 2: 1
    Object to be Monitored: fdotLog90Full.0
    Object to be Logged: fdotLog90Full.0
    Enable Logging: y
18. Repeat step 3.
19. Repeat steps 8, 9, and 10.
20. Examine the log entries for class one. At the main command prompt, enter
    “globalreport.” At the Global Report command prompt, enter “status.” At the
    Global Report Status command prompt, enter “logentry.” As prompted, enter the
    following information:
    Class Number: 1
    Log Entry Number: all
    Verify that ten log entries are reported (nine entries is also acceptable),
    corresponding to sequentially decremented values of the activation.
21. Verify that a log warning is reported. At the main command prompt, enter
    “fdot.” At the FDOT command prompt, enter “status.” Verify that a log fill
    warning is reported.



                                        76
                                              Progress Report No.5: January 2005 – March 2005


22. Examine the log entries for class two. At the main command prompt, enter
    “globalreport.” At the Global Report command prompt, enter “status.” At the
    Global Report Status command prompt, enter “logentry.” As prompted, enter the
    following information:
    Class Number: 2
    Log Entry Number: all
    Verify that one log entry is reported, corresponding to the time of the ninth log
    entry in event class one (Successful Results for Steps 21 and 22 Satisfy
    Requirement 23.6 Log Warning).
23. Set the pixel failure threshold. At the main command prompt, enter “single.”
    Enter the following information as prompted:
    Request Type: set
    Object Name: fdotMaxNumPixelFailure.0
    Object Syntax Type: i
    Value: 1
24. Obtain pixel failure threshold information. At the main command prompt, enter
    “single.” Enter the following information as prompted:
    Request Type: get
    Object Name: fdotMaxNumPixelFailure.0
    Object Syntax Type: d
25. Examine the report file. Verify that no errors are reported and verify that the
    value obtained from the request in step 24 is 1 (Satisfies Requirement 23.3
    Obtain Pixel Failure Threshold Information).
26. Induce a pixel failure.
27. Clear the pixel failure table. At the main command prompt, enter “control.” At
    the control command prompt, enter “pixel test.” At the pixel test command
    prompt, enter “cleartable.”
28. Display a message. At the main command prompt, enter “quickset.” When
    prompted to enter a message, enter “DOT.”
29. Examine the report file and verify that no errors are reported. Verify that the
    message is properly displayed.
30. Activate a pixel test. At the main command prompt, enter “control.” At the
    control command prompt, enter “pixel test.” At the pixel test command prompt,
    enter “test.”
31. Verify that the pixel test is carried out and verify that the sign is blanked upon
    detection of the failed pixel. Examine the report file and verify that no errors are
    reported (Satisfies Requirement 23.4 Set Pixel Failure Threshold).
32. Obtain error information. At the main command prompt, enter “control.” At the
    control command prompt, enter “status.”
33. Examine the report file. Verify that no errors related to communication with the
    device are reported. Verify that the status report indicates the source of the
    displayed message to be excessive numbers of failed pixels (Satisfies
    Requirement 23.5 FDOT Specific Conditions).




                                         77
                                                     Progress Report No.5: January 2005 – March 2005




24. MULTI Tag Requirements

FDOT requires the support of several MULTI tags, used for formatting text on the sign.
The following tags are required: cbx (background color), cfx (foreground color),fx,y
(field), fltxoy/fl (flashing text), fox (font), jlx (line justification), jpx (page justification),
mvtdw,s,r,text (moving text), nlx (new line), np (new page), ptxoy (page timing), and
scx (character spacing).

Requirements

       24.1 Set Messages with MULTI Tags – Verify that all required MULTI tags are
        supported by the device, and that messages containing MULTI tags are properly
        displayed when activated.



Requirement             Status/       Related Files           Comments
                        Date
24.1 Set Messages       Passed        centrallog24ADDCO.      We were unable to activate messages
with MULTI Tags         17 Mar 05     txt,                    making use of the fields for several of
                                      retest24ADDCO.txt       the required MULTI fields.Initially we
                                                              were able to set and activate the message
                                                              “[f4,3] [np] [f7,3]”.However, subsequent
                                                              attempts to activate this message
                                                              failed.Several subsequent messages
                                                              utilizing the MULTI field tags also
                                                              failed.The messages “[f4,3]”,
                                                              “[f3,4]”,”[f1,5]” and “[f10,2]” were
                                                              tested and none were validated.It appears
                                                              that all of the required MULTI tags are
                                                              not supported.However for each of the
                                                              validation failures, the device indicated
                                                              the error to be a MULTI syntax error,
                                                              but the syntax errors were not reported to
                                                              be unsupported tag errors. Instead, the
                                                              dmsMultiSyntaxError.0 object reported a
                                                              value of 2 or a value of 5.These values
                                                              did not seem to be consistent with the
                                                              messages set. After software upgrades,
                                                              messages making use of field MULTI
                                                              tags, flashing text MULTI tags, page
                                                              justification tags, and page timing tags
                                                              were successfully set and displayed.




Example Test Procedure




                                                78
                                                Progress Report No.5: January 2005 – March 2005




Required Macros
    DMScentral.mac

Required Input Files
None

   1. Run the DMScentral.mac macro.
   2. Display a message utilizing information from field devices. At the main command
       prompt, enter “quickset.” When prompted to enter the message, enter
       “[f4,3][np][f7,3].”
   3. Verify that the message (alternating between a message showing the temperature
       in degrees Fahrenheit and a message showing the day of the week) is properly
       displayed. Examine the report file and verify that no errors are reported.
   4. Display a flashing message. At the main command prompt, enter “quickset.”
       When prompted to enter the message, enter “[flt10o10]DOT[/fl].”
   5. Verify that the message (the letters “DOT” flashing on for 1 second and off for 1
       second) is properly displayed. Examine the report file and verify that no errors
       are reported.
   6. Display a message using multiple fonts. At the main command prompt, enter
       “quickset.” When prompted to enter the message, enter
       “[fo1]DOT[np][fo2]DMS.”
   7. Verify that the message (alternating between a message showing the letters
       “DOT” and a message showing the letters “DMS” in a different font) is properly
       displayed. Examine the report file and verify that no errors are reported.
   8. Display a message utilizing justification MULTI tags. At the main command
       prompt, enter “quickset.” When prompted to enter the message, enter
       “[jp2][jl2]TL[np][jp3][jl3]MC[np][jp4][jl4]BR.”
   9. Verify that the message (alternating between the letters “TL” top left justified,
       “MC” middle center justified, and “BR” bottom right justified) is properly
       displayed. Examine the report file and verify that no errors are reported.
   10. Display a message using new line and spacing MULTI tags. At the main
       command prompt, enter “quickset.” When prompted to enter the message, enter
       “[sc0]TM[nl0]MT[np][sc3]TM[nl2]MT .”
   11. Verify that the message is correctly displayed. The message consists of two
       alternating pages. The first page contains no spacing between characters or lines
       and contains the letters “TM” above the letters “MT.” The second page contains
       the same message, but with spaces of three pixels between characters and spaces
       of two pixels between lines. Examine the report file and verify that no errors are
       reported.
   12. Display a message using page timing MULTI tags. At the main command prompt,
       enter “quickset.” When prompted to enter the message, enter
       “[pt30o10]DOT[np][pt30o50]DMS.”
   13. Verify that the message is displayed correctly. The message consists of two
       alternating pages. The first page contains the message “DOT,” while the second
       page contains the message “DMS.” The first page should remain on for three



                                           79
                                                     Progress Report No.5: January 2005 – March 2005


        seconds and then off for one second before transitioning to the second page. The
        second page should remain on for three seconds and then off for five seconds
        before transitioning back to the first message. Examine the report file and verify
        that no errors are reported (Successful Results of Steps 3, 5, 7, 9, 11, and 13
        Satisfy Requirement 24.1 Set Messages with MULTI Tags).



           IV. Conclusion

   Many of the goals of the NTCIP testing project are now being realized. Nine manufacturers
have completed the DMS NTCIP qualification process. Through testing, a number of problems,
which could have led to incompatibilities in the field, have been identified and addressed. The
process is serving to help ensure that only manufacturers having a sufficient understanding of the
NTCIP engage in projects within Florida. Additionally, the process is serving to help ensure that
the products offered by these manufacturers are not only NTCIP compliant, but also compliant to
the specific requirements of Florida, helping to ensure that a sufficient degree of
interchangeability is attained between manufacturers. Though the test is not exhaustive and
certainly cannot identify all problems, the test does help ensure that the intended benefits of the
NTCIP are realized. Additionally, building on the lessons learned and knowledge base acquired
from the DMS testing process, efforts are being made to develop a similar program for ASCs.
The groundwork for the development of this program is being laid by the research of relevant
documents currently being conducted and the development of new testing tools. The NTCIP
requirements for ASCs are also currently being developed. Once complete, the draft
requirements developed by the working group can be sent to all affected agencies for comment
and revision. In parallel with this process, the ASC testing program will be under development.
Therefore, although a great deal of work must still be done, these efforts bring the project much
closer to the realization of the overall goals.
 Although a great deal of work must still be done, these efforts bring the project much closer to
the realization of the overall goals.




                                                80

								
To top