Appendix A: Interview Questionnaire
| Question | Response | Remarks / Analysis / Action Items |
|---|---|---|
| 1.1 Is the standard suitable and does it contain all elements/features that would be usable by end users? Is there anything that's not specified? | LEDSTAR: Very suitable. Addresses lots of shortcomings from the first standard. Not Covered: Auxiliary (Trigger) inputs, standard says outside of scope of standard at this time. – Version 2 allows for better usage of LED technology as opposed to original around ’96. – Certain types of signs not well addressed by standard like hybrid signs, speed limit + small DMS. |
No Findings. |
| Question | Response | Remarks / Analysis / Action Items |
|---|---|---|
| 2.1 Are the standards clear and unambiguous? | IBI Group: It contains all the information for a user developing central software. It's too lengthy and there are references that need to be referred to back and forth. There is so much data and what may seem like a simple sentence actually contains more information than it should. This was discovered during several iterations of the development. There is much more to a “single statement”. Structure of the standard could be improved. | No Findings. |
| Question | Response | Remarks / Analysis / Action Items |
|---|---|---|
| 3.1 Do the standards promote interoperability/interchangeability? | Trevilon: Met well by consistent interface – Complexity of running the signs/ putting tests in place – Comments that were generated as a whole part of the effort. Even features that weren't employed. LEDSTAR: Use of standard contributes positively. But still ambiguity's and areas left to interpretations. |
No Findings. |
| 3.2 Does implementation of standards benefit in sign making technology? | LEDSTAR: Yes, without that we would have a different standard and different sign for every DOT. DOTs realize benefit of standards because it gives them flexibility in vendors of signs. | No Findings. |
| Question | Response | Remarks / Analysis / Action Items |
|---|---|---|
| 4.1 Are the standards effective in supporting DMS functionality? | LEDSTAR: Designed to encompass many different sign types and vendors as well as looking to the future. So what may be a basic DMS, there might be a lot of controls in the multi or objects that is not necessarily need support but they are there for future usage or more advance features like color signage or graphics (which is not required by most DOT's for roadway signs). More forward thinking features. IBI Group: By far more than we can implement. It provides us with additional functionality that we can provide clients |
No Findings. |
| 4.2 What area could messages/dialogs/objects be added or changed to improve the effectiveness of the standards? | IBI Group: Better description of the Scheduling. Global Definitions of the Scheduling in the Day Plans and how it works and how tables interact with each other. Three different tables for scheduling Action Items – didn't realize how they interact with each other and how they worked – could have better information regarding this. | No Findings. |
| Question | Response | Remarks / Analysis / Action Items |
|---|---|---|
| 5.1 Are there any tasks you would like to accomplish, but can not using the standards? | IBI Group: No – the standard had everything. It had more functionality than what they would have thought of using. | No Findings. |
| 5.2 Were there any areas of the standards regarding their purpose or implementation that were not understandable? | IBI Group: There is a section on diagnostics – there are different levels of diagnostics and without understanding the levels, the data looks redundant. More description would help this area. | No Findings. |
| 5.3 Were there any messages or elements of the standards that were open-ended or could be interpreted in more than one way? | IBI Group: There were some and these have been documented. | No Findings. |
| 5.4 Were there any cases where you increased or decreased the range of any data elements or enumerations in the standards? Why? | IBI Group: No. | No Findings. |
| 5.5 Were there any cases where you changed the array size of any data array elements in the standards? | IBI Group: No. | No Findings. |
| 5.6 Were there any cases where you changed the data type of any data elements in the standards? Why? | IBI Group: No. | No Findings. |
| 5.7 Were there any cases where you did not implement a data frame/element that was required by the standard? Why? | IBI Group: No. | No Findings. |
5.8 Were there any areas of the standards where you needed or sought guidance or clarification?
What technical assistance did you receive in interpreting the standards? |
IBI Group: Asked Trevilon questions relating to missing data in humidity sensor table. Objects referenced in it were missing. Also asked questions on the new standardized dialogs and its Interpretation. | No Findings. |
| 5.9 Did the use of the ITS standards simplify your life cycle process for requirements, design, build, evaluate and deploy? | IBI Group: Yes. By the way it's set up, the client can select user needs and the needed functionality can be implemented. | No Findings. |
| 5.10 Are there any areas of the standard that seem either deficient or out of scope of its purpose? | IBI Group: No. | No Findings. |
| 5.11 Do you feel that there were any programmatic, technical or operational impacts on you (positive or negative) because of the use of the ITS standards? | IBI Group: No. | No Findings. |
| 5.12 Did you adapt your operational needs to the standards? Were adaptation recognized as having a positive or negative effect? | IBI Group: Yes. There is much more we can now offer to the clients | No Findings. |
| 5.13 Did you implement 100% of the requirements stated in the VDOT PRL? | IBI Group: Yes. | No Findings. |
| 5.14 Were there any challenges to implementing specific requirements for the VDOT PRL? | IBI Group: See report on inconsistencies on variable tables and supplemental mandatory and optional requirements. | No Findings. |
5.15 During the testing of the central software testing, we noticed that IBI Implemented Standardized and Non-Standardized Interfaces – Standardized Dialogs are those that are defined by NTCIP – Non-Standardized – Those that address Typical User functionality |
IBI Group: Standard Dialogues – Simple and Complex. Main interpretation problem for simple dialogs was not in the section labeled “dialogs” – SNMP gets and sets. Definitions for specific complex dialogs – One set can get multiple objects in a single “get”. But IBI group implemented 5 packets for 5 objects. 60% Non-standardized, 40% Standardized. Standardized dialogues are only way to test compliance for NTCIP | No Findings. |