Research Papers Java Syntax Evaluator

Document Sample
Research Papers Java Syntax Evaluator Powered By Docstoc
					                                   Progress Report

Reporting Period: April 2004 – June 2004

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

              Communication Engineer -- James Langston

              Research Associate -- Mandar Ambre (graduated with M.S. in May)
                                    Michael Case
                                    Olivier Marietta-Tondin
                                    Jamie Meeks
                                    Khue Ngo, Lead Associate
                                    Francisco Ortiz (co-op from June to August)

              Technical Staff --    Christine Chen
                                    Brandon Mathews (left in May)
                                    Kayelyn Richarson (co-op in summer)
                                    Angela Ruffin


              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, July 2004.
                                                    Progress Report No.2: April 2004 – June 2004



1. PROGRESS
1.1 Milestones accomplished during this reporting period:

   April 12, 2004: completed the NTCIP Qualification Test for Adaptive Micro Systems
      Permanent Mount Dynamic Message Sign.

   May 25, 2004: Michael Case and Francisco Ortiz conducted lesson 2 of the Train the
     Evaluators program entitles The Pre-evaluation Process.

   June 9, 2004: Dr. Jim Simpson, Carl Morse, Bob Griner and Michael Case visited Peek‟s
       North Sarasota Plant.

   June 10, 2004: Khue Ngo-Quoc made a presentation titled ''Analytical Software Tool
      for Travel Time Studies Using GPS Technology'' at the Florida Section ITE
      meeting in Sarasota, FL

   June 23, 2004: Khue Ngo-Quoc presented a paper titled “An Alternative Approach to Travel
       Time Studies Using GPS Technology” at the 2004 International MultiConference in
       Computer Science & Computer Engineering in Las Vegas, NV


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, Advanced Transportation Controllers
       (ATC), and Dynamic Message Signs (DMS). His summer schedule of 2004 at
       TERL is from 8:30 AM to 12:00 PM, Monday through Thursday.

       Jim Zheng coordinates the research activities of the Monitoring of LED Traffic
       Signals area that includes the testing of LED signal heads, conventional signal
       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 engineer, four research
      associates, and two 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.


                                             1
                                                  Progress Report No.2: April 2004 – June 2004




    In the summer of 2004, 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 summer 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 (FDOT) work with 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.) Jamie Meeks, a graduate
          student and TERL Research Associate, has been working closely with and
          under the supervision of Dr. Zheng. A progress report by Jamie 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 3)

       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. James Langston, a communication engineer,



                                            2
                                               Progress Report No.2: April 2004 – June 2004


      Mandar Ambre, a graduate student and TERL Research Associate, and Angela
      Ruffin, a technical staff, work closely with Dr. Tung and Mr. Morgan in this
      area. Mandar has graduated with a M.S. degree in Electrical Engineering in
      May. A progress report by James, Mandar, and Angela is attached.
      (Attachment 2)

   d) Technology Transfer:
      Technical staff Brandon Mathews assisted Mr. Morgan and Dr. Tung as
      computer system administrator and in the area of technology transfer by
      maintaining and organizing the TERL website located at http://rite.eng.fsu.edu.
      Brandon left TERL in May. Technical staff/administrative assistant Christine
      Chen is working on a 10-minute video presentation of TERL under the
      supervision of Mr. Morgan and Dr. Tung.

   e) Advanced Transportation Traffic Signal Controller & Intersection Operation:
      Mandar Ambre, a graduate student and TERL research associate, assisted Mr.
      Morgan, Mr. Carl Morse and Dr. Tung in the area of advanced transportation
      traffic signal controllers. Mandar graduated in May.

   f) Quality Engineering:
      Quality control of manufactured traffic equipment is essential to ensuring that
      consistent, high quality products are purchased and installed in Florida's traffic
      intersections. This research focuses on the design of a requirement that all
      manufacturers must meet minimum quality standards before they will be
      allowed to sell traffic control equipment in the State of Florida. Francisco
      Ortiz, Olivier Marietta-Tondin, Michael Case, all graduate students and TERL
      Research Associates, and Kayelyn Richarson, an undergraduate and a technical
      staff, have been assisting Dr. Simpson, Mr. Morgan and Mr. Bob Griner in
      developing and implementing this program. In this summer, Francisco and
      Kayelyn left and are participating co-op programs. On June 21, Khue Ngo has
      joined the Quality Research Team. A progress report by the Quality Research
      Team is attached. (Attachment 5)

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)



                                         3
                                              Progress Report No.2: April 2004 – June 2004


      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 scipts)

2) Quality Research Engineering
     modification of the quality control minimum standards checklist (ongoing)
     identify manufacturers who have sold product within the past two years
       (ongoing)

3) Display Properties Testing for LED Traffic Signals and DMS
     design and build a 60-foot light tunnel (50%)
     purchase equipment for the PC based testing system (60%)
     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 (90%)

4) Vehicle Detection
     evaluation of various installed detector technologies (on going)
     re-evaluation of various detectors that were previously evaluated by the
       TERL (on going)
     update the current TERL developed vehicle detection standards
       (microwave, infrared, video, radar, etc.) which contain the minimum
       standards required to become approved and placed on the Approved
       Product List (APL). (on going)
     develop analytical software tools to perform statistical analysis on the
       travel-time data collected with GPS technology. (on going)

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

6) Technology Transfer
     maintain the TERL project internet web site located at
       http://rite.eng.fsu.edu, including the Approved Product List (APL).
     publish TERL quarterly newsletter, Technology Lab Notes, which
       highlights a specific activity each quarter.

7) Continue the solicitation, compiling, and sorting of specs / standards in all


                                       4
                                       Progress Report No.2: April 2004 – June 2004


major research areas (on going).




                                   5
                                                   Progress Report No.2: April 2004 – June 2004




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.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) Update the Florida Statewide LED Signal Usage Report.
3) Begin the implementation 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:
1) Continuously maintain the real-time testing system (mast arm and a detection system)
    already set up at the TERL and evaluate various detectors that are submitted for
    evaluation.
2) Investigate and/or survey detection manufacturers to see if there is a viable “on-site”
    inductive loop testing equipment that we could purchase to conduct on-site field tests
    at signalized intersections.
3) Produce a smart detector paper- what is available, what can they do,

2.5 Vehicle Traffic Controller Technology:
1) Maintain a status concerning the development of the national standards for the
    Advanced Transportation Controller (ATC).
2) Develop the knowledge required to produce training material and provide training
    and assistance concerning signalized intersection & traffic controller operation
    (isolated and coordinated intersection operation).
3) 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.




                                             6
                                                   Progress Report No.2: April 2004 – June 2004


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.
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.2: April 2004 – June 2004




Attachment 1
Schedule for TERL
  Summer 2004




        8
                                                                    Progress Report No.2: April 2004 – June 2004




                          TERL Schedule for Summer 2004 Semester

                               Monday           Tuesday           Wednesday        Thursday           Friday       Hrs

Michael Case                  9:00 - 12:00      1:00 - 5:00                        9:00 - 5:00                     15

Christine Chen                11:00 - 5:00     11:00 - 5:00                        7:00 - 3:00                     20

James Langston                7:00 - 3:30       7:00 - 3:30                                         12:00 - 4:30   21.5

Jamie Meeks                                     2:00 - 6:00       2:00 - 6:00     8:00 - 12:00                     12

Khue Ngo                                        9:00 - 1:00       9:00 - 1:00      9:00 - 3:00                     14

Angela Ruffin                 11:30-4:00                          11:30-4:00      9:00 - 12:00                     12

Olivier Tondin                    ???              ???               ???              ???               ???        ??


                 The meetings are scheduled for Thursdays at 9.15 am

       CONTACT INFORMATION:
        IPTEL                                410-6415                 EE Fax                     410-6479
        TERL (FSU Line)                      414-5255                 TERL Fax                   487-0011
        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
           Michael Case                      212-2276                 case@eng.fsu.edu
           Christine Chen                    668-3102                 yfs@devils.eng.fsu.edu
           James Langston                    421-8453                 langston@eng.fsu.edu
           Olivier Marietta-Tondin           321-6542                 marietta@eng.fsu.edu
           Jamie Meeks                       284-7820                 meeks@eng.fsu.edu
           Khue Ngo                          443-0669                 khuengo@eng.fsu.edu
           Francisco Ortiz                   878-6642                 fortiz@eng.fsu.edu
           Kayelyn Richarson                 ???-????                 richaka@eng.fsu.edu
           Angela Ruffin                     915-5765                 ruffian@eng.fsu.edu




                                                              9
                Progress Report No.2: April 2004 – June 2004




  Attachment 2
Research Progress Report

          By

    James Langston
     Angela Ruffin




           10
                                                      Progress Report No.2: April 2004 – June 2004




         National Transportation Communication for ITS Protocol
                                       James Langston
                                       Mandar Ambre
                                        Angela Ruffin


NT 2.1.4.2-1
Completed: 06/15/04


I. Introduction

    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).


                                               11
                                                       Progress Report No.2: April 2004 – June 2004


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. Recent work focused on the development of this test procedure and actually
carrying out this test on 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 were successfully carried out on devices
submitted by Skyline, Vultron, Dambach, Mark IV, 3M, Swarco, and Daktronics. 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
            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

Efforts toward these goals have consisted or reviewing a number of relevant standards and
documents, as well as the development of more suitable testing tools. Recent work in the NTCIP
area has focused on the development of testing tools, culminating in an initial version of the
TERL‟s ANTS program, as well as the testing of new DMS submittals. This recent work is
summarized below:

       Development of ANTS framework
       Development of ANTS core library
       Development of ANTS Host application
       Test of Adaptive Micro Systems DMS

III. ANTS Framework

       One of the primary needs for the ASC testing program was the acquisition of more
suitable testing tools. For DMS testing, the NTCIP Exerciser was used successfully.
However, the Exerciser had a number of drawbacks, including the following points:

       Limited scripting capability (no real support for modular programming, requires use of
        the “goto” statement)
       No support for STMP or SFMP
       No support for routable protocols (i.e. TCP/IP and UDP/IP)
       Limited file I/O capabilities
       Slow execution of large scripts (interpreted at a high level)

These issues limited the types of tests which could be carried out, limited the degree of testing
automation that could be achieved, and generally necessitated lengthy testing periods. As other
testing software became available, an effort was made to assess the available testing software
packages and acquire a new testing tool. As this process would cover the assessment of tool kits


                                                12
                                                          Progress Report No.2: April 2004 – June 2004


(used to build testing applications) as well as functional testing applications, the effort, as well as
the resulting testing tool, was simply identified as Alternative NTCIP Testing Software (ANTS).
       The ANTS assessment effort included the assessment of tools such as netsnmp,
SNMP++, Abderaware‟s SNMP.NET, and Intelligent Devices Inc. (IDI) NTCIP
AcitiveX control, as well as testing programs such as Trevilon‟s NTester, SimpleSoft‟s
SimpleTester, and IDI‟s DeviceTester. However, it was determined that, in order to
provide a suitable degree of flexibility for future expansion and evolution, ANTS should
be, instead of a program, a framework for developing NTCIP testing software.
       The platform for this framework was chosen to be Microsoft‟s .NET platform. The .NET
platform, a framework for integrating existing standards (e.g. COM, ActiveX, etc.) and providing
for more rapid development of distributed applications, was chosen primarily for its integration of
various existing programming languages. The .NET platform, in a manner similar to the Java
approach, allows high level code to be compiled into an intermediate language, which is then
interpreted by a runtime environment, allowing the same code to be executed on any
OS/architecture for which a runtime environment exists (currently most Windows platforms). A
primary difference between the .NET and Java approaches, however, is that, while the Java
approach provides a single high level programming language, the .NET framework provides a
Common Language Specification (CLS) to which existing languages can be modified to adhere.
This means that any .NET compatible language (including managed C++, C#, VB .NET, JScript
.NET, PerlNet, etc.) can be used to generate assemblies which can be utilized by any other .NET
compatible language. By utilizing this platform, ANTS applications can be designed to work
with libraries written in any .NET compatible language, effectively eliminating any restrictions
imposed by a given scripting language.
       The ANTS framework, therefore, simply consists of interfaces, enumerations, and
exceptions needed to implement the functionality required for NTCIP testing, along with
minimum requirements for applications. Figure 1 illustrates how an application could be
constructed using this framework. The application ties together all of the elements using a
scripting engine and exposes to the scripting engine the objects necessary for testing. The
application provides objects implementing interfaces defined in the ANTS Core library for user
interaction (IANTSStandarIO), report generation (IANTSReport), and communication with the
device under test (ISNMPConnection). The actual functionality for the software (e.g. classes to
control ASCs, automated tests, data acquisition, etc.) will be provided by libraries, which can be
loaded at run time, which make use of the standard interfaces provided by the application. In this
way, libraries can be ported to other applications utilizing this framework. This will allow the
application to evolve and expand gracefully over time.




                                                  13
                                                               Progress Report No.2: April 2004 – June 2004




                                                                Script Engine


                      Input
                                     User Interface              IANTSStandardIO
                     Output
                                                                                                     ANTSCore.dll

          User


                                                                                                     GlobalControl.dll
                       Input
                                     Report                IANTSReport
                      Output

                                                                                                     ASCControl.dll


                       Input

                      Output           NTCIPConnection
                                                                                                     Utilitities.dll
                                                                         ISNMPConnection
           DUT




                                                                                           Utility
                                 Test Scripts
                                                                                           Scripts




Figure 1 ANTS Framework



IV. ANTS Core Library

    As noted above, the ANTS framework is centered around interfaces, enumerations, and
exceptions which can be utilized by any class written in a .NET compatible language. These
building blocks are provided in a core library, ANTSCore.dll. In addition to these types, this
library provides base implementations for most of the interfaces. Each of these classes makes use
of virtual members. This allows classes to be derived from these classes and allows the derived
classes the freedom to override any members. This allows applications to be quickly constructed,
while allowing the flexibility for the classes to be customized to the application. This also serves
to allow the applications to evolve gracefully, by gradually replacing code. Although these base
implementations are provided, since the framework is built around interfaces, the base
implementations can be replaced entirely with other classes implementing the interfaces, without
changing the interaction with the libraries and scripts. Again, this removes the dependence of the
applications and libraries on the base implementations of the ANTS Core library.
    This core library is generated from four source files, written in C#. One file,
ANTSIO.cs, provides the interfaces for user interaction and report generation, along with


                                                      14
                                                    Progress Report No.2: April 2004 – June 2004


a class providing a base implementation of these interfaces. A second file,
ANTSComInterfaces.cs, provides the interfaces, enumerations, and exceptions needed for
NTCIP communication with a field device. Another file, ANTSCom.cs, provides base
implementations of many of these interfaces. A fourth file, ANTSScriptEngine.cs,
provides a base implementation of a script host utilizing the .NET platform‟s
JScript .NET scripting engine. These basic building blocks allow applications to be
quickly developed, and allow the primary focus of application development to center on
the user interface. Although a base class for communication may be provided in the
future with the library, at this time, the application must provide the implementation of
the ISNMPConnection interface. The code defining the interfaces is provided below.

       /// <summary>
       /// Interface representing a communication connection. This may represent a
connection
       /// utilizing one or more protocols.
       /// </summary>
       public interface IConnection
       {
               /// <summary>
               /// Method to send a PDU and wait for a response. The byte array provided
by request should be directly inserted into the payload
               /// of the PDU sent. The method should wait for the time specified by the
timeout property to expire or
               /// for the arrival of a response PDU before returning. If a respons PDU
is not recieved, this method
               /// should return a null value;
               /// </summary>
               /// <param name="request"></param>
        byte[] Send(byte[] request);

               /// <summary>
               /// Mehod to wait for a PDU to arrive. The method should wait for a PDU
to arrive or for the time specified
               /// by the timeout property before returning. If a PDU is not recieved,
this method should return a null value.
               /// </summary>
               byte[] Receive();

                 /// <summary>
                 /// Property exposing the last PDU successfully sent.
                 /// If no PDUs have been sent, this property should return a null value.
                 /// </summary>
                 byte[] LastSentPDU { get; }

               /// <summary>
               /// Propery exposing the last PDU recieved.    If no PDUs have been
received, this property should
               /// return a null value.
               /// </summary>
               byte[] LastReceivedPDU { get; }

                 /// <summary>
                 /// Method for establishing a connection.
                 /// </summary>
                 void Connect();

                 /// <summary>
                 /// Method for removing a connection.
                 /// </summary>
                 void Disconnect();

                 /// <summary>
                 /// Propery indicating whether or a connection is established (ready to
send packets).




                                             15
                                                      Progress Report No.2: April 2004 – June 2004


                 /// </summary>
                 bool Connected { get; }

               /// <summary>
               /// Property indicating the amount of time to wait for a PDU to be
received with a Send() or Receive() method.
               /// </summary>
               int Timeout {get; set;}

               /// <summary>
               /// Property used to specify an underlying connection for the given
connection. If no underlying
               /// connection is used (i.e. the current connection implements all
protocols through the physical
               /// layer), this property should return a null value.
               /// </summary>
               IConnection Connection { get; set; }
       }


        public interface ISNMPConnection : IConnection
        {
                /// <summary>
                /// Method for sending a structured SNMP request. The returned
                /// SNMPResponse object should reflect the received SNMP packet.       If
                /// no response is received, a null value should be returned.
                /// </summary>
                ISNMPPDU Send(ISNMPPDU request);

                 /// <summary>
                 /// Property indicating whether request IDs are to be automatically
assigned
                 /// to PDUs by the object implementing the ISNMPConnection interface.
                 /// A value of true indicates that request IDs are to be automatically
assigned.
                 /// A value of false indicates that the request ID specified by the
RequestID
                 /// property of the object implementing the ISNMPPDU interface should be
used.
                 /// </summary>
                 bool AutoReqID { get; set;}


        }   //   End INTCIPConnection interface definition.


        /// <summary>
        /// Interface to provide access to elements of an SNMP PDU.
        /// </summary>
        public interface ISNMPPDU
        {
                /// <summary>
                /// The SNMP message type.
                /// </summary>
                SNMPMessageType MessageType { get; }

                 ///   <summary>
                 ///   The request ID.
                 ///   </summary>
                 int   RequestID { get; }

                 /// <summary>
                 /// The error status for the PDU.
                 /// </summary>
                 byte ErrorStatus { get; }

                 ///   <summary>
                 ///   The error index for the PDU.
                 ///   </summary>
                 int   ErrorIndex { get; }




                                               16
                                                     Progress Report No.2: April 2004 – June 2004


                /// <summary>
                /// PDU community name.
                /// </summary>
                string CommunityName { get; }

                /// <summary>
                /// The variable binding list for the PDU.
                /// </summary>
                IVarBinding[] VarBindingList { get; }
       }


       /// <summary>
       /// Interface to provide access to an SNMP variable OID, Syntax, and Value.
       /// </summary>
       public interface IVarBinding
       {
               /// <summary>
               /// The object's OID (e.g. the object ID 1.3.256.4.3 would be returned
               /// as {1, 3, 256, 4, 3}.
               /// </summary>
               long[] OID { get; }

       /// <summary>
       /// The ASN1 Type of the object.
       /// </summary>
              byte Syntax { get; }

                /// <summary>
                /// The value for the object as a byte array.
                /// </summary>
                byte[] Value { get; }

       }   //   End IVarBinding braces.


/// <summary>
        /// This interface contains methods used to provide the user with information
        /// and obtain input from the user.
    /// </summary>
        public interface IANTSStandardIO
        {
                /// <summary>
                /// Provides the user with the information provided in text (e.g.
                /// writes text to the console for a console based application).
                /// </summary>
                /// <param name="text"></param>

                void CWrite(string text);

                ///   <summary>
                ///   Prompts the user with the information provided in text and
                ///   returns the user's input as a string.
                ///   </summary>
                ///   <param name="text"></param>
                ///   <returns></returns>

                string CInput(string text);
       }

       /// <summary>
       /// This interface is used to provide a central system for
       /// reporting information. This interface contains methods
       /// for opening and closing files, as well as reading and writing
       /// from files.
       /// </summary>
       public interface IANTSReport
       {

                /// <summary>
                /// Opens a file with file name (including path) given by filename.



                                              17
                                                   Progress Report No.2: April 2004 – June 2004


              ///   The mode for the file is given by mode with the following options:
              ///     "r" - read only
              ///     "a" - write only (append to existing file if the file exists)
              ///     "o" - write only (overwrite existing file if the file exists)
              ///   This method should return a positive integer to be associated with
              ///   the opened file in future calls to FWrite(), ReadLine(), and FClose().
              ///   The identifer returned should not be 0, as this is reserved for
              ///   standard output to the user or input from the user. If an error was
encountered
              ///   opening the file, a negative value will be returned.
              ///   </summary>
              ///   <param name="filename"></param>
              ///   <param name="mode"></param>
              ///   <returns></returns>
              int   FOpen(string filename, string mode);


              /// <summary>
              /// Closes the file with file identifier fid.
              /// </summary>
              /// <param name="fid"></param>
              void FClose(int fid);

              /// <summary>
              /// Writes the information provided in text to the destination
              /// specified by fid. The variable fid should be an integer type
              /// corresponding to a valid file identifier associated with a file
              /// opened for writing (mode should be "a" or "o"). If fid is 0,
              /// the information in text should be provided to the user (e.g.
              /// written to the console for a console based application).
              /// </summary>
              /// <param name="fid"></param>
              /// <param name="text"></param>
              void FWrite(int fid, string text);


              /// <summary>
              /// Reads a single line of text from the file specified by fid.
              /// The variable fid should be an integer type corresponding to
              /// a valid file identifier associated with a file opened for
              /// reading (mode should be "r").
              /// </summary>
              /// <param name="fid"></param>
              /// <returns></returns>
              string FReadLine(int fid);

              /// <summary>
              /// Method used to report information contained in the string text
              /// to all subscribers. The parameter id should be a reference to the
              /// object calling the method.
              /// </summary>
              /// <param name="id"></param>
              /// <param name="text"></param>
              void Report(object id, string text);


              /// <summary>
              /// Method used to subsribe to reported information. The parameter
              /// reporter should be a reference to a reporting object. The target
              /// parameter should be a valid file identifier.
              /// </summary>
              /// <param name="id"></param>
              /// <param name="text"></param>
              void Subscribe(object reporter, int target);


              ///   <summary>
              ///   Method used to remove a report subscription. The reporter parameter
              ///   be a reference to a reporting object. The target parameter should be
              ///   a valid file identifier.
              ///   </summary>




                                            18
                                                    Progress Report No.2: April 2004 – June 2004


               /// <param name="reporter"></param>
               /// <param name="target"></param>
               void UnSubscribe(object reporter, int target);
       }   // End IANTSReport braces.



V. ANTS Host Application

       In order to provide an initial application making use of the ANTS framework, the
ANTS Host application was developed. This command line program provides
implementations for the necessary interfaces and allows the user to load JScript .NET
scripts as well as libraries written in any .NET compatible language. The program
implements the ISNMPConnection interface using Intelligent Devices‟ NTCIP ActiveX
control. Thus, the program provides for communication using proven, third party
software. However, neither the application providing this interface nor the libraries and
scripts making use of this interface depend on the Intelligent Devices software, as this
interface could be implemented using almost any third party NTCIP or SNMP tool kit.
       The program, shown in Figure 2, starts up as a “blank” application, with no
libraries or scripts loaded. The program simply initializes the scripting engine, exposes
implementations of the three interfaces to be provided by the application, and provides
the user with a configuration command prompt from which to configure the scripting
engine. From this command prompt, the user can reference libraries, add import
statements, load scripts, and compile and start the scripting engine. (The application also
provides the capability for the user to run configuration scripts so that this process can be
automated.) Therefore, the user can fully customize the application to his/her needs.
Therefore, the program can be configured for testing DMS, CCTV, ASC, or any other
device simply by loading in an appropriate library. Once the scripting engine is started,
any global code is executed. This allows the user to immediately start execution of a
script or invoke a command shell from which scripts can be dynamically launched.
Again, the user has full control over every aspect, including the command shell that is
actually loaded (a simple command shell providing access to all loaded classes and
libraries can be written in JScript .NET in 10 to 15 lines of code making uses of JScript‟s
eval() function). In order to make the application more user friendly, however, a default
start up script has been provided, along with a default command shell.




                                             19
                                                     Progress Report No.2: April 2004 – June 2004




Figure 2 ANTS Host Application


       While a great deal of work is needed to transform this application into a primary
testing tool, the application does represent a fully functional program which can be used
for NTCIP testing. As a test of the application, an example DMS control class was
written and successfully used to post messages on a DMS. Future work with ANTS will
concentrate on the development of libraries to be used with the host applications, as well
as the development of a GUI-based application tailored for ASC testing.


VI. Test of Adaptive Micro Systems Dynamic Message Sign

       In addition to the work done in the development of testing software, an actual test
on an Adaptive Micro Systems DMS was carried out. A software upgrade was required
to address some issues, but, 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.


                                              20
     Progress Report No.2: April 2004 – June 2004




21
                                                              Progress Report No.2: April 2004 – June 2004



        NTCIP Qualification Test Report for Adaptive Micro Systems
               Permanent Mount Dynamic Message Sign

NT 3.2.1.1.8.2-1
Initiated: 02/05/04
Completed: 04/12/04


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
         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/           objectcheckAMS.txt        All of the required objects are supported by
Support               06 Feb 04                                   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



                                                      22
                                                             Progress Report No.2: April 2004 – June 2004




    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.

         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/         centrallog01AMS.txt       All of the required global configuration
Configuration          12 Apr 04       centrallog01bAMS.txt      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.




                                                     23
                                                            Progress Report No.2: April 2004 – June 2004



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.



Requirement              Status/           Related Files              Comments
                         Date
2.1 Obtain Time          Passed/           centrallog02AMS.txt        The global time management
Information              13 Feb 04                                    objects correctly responded to
                                                                      SNMP “get” requests.
2.2 Set Time             Passed/           centrallog02AMS.txt        Each of the global time management
Parameters               13 Feb 04                                    objects was set properly.


Example Test Procedure

Required Macros
    DMScentral.mac

Required Input Files
None

    1.   Run the DMScentral.mac macro. interpret
    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.



                                                   24
                                                             Progress Report No.2: April 2004 – June 2004


                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
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/           centrallog03AMS.txt       The maximum event log size and
Log Information        29 Mar 04         retest03.txt              maximum event classes supported by the
                                                                   device, 800 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



                                                    25
                                                            Progress Report No.2: April 2004 – June 2004


                                                                 supported by the device, „50‟, is in
                                                                 accordance with the FDOT minimum
                                                                 requirement of „50‟.
3.2 Set Up Classes     Passed/           retest03.txt            Classes were properly configured.
                       2 Apr 04
3.3 Configure          Passed/           retest03.txt            Events were properly configured.
Events                 2 Apr 04
3.4 Obtain Log         Passed/           retest03.txt            The information for logged events was
Information            2 Apr 04                                  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/           retest03.txt            Classes were properly cleared.
                       2 Apr 04



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


                                                    26
                                                         Progress Report No.2: April 2004 – June 2004


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



                                                 27
                                                          Progress Report No.2: April 2004 – June 2004


    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:
    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.”



                                                 28
                                                             Progress Report No.2: April 2004 – June 2004


    34.   Repeat steps 17 through 19.
         (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
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/          centrallog04AMS.txt      All global security objects properly
Security              16 Feb 04                                 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/          centrallog04AMS.txt      The administrator community name was
Administrator         16 Feb 04                                 modified, and only the new administrator
Community Name                                                  community name was given access to the
                                                                security node.
4.3 Set User          Passed           centrallog04AMS.txt      A user community name was added and
Access                03/08/04         ExLog04AMS.log           was recognized by the device with the
                                                                appropriate privileges. The user
                                                                community name access mask (index 1)
                                                                was set to 0xFF 0xFF 0xFF 0xFF. The
                                                                associated community name (“public”) was
                                                                subsequently used to set the


                                                    29
                                                            Progress Report No.2: April 2004 – June 2004


                                                               dmsMessageStatus.3.1 object to a value of
                                                               7 to validate a message.




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
          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.



                                                    30
                                                           Progress Report No.2: April 2004 – June 2004


    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.
    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/        centrallog05AMS.txt     The information provided by the
Configuration            23 Feb 04                              dmsSignType.0 and dmsBeaconType.0
Information                                                     objects, „full matrix‟ and „no beacons‟
                                                                respectively, was correct for the device
                                                                and in accordance with FDOT
                                                                specifications.




                                                   31
                                                              Progress Report No.2: April 2004 – June 2004


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 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/         centrallog06AMS.txt     The information provided by the
Appearance                23 Feb 04                               dmsSignTechnology.0 object, LED, was
Information                                                       correct for the device and in accordance
                                                                  with FDOT specifications.




Example Test Procedure

Required Macros
    DMScentral.mac


Required Input Files



                                                     32
                                                             Progress Report No.2: April 2004 – June 2004


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).




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/        centrallog07AMS.txt         The value of the numFonts.0 object,
Information               29 Mar 04      centrallog07bAMS.txt        '4', is in accordance with the FDOT
                                         retest07.txt                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/        centrallog07AMS.txt         The new font characters were
                          26 Feb 04      centrallog07bAMS.txt        downloaded to the device and properly
                                                                     displayed.




                                                    33
                                                              Progress Report No.2: April 2004 – June 2004




Example Test Procedure

Required Macros
DMScentral.mac

Required Input Files
None

    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.




Requirement               Status/         Related Files            Comments
                          Date
8.1 Obtain VMS Sign       Passed/         centrallog08AMS.txt      The sign height and width, „7‟ and „15‟
Configuration             25 Feb 04                                pixels, respectively, and is correct for the



                                                     34
                                                               Progress Report No.2: April 2004 – June 2004


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.2 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.




Requirement                Status/         Related Files             Comments
                           Date
9.1 Obtain MULTI           Passed/         centrallog09AMS.txt       The information about MULTI default
Defaults Information       25 Feb 04                                 parameters was correctly reported by the



                                                      35
                                                             Progress Report No.2: April 2004 – June 2004


                                                                   device.
9.2 Set MULTI              Passed/        centrallog09AMS.txt      Instead of using Font 2 and
Defaults                   25 Feb 04                               “DOT[np]DMS”(as described by the
                                                                   Qualification Test Report), Font 4 and
                                                                   “GOP[np]POG” were used, respectively.
                                                                   All of the MULTI defaults were able to
                                                                   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.
    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,”



                                                     36
                                                              Progress Report No.2: April 2004 – June 2004


        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).




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.



                                                     37
                                                             Progress Report No.2: April 2004 – June 2004


        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.
        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/         centrallog10AMS.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/         centrallog10AMS.txt        Valid messages were set and all
                         3/10/2004                                  related parameters were properly set as
                                                                    well.
10.3 Obtain              Passed/         centrallog10AMS.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/         centrallog10AMS.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/         centrallog10AMS.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                                               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



                                                    38
                                                        Progress Report No.2: April 2004 – June 2004


    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, 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
    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


                                                39
                                                              Progress Report No.2: April 2004 – June 2004


        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 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          centrallog11AMS.txt         The device indicates central control at
Mode Information          03/08/04                                    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     Not Tested                                  See comment for Requirement 11.1.
                                                                      Since the device cannot be changed to
                                                                      local control, there is never a need to
                                                                      switch control to central override
                                                                      mode. This was not tested.
11.3 Software Reset       Passed          centrallog12AMS.txt         The device was successfully reset
                          02/18/04                                    from central, and the default software


                                                     40
                                                           Progress Report No.2: April 2004 – June 2004


                                                                  reset message was displayed.
11.4 Activate Message    Passed/        centrallog11AMS.txt       Valid message was activated and
                         27 Feb 04                                properly displayed.
11.5 Obtain Message      Passed/        centrallog11AMS.txt       The dmsMessageTimeRemaining.0
Timing Information       27 Feb 04                                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/        centrallog11AMS.txt       The message timer was modified to
Timing                   27 Feb 04                                change the duration of an activated
                                                                  message and the new time was
                                                                  implemented by the device.
11.7 Obtain Message      Passed         centrallog11bAMS.txt      A message was displayed and the
Source Information       03/08/04                                 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/        centrallog11AMS.txt       Message with an invalid CRC was not
with Invalid CRC         27 Feb 04                                activated.
11.9 Activate Message    Passed/        centrallog11AMS.txt       Message activation with an activation
with Low Priority        1 Mar 04                                 priority lower than the run time
                                                                  priority of the existing message was
                                                                  not carried out by the device.



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



                                                   41
                                                          Progress Report No.2: April 2004 – June 2004


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



                                                  42
                                                              Progress Report No.2: April 2004 – June 2004


    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
        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          centrallog12AMS.txt      See comments for requirement 12.2. The
Messages Information      02/18/04                                 device correctly reported the default
                          (Tested by                               message settings.
                          James
                          Langston)
12.2 Set Default          Passed          centrallog12AMS.txt      Set messages in changeable memory (1-
Messages                  02/18/04                                 6). Set the default messages to point to
                          (Tested by                               these six messages. Induced each of
                          James                                    special conditions (power loss, short
                          Langston)                                power loss recovery, long power loss
                                                                   recovery, software reset, communications
                                                                   loss, and message expiration). In each


                                                     43
                                                         Progress Report No.2: April 2004 – June 2004


                                                             case, the correct default message was
                                                             displayed by the sign. The only exception
                                                             to this was power loss, for which the sign
                                                             was blanked.



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


                                                 44
                                                              Progress Report No.2: April 2004 – June 2004


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


                                                      45
                                                             Progress Report No.2: April 2004 – June 2004



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

    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).




                                                     46
                                                            Progress Report No.2: April 2004 – June 2004




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.




Requirement              Status/         Related Files           Comments
                         Date
14.1 Obtain MULTI        Passed          centrallog14AMS.txt     The device correctly reported a MULTI
Error Information        03/08/04                                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.



                                                    47
                                                              Progress Report No.2: April 2004 – June 2004


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

Requirements

        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/          centrallog15AMS.txt       All Illumination/Brightness Control
Control Information        3 Mar 04                                   objects correctly responded to SNMP
                                                                      “get” requests and provided the correct
                                                                      information.
15.2 Manual Control        Passed/          centrallog15AMS.txt       The sign‟s brightness was controlled
                           3 Mar 04                                   manually and the information reported
                                                                      by the device correctly indicated the
                                                                      brightness of the device.
15.3 Photocell Control     Passed/          centrallog15AMS.txt       The sign‟s brightness was controlled
                           3 Mar 04                                   using the photocell and the
                                                                      information reported by the device
                                                                      correctly indicated the brightness of
                                                                      the device.
15.4 Photocell             Not Tested
Algorithm
Configuration



Example Test Procedure

Required Macros
    DMS Central.mac

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).




                                                     48
                                                             Progress Report No.2: April 2004 – June 2004


    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

        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          centrallog16AMS.txt        The device reports the field
Field Information         2 Apr 04        centrallog16bAMS.txt       information for all fields which are or
                                          retest16AMS.txt            previously have been displayed. This
                                                                     is not correct.
                                                                     After a software upgrade, the device
                                                                     correctly reported the information
                                                                     associated with status fields.
16.2 Obtain Watchdog      Passed/         centrallog16AMS.txt        The watchdogFailureCount.0 object
Failure Counts            4 Mar 04                                   correctly reported the number of
Information                                                          watchdog failures.
16.3 Obtain Cabinet       Passed/         centrallog16AMS.txt        The dmsStatDoorOpen.0 object
Doors Status              4 Mar 04                                   correctly reported the status of the
Information                                                          cabinet doors.


                                                    49
                                                             Progress Report No.2: April 2004 – June 2004




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 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        Passed/         centrallog17AMS.txt        The device incorrectly reports a pixel
Error Information         2 Apr 04        centrallog17bAMS.txt       error in the short error status even
                                          retest17.txt               when the pixel failure table is cleared.
                                                                     After receiving a software upgrade,
                                                                     errors with the device were correctly
                                                                     reported.



                                                     50
                                                              Progress Report No.2: April 2004 – June 2004




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.
    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/         centrallog18AMS.txt         Information about failed pixels was



                                                     51
                                                            Progress Report No.2: April 2004 – June 2004


Error Information        3 Mar 04                                  correctly reported.
18.2 Activate Pixel      Passed/         centrallog18AMS.txt       Pixel test was activated using
Test                     3 Mar 04                                  pixelTestActivation.0 object
18.3 Clear Pixel         Passed/         centrallog18AMS.txt       Pixel failure table was cleared using
Failure Table            3 Mar 04                                  the pixelTestActivation.0 object.


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.

         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



                                                   52
                                                                   Progress Report No.2: April 2004 – June 2004




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




                                                         53
                                                              Progress Report No.2: April 2004 – June 2004


Requirement               Status/          Related Files            Comments
                          Date
20.1 Activate Fan Test    Passed/          centrallog20AMS.txt      The fan test was activated using
                          4 Mar 04                                  fanTestActivation.0 object.
20.2 Obtain Fan           Passed/          centrallog20AMS.txt      Information about fan failures was
Failure Information       4 Mar 04                                  correctly reported.


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.



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         Passed/          centrallog21AMS.txt      Sign voltage, line voltage, and power
Status Information        4 Mar 04                                  source type were properly reported.



Example Test Procedure




                                                      54
                                                             Progress Report No.2: April 2004 – June 2004


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.

         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          centrallog22AMS.txt      The device reported temperature
Temperature               03/08/04                                 information, but the information was
Information                                                        incorrect. Additionally, these values
                                                                   were not the values inserted into
                                                                   messages making use of the temperature
                                                                   field MULTI tag.



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




                                                     55
                                                                    Progress Report No.2: April 2004 – June 2004


         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. 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.




Requirement                 Status/           Related Files                  Comments
                            Date
23.1 Obtain Maximum         Passed/           centrallog23AMS.txt            The device correctly responded to
Poll Time Parameter         9 Apr 04                                         “get” requests for the
Information                                                                  fdotDmsMaxPollTime.0 and
                                                                             fdotDmsErrorGenerationToggle.0


                                                          56
                                                           Progress Report No.2: April 2004 – June 2004


                                                                  objects.
23.2 Set Maximum         Passed/        centrallog23AMS.txt       A maximum poll time for error
Poll Time Parameters     9 Apr 04                                 generation disabling was set. The error
                                                                  generation was disabled when the time
                                                                  limit was exceeded.
23.3 Obtain Pixel        Passed/        centrallog18AMS.txt       The device appropriately responded to
Failure Threshold        3 Mar 04                                 “get” requests for the
Information                                                       fdotMaxNumPixelFailure.0 object.
23.4 Set Pixel Failure   Passed/        centrallog18AMS.txt       The pixel failure threshold was able to
Threshold                3 Mar 04                                 be set. The sign was blanked and the
                                                                  correct information, pixel failure, was
                                                                  reported when this threshold was
                                                                  exceeded.
23.5 FDOT Specific       Passed/        centrallog18AMS.txt       The fdotMsgSourceModeExstention.0
Conditions               3 Mar 04                                 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/        centrallog23AMS.txt       The fdotLog90Full.0 object correctly
                         9 Apr 04                                 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 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



                                                   57
                                                          Progress Report No.2: April 2004 – June 2004


      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).
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



                                                  58
                                                           Progress Report No.2: April 2004 – June 2004


      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.
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 “pixeltest.” 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).




                                                   59
                                                               Progress Report No.2: April 2004 – June 2004


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          centrallog24AMS.txt                 Messages making use of field
with MULTI Tags            03/01/04        centrallog24bAMS.txt                MULTI tags, flashing text
                                                                               MULTI tags, page and line
                                                                               justification tags, character
                                                                               spacing tags, and page timing
                                                                               tags were successfully set and
                                                                               displayed.



Example Test Procedure


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.”




                                                       60
                                                         Progress Report No.2: April 2004 – June 2004


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 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).




                                                 61
                                                  Progress Report No.2: April 2004 – June 2004




VI. Conclusion

    Many of the goals of the NTCIP testing project are now being realized. Eight
manufacturers have completed the DMS NTCIP qualification process and another
manufacturer is currently involved in the process. Through the test, 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 to 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 ANTS framework, core library, and initial host application represent
significant progress toward this goal. Functionality regarding device control, automated
tests, and data acquisition capabilities for closed loop testing may all be added in the
future through libraries. 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.




                                           62
                Progress Report No.2: April 2004 – June 2004




  Attachment 3
Research Progress Report

          by

       Khue Ngo




           63
                                                          Progress Report No.2: April 2004 – June 2004


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

          Research Progress Report – 2nd Quarter 2004
   Vehicle and Pedestrian Detection System + GPS Travel Time


Area Manager: Dr. Leonard J. Tung
Research Associate: Khue Q Ngo
Date: June 2004

    1. GPS-based Travel Time Study project

During this quarter, I spent most of the time finishing up on “GPS based travel time study on
Florida roadway” project with the major part is of analytical software tools. I tried some different
alternative ways of presenting the travel time data in the effort of helping transportation engineers
get better understanding on roadway conditions. Some 3-D representations have been exploired,
other alternative 2-D representation have been conducted.

    2. ITS Vehicle Detection Systems’ Standard Specifications and Requirements

I had a discussion with ITS section officers in the effort of exploring the differences in standard
specifications and requirements of Vehicle Detection Systems, reviewing and comparing the
standard specs and requirements from both parties. Worked closely with Arun Krishnamurthy on
finalizing the two sets of document.

    3. Presentations and Conference papers

Two technical papers has been submitted and accepted at the following international multi-
conferences in computer science and information technology

A. The 2004 International MultiConference in Computer Science & Computer Engineering, Las
   Vegas, NV June 21 – 24, 2004

Conference website: http://www.world-academy-of-science.org

Submitted paper title:

“An Alternative Approach to Travel Time Studies Using GPS Technology”

Authors: Khue Ngo-Quoc, Bing. W. Kwan, Leonard J. Tung

See program at http://www.world-academy-of-science.org/IMCSE2004/ws/Program/cis23

Presentation date: June 23, 2004 2.40 PM – 3PM


The International MultiConference in Computer Science and Computer Engineering is a major annual
international research event. It assembles a spectrum of affiliated research conferences, workshops, and
symposiums into a coordinated research meeting held in a common place at a common time. This model



                                                  64
                                                             Progress Report No.2: April 2004 – June 2004


facilitates communication among researchers in different fields of computer science and computer
engineering.

The last Multiconference attracted over 1,650 computer science and Engineering researchers from 78
countries. It is anticipated that The 2004 Int'l Multiconference will attract about 2000 participants. The
2004 event is composed of 18 (planned) major conferences - attendees will have full access to all 18
conferences' sessions & tracks. Each event is the premier conference for presentation of advances in their
respective subjects. All conferences will be held simultaneously (same location and dates: June 21-24,
2004, Las Vegas, USA). Each conference will have its own proceedings. All conference proceedings/books
are considered for inclusion in major database indexes that are designed to provide easy access to the
current literature of the sciences (database examples: ISI Thomson Scientific, IEE INSPEC, DBLP, ...).

B. International Conference on Cybernetics and Information Technologies, Systems and
    Applications: CITSA 2004, July 21 - 25, 2004 in Orlando, Florida, USA

Conference website: http://www.infocybernetics.org/citsa2004/website/default.asp

Submitted paper title:

''Analytical Software Tool for Travel Time Studies Using GPS Technology''

Authors: Khue Ngo-Quoc, Bing. W. Kwan, Leonard J. Tung

Presentation date: Sunday July 25, 2004 9:30 AM – 12.00 PM

See program at http://www.infocybernetics.org/citsa2004/program/html/program.htm


The joint event of CITSA '04/ISAS ’04 is an International Multi-Conference being organized with the
purpose of providing researchers, practitioners, developers, consultants, and end-users of computerized,
Communications and/or Control systems and technologies, as well as their industrial and social
applications in the private and the public sectors, an opportunity to join in a common place sharing
experience and knowledge. It is intended to be a forum to expose and share current and future research
work and innovations in these areas, as well as in the relationships among them.

One of the primary objectives of CITSA '04/ISAS ’04 is to promote and encourage "interdisciplinary cross-
fertilization", "epistemic things" and the production of "technical objects". Its intellectual perspective
context is systemic thinking and practice, including the analogical thinking that characterizes the Systems
Approach.

The International Conference on Information Systems, Analysis and Synthesis (ISAS ’04) is an event that
has been held every year for the last 10 years intending to be a forum for Information Systems consultants,
practitioners, researchers, and users who have had the opportunity of interchanging ideas, research results
and innovations in the Information Systems field. The actual knowledge-based infrastructure support for
research papers presented at ISAS Conferences has been the analytical and synthetic thinking applied in
particular to the Information Systems area but strengthened by establishing relationships (in the form of
analogies, "epistemic things", "technical (synthetic) objects", idea cross/fertilization, hybrid systems and
the like) with other diverse areas.

C. Presentations: Florida Section ITE meeting Sarasota, FL June 9 – 11, 2004

Presentation title:

''Analytical Software Tool for Travel Time Studies Using GPS Technology''



                                                    65
                                                    Progress Report No.2: April 2004 – June 2004



D. Guest speaker at IMSA's 109th Annual Conference and 27th Annual School, July 16 - 23,
   2004 Denver, Colorado

Presentation title:
“Maintenance of Traffic at Intersection using Non-Intrusive Vehicle Detection Technologies
Guideline: Overview”

Due to some travel issues, the offer was turned down and on hold for the next year IMSA 2005‟
International Conference in St. Petersburg, FL

   4. Training

I attended three training sessions. One on NTCIP – ANTS software programming conducted by
James Langston – NTCIP team. Others are QA pre-evaluation and evaluation procedures,
conducted by Michael Case – Quality Research team.

   5. Other tasks

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




                                             66
                Progress Report No.2: April 2004 – June 2004




  Attachment 4
Research Progress Report

          by

 Quality Research Team




           67
                             Progress Report No.2: April 2004 – June 2004




Traffic Engineering Research Laboratory (TERL)


   Florida Department of Transportation (FDOT)



          Quality Assurance Department


                Progress Report


                         For
                  Period Covering:
            April 1 2004 – June 30 2004



              Quality Research Team:

                Dr. James Simpson
                  Francisco Ortiz
              Olivier Marietta-Tondin
               Kayelyn Richardson
                   Michael Case




                        68
                                                     Progress Report No.2: April 2004 – June 2004




1.0    Introduction
        This second quarter of the year has seen somewhat of a lull in new submittals.
This is being viewed as the calm before the storm as the rate of arrival of the submissions
is expected to rise dramatically with the March 1 deadline for submittals approaching. It
is expected that the rate could double or triple within the next quarter. Steps are being
taken to combat this rise with the recent addition of two new QRT members (see section
2) and the commencement of the train the evaluators program (see section 4.1)

2.0    Personnel
         Ms. Kayelyn Richardson one of QRT‟s newest members continues in her
training program and has completed two pre-evaluation on companies. However for the
summer Kaylene is on co-op working experience and is out for the summer.
       On June 21 Khue was assigned to the QA department for the balance of the summer.
Khue will undergo a period of internal training before being able to function fully in the
department.

3.0    Progress on Questionnaire v4.0
         The QRT has been working on improving and starting to finalize the next version of the
questionnaire. Along with this new questionnaire is also being developed a more clearly defined
set of rules in order to grade a set of answers. The current document is shown in appendix 1.

4.0    Database Update
        The QA Department database is up and running. The database was designed to cut
down on the time spent updating files and status reports after each pre-evaluation or
evaluation. Pre-evaluations are completed within the database and when saved it is
automatically emailed to Jeff and stored in its file. The architecture for the evaluation
procedure has not yet been fine-tuned, however evaluations can still be completed and
entered as a generic event. The main company log sheet is also automatically updated
according to the following priority.
    Pre-evaluation Pending
    Evaluation Pending
    Due for Re-evaluation
    Pre-evaluation Failed
    Evaluation Failed
    Qualified
    On Hold (Inactive)
The dates of each process and the dates of submission of documents are also secondary and
tertiary priorities respectively. Those who have worked with the database so far are asked to
submit comments and suggestions for its improvement to the department.

5.0    QRT Presentations at TERL
       QRT Personnel made three Presentations at the TERL, these are:

       1. Maintaining Agency Feedback – Kayelyn Richardson (see minutes of 4/15/04)



                                              69
                                                     Progress Report No.2: April 2004 – June 2004


       2. QA Information Database – Olivier Marietta (see minutes of 4/22/04)

       3. Photovoltaics in Traffic Engineering – Michael Case (see Minutes of 6/24/04)


        5.1      Train the Evaluators Program
        On Tuesday afternoon May 25, Michael and Francisco conducted lesson 2 of the Train
the Evaluators program entitles The Pre-evaluation Process. Present for the lesson were
Elizabeth, Jeff, Bob and Carl. A recap of lesson 1 (QA Overview) was followed by a short power
point presentation on the pre-evaluation process. Trainees then had some hands on experience in
pre-evaluating the Econolite submittal. Lesson 3 will be on the Database and lesson 4 on the
Evaluation process. Both lessons are expected to be given before the end of the summer session.


6.0    TERL QA Certification
        Initial enquiries have been made to the ASQ for the certification of the TERL as a
bonafide quality auditing organization. It would be the process of auditing the auditors.
More will be written on this as it develops. Plans are also underway for each QRT
member to be certified as a Certified Quality Auditor (CQA). This process involves
sitting qualifying exams, which is given in December of each year. The first students
from the department plan on sitting this exam in December 2004.

7.0    QA Evaluation Update
       To date 45 Vendors/Manufacturers have submitted documents for qualification
            17 have qualified
            21 remain in the system in various queues and re-routings
            7 Remain inactive

8.0    On Site Audit (Peek)
        On Wednesday afternoon June 9, 2004 four TERL personnel (Jim Simpson, Carl Morse,
Bob Griner and Michael Case) visited Peek‟s North Sarasota Plant. Please see Appendix I for
detailed report

9.0    Concluding Remarks
         With the March 1, 2005 deadline for submission approaches many companies are
beginning to take our warning more seriously. In meetings with company‟s
representatives it is clear that this deadline is being taken seriously. Another point to note
is that there has been a significant improvement in the quality of submittals as well as the
quality systems of companies as a result of the quality evaluation program at TERL.




                                              70
                                                              Progress Report No.2: April 2004 – June 2004



10.0 Appendix 1

Management Responsibilities
Quality policy
- Describe your quality policy. Where is it documented?

What to look for: We want a documented statement within the quality manual that
explains the objectives for quality and its commitment to quality.

Importance: High

- Who is responsible for ensuring that the quality policy is communicated to all levels of the
organization? Where is it documented?

What to look for: The person responsible should have access to the highest level of
management i.e. a member of executive management. Check the organization chart that company
should of provided. An example of what to look for is:


                                                General
                                                Manager


                        Production              Quality                Marketing/Sales
                         Manager                Manager                  Manager

Note: This is only an example. Small companies may not have a full-time quality manager. It is
common for someone in production to also handle quality.

Importance: High

 - How do you ensure that the quality policy is understood at all levels of the organization? Can
you provide evidence that demonstrates this?

What to look for: We wish to see evidence (if any) that their quality assurance system is
fully implemented. This question should be used to give the company advice on how to
implement it.

Importance: Low

Responsibility and Authority
- Who has the authority to initiate action to prevent the occurrences of any nonconformities related to
product, process, and quality system?



                                                     71
                                                                  Progress Report No.2: April 2004 – June 2004



What to look for: Looking for documentation that states this clearly.

- Who has the responsibility of identifying and recording problems related to the to product, process, and
quality system?

What to look for: Looking for documentation that states this clearly.

Importance: Medium

- Who has the responsibility for verifying the implementation of solutions?

What to look for: Looking for documentation that states this clearly.

Importance: Medium

- Who has “stop work” authority until the deficiency or unsatisfactory condition has been corrected?

What to look for: Looking for documentation that states this clearly.

Importance: Medium


Management Review
- Describe the internal personnel responsible for performing a quality program reviews/audits. Where is it
documented?

What to look for: Looking for documentation that states this clearly. The person responsible should be a
member of executive management.

Importance: High

- How often are these reviews/audits performed? Where is it documented?

What to look for: Looking for documentation that states this clearly. Should be at least once a year.

Importance: High

- Please provide records of your last reviews/audits?

What to look for: Review the records to get an idea of the extensiveness of the review.
This question should be used to give the company advice.

Importance: Low

Design Control
Note: This section may not apply to all companies being evaluated. Some companies do not design new products
rather simply manufacture a product for someone else. Evaluator must determine whether or not to these questions are
relevant.

- Who is responsible for the planning each design and development activity? Where is it
documented?


                                                         72
                                                       Progress Report No.2: April 2004 – June 2004



What to look for: Looking for documentation that states this clearly.

Importance: High

- Describe the general procedure used for design and development of a product. How are design
inputs requirements related to the product identified and documented? How are design outputs
documented and reviewed? Describe the role quality management plays in product design
reviews. Provide copies of documents generated from such activities.

What to look for: Looking for documentation that shows that a clearly design and
development defined process is in place. This may be a little subjective therefore
importance level is medium. This question should be used to give the company advice.

Importance: Medium

Are formal documented reviews of the design results conducted? Who is in charge of planning
and conducting these reviews? Who is in charge of maintaining records of these reviews? Where
is it documented?

What to look for: Looking for documentation that states this clearly.

Importance: High

Who is responsible for design verification and validation activities? Where is it documented?

What to look for: Looking for documentation that states this clearly.

Importance: High

Who is authorized to identify the need for design changes? Where is it documented?

What to look for: Looking for documentation that states this clearly.

Importance: High

Who is authorized to review and approve design changes? How is approval indicated? Where is
it documented?

What to look for: Looking for documentation that states this clearly.

Importance: High

Purchasing
- How does the purchasing system work? Where is it documented? Should be addressed in video.
- Define “subcontractor”.

        Evaluation of subcontractors




                                               73
                                                         Progress Report No.2: April 2004 – June 2004


- Where is the type and extent of control exercised by your company over subcontractors defined?

What to look for:
Importance:

- What requirements are used to evaluate and select subcontractors? Are their any quality
standards requirements that a subcontractor must meet?

What to look for:
Importance:

- Do you have a “Vendor Rating System”? If so, please explain the system and show where it is
defined. In explaining be sure to address the following:

        - Are there different evaluation/selection criteria for different types of subcontractors?
- What are the qualifications of the auditor evaluating the subcontractor?
- How do subcontractors become disqualified?

What to look for:
Importance:

- Do you have an “Approved Supplier List”? If so, who is in charge of maintaining and updating
it? Please provide the “Approved Supplier List”.

What to look for:
Importance:

- Do you maintain quality records for each acceptable subcontractor? If so please provide some
example of them.

What to look for:
Importance:

Product Identification and Traceability


- Describe how a product identification and traceability maintained throughout production,
delivery, and installation? In explaining be sure to address the following:

- Are parts, lot, or batch numbers used? How are these number assigned?
- Provide examples (e.g. pictures, labels) of where the product I.D. and traceability information is
marked on the finished product.
- Where is all this documented?

What to look for: A company must have documented procedures identifying the product
throughout production, delivery, and installation. The company should also have documented
procedures for unique identification of individual product or batches.

Importance: High

Process Control


                                                 74
                                                       Progress Report No.2: April 2004 – June 2004




How are production processes that affect quality identified and planned? Who is responsible for
identifying and planning these processes? Where is it documented?

What to look for:
Importance:

Estimate the number of processes statistically monitored in your process.

What to look for:
Importance:

Which statistical process control techniques are used to monitor and verify processes capability
and stability? Provide examples of control charting if used.

What to look for:
Importance:

Has top management received training on statistical process control methodology and
applications? If so, what type of training?

What to look for:
Importance:

Does your company have an SPC specialist available? If so, please provide his contact
information?

What to look for:
Importance:

Inspection and Testing

A company must do the following:

- Have documented procedures for inspection and testing in order to verify that the product meets
  specific requirements.
- Ensure that incoming products are not used until they have been inspected or verified.
- Have and maintain records that show that the product has been inspected and tested.
- Records should show what test the product has passed and failed.
- Records should show who inspected and relased the product.

        Receiving Inspection and testing

- Describe your receiving inspection and testing procedure. In doing so please address the
  following:
- What statistical sampling technique is used (e.g. 100% testing, random testing, etc.)?
- How are damaged goods handled?
- What data is maintained to provided feedback to your purchasing procedures?
- Where are these procedures defined?



                                               75
                                                        Progress Report No.2: April 2004 – June 2004


What to look for:
Importance:

        In-Process Inspection and Testing

Who is authorized to perform in-process inspection and testing? Where is it documented?

What to look for:
Importance:

Where is it defined which products require in-process inspection and testing?

What to look for:
Importance:

Where is it defined what the required in-process inspection and tests should be?

What to look for:
Importance:

Final Inspection and Testing

Who is authorized to perform final inspection and testing? Where is it documented?

What to look for:
Importance:
Where is it defined what the required final inspection and tests should be?

What to look for:
Importance:

Describe what happens when a product fails final inspection. Where is it documented?

What to look for:
Importance:

Inspection and Test records

- How are inspection and testing results recorded? Provided example records that:
- Show whether the product has passed or failed inspection or testing.
- Identify the inspector that released the product.

Controlling Measuring and Test equipment


- Describe the procedures used for inspection and calibration of tools, gauges, and test equipment.
  In doing so please address the following:
- Who ensures that measuring and test equipment are calibrated and adjusted at predetermined
  intervals?
- How are uncalibrated or outdated items identified and/or stored in such a manner as to preclude
  their use pending calibration?


                                                76
                                                            Progress Report No.2: April 2004 – June 2004


- How are tools, gauges, and test equipment that require regular re-calibration recalled?
- Where are these procedures defined?

What to look for:

Importance: High

What certifications of calibration are on file? Please a copy of the last two certificates.

What to look for: Check to see if the dates in which the equipment was calibrated are consistent
with the predetermined intervals indicated in their procedure

Importance: High

Controlling Nonconforming Products


A company must do the following:
- Establish procedures preventing products that do not conform to requirements from unintended
  use.
- Provide for identification and segregation on nonconforming products.

- What formal company procedures are established for the segregation of discrepant material?

What to look for:
Importance:

- What formal company procedures are established for the identification and/or marking of discrepant
material?

What to look for:
Importance:

- How is reinspection of repaired and/or reworked products documented?

What to look for:
Importance:

Corrective and Preventative Action


- Describe the procedures in place for implementing corrective and preventative action. In doing
  so please address the following:

- What triggers corrective action?
- Who is responsible for investigating the causes of nonconformities and recording the results of
  the investigation? How do records indicate the nature of deficiencies? Please provide an
  example copy of these records?
- How do records indicate the positive corrective action taken? How does the system ensure
  prompt action to corrections needed? Please provide an example copy of these records?
- Who is responsible for determining and implementing the necessary steps to deal with problems
  requiring preventive action?


                                                   77
                                                      Progress Report No.2: April 2004 – June 2004


- How is the effectiveness of the preventative action measured?
- Where are all these procedures documented?
- Describe the procedure for handling customer complaints and reports of product
  nonconformities. Where is it documented?




                                              78
                                                      Progress Report No.2: April 2004 – June 2004



11.0 Appendix 2
On Site Audit (Peek)
Preamble
         Peek, a manufacturer of Traffic Controllers from north Sarasota Florida, submitted an
application to TERL for quality assurance qualification on August 7 2003. Peek passed the pre-
evaluation process three weeks later on August 26. However, since then there has been much re-
routing of information and documentation during the evaluation process that ensued as Peek‟s
quality system left much to be desired.
         On September 10 a quality evaluation was completed and some of the major concerns
with their submittal follows:
       Overall, Peek answered the majority of the questions adequately. However, certain
          responses lacked the evidence needed to substantiate that their quality system has been
          implemented fully and is adequate. There was therefore a lack of evidence that Peek had
          an adequate QA system in place. There was also no indication that there was upper level
          management support for their quality system and there was no quality assurance
          manager in the company

             o   No functioning organizational chart with reference to quality
             o   Peek lacked external quality certification
             o   No proof of in process or final inspection of products
             o   An absence of Statistical process control techniques
             o   No proof of Corrective action taken
             o   No certificate of calibration of tools and gauges provided
             o   Inadequate place for non-conforming materials

        Over the next 8 to 9 months there has been three submissions of materials and
information that has slowed the evaluation process. There were a number of discussions with
Peeks management including several emails and a teleconference. Peeks quality system was in
bad shape. Following mounting pressure from TERL a decision was taken by Peek‟s management
to make a re-submittal, discounting what had transpired before. At about the same time May/June
2004, TERL decided to send a team of Auditors to conduct an onsite audit of Peek‟s operation.
On Site Visit
        On Wednesday afternoon June 9, 2004 four TERL personnel (Jim Simpson, Carl Morse,
Bob Griner and Michael Case) visited Peek‟s North Sarasota Plant. These are some of their
findings:
Positive Impressions
        There were several positive impressions that were made during the visit. Overall there
was an improvement in their management‟s approach to quality and steps were being taken to
conform to TERL‟s requirements for quality.

        Peek‟s QA program now has full upper management support and backing, this was
         evident from the fact that the general manager himself conducted a significant part of
         the site visit.
        Peek now has a full time QA manager in the person of Jim Mohr who has had over 20
         years of manufacturing experience, several of which were at Peek.
        Peek submitted two folders of documentary evidence (forms, reports etc) of their QA
         system
        There was an area designated for non-conforming materials with each non-conformant
         being red tagged.



                                               79
                                                        Progress Report No.2: April 2004 – June 2004


           Company seemed to be in the process of implementing ISO 9000 procedures

Negative Impressions
           There were also several areas that needed improvement among these were:

          QA manager is not trained in statistical procedures, and hence SPC is not instituted at
           Peek.
          The reserved area for non-conforming materials is too close to the goods receival area
           and should be preferable caged with a lock and key
          A QA training program need to be implemented where more personnel can be trained and
           added to the QA department

    Peek‟s new submittal has entered the evaluation queue at TERL awaiting their second full
evaluation, and from the impressions of the site visit this will be a marked improvement over
their first submittal.
          This visit highlighted the fact that the QA system of evaluation at TERL is working.
Vendors and manufacturers are taking heed and putting in place systems and procedures to ensure
better quality in their organizations




                                                 80
                Progress Report No.2: April 2004 – June 2004




  Attachment 5
Research Progress Report

          by


     Jamie Meeks




           81
                                                           Progress Report No.2: April 2004 – June 2004



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

             Research Progress Report – 2nd Quarter 2004

                                LED Signal Research
Area Manager: Dr. Jim Zheng
Research Associate: Jamie Meeks
Date: June 30, 2004
Report ID: LED 2.2.4.2-01


             The LED department remains focused on the improvement of our testing procedures and
   facilities. Optical tables for the light testing tunnel have been delivered and set up in the tunnel
   building making it possible for signal testing to begin. Most of the testing procedures have been
   up dated to include computer controlled automated chromaticity and intensity testing through the
   SpectraWin software. The signal testing procedure is now only two steps from being completely
   automated. The first of these steps, creating a data acquisition system to automatically compile
   the test results into a report format, is currently underway. The second step, outfitting the
   goiniometer with computer controlled rotational stages, remains a future goal. The updated
   procedures are, however, far from complete. The alignment procedure is currently being reviewed
   and changed to use precise laser alignment rather than crude manual measurements. In the Real
   World Testing Procedures the final cycle times have not been determined. To make this decision,
   we plan to run experiments varying the cycle time to determine the most advantageous cycle for
   each color. Secondly, we will look at data collected from various intersections which give a
   realistic picture of the signals field cycle time. By comparing these two sets of data, appropriate
   cycle times will be determined. Most if not all of the unfinished portions of the up dated
   procedures will be completed in the next quarter with the initiation of testing in the tunnel
   facility.
             Along with the improvement of the testing procedures and facilities, the LED department
   has been preparing a brief presentation to be included in the TERL informative video. We feel it
   is vital that vendors and other interested parties understand a bit of the mechanics of the testing
   that we do at TERL as well as the motivating reasons which make this research so fundamentally
   important. It is our hope that this video will serve as a comprehensive illustration of the research
   preformed at TERL.

           Attachments:

           A)      LED 3.1.2.4-02 Primary Standard Intensity Measurement Procedures
           B)      LED 3.1.2.6-02 Primary Real World Intensity Measurement Procedures
           C)      LED 3.1.2.5-02 Secondary Standard Intensity Measurement Procedures
           D)      LED 3.1.2.5-02 Secondary Real World Intensity Measurement
                                    Procedures
           E)      LED 2.3.4.2-01 TERL Video Presentation LED Script
           F)      Work In Progress




                                                   82
                                                        Progress Report No.2: April 2004 – June 2004



Attachment A: LED 3.1.2.4-02 Primary Standard Intensity
                             Measurement Procedures
A) Warm Up and Testing Environment Preparation

   1) Power signal up and allow the signal to remain for a set amount of time (60 min. unless
      otherwise specified)

   2) Power on Photo Research and allow it to warm-up with signal.

   3) Record time in log book.

   4) Record the temperature and humidity of the test environment in log book.

   5) Ensure that the area behind the signal is dark (i.e. the wall behind the signal is black or
      has been covered by black material).



B) Alignment

**NOTE** This step is crucial and should never be omitted or assumed to be correct.

   1) Squaring the Goniometer:

           a. Measure the distance from the wall to both sides of the back of the Goniometer.
           b. Measure the distance from the wall to both sides of the side of the Goniometer.
           c. Using a level, set the angle measurement so that the vertical mobile portion of the
              Goniometer is perpendicular to the surface of the table when the angle reads zero.
           d. Using a level, set the angle measurement so that the horizontal mobile portion of
              the Goniometer is flush with the frame of the Goniometer when the angle reads
              zero.


   2) Setting the Photo Research:

           a. Measure the distance from the floor to the center of the signal (height).
           b. Match the height of the signal to the height of the sensor (measured from the
              floor to the center Photo Research lens).
           c. Measure the perpendicular distance from the wall to the center of the signal
              (vertical distance).
           d. Match the vertical distance of the signal to the vertical distance of the sensor
              (measured from the wall to the center of the Photo Research lens such that it is a
              perpendicular distance).
           e. Measure the perpendicular distance from the center of the signal to the center of
              the sensor. (Make sure that this distance is greater than 57 feet when using the
              Photo Research to perform the intensity tests on a 12” signal and greater than 38
              feet when using the Photo Research to perform the intensity tests on an 8”
              signal.)




                                                83
                                                   Progress Report No.2: April 2004 – June 2004




C) Intensity Measurements

   1) Intensity Testing with the Photo Research

          a. Connect the Photo Research to the computer (this step is only necessary if the
             Photo Research was not used immediately prior for chromaticity testing.)
          b. Set the first angle combination to be measured on the Goniometer.
          c. Open the Spectrawin software.
          d. Record time in log book.
          e. Record temperature and humidity of the testing environment in log book.
          f. Under the “Set Up” drop down menu, choose “Instrument Selection” (Ctrl+I). Be
             sure that the “Current Instrument: Model and Serial Number” boxes read PR-650
             and 60000903 respectively.
          g. If the “Current Instrument: Model and Serial Number” are not correct, in the
             “Instruments” box double click PR-650 so that the correct readings do appear in
             the “Current Instrument: Model and Serial Number” boxes.
          h. Click “OK”




          g.


                                                                                f.




                            h.

          i. Under the “Set Up” drop down menu, choose “Auto Modes” (Ctrl+U).
          j. In the “New Measurement” box choose “Overwrite Current Measurement”.
          k. To the right of the “New Measurement” box choose “Continuous
             Measurements” and input the number of sequential measurements you wish to
             perform (10 unless otherwise specified).
          l. In the box below the “New Measurement” box choose the following:
                   i. “Auto Save”
                  ii. “Use Macro Name”
                 iii. “File Type” => “.TXT”
                 iv. “Auto Save Name” => Horizontal Angle Direction (Left or Right) and
                      Degree (2.5, 7.5, 12.5….)being measured_Vertical Angle Direction (Up


                                            84
                                         Progress Report No.2: April 2004 – June 2004


         or Down) and Degree (2.5, 7.5, 12.5….) being measured (example:
         L17.5_D2.5)
      v. “Folder” => Choose Path which will lead to
         …\LED\3Testing\2Reports\XVender\1Data\XYear\1SpectraWin\XSerial
         Number (Note X will be specific numbers to that vender, year the test is
         preformed and serial number of the device being tested)




        Save generated SpectraWin
              text files here.




m. Click “OK”




                                    85
                                                       Progress Report No.2: April 2004 – June 2004




           j.                                                                     k.




          li.                                   lii.

          liv.                                 liii.

          lv.




           m.




           n. Look through the view finder to ensure that the Photo Research is in line with the
              signal being measured. (IMPORTANT: Do not touch the Photo Research or
              mount to ensure previously set alignment is undistributed)
           o. Under the “Measurements” drop down menu, choose measure (F2).
           p. Set next angle combination on the Goniometer.
           q. Repeat steps (d) through (p) until all 44 points have been measured as per ITE
              standards.

   2) Evaluating Data with Automated Data Acquisition System

***** In Progress*****




                                              86
                                                           Progress Report No.2: April 2004 – June 2004



Attachment B: LED 3.1.2.6-02 Primary Real World Intensity
                             Measurement Procedures
         In testing the light emitting diode (LED) traffic signals, ITE standards call for a minimum
of a thirty minute warm up period. While this procedure is functional in a laboratory setting, it is
not an accurate depiction of how the LED signal will perform in the field. In an intersection, the
signal will not be allowed a warm-up period. In fact, the signal will continually move from power
on to power off as the set of signals controls the flow of traffic at the intersection. Due to this fact,
a set of testing procedures was developed to more accurately capture the “Real World”
performance of the LED signal. The Real World testing procedure differs between red and green
signals and yellow signals due to their difference in performance in a working intersection. For
further explanation and justification of the chosen time schedule, see LED 7.2.X-0X “Real World
Test Timing Schedule”.


A) Warm Up and Testing Environment Preparation for Green, Yellow, and Red Signals

    1) Power on Photo Research and allow it to warm up for 15 minutes.

    2) Record time in log book.

    3) Record the temperature and humidity of the test environment in log book.

    4) Ensure that the area behind the signal is dark (i.e. the wall behind the signal is black or
       has been covered by black material).



B) Alignment for Green, Yellow, and Red Signals

**NOTE** This step is crucial and should never be omitted or assumed to be correct.

    3) Squaring the Goniometer:

             a. Measure the distance from the wall to both sides of the back of the Goniometer.
             b. Measure the distance from the wall to both sides of the side of the Goniometer.
             c. Using a level, set the angle measurement so that the vertical mobile portion of the
                Goniometer is perpendicular to the surface of the table when the angle reads zero.
             d. Using a level, set the angle measurement so that the horizontal mobile portion of
                the Goniometer is flush with the frame of the Goniometer when the angle reads
                zero.


    4) Setting the Photo Research:

             a. Measure the distance from the floor to the center of the signal (height).
             b. Match the height of the signal to the height of the sensor (measured from the
                floor to the center Photo Research lens).
             c. Measure the perpendicular distance from the wall to the center of the signal
                (vertical distance).



                                                   87
                                                      Progress Report No.2: April 2004 – June 2004


           d. Match the vertical distance of the signal to the vertical distance of the sensor
              (measured from the wall to the center of the Photo Research lens such that it is a
              perpendicular distance).
           e. Measure the perpendicular distance from the center of the signal to the center of
              the sensor. (Make sure that this distance is greater than 57 feet when using the
              Photo Research to perform the intensity tests on a 12” signal and greater than 38
              feet when using the Photo Research to perform the intensity tests on an 8”
              signal.)



C) Intensity Measurements for Green and Red Signals

   3) Intensity Testing with the Photo Research

           a. Connect the Photo Research to the computer (this step is only necessary if the
              Photo Research was not used immediately prior for chromaticity testing.)
           b. Set the first angle combination to be measured on the Goniometer.
           c. Open the Spectrawin software.
           d. Record time in log book.
           e. Record temperature and humidity of the testing environment in log book.
           f. Under the “Set Up” drop down menu, choose “Instrument Selection” (Ctrl+I). Be
              sure that the “Current Instrument: Model and Serial Number” boxes read PR-650
              and 60000903 respectively.
           g. If the “Current Instrument: Model and Serial Number” are not correct, in the
              “Instruments” box double click PR-650 so that the correct readings do appear in
              the “Current Instrument: Model and Serial Number” boxes.
           h. Click “OK”




                  g.


                                                                           f.




                                 h.




           i. Under the “Set Up” drop down menu, choose “Auto Modes” (Ctrl+U).
           j. In the “New Measurement” box choose “Overwrite Current Measurement”.
           k. To the right of the “New Measurement” box choose “Continuous
              Measurements” and input the number of sequential measurements you wish to
              perform (10 unless otherwise specified).



                                              88
                                               Progress Report No.2: April 2004 – June 2004


l.   In the box below the “New Measurement” box choose the following:
           i. “Auto Save”
          ii. “Use Macro Name”
         iii. “File Type” => “.TXT”
         iv. “Auto Save Name” => Horizontal Angle Direction (Left or Right) and
              Degree (2.5, 7.5, 12.5….)being measured_Vertical Angle Direction (Up
              or Down) and Degree (2.5, 7.5, 12.5….) being measured (example:
              L17.5_D2.5)
          v. “Folder” => Choose Path which will lead to
              …\LED\3Testing\2Reports\XVender\1Data\XYear\1SpectraWin\XSerial
              Number (Note X will be specific numbers to that vender, year the test is
              preformed and serial number of the device being tested)




              Save generated SpectraWin
                    text files here.




m. Click “OK”




                                          89
                                                        Progress Report No.2: April 2004 – June 2004




           j.                                                                      k.




           li.                                  lii.

          liv.                                  liii.

           lv.




            m.




           n. Look through the view finder to ensure that the Photo Research is in line with the
              signal being measured. (IMPORTANT: Do not touch the Photo Research or
              mount to ensure previously set alignment is undistributed)
           o. Power signal on and allow it to remain on for one minute before taking the
              measurements.
           p. Under the “Measurements” drop down menu, choose measure (F2).
           q. Set next angle combination on the Goniometer.
           r. Power Signal off and allow it to remain off for one minute while repeating steps
              (d) through (n).
           s. Continue repeating the above outlined process [steps (o) through (r)] until all 44
              points have been measured as per ITE standards.

   4) Evaluating Data with Automated Data Acquisition System
***** In Progress *****


D) Intensity Measurements for Yellow Signals

   1) Intensity Testing with the Photo Research

           a. Connect the Photo Research to the computer (this step is only necessary if the
              Photo Research was not used immediately prior for chromaticity testing.)
           b. Set the first angle combination to be measured on the Goniometer.
           c. Open the Spectrawin software.
           d. Record time in log book.
           e. Record temperature and humidity of the testing environment in log book.
           f. Under the “Set Up” drop down menu, choose “Instrument Selection” (Ctrl+I). Be
              sure that the “Current Instrument: Model and Serial Number” boxes read PR-650
              and 60000903 respectively.




                                               90
                                          Progress Report No.2: April 2004 – June 2004


g. If the “Current Instrument: Model and Serial Number” are not correct, in the
   “Instruments” box double click PR-650 so that the correct readings do appear in
   the “Current Instrument: Model and Serial Number” boxes.
h. Click “OK”




       g.



                                                               f.




                      h.




i. Under the “Set Up” drop down menu, choose “Auto Modes” (Ctrl+U).
j. In the “New Measurement” box choose “Add to Measurement Series”.
k. To the right of the “New Measurement” box choose “Continuous
   Measurements” and input the number of sequential measurements you wish to
   perform (10unless otherwise specified).
l. In the box below the “New Measurement” box choose the following:
         i. “Auto Save”
        ii. “Use Macro Name”
       iii. “File Type” => “.TXT”
       iv. “Auto Save Name” => Horizontal Angle Direction (Left or Right) and
            Degree (2.5, 7.5, 12.5….)being measured_Vertical Angle Direction (Up
            or Down) and Degree (2.5, 7.5, 12.5….) being measured (example:
            L17.5_D2.5)
        v. “Folder” => Choose Path which will lead to
            …\LED\3Testing\2Reports\XVender\1Data\XYear\1SpectraWin\XSerial
            Number (Note X will be specific numbers to that vender, year the test is
            preformed and serial number of the device being tested)




                                  91
                                                   Progress Report No.2: April 2004 – June 2004




              Save generated SpectraWin
                    text files here.




m. Click “OK”




                                                                       k.
        j.



       li.                                 lii.

       liv.                                liii.

       lv.




        m.




n. Look through the view finder to ensure that the Photo Research is in line with the
   signal being measured. (IMPORTANT: Do not touch the Photo Research or
   mount to ensure previously set alignment is undistributed)


                                          92
                                                      Progress Report No.2: April 2004 – June 2004


           o. Power signal on and allow it to remain on for ten seconds before taking the
              measurements.
           p. Under the “Measurements” drop down menu, choose measure (F2).
           q. Set next angle combination on the Goniometer.
           r. Power Signal off and allow it to remain off for one minute while repeating steps
              (d) through (n).
           s. Continue repeating the above outlined process [steps (o) through (r)] until all 44
              points have been measured as per ITE standards.

   2) Evaluating Data with Automated Data Acquisition System

***** In Progress *****




                                              93
                                                      Progress Report No.2: April 2004 – June 2004



Attachment C: LED 3.1.2.5-02                  Secondary Standard Intensity
                                            Measurement Procedures
A) Warm Up and Testing Environment Preparation

   6) Power signal up and allow the signal to sit for a set amount of time (60 min. unless
      otherwise specified)

   7) Power on the Newport Power Meter and allow it to warm-up with signal.

   8) Record time in log book.

   9) Record the temperature and humidity of the test environment in log book.

   10) Ensure that the test environment may be completely blacked-out. (i.e. the only source of
       light in the test environment should be the signal being tested)



B) Alignment

**NOTE** This step is crucial and should never be omitted or assumed to be correct.

   5) Squaring the Goniometer:

           a. Measure the distance from the wall to both sides of the back of the Goniometer.
           b. Measure the distance from the wall to both sides of the side of the Goniometer.
           c. Using a level, set the angle measurement so that the vertical mobile portion of the
              Goniometer is perpendicular to the surface of the table when the angle reads zero.
           d. Using a level, set the angle measurement so that the horizontal mobile portion of
              the Goniometer is flush with the frame of the Goniometer when the angle reads
              zero.


   6) Setting the photo sensor

           a. Measure the distance from the floor to the center of the signal (height).
           b. Match the height of the signal to the height of the sensor (measured from the
              floor to the center of the sensor).
           c. Measure the perpendicular distance from the wall to the center of the signal
              (vertical distance).
           d. Match the vertical distance of the signal to the vertical distance of the sensor
              (measured from the wall to the center of the sensor such that it is a perpendicular
              distance).
           e. Measure the perpendicular distance from the center of the signal to the center of
              the sensor. (Make sure that this distance is at least 25 feet.)




                                              94
                                                      Progress Report No.2: April 2004 – June 2004


C) Intensity Measurements

   5) Intensity Testing with the Newport Power Meter

           a. Set the new port power meter to calibration mode and turn the dial until the
              readout matches the determined calibration factor (Factor was calculated from
              the measured peak wavelength in the chromaticity test [procedure found LED
              3.1.2.3-02 Chromaticity Measurement Procedures] and was found on the chart
              LED 4.3.1-01 Power Meter Calibration).
           b. Return the new port power meter to measurement mode.
           c. Turn all lights off in the testing environment, other than the signal being
              measured.
           d. Block the photo sensor from receiving any light from the signal.
           e. Adjust the “zero dial” so that the meter reads 0.00 when the sensor is in total
              darkness.
           f. Uncover the sensor (or signal depending on how the light source was blocked for
              step (d)).
           g. Set the horizontal and vertical angles on the Goniometer to the data point to be
              collected.
           h. Record reading in log book
           i. Repeat steps (d) and (h) until data has been collected for all 44 points as per ITE
              standards.



     Newport      POWER METER          Model 1815-C

                                             W mW uW 2                   20 uW mW W
                                                uW nW 200               200 uW mW W
                                                uW nW 20                  2 mW W kW

                                                            LOW POWER
                                                         LOW POWER W/ATTN
                                                            HIGH POWER
          POWER    CAL
                                  b                                               ZERO
                                               CAL ADJ
      I
      O                           a                                 d



   6) Using Template LED 3.3.3.X-01

           a. In cell A2 enter the model and serial number of the signal being tested.
           b. In cell A4 enter the test date.
           c. In cell C6 enter warm up time in minutes.
           d. In cell H1 enter Researchers name.
           e. Under File drop down menu, choose Save As.
           f. Save file so that path leads to …\LED\3Testing\2Reports\XSpecific
              Manufacturer being Tested (i.e. 1Dialight)\1Data\(X)Year Test Preformed
              (i.e. (4)2004)
           g. Title file Next_report_number-version Color and Serial or Model number (i.e.
              6_01 Yellow 446-0235)


                                              95
                                            Progress Report No.2: April 2004 – June 2004


h. Click OK to save.

i. In cell C7 enter the perpendicular distance between the sensor and the signal
   being measured in feet. This distance was measured during the alignment
   process in step (?)
j. In cell A16 enter the peak wavelength found in the chromaticity test (LED
   3.1.2.3-02 Chromaticity Measurement)
k. In cell E16 enter the relative sensitivity factor calculated during the chromaticity
   test (LED 3.1.2.3-02 Chromaticity Measurement) from chart (LED 4.3.2-01
   Luminous Relative Sensitivity)
l. In cells C20 through C41 enter the power meter readings for the corresponding
   angles to the left in watts.
m. In cells C45 through C66 enter the power meter readings for the corresponding
   angles to the right in watts.




                                    96
                                                           Progress Report No.2: April 2004 – June 2004




Attachment D: LED 3.1.2.5-02 Secondary Real World Intensity
                             Measurement Procedures
         In testing the light emitting diode (LED) traffic signals, ITE standards call for a minimum
of a thirty minute warm up period. While this procedure is functional in a laboratory setting, it is
not an accurate depiction of how the LED signal will perform in the field. In an intersection, the
signal will not be allowed a warm-up period. In fact, the signal will continually move from power
on to power off as the set of signals controls the flow of traffic at the intersection. Due to this fact,
a set of testing procedures was developed to more accurately capture the “Real World”
performance of the LED signal. The Real World testing procedure differs between red and green
signals and yellow signals due to their difference in performance in a working intersection. For
further explanation and justification of the chosen time schedule, see LED 7.2.X-0X “Real World
Test Timing Schedule”.


D) Warm Up and Testing Environment Preparation for Green, Yellow and Red Signals

    11) Power on the Newport Power Meter and allow it to warm-up for 15 minutes.

    12) Record time in log book.

    13) Record the temperature and humidity of the test environment in log book.

    14) Ensure that the test environment may be completely blacked-out. (i.e. the only source of
        light in the test environment should be the signal being tested)



E) Alignment for Green, Yellow and Red Signals

**NOTE** This step is crucial and should never be omitted or assumed to be correct.

    7) Squaring the Goniometer:

           a. Measure the distance from the wall to both sides of the back of the Goniometer.
           b. Measure the distance from the wall to both sides of the side of the Goniometer.
           c. Using a level, set the angle measurement so that the vertical mobile portion of the
                Goniometer is perpendicular to the surface of the table when the angle reads zero.
           d. Using a level, set the angle measurement so that the horizontal mobile portion of
                the Goniometer is flush with the frame of the Goniometer when the angle reads
                zero.
    8) Setting the photo sensor

             a. Measure the distance from the floor to the center of the signal (height).
             b. Match the height of the signal to the height of the sensor (measured from the
                floor to the center of the sensor).
             c. Measure the perpendicular distance from the wall to the center of the signal
                (vertical distance).




                                                   97
                                                      Progress Report No.2: April 2004 – June 2004


           d. Match the vertical distance of the signal to the vertical distance of the sensor
              (measured from the wall to the center of the sensor such that it is a perpendicular
              distance).
           e. Measure the perpendicular distance from the center of the signal to the center of
              the sensor. (Make sure that this distance is at least 25 feet.)



F) Intensity Measurements for Green and Red Signals

   7) Intensity Testing with the Newport Power Meter

           a. Set the new port power meter to calibration mode and turn the dial until the
              readout matches the determined calibration factor (Factor was calculated from
              the measured peak wavelength in the chromaticity test [procedure found LED
              3.1.2.3-02 Chromaticity Measurement Procedures] and was found on the chart
              LED 4.3.1-01 Power Meter Calibration).
           b. Return the new port power meter to measurement mode.
           c. Turn all lights off in the testing environment. (Note: the signal should not be on
              at this time!)
           d. Adjust the “zero dial” so that the meter reads 0.00 when the sensor is in total
              darkness.
           e. Set the horizontal and vertical angles on the Goniometer to the first data point to
              be collected.
           f. Turn signal on and allow it to remain for one minute before recording data.
           g. Record reading in log book.
           h. Set the horizontal and vertical angles on the Goniometer to the next data point to
              be collected.
           i. Turn signal off and allow it to remain off for one minute.
           j. Repeat steps (f) through (i) until data has been collected for all 44 points as per
              ITE standards.




     Newport      POWER METER          Model 1815-C

                                             W mW uW 2                   20 uW mW W
                                                 uW nW 200              200 uW mW W
                                                 uW nW 20                 2 mW W kW

                                                            LOW POWER
                                                         LOW POWER W/ATTN
                                                            HIGH POWER
          POWER    CAL
                                   b                                              ZERO
                                               CAL ADJ
      I
      O                            a                                d




   8) Using Template LED 3.3.3.X-01


                                               98
                                                        Progress Report No.2: April 2004 – June 2004



           a.   In cell A2 enter the model and serial number of the signal being tested.
           b.   In cell A4 enter the test date.
           c.   In cell C6 enter none.
           d.   In cell H1 enter Researchers name.
           e.   Under File drop down menu, choose Save As.
           f.   Save file so that path leads to …\LED\3Testing\2Reports\XSpecific
                Manufacturer being Tested (i.e. 1Dialight)\1Data\(X)Year Test Preformed
                (i.e. (4)2004)
           g.   Title file Next_report_number-version Color and Serial or Model number (i.e.
                6_01 Yellow 446-0235)
           h.   Click OK to save.
           i.   In cell C7 enter the perpendicular distance between the sensor and the signal
                being measured in feet. This distance was measured during the alignment
                process in step (?)
           j.   In cell A16 enter the peak wavelength found in the chromaticity test (LED
                3.1.2.3-02 Chromaticity Measurement)
           k.   In cell E16 enter the relative sensitivity factor calculated during the chromaticity
                test (LED 3.1.2.3-02 Chromaticity Measurement) from chart (LED 4.3.2-01
                Luminous Relative Sensitivity)
           l.   In cells C20 through C41 enter the power meter readings for the corresponding
                angles to the left in watts.
           m.   In cells C45 through C66 enter the power meter readings for the corresponding
                angles to the right in watts.


D) Intensity Measurements for Yellow Signals

   1) Intensity Testing with the Newport Power Meter

           n. Set the new port power meter to calibration mode and turn the dial until the
              readout matches the determined calibration factor (Factor was calculated from
              the measured peak wavelength in the chromaticity test [procedure found LED
              3.1.2.3-02 Chromaticity Measurement Procedures] and was found on the chart
              LED 4.3.1-01 Power Meter Calibration).
           o. Return the new port power meter to measurement mode.
           p. Turn all lights off in the testing environment. (Note: the signal should not be on
              at this time!)
           q. Adjust the “zero dial” so that the meter reads 0.00 when the sensor is in total
              darkness.
           r. Set the horizontal and vertical angles on the Goniometer to the first data point to
              be collected.
           s. Turn signal on and allow it to remain for ten seconds before recording data.
           t. Record reading in log book.
           u. Set the horizontal and vertical angles on the Goniometer to the next data point to
              be collected.
           v. Turn signal off and allow it to remain off for one minute.
           w. Repeat steps (f) through (i) until data has been collected for all 44 points as per
              ITE standards.




                                                99
                                                    Progress Report No.2: April 2004 – June 2004


       x. When entering the measured data into the appropriate template (LED 3.3.3.X-01)
          be sure to enter the relative sensitivity factor found in the chromaticity test in the
          appropriate spot.



 Newport      POWER METER            Model 1815-C

                                           W mW uW 2                    20 uW mW W
                                               uW nW 200               200 uW mW W
                                               uW nW 20                  2 mW W kW

                                                          LOW POWER
                                                       LOW POWER W/ATTN
                                                          HIGH POWER
      POWER     CAL
                                b                                                ZERO
                                             CAL ADJ
  I
  O                             a                                  d




9) Using Template LED 3.3.3.X-01

       a.   In cell A2 enter the model and serial number of the signal being tested.
       b.   In cell A4 enter the test date.
       c.   In cell C6 enter none.
       d.   In cell H1 enter Researchers name.
       e.   Under File drop down menu, choose Save As.
       f.   Save file so that path leads to …\LED\3Testing\2Reports\XSpecific
            Manufacturer being Tested (i.e. 1Dialight)\1Data\(X)Year Test Preformed
            (i.e. (4)2004)
       g.   Title file Next_report_number-version Color and Serial or Model number (i.e.
            6_01 Yellow 446-0235)
       h.   Click OK to save.
       i.   In cell C7 enter the perpendicular distance between the sensor and the signal
            being measured in feet. This distance was measured during the alignment
            process in step (?)
       j.   In cell A16 enter the peak wavelength found in the chromaticity test (LED
            3.1.2.3-02 Chromaticity Measurement)
       k.   In cell E16 enter the relative sensitivity factor calculated during the chromaticity
            test (LED 3.1.2.3-02 Chromaticity Measurement) from chart (LED 4.3.2-01
            Luminous Relative Sensitivity)
       l.   In cells C20 through C41 enter the power meter readings for the corresponding
            angles to the left in watts.
       m.   In cells C45 through C66 enter the power meter readings for the corresponding
            angles to the right in watts.




                                            100
                                                    Progress Report No.2: April 2004 – June 2004



Attachment E: LED 2.3.4.2-01 TERL Video Presentation LED
                                           Script


   I. PART ONE: OUTLINE

           A) Video Images To Be Captured:
                    a) Intersection Signals
                             Sunny Morning
                             Sunny Afternoon
                             Clear Dusk
                             Rainy Day
                             Night

                    b) Other Highway Shots
                            Working DMS Signal Day
                            Working DMS Signal Night

                    c) In Lab Testing
                            Primary with Photo Research (Signal)
                            Primary with Photo Research (DMS)
                            Secondary with Power Meter (Signal)


           B) Still Photo Slides to be Used:
                      Commission Internationale de I‟Eclairage (CIE) standard observer chart


           C) Dialog Progression:
                    a) Mission Statement
                            Insuring compliance
                            Monitoring apparatus performance
                            Developing testing procedures and methods to support these
                            goals in the lab and in the field

       “The LED Signal Research Department has three main responsibilities; ensuring
apparatus compliance with relevant specifications, monitoring the long term performance
of an LED device, and improving upon and expanding the current testing methods.”

                    b) Background
                            Chromaticity Testing and compliance
                            Intensity Testing and compliance

       “There are many factors in the environment which may affect the performance of



                                            101
                                                      Progress Report No.2: April 2004 – June 2004


an LED traffic device. Extreme hot or cold weather, humidity or environmentally caused
corrosion may have adverse effects on the performance and lifetime of and LED traffic
device. The LED department at TERL tests and studies many of these potential hazards. In
any LED device, however, there are two main optical properties which must meet and
maintain specified standards regardless of the environment in which it will be used. First,
the chromaticity, or color, of the apparatus must fall with in a particular range. This task is
a bit more complex than you might think due to the fact that no two human observers will
observe color in the exact same way. The variation is due to inherent differences in the
structure of an individual’s eye. Because of this discrepancy, viewable color is commonly
expressed in terms of hypothetical averages modeled in the coordinate system utilizing the
Commission Internationale de I’Eclairage (CIE) standard observer chart. The CIE
standard observer chart specifies an x- and y-coordinate for each color. Chromaticity
standards are defined as narrow ranges of these x- and y-coordinates.
        “The second optical property which must be tested is the intensity of the apparatus.
LEDs are relatively unidirectional and thus the intensity of the signal must be tested for a
variety of viewing angles. Currently the Florida Department of Transportation follows ITE
standards for chromaticity and intensity and requires that the standard LED traffic signal
pass a forty-four point intensity test.”


                      c) Problems with the LED signal which make our work necessary
                          1) Visibility of apparatus in any weather condition
                                      Bright sun
                                      Rain
                                      Wind
                                      Fog
                                      Night

        “Why is it so important that LED devices not only meet but maintain such strict
standards? The most important reason is safety. By ensuring that all LED devices maintain
their specified chromaticity requirements, we are ensuring that drivers and pedestrians
alike will recognize a red traffic light as a red traffic light because the shade of red will be
the same whether in Miami or Pensacola. Subsequently, by initially testing and monitoring
the intensity performance of an LED device, we are ensuring the visibility of that device to
motorists and pedestrians in any weather, day or night.”


                      d) In lab procedure
                           1) Chromaticity Test
                                      Photo Research Spectral Analysis
                                      Gaussian Plot
                                      x-y coordinates
                           2) Primary Intensity Test
                                      Intensity Readings
                                      Automation
                           3) Secondary Intensity Test
                                      Power Readings
                                      Conversion
                           4) Goiniometer
                           5) DMS Sign



                                              102
                                                      Progress Report No.2: April 2004 – June 2004


        “Both intensity and chromaticity testing preformed in the lab is carried out using
the Photo Research Spectro-Scan 650. In the current set-up of the LED testing facilities, the
Photo Research and the LED signal are placed 60 feet apart. The Photo Research and the
signal are aligned so that the Photo Research is measuring only the light being emitted from
the signal in question. Once the alignment is correct, testing parameters are entered so that
the SpectroWin software will gather the appropriate data. Next the correct horizontal and
vertical test angles for the signal are set on the goiniometer. When everything is in place, the
measurement is initiated. This process is repeated for all forty-four critical points. The
chromaticity x- and y-coordinates, peak wavelength information and intensity readings are
stored as an individual text file for each point tested. The results of the Photo Research
intensity test can be verified by performing a second forty-four point intensity test using a
photo sensor and Newport power meter.
        “While these tests provide the necessary data to determine if a new LED device
meets FDOT’s minimum requirements for field use, our ultimate goal is that these testing
procedures be modified so they maybe used to monitor LED devices in the field as well as in
a laboratory environment.”
        “Why is it so important that LED devices not only meet but maintain such strict
standards? The most important reason is safety. By ensuring that all LED devices maintain
their specified chromaticity requirements, we are ensuring that drivers and pedestrians
alike will recognize a red traffic light as a red traffic light because the shade of red will be
the same whether in Miami or Pensacola. Subsequently, by initially testing and monitoring
the intensity performance of an LED device, we are ensuring the visibility of that device to
motorists and pedestrians in any weather, day or night.”




                                              103
                                                          Progress Report No.2: April 2004 – June 2004



PART TWO: SCRIPT

Opening Image: ?
        “The LED Signal Research Department has three main responsibilities; ensuring
apparatus compliance with relevant specifications, monitoring the long term performance of an
LED device, and improving upon and expanding the current testing methods.”


Image: Traffic Signals at a large intersection in the rain or fog or snow
     (some sort of less that satisfactory weather condition maybe more
     than one shot)
        “There are many factors in the environment which may affect the performance of an LED
traffic device. Extreme hot or cold weather, humidity or environmentally caused corrosion may
have adverse effects on the performance and lifetime of an LED traffic device. The LED
department at TERL tests and studies many of these potential hazards. In any LED device,
however, there are two main optical properties which must meet and maintain specified standards
regardless of the environment in which it will be used.


Image: Traffic signal fully illuminated (in lab shot of red, yellow and
     green signals) moving to a DMS sign in lab.
First, the chromaticity, or color, of the apparatus must fall with in a particular range. This task is a
bit more complex than you might think due to the fact that no two human observers will observe
color in the exact same way. The variation is due to inherent differences in the structure of an
individual‟s eye. Because of this discrepancy, viewable color is commonly expressed in terms of
hypothetical averages modeled in the coordinate system utilizing the Commission Internationale
de I‟Eclairage (CIE) standard observer chart.


Image: CIE standard observer chart
The CIE standard observer chart specifies an x- and y-coordinate for each color. Chromaticity
standards are defined as narrow ranges of these x- and y-coordinates.



Image: Series of same colored signals at visibly different intensities
        “The second optical property which must be tested is the intensity of the apparatus. LEDs
are relatively unidirectional and thus the intensity of the signal must be tested for a variety of


                                                  104
                                                         Progress Report No.2: April 2004 – June 2004


viewing angles. Currently the Florida Department of Transportation follows ITE standards for
chromaticity and intensity and requires that the standard LED traffic signal pass a forty-four point
intensity test.”


Image: Series of intersection shots from different angles (simulating views
     from different lanes of traffic) Day and night shots. (Intersection
     includes signal and pedestrian signal as well as DMS if applicable)
         “Why is it so important that LED devices not only meet but maintain such strict
standards? The most important reason is safety. By ensuring that all LED devices maintain their
specified chromaticity requirements, we are ensuring that drivers and pedestrians alike will
recognize a red traffic light as a red traffic light because the shade of red will be the same whether
in Miami or Pensacola. Subsequently, by initially testing and monitoring the intensity
performance of an LED device, we are ensuring the visibility of that device to motorists and
pedestrians in any weather, day or night.”


Image: In lab testing making sure dialogue corresponds to appropriate
     portion of the testing process and device being described
         “Both intensity and chromaticity testing preformed in the lab is carried out using the
Photo Research Spectro-Scan 650. In the current set-up of the LED testing facilities, the Photo
Research and the LED signal are placed 60 feet apart. The Photo Research and the signal are
aligned so that the Photo Research is measuring only the light being emitted from the signal in
question. Once the alignment is correct, testing parameters are entered so that the SpectroWin
software will gather the appropriate data. Next the correct horizontal and vertical test angles for
the signal are set on the goiniometer. When everything is in place, the measurement is initiated.
This process is repeated for all forty-four critical points. The chromaticity x- and y-coordinates,
peak wavelength information and intensity readings are stored as an individual text file for each
point tested. The results of the Photo Research intensity test can be verified by performing a
second forty-four point intensity test using a photo sensor and Newport power meter.


Image: Final shots of LED traffic devices in the field
         “While these tests provide the necessary data to determine if a new LED device meets
FDOT‟s minimum requirements for field use, our ultimate goal is to modify these testing
procedures so they maybe used to monitor LED devices in the field as well as in a laboratory
environment.”


                                                 105
                                       Progress Report No.2: April 2004 – June 2004



Attachment F: Work In Progress
         1) Real World Timing Testing and Study

         2) Up-Dated Chromaticity Testing Procedure

         3) DMS Chromaticity and Intensity Testing Procedures

         4) General LED Lab Manual
              Compilation of all the up-dated procedures with corresponding
                 flow charts, diagrams and explanations

         5) Light Tunnel Experimentation
               Testing will be preformed to determine:
                      Photo Research dependence on small alignment angles
                      Signal warm-up time
                      Real World signal cycle time




                               106

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:83
posted:8/12/2011
language:English
pages:108
Description: Research Papers Java Syntax Evaluator document sample